On Sat, Jun 14, 2008 at 1:40 PM, Norman Maurer <[EMAIL PROTECTED]> 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 <[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 ....
+1 >> > 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 :-) > > > >> 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. +1 >> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
