james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Two builds [was: Re: Embedding James in a Java application]
Date Sat, 14 Jun 2008 12:16:37 GMT
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> 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.
>> 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.

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

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.


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

View raw message