directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Maven Builds
Date Tue, 29 Aug 2006 07:03:39 GMT
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

Mime
View raw message