On Dec 30, 2008, at 8:16 PM, Alan D. Cabrera wrote:
I've mentioned it before but will repeat it again here so as to avoid the earlier unproductive thread. The touchpoint of ASF projects is the code not the release JARs and WARs. One of the priorities is to make things easy to grasp and transparent for new and potential community members not just keep the status quo of the original developer group.
I definitely believe that, but I think everyone is bringing their biased opinion to the table. The simplified issue here is flexibility vs consistency/convention. Ant+Ivy offers much more flexibility, whereas Maven is very consistent and does things the "Maven-way". Ant's flexibility can be abused, just as any flexible system can be - but I think it can easily be argued that JSecurity isn't abusing it. It's current build is pretty standard and simple.
I don't think it's fair to say that the Maven solution is the only consistent approach though - even using Ant, we're following approaches that have been the Java industry-standard for many, many years. We have a docs, samples, src, support, and test directory. Nothing difficult to grok there. We pull dependencies into a lib directory...ok, pretty standard. We create a "build" directory that contains pre-processed and compiled files that are being prepared for artifacts.
Is this the Maven way? No, not exactly. Is it consistent? Uh, yeah - I've seen a million Java projects setup this exact way for the past 8 years or so. It's a slightly "flatter" directory structure than the standard Maven structure, and to some contributors that matters, to others "who cares".
I think there are a lot of smart people on this list, and throughout the Java community - some prefer Ant+Ivy, some prefer Maven, some prefer more cutting edge build systems like buildr or gradle. I think there are pros and cons to every approach, and it's valid for us to discuss those, but ultimately this is going to boil down to how people value flexibility in handling cases that Maven doesn't handle automagically vs. how they value consistency with other projects that do things the Maven way.
Jeremy
