5 messages in org.apache.james.server-devRe: Two builds [was: Re: Embedding Ja...
FromSent OnAttachments
Stefano BagnaraJun 14, 2008 5:16 am 
Norman MaurerJun 14, 2008 5:40 am 
Robert Burrell DonkinJun 15, 2008 5:29 am 
Bernd FondermannJun 15, 2008 7:18 am 
Stefano BagnaraJun 16, 2008 2:59 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: Two builds [was: Re: Embedding James in a Java application]Actions...
From:Stefano Bagnara (apa@bago.org)
Date:Jun 14, 2008 5:16:14 am
List:org.apache.james.server-dev

I'm moving to dev because we are OT in the user list.

Bernd Fondermann ha scritto:

On Fri, Jun 13, 2008 at 9:39 AM, Stefano Bagnara <apa@bago.org> wrote:

Bernd Fondermann ha scritto:

On Thu, Jun 5, 2008 at 10:05 AM, Stefano Bagnara <apa@bago.org> wrote:

nodje ha scritto:

hey thanks

I haven't open the documentation yet but thanks to Maven I have been able to compile the whole stuff. spring-integration wouldn't compile on it's own though. Some missing dependencies - or repository issue.

I committed fix to poms yesterday, please try again with the latest version.

We are going long ways to maintain two build tools. I'd suggest we better point our users to the ant build and not turn people away early because they try to use maven and fail.

Bernd

If you look at the thread I already suggested him to use ANT but he decided to use maven anyway. So I preferred to take the opportunity to fix the maven build (we needed this action anyway for our website build).

In my answer I never used the maven word and here is a quote from what I suggested him:

If you checkout the whole sources for trunk and run "ant" on the root it will build also the spring-deployment packages.

Yes, I know. I can read ;-) The point is: Having two build tools means, changing one build probably breaks the other one. We did not yet agree to maintain both (except for using maven for docs). The nightly build for example does not check the maven build. But having a broken build is bad for those innocent folks trying to use it.

I committed myself to keep updating the maven build and an almost complete maven configuration is needed if you want to create maven reports for the website.

But I'll stop doing this as no one asked me this. If needed the PMC will find consensus and will ask me to work on that.

But there is another aspect. AFAIK, maintaining a complete maven build is not consensus in the team. This thing appears to be sneaking in. It is better to try to have an open discussion about that instead of silently acting upon it. That's also why I bring it up.

I don't have problem with this: I thought that I was doing something harmless, but updating the maven build for a version I'm no more using is a waste of time for me, so I was doing this for the community, for our website and because I thought I was the more indicated person for that work (Not that I have any special skill: simply because I created the maven website/build in the first place, I better know where to tweak it). So there is no real reason to keep doing a work that I don't need to do and some PMC member think is harmful.

I think it is vital for Apache projects to not depend on remote repositories to be available to make builds work and to have all dependend libraries in the project's repository. Otherwise, some day, old builds will no longer work because of missing dependencies.

Apart from that, I do not prefer ant over maven.

Or to put it the other way round: I am +1 to switch to maven if I can do

svn co $TRUNK <switch off network access> rm -rf $LOCAL_MAVEN_REPOSITORY mvn => build succeeds <optional: switch on network access :-) >

Bernd

The local stage folder is there to solve this: but maven plugins are downloaded from the net. We could even place maven plugins in the stage folder, but this will increase a lot the size.

If you don't want to mantain maven you will have to find another way to build the website with ant. Until we miss this step in the ant build I thought we had to mantain the maven build, too.

FYI our ant based build for jsieve does not comply with your requirement above because after an svn co $TRUNK you will have to manually download javacc, javamail and activation jars.

Stefano