On Dec 26, 2008, at 3:33 PM, Les Hazlewood wrote:
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.
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.
Can you explain the exotic customizations that we would require in
this project that can only be solved with Groovy?
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.
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?
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.
Which, as far as I can see we won't 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.
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.
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?
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.
Good idea. I was thinking that this was where you were headed with
this. We should start a discussion with the community about this.
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.
Maven can also handle this quite cleanly w/out your verbose Ant scripts.
IMO this issue is orthogonal to the
Gradle discussion.
Agreed.
Regards,
Alan
