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 <[EMAIL PROTECTED]> wrote: > >> Bernd Fondermann ha scritto: > >>> On Thu, Jun 5, 2008 at 10:05 AM, Stefano Bagnara <[EMAIL PROTECTED]> > >>> 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.
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> > > 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. > 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... Bye Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
