Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=YPO9fSRs2765Mzc7ta8aCqi1KqbSFXYVt9PPM3ut48il/qO0K83nLHnETmpKkcq21ayR18jrIT5AnQJcXLBAp0XbrQvgPKo9WsqvqAXJgCmbT77tcca4T5gGo03tu6rC2AwsJPuwfDX9MzaNrmMjiOSqxIH3NhTw7MlafQoL/4M=
  ;
Message-ID: <20060829175654.17303.qmail@web60724.mail.yahoo.com>
Date: Tue, 29 Aug 2006 10:56:54 -0700 (PDT)
From: Ole Ersoy <ole_ersoy@yahoo.com>
Subject: Re: Maven Builds
To: Apache Directory Developers List <dev@directory.apache.org>,
  elecharny@iktek.com
In-Reply-To: <44F3E6CB.4020907@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


--- Emmanuel Lecharny <elecharny@gmail.com> 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.


Time out.  OK - Suppose I create a project:

<artifactId>OleProject</artifactId>
<version>1.0</version>

And now version 1.0 of OleProject dependes on 

<dependency>SomeJar</dependency>
<version>1.0</dependency>

And Later I Upgrade OleProject to version 2.0,

<artifactId>OleProject</artifactId>
<version>2.0</version>

And this is built with version 3.0 of SomeJar 

<dependency>SomeJar</dependency>
<version>3.0</dependency>

So now the build automatically uses version 3.0 of
some jar.

That's configuration management / dependency
management right?


So if I control the repository that that has version
1.0 of SomeJar and 3.0 of SomeJar, I control
everything.


> 
> >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.


Indeed.


> 
> >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 :)


That some Day all repositories will be Equal!!


> 
> >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 


Ant Goodddd!!!


> 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 


Beer Gooddd!!


> 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
> 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com