Re: Maven Optimism
Re: Maven Optimism
- Subject: Re: Maven Optimism
- From: Chuck Hill <email@hidden>
- Date: Thu, 10 Jul 2008 10:50:49 -0700
On Jul 9, 2008, at 8:41 PM, Henrique Prange wrote:
Hi Chuck,
Chuck Hill wrote:
Hi Pierce,
On Jul 9, 2008, at 2:50 AM, Pierce T. Wetter III wrote:
I'm using this as a measure:
wc -l `find . -name "build.xml" -print` Build/build/build-*.xml
Build/build/generic.xml `find . -name "build.properties" -print`
`find . -name "*.patternset" -print` `find . -name ".classpath" -
print`
Because the problem as I've found with Ant is that the build
information is in all of those files, not just build.xml.
Lets place the blame where the blame belongs and make a more honest
comparison. This is most NOT an Ant issue. It is a WOProject /
build philosophy issue. The duplication between .classpath and
some of the files in woproject/ are a deficiency in the woproject
Ant tasks in that they currently can't use what is in .classpath.
Mike is working on fixing this.
Will Ant tasks rely on Eclipse .classpath file to build WO projects?
Can anyone explain a bit more about this subject?
I think Mike has covered that already.
Now, what does maven do for this? Unless it is reading
the .classpath file, it also has to somehow, somewhere duplicate
the information that Eclipse uses. Duplication is duplication.
And will Eclipse update the Maven information in the pom.xml when
a new framework is added? When a new jar is added to the project?
Or is that all manual pom fiddling?
Maven takes care of the project management. So, you only have to
change the POMs (as explained by Lachlan). This way, you can
generate configuration files for Eclipse, IDEA, Netbeans and any
other IDE you want (maybe you have to write a plug-in).
You can make the changes inside Eclipse with q4e or m2eclipse. These
plug-ins synchronize the Eclipse configuration after a change in the
POM.
That is an interesting way of doing it.
The rest of the patternsets are also not an Ant issue, but a design
philosophy in woproject (to not force a project layout).
Maven don't force a directory layout also.
My point was that using either Maven or woproject, if you want a
flexible layout you need to do more work. If you can accept a set
layout, your life is easier. It is not an Ant vs Maven issue as
Pierce was suggesting.
If you do use a project layout, as Wonder does, these can easily be
rendered unnecessary.
Finally, build.properties:
principalClass=
project.name=
customInfoPListContent=
eoAdaptorClassName=
webXML=
webXML_CustomContent=
classes.dir=
If Maven does not use these and does not have a parallel system,
then it has less flexibility. How would Maven handle it if the
package name for the Application were changed in Eclispe?
maven-wolifecycle-plugin use this file to generate the WOA package.
In fact, this plug-in also use the WOProject Ant Tasks for this
goal. :)
If you don't want to use the build.properties (or the maven-
wolifecycle-plugin), you can add that information on your POM using
properties and filtering the required resources on each build.
That is what I suspected. So Pierce is wrong to count those files
"against" Ant as both build system use them.
Chuck
Chuck
This makes it easier to use a single generic Ant build file, but
to some extent that's the whole point of maven in my mind. With
Ant, everything is so bloody explicit that you end up creating a
sort of virtual maven via Wonder's generic.xml.
To quote from "generic.xml":
2) to build your own projects that have the same layout as a
wonder project
So mvn/Wonder have the same approach. Standardize on a layout, so
that you can use the same build methodology everywhere. You use
the same recipe you get the same bread.
But I have to say, the ant build files are very complicated to
understand compared to the pom.xml files. In the past, I've found
that I end up having to grok all 1300 lines of Build/build/
build.xml and Build/build/generic.xml in order to debug the build
of one of my projects.
Second, the individual build files build way more projects:
macbook:Wonder ak$ find . -name build.xml|wc
67 67 2775
macbook:Wonder ak$ find . -name pom.xml|wc
56 56 2121
You're looking at what you have, but I've rewritten all of those
and added new ones. I have files to build nearly everything in
Wonder on my system:
sierramadre:Wonder pierce$ find . -name pom.xml | wc
68 68 2440
Thirdly from what I've seen, someone needs to change all these
files whenever we bump a version. All of Ulrichs commits so far
where these xml fixes. All *I* need to do is set one property.
I'm using a property in my pom.xml versions as well. So changing
all those files isn't really necessary, I can change the version
by changing the master pom.xml, same as you can. Eventually, I'll
move all the jar references up to the master pom, which will save
me a line per reference, and standardize the versions used.
Fourth, adding a project typically requires five lines in Build/
build/build.xml to add it to the correct group and some props. I
might consider moving these props from the build file to a
build.properties and making Build/build/build.xml only specify
the inter-related deps.
Except you have to add the build dependencies somewhere as well,
which if you want to compare apples/oranges, you really have to
count right? You also have to count the information in
build.properties. The information in the pom.xml file for a new
project without dependencies is more then 5 lines, its like 10
lines, but 5 of those name the project so you can reference it
elsewhere and the other 5 reference the super-pom.
I'll grant you one point for the commons-logging versions, but I
use neither ERJGroups or EROpenID. If I were and I'd be bothered,
I'd figure out a way to keep them using only one.
It's not just that jar. WO uses commons-logging as well. The real
point here is that managing jar dependencies sucks. I know you
feel criticized but you shouldn't take it personal because I'm
talking about Wonder as my real point is that Wonder, which is
widely used, and considered pretty stable, has some jar dependency
issues. The solution to the jar problem that Wonder uses is the
ERJars framework for common jars, and Libraries directories for
unique jars, but that doesn't really solve the problem unless
someone with Obsessive-Compulsive-Disorder dedicates their life to
keeping ERJars in sync. Even then, what if you want some
frameworks and not others from Wonder, or you need the same (but
newer version) jar in one of your applications.
The maven solution is to document the dependencies, and setup a
whole bunch of infrastructure in order to be able to compute all
that stuff on the fly.
Again, you use the same recipe you get the same bread;
conceptually, ERJars functions as a maven repository, just one
manually maintained.
Having had to fight with a whole bunch of jar dependency issues in
production recently, I'm leaning more towards the maven way; as
opposed to trusting that every engineer will dutifully scour all
the other Libraries directories in all the other projects to see
what's needed where. Or even that I'll remember to push the
missing jar into production.
So far we've seen that maven is neither more terse nor more
powerful (at least in a way that would mean something to me).
I think maven makes a reasonable attempt to solve a really,
really annoying problem.
As far as terseness goes, perhaps that's not the right measure,
but generic.xml gives me the freaking willies, while pom.xml seems
stunningly obvious. I mean I really, really detest Ant build
files. I'd actually prefer regular make files.
The other issues I have with it is that I actually *need* the
flexibility in deployment structure. In some projects I *don't*
want all-embedded builds as that stuff goes out of hand with 7
apps*all the frameworks. The resulting release tops 250M. So I
want some of them embed only some jars. Show me how this works
with maven *without* writing any "goals" or "mojos".
Well, now you're bottoming out my maven knowledge, as I'm not
quite sure what you're complaining about.
So in summary, maven may or may not be nice. But I've been
building Wonder with the build files for 7 years now and they
haven't really changed a lot in this time. They do the roughly
the same as some 20MB tool chain where you *still* have to write
java plugins for.
And I have to maintain a build that's based on some stale snapshot
of the Wonder build files, and given a choice between grokking
generic.xml and or throwing it out and learning maven, I'm leaning
towards Maven, because its sucked so far. Of course, the latest
Wonder generic.xml looks a lot cleaner then what I have now, so
that's not necessarily a fair criticism. But maybe it is, because
I would never have dived into Wonder to tweak the Ant builds, but
tweaking the Maven builds was pretty simple.
But as I keep saying, you use the same recipe you get the same
bread. The Wonder Ant build and the Maven build at the end of the
day have to do the same steps and need the same information. Ant,
being more explicit, ends up pushing you towards a generic.xml
type solution, where every step in the build is spelled out
explicitly, but a certain folder layout is assumed, and certain
things are stored in external files. That way, you can use the
same Ant build script over and over.
Maven, being more implicit, ends up pulling the equivalent of
generic.xml into these plugin definitions based on the assumption
that all WO framework projects have to be built the same way for
all developers. That leaves the project specific information to be
specified somewhere like the project name and dependencies. Which
goes in one place, the pom.xml.
So at the end of the day, to use Wonder's generic.xml, you have to
setup your folder structure in a certain way and put certain
information in .classpath, .patternset, and .properties files. To
use maven, you have to setup your folder structure in a certain
way and put that same information in pom.xml. At the system level
you have to think of Ant as Ant plus the generic.xml you're using,
and at that point, Ant+Wonder Build Scripts == Maven. Maven just
goes on to leverage the information in the pom in other ways.
This title of this post is "Maven Optimism", following up from
"Maven Skepticism". I'm still a long way from being a maven
expert, but I've sort of refused to become an Ant expert. But so
far, I'm a lot more optimistic about being able to use Maven
effectively. I think it brings a lot to the table, and solves some
tough development issues.
Pierce
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden