> > So, you bring it up as an example of why we should avoid Maven and when I > point out that it might not be relevant you reply that it doesn't matter if > his problems would be encountered here. ??? Ok. >
Allan's problems are an indication of something that caused pain when using Maven. I'm saying that even though we might not experience the same problems, it doesn't matter - we might experience some kind of pain later if customization is needed when using Maven. I'd just assume avoid that possible pain entirely. > Can you explain the exotic customizations that we would require in this > project that can only be solved with Groovy? Nope, I can't - I can't foresee the future. But I'm claiming that the latest generation of build tools like Gradle, Buildr, and others are more capable and flexible while feeling more natural to customize (via scripting) if customization is desired. If there is something that handles both a declarative model _and_ very easy customization via script without XML - then sign me up. The 'if it ain't broke, don't fix it' mentality is not appealing to me - I'm naturally drawn to doing things more efficiently in a cleaner way if possible. At the very least, I want to investigate and try out these possibilities, which is why I emailed this list hoping to experience the same sort of desire. I think Gradle offers a good approach, and I was hoping others would be willing to try, that's all. There's nothing saying we can't revert back to Ant XML if we didn't like the new approach. I'm of course willing to try Maven the same way and see what we like best - this isn't a "define it in stone" issue... > Maven is all about convention over configuration. Again, can you provide > concrete examples of where we would need to support this kind of > customization complexity? I could only do that if I was equally skilled with Maven, which I'm not, so I can't answer this question. But IMO, declaration + inline scripting flexibility is way more powerful than only declaration in xml. It is a fundamental belief of mine that build scripts should not be XML based (I felt this way when Ant came out too). I don't think anyone who sees Ant if-else logic would disagree with me. Scripting with groovy is nice because it is there if we need it. I like that feeling of flexibility if we need it, that's all. >> >> I'm now using Gradle in a much larger corporate project and found the >> product to be quite stable and fun to use. Given that JSecurity has >> far less stringent time/budget issues (i.e. almost non-existent), this >> shouldn't be an issue for us. The #1 issue for me is that, in its >> current state, can it do everything that we want? I haven't found >> anything that makes me think otherwise, especially since you have >> direct access to Ant and Ivy if you need it. > > Which, as far as I can see we won't need it. Do you know that for a fact? I don't, which is why I'm more comfortable with a solution that allows me to do so if the need ever crops up. Its a safety net. All your eggs in one basket, etc... > >>> One of the arguments I have heard for the the use of Ant is to keep all >>> our >>> source code into a single directory. >> >> I think (I hope) this is a slight misunderstanding. At least my >> understanding of our argument is that I like that Ant doesn't require >> us to change our directory structure to match some convention - >> whatever directory structure that may be. I want our source to be in >> multiple directories - some segmentation would make sense. >> >> One of my complaints against Maven is, and I know people may not feel >> the same, that I can't stand Maven's directory layout. I take the >> simpler approach, for example, resources and source code are in the >> same directory. That way the dir tree maintains a 1:1 classpath >> correlation. I like this, it is clean to me. KISS and all that. > > Resources in the resource directory are passed through a preprocessor before > it's added to the final artifact. It allows for nice macro substitutions. > Very handy. I don't like to traverse directory trees to see this stuff. I don't like using the 'package' view - just my preference. > >> Also, I don't like traversing down 3 or 4 directories just to get to >> the root level package (src/java/main/org/blah/blah or whatever it >> is). Although of course my IDE supports 'modules' and Maven layouts >> such that I don't have to look at trees, I still like to have the >> 'master view' of my project open at all times, where I see the project >> root, and manually click down to whatever tree I need. The more >> directories, the more of a pain this is for *me*. I understand that >> this is specific to the way that I like to develop, but it is a factor >> influencing my vote nonetheless. > > I think that all IDEs provide a package view which provides the view that > you describe. Actually, the fact the actual location of the Java files > doesn't matter to me when I use my IDE. It's been a rare, very rare, day > where I have to actually run up and down those directory "stairs". I don't > understand why you have to do so. > > What IDE are you using? If it makes you do so much work maybe you should > consider a new one instead of making the project use an ad hoc directory > setup and Groovy scripts? Like I said, my IDE (IntelliJ 8.0) does indeed support what you say, but I personally don't like using 'package' view - it drives me crazy. I _like_ to see the entire project, as it exists in the directory tree, while I'm developing. I like to see the forest through the trees so to speak... So, the fewer the directories, the easier this is on me, my eyes, and the total number of button clicks that I have to make to get to what I want. Again, I said this is particular to the way *I* like to develop. I expect a tool to conform to my desires, not the other way around (if it is a good tool).
