I'm just a meager user, not a committer or anything...so I don't expect to add much but anecdotes...
I can say that when I started using J2 it was via the Maven1 build. I'd used Maven before, but never with anything that used it like J2. No offense, but people at my work who were unfamiliar with Maven1 (prior to M2) would ask me "well how can I do ___ with Maven?" I honestly found myself on more than one occasion telling them "well go look at the Jetspeed2 project" as it was one of if not the most extensive user of Maven features ranging from the multiproject plugin to pom inheritance to pre and post-goals that I'd seen. I think I agree with Roger - while the current build process may work, it is highly complex. I don't think that migrating to Ant will aid that at all. It will only change the syntax of the build code. I don't agree with "ant is simpler" arguments - because I can tell you I've spent my fair share of hours trying to figure out what large builds are trying to do, where they're doing it, and why. Ant's lack of project standardization is both its best feature for small projects and its most crippling drawback for maintaining large projects in my honest opinion. The whole purpose of the original Maven was to make it such that all Apache projects were structured and built in a standardized way. M2 was designed to reduce the flexibility and up-front ease that was present in M1 - but that's a good thing because it reduces the build process maintenence in the long run. An example of this is the removal of scriptable plugins and pre/post goals. I know some people in this thread have said things like "I don't know maven" and "the project should be easier for new people and people know ant" - but on the same token, look at the rest of Apache Java projects. A quick browse of the SVN and CVS repos seem to indicate that most projects are using either M1 or M2. Standardization across Apache projects (or at least amont sub-grouping like Portals or Commons) is a huge plus. I can't tell you how frustrating it was for me to start digging into log4j source. Sure it has an ant build, but it doesn't (or at that time didn't) handle retrieval or versioning of dependencies, etc. so I ended up spending a decent amount of time just setting up the build environment to make the project buildable as a whole That to me is a lot more frustrating to me as a non-committer user because there were only small parts of the code I was interested in (as I would think would be J2 non-committing users). As a side note, I notice that Pluto is using an M2 project approach, but I don't follow the Pluto lists so I wouldn't know of their migration experience. I guess I'd just advise that the J2 community decide upon the build philosophy of J2 *then* find a tool that is in-line with that philosophy. Maven (especially M2) is much more than just a build tool... and as such it specifies exactly what its philosophy is. If that doesn't align with that of the project (not limited to J2 and its subprojects) or its committers, then it's not the right tool and there will forever be friction. Regards, Scott Heaberlin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
