james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: Two builds [was: Re: Embedding James in a Java application]
Date Sun, 15 Jun 2008 12:30:14 GMT
On Sat, Jun 14, 2008 at 1:40 PM, Norman Maurer <norman@apache.org> wrote:
> 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 been
>> >>>>> able
>> >>>>> to compile the whole stuff.
>> >>>>> spring-integration wouldn't compile on it's own though. Some
>> >>>>> 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 :-) >
>> 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..

i'm agnostic. i'm grateful that stefano maintains the website and
since he prefers maven, that's fine by me.

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

IIRC we could include the jars but not the poms :-/

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

AIUI the current code has been relicensed but is awaiting a release

- robert

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

View raw message