On Dec 26, 2008, at 4:43 PM, Les Hazlewood wrote:
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.
Wha? First it does matter, then it doesn't, then it might but we're
not sure? I feel like I'm playing wack-a-mole here with the same
moles that were previously wacked popping back up.
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...
I'm seeing the same arguments here as we had when you we're trying to
cook up a custom logger wrapper. Lots of rhetoric and and a plea that
if we don't like it we can revert it back to the other way that you
want.
All of this, seemingly driven by contracts that you are working on.
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.
But in maven for this project there is no need for "scripting". The
POMs are crazy simple. You continuously bring the specter of
complexity and when I ask where it is your arguments trail off along
rhetorical lines.
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...
Safety net? Eggs in one basket? Wha?
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.
Traverse directories? You sound like Rocky, in your case Sisyphus, on
front steps of the Philadelphia Museum of Art. Really, I don't
understand how this trivial point is wagging the dog.
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).
You, you, you, you. You want to have things organized the way you
like it. You want the project built the way you want it with the
scripts that you build. All of this with a disregard of anyone else
new that has to come along and grok how you want to work. And here is
where I have an enormous amount of experience. If I had a nickel for
every cute way that a project thought the world should be building
things I would be able to pull this country out of its credit crisis.
At the ASF the touch point to the community is not the final JAR or
WAR. It's the code. Standardizing the organization of the project
has tremendous benefits such as ease of comprehension and visibility;
there's no value added in having people grok how Les Hazelwood likes
to develop with his irrational distain for directories.
I grow weary of trying to have discussions when all your "logical"
arguments all dwindle down to personal preferences.
Regards,
Alan
