Ole Ersoy a écrit :
Guys,
These build issues are really of our own "Choosing".
Well, yes. I have to agree. But the point is that Maven development have
been so intense those last two years (the switch from maven1 to maven 2
brought so tremendous improvment that I really can't understand how we
were able to live we m1 :) that we were left (and still are) without
any decent documentation.
Right now, M2 is usable, but really, some tricky problem need to be
fixed and be set as default. "Coosing" mean you know that you can
choose, and sorry, but the "documentation" is really the biggest problem
atm.
When a project is started, we can point maven to
repositories of our choice, or download all the
dependencies manually, build a maven repository
ourself, and then manage the updates of that
repository, so that we know of every change made to
it.
Let's do that. I have sent a mail 2 months ago suggesting that we have
to do exactly that.
The reason the maven repository is so useful is
because it communicates to anyone who wants to build
the project what the dependencies are and where they
can get them.
They are usefull - really - because you can grab the last one and bring
all the information regarding transitive dependencies. But this is
usefull only once : when you start using a version. However, the version
checking done by maven is *not* the best. It assumes that everybody use
the same notation. For instance, acme-20020825.jar is seens as newer
than acme-3.0.jar (let say that acme-3.0 was out last month). I'm ok
with that, but then you must have a way to get the control of the whole
process.
So if we want control we can have it, for both plugin
repositories and source repositories, right at the
start of the project and thereafter.
yeahhhhh !
If were using Ant - we'd have to tell everyone wanting
to do a build where to find the dependencies...
setup the class path, etc. etc. etc. and we could even
have the ant script download and setup a custom
repository and classpath, but then we all of a sudden
have Maven.
No. That's a misconception of what should be a build. When you are
building a product wich has versions, then whenyou do a checkout, you
*must* (I insist) download all the files, including all the jars, to be
able to build the exact version you want to build. So it's not a
question of using ant or maven, it's a question of being able to build a
version X reliably. That means versionning ALL the files. acme-3.0.jar
should be versionned and tagged with version 1.0 if it is used to build
version 1.0. If you build version 2.0, which use acme-4.0.jar, then this
jar has to be tagged as a member of this build. Maven bring *nothing* to
solve this issue. Maven bring a better structure and transitive
dependencies handling (and these are good thing), that's it. It's not a
way to solve configuration managment which is not handled.
If Maven had the checksum validation Emmanuel
mentioned when we listed ways to lock down the build
process, that's as good as it gets as far as
validating and using dependencies and plugins goes.
Yeah, I agree. But checksum validation is only good for people managing
maven repos. We are not managing them, we are using them. And in my
mind, we should only use them once, when we grab our initial jars.
If only we had a plugin that read the parent pom and
all the module poms, analyze them, and tell us where
we used the same dependency, but different version,
alerted us whenenver a plugin/dependencies checksum
changed without a version change, and created a report
detailing all of the automatically updated plugins /
dependencies - Bravo! We would be in primo condition
because the build be intelligent, and tell us when
something unexpected were about to happen, or when
something could go awry due to the configuration of
maven.
You had a dream :)
So theres obviously some room for improvement, but
Maven is a brilliant piece of work, and those
improvements are easy to do with Maven. We just need
some "Summer of Code" guys. Anyone got connections?
Maven may be a brilliant piece of software, but, sorry about that, I'm
not intelligent enough to just guess what it does when it goes wild.
Sorry to insist : we have lost 2 hours yesturday with ersin to just
understand what could be the problem with the build when it suddenly
broke because somebody modified a jar somewhere in one unknown repos. At
least, Stefano and other maven guru's helped us to find out a solution.
But I really see it dangerous when a tool need guru's to be used. We are
locked down. I never felt that with ant, and trust me, I'm not a Ant
guru (the less I have to deal with build system, the more happy I'm).
And please don't tell me that ant can't handle big builds, because I
just used it successfully to build a broject with 300 modules, 250
developpers, and the ant scripts were built in 2 weeks, and was handling
transitive dependencies, without the help of ivy. Here, the question is
not if we want to switch to ant, it's "how for christ sake can we have a
*RELIABLE* build with maven.
So let's find solution, because discussion about maven, ant, ivy,
./configure advantages are better in a bar with a lot of beers, and the
place to have them is Austin, october 9-13. Now we just want to have the
best possible maven build for ADS ;)
OK OK OK - I'll shatt up now and get to work on
analyzing where to apply our currently known
solutions.
Really kool!!!
Cheers,
- Ole
Thanks Ole :)
Emmanuel
