james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <nor...@apache.org>
Subject Re: Two builds [was: Re: Embedding James in a Java application]
Date Sat, 14 Jun 2008 12:40:48 GMT
Am Samstag, den 14.06.2008, 14:16 +0200 schrieb Stefano Bagnara:
> 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 <apache@bago.org> wrote:
> >> Bernd Fondermann ha scritto:
> >>> On Thu, Jun 5, 2008 at 10:05 AM, Stefano Bagnara <apache@bago.org>
> >>>> nodje ha scritto:
> >>>>> hey thanks
> >>>>>
> >>>>> I haven't open the documentation yet but thanks to Maven I  have
> >>>>> 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.
> >> Stefano
> > 
> > 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.

No please not stop ....

> > 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>
> > 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.

I think this is a "bad" idea. 

> 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.

Maven do a good job for site generation. I even like it more then ant
but that's maybe because I not looked to "deep" in ant functions..

> 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

Good point, but aren't we allowed to place the javamail and activation
jar in our svn tree ? I think we do the same on james-server.
And why we can't include javacc ? From the webpage it seems to be under
BSD-licence ( https://javacc.dev.java.net/ ). Maybe I miss something...


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message