>> Based on Allan's comments and my own exposure to Maven as well as >> Jeremy's input over time, I just prefer not to go down a road that >> might cause problems later. I want something that in concept works >> like Maven, but doesn't have the stigma of being difficult to deal >> with if you need to do something non-standard. Allan's and my >> experiences only further solidified that opinion. > > I've mentioned this before and I'm not sure anyone answered. Allan's > experiences are not relevant to this project. More specifically his > situation is not the same as the project's. For example, will not need to > write plugins for a legacy build environment. I, personally, have had > plenty of experience writing maven plugins and have not had the drama that a > few people claim to have. > > Again, not sure that his all relevant here.
>From my perspective, (just my opinion), I don't feel this is relevant. To me, it doesn't matter if his problems will be encountered here. It does matter to me that _if_ we encounter customization issues, I don't want to jump through hoops to solve the problem. I certainly don't want to have to find out that I might need to write a plugin for something so simple that I would feel I could just write a line of Groovy and be done with it. I don't know if we'll encounter that or not, but I feel 'safer' with something I have flexible/direct control over in a very simple manner just in case. >> Gradle sits on top of ant and ivy and adds some Maven features without >> getting in your way. It is the best of all 3 (IMO) because it wraps >> them and enables the power of each without restricting you Also, >> .gradle build scripts are just Groovy files, but with a bunch of >> domain-specific Gradle closures, which allows us to do anything Groovy >> can do. Ant and Ivy are first class citizens, allowing native usage >> if you want to. >> >> Gradle's default conventions are very similar (if not identical) to >> Maven, but it took me all of 4 lines of Groovy code to make overrides >> that match the directory structure of an existing large project that >> didn't (thank God) follow Maven's default directory layout. It was >> painless. >> >> So with Gradle (based on my admittedly limited experience), you get >> build-by-convention, without any pain when it comes to customization. >> It was a very pleasant experience. > > Hmm. Build by convention, where did I hear that term before? Like I said - great concept, poor execution. I like the idea, not Maven's approach. Gradle's approach is build-by-convention also but is much nicer IMO, and certainly dead easy to modify if necessary: Maven is declarative. So can Gradle be - using closures to mirror what Maven does in XML. But the biggest benefit of all is that you can use scripting logic to change or enhance the declaration model. Conditional logic based on environment, etc, directly in the build declaration. This is so much nicer than writing plugins or XML to write logic, I would hope that no one disagrees that having both in the same tool is a very nice capability. > >> Concerning buildr - I haven't looked at or used it, so I can't say yay >> or nay to it. At first glance, it appears to be ruby-based. I can't >> say enough about using a proper scripting language to perform >> customization or conditional logic - SO much easier than XML. But, >> given my choice, I'd gladly stick with Groovy, as it is so like Java, >> it took almost no time to learn. I don't use Ruby for anything else >> in my personal or professional projects, so I wouldn't want to bother >> with it just for a build system. Groovy is the way to go for existing >> Java developers IMO. >> >> So, my recommendation was just based on the experience that I had at >> work this week, and given that it was so pleasant, thought it would be >> nice to have the same feeling in JSecurity :) > > IMO, with gradle being at 0.5 it's a bit premature to jump on that band > wagon. 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. > 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. 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. > structure we currently have. It strikes me as organized on an ad hoc basis. > For example we jam the web and core source code in one directory and have > Ant extract the bits that are needed. Not only is there a lack of > transparency as to what is going on I'm wondering if there can be an > accidental circularity in their dependencies. I want to change this asap and isn't a function of our build environment - its just a matter of time changing the dir structure. > > So the web and core code is in one source directory but there echache, etc., > bits in a separate directory called support. Ecache seems to be stitched in > at the last second into the core jar. > > IMO, this all strikes me as very disorganized. I could, of course, have > misread this state of affairs. See it as "in flux" - the concept of how to break out the source code hasn't been fully implemented yet. For example, I would prefer to see a 'core' module, a 'web' module, a 'spring' module, etc. I just haven't done it yet, and wanted to wait until I got feedback on Gradle. So, if we were to change to a different build tool, we could do all the change at once to feel the least impact. But Ant/Ivy and our current build scrips can handle this no problem - we just have to change them. IMO this issue is orthogonal to the Gradle discussion. Best, Les
