On 18 December 2011 18:03, Phil Steitz <phil.ste...@gmail.com> wrote: > On 12/17/11 11:42 AM, Antonio Petrelli wrote: >> 2011/12/17 Mark Thomas <ma...@apache.org> >> >>> On 17/12/2011 18:35, Antonio Petrelli wrote: >>>> 2011/12/17 Mark Thomas <ma...@apache.org> >>>> >>>>> On 17/12/2011 18:14, Antonio Petrelli wrote: >>>>>> Ok then interprete my words as: now you can use a staging repository. >>>>>> This way, artifacts may be tested *before* they are released. >>>>> The scp+rsync process also has a staging repository (and using that did >>>>> not cause any meta-data issues). >>>>> >>>>> The JARs are the standard Tomcat JARs. The Maven release process just >>>>> adds the metadata files and moves the JARs + metadata around. Since the >>>>> JARs are already tested as part of the Tomcat release process, we never >>>>> had a need to use the staging repository and I don't see that changing. >>>>> >>>>> There is also a snapshot repository and we did use that early on in the >>>>> Tomcat 7 development process (before the first release) mainly because >>>>> one user who was doing a lot of testing was using Maven and the snapshot >>>>> repository was the easiest way to get them the latest build. We stopped >>>>> using the snapshot repository some time ago. I can't remember if it was >>>>> after the first release or after the first stable release. >>>>> >>>>> >>>> Ok then using Nexus makes sense only if you are going to use Maven for >>> all >>>> the release process (it's a matter of two commands and a Nexus stage >>>> promotion). >>>> I think that now you should change the subject into: why should you >>> switch >>>> to pure Maven build process? :-D (Joking, but not too much) >>> Yeah, that isn't going to happen :) >>> >>> I've seen way to much pain and grief with Maven on the Commons list to >>> ever want to even think about converting the Tomcat build process to Maven. >>> >> Commons? That's strange, they are only libraries. Probably they never had >> <cringe-mode-off /> a Maven wizard like me <cringe-mode-on />. > > We have several maven committers on the PMC and have been using > maven since the 1.x days. > > One thing we have learned is that maven builds require regular care > and feeding. We are on version 23 of the Commons Parent pom. One
That's partly due to Maven, but quite a few of those changes are due to new requirements, and updated plugins etc. Having a shared parent pom means more attention has to be paid to it and less to the component poms. So I don't think that's an entirely fair statistic. But I do agree that fixing Maven issues is generally a lot harder than fixing Ant issues. > statistic that I have often thought would be interesting to look at > is how much time (maybe proxied by number of metadata commits) is > spent maintaining maven vs Ant builds. I wonder if on net maven > saves time? The tomcat Ant build has been relatively stable > compared to the maven projects I know. Could be I am wrong, but I > bet tomcat has overall spent less time fussing with its build than > the average ASF maven project. In Commons, our success getting to > periods of stability (we are between stable points now) has depended > on having multiple deeply maven-knowledgeable people prepared to do > the work to keep component builds up to date with maven, > ASF/Sonatype infrastructure and plugin changes. If there are several > tomcat committers willing to step up to do this, then I am sure you > can get it to work. Otherwise, you are likely better off staying > with Ant. I'm inclined to agree here. I think Commons is somewhat different as it has many small components independently released. Maven enforces some conventions which mean the build processes tend to be similar across projects. Ant is more flexible and it would take a fair amount of work to ensure that all Commons components used standardised Ant build targets. Also Common components are libraries that are often consumed by other Maven projects. Tomcat is mainly a stand-alone download. I don't particularly like Maven - there's far too much built-in magic, which is not always properly explained - but it does have benefits in standardisation and (some aspects of its) dependency management. > Phil >> Seriously, if I have the time, I could fork Tomcat 7 from GitHub to try if >> I can change this situation. I already did it for Velocity (using SVN). The >> only difficulty is the website. >> >> Antonio >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
