Re: Re: Re: Maven integration and Orbeon dependency mess

>
> Hi Erik and Alex,
>
> Well, everything new does look complex? Does it? Maven is in fact a
> replacement for ant, and both use java. So, I wouldn't say you would  
> need
> 'new' tools or executables. Sure, you have to install maven, but for  
> ant
> you'd need a jar too! If something that can grow complex it would be
> configuring the build scripts for ant, especially regarding the  
> classpath
> (been there done that), and dealing with multiple artifacts. Maven  
> is far
> more better arranged. Ivy or anthill, is all wrapped around Ant. I  
> have no
> experience with those, but knowing it is based on Ant says enough  
> (for me).
> I forgot to mention Codehaus, which is another good reference. They  
> do all
> their open source projects in maven. In fact, maven is incubated  
> there.
>
> You say you've read problems with Maven 2, well, I can tell you  
> those are
> over! At start there were some child-diseases and lack of plugins,  
> the first
> are solved and the other is in abundance (and standarized). And if  
> needed,
> easy to write yourself.
>
> Yes, dependencies are sensitive. Especially when you're having  
> multiple
> projects and usually have copies of jars all over around. Thats  
> where the
> repository comes in. You don't need to have a repository, it already  
> is
> there! Maven uses a remote repository (or plural, using mirrors) and  
> a local
> one. The local one is on your local development environment, and all  
> your
> projects use that (when using Maven). Thats just one advantage of  
> Maven, a
> neat organized layout of jars. The other advantages weigh heavy as  
> well, but
> I am going to keep this post small. For more information I really  
> need to
> refer to the maven site itself.
>
> Osgi is the way to go, I agree here. But thats just a different
> specification which could co-exist easily (judging by glance).
>
> You mention, oh, its just a few Mb's. But it is a few Mb's  
> nonetheless. Not
> only in size, but likely in memory as well. Speaking of source,  
> binaries
> should not belong in there, they are derived from it. The only setup  
> is a
> single file called pom.xml, compared to the build.xml. Upgrading  
> third party
> software is changing a single digit (or two when its major)!
>
> What I can do, is to provide an example, of how Maven would deal  
> with the
> Orbeon build. Not only the pom.xml but also the different layout of  
> source
> files (which has a small impact compared to the situation now). For  
> that
> matter, I could setup a mirror, with sources matching the standard  
> followed
> by Maven and the build would deliver the same artifact, namely the
> ops-3.6.0.war. From there we could discuss it further?
>
> If I were to proceed on this, I'd require feedback regarding the  
> current
> source layout when looking at:
> http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/ops/
> As in, what would be the core and what is not needed?
>
> Regards,
> Mike
> --
> View this message in context: http://www.nabble.com/Maven-integration-and-Orbeon-dependency-mess-tp17203540p17257051.html
> Sent from the ObjectWeb OPS - Users mailing list archive at  
> Nabble.com.