directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Porter" <>
Subject Re: Maven Builds
Date Tue, 29 Aug 2006 07:10:13 GMT
Here is an explanation of the problem and how to make your build more

Basically it comes down to only using snapshot plugins when you really
really have to. Currently, too many projects are setting their default
builds to grab all the unstable plugins, which is obviously a receipe
for disaster.

We're certainly working to improve that story for future Maven releases.

I have now turned off, so the errors
should be a whole lot less subtle if it is still in use anywhere else

- Brett

On 29/08/06, Emmanuel Lecharny <> wrote:
> 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

Apache Maven -
"Better Builds with Maven" book -

View raw message