Maven integration and Orbeon dependency mess

>  When looking at the libraries used, I see alot jars without versioning (sure
>  you can investigate their manifest, but often those aren't correct, i.e.
>  with luck you get the version). Some of the jars are alterered, that is,
>  they contain patched files to support correct functionality (see saxon-8.8,
>  they contain org.orbeon packages and zero saxon packages). And, some of
>  these are renamed to reflect transitive dependencies which leads to more
>  confusement.
>
>  In my opinion, this is wrong. Upgrading becomes hard when you're not sure
>  what version you are using.

> Some of the jars are alterered, that is,
> they contain patched files to support correct functionality (see  
> saxon-8.8,
> they contain org.orbeon packages and zero saxon packages). And, some  
> of
> these are renamed to reflect transitive dependencies which leads to  
> more
> confusement.
>
> In my opinion, this is wrong. Upgrading becomes hard when you're not  
> sure
> what version you are using.

> Another observation is that I find 'conflicting' solutions/
> dependencies,
> where all in all, the whole lot becomes bloated? The lib directory is
> (rounded up) 50Mb.
>
> For example:
> - fop vs itext
> - dom4j vs jdom
> - saxon vs xalan
>
> This leads to the next question, what is minimal required to run  
> Orbeon?
> Meaning, what do I need to have for a clean and mean Orbeon (without  
> all
> examples and their required libraries). Less is more?

>
> Hi Erik,
>
> Well, as a solution you could migrate the build process to adopt  
> Maven. Alot
> open source projects are doing this (almost all Apache's for example).
> Recently, Cocoon is embracing this as well (look at their 2.2  
> release for
> example, of how they deal with modules).
>
> A good example would be the embedded eXist. Current OPS bundle comes  
> with
> eXist 1.1.1 while 1.2 is out. Sure you can wait till a new release  
> for OPS
> comes, with hopefully an upgraded eXist. Or, you can 'open up' the lib
> folder and replace the jars by hand. Thing is, Maven could this for  
> you
> automatically and alot more.
> Another example is that you can keep the footprint to source code  
> alone,
> instead of carrying along the required jars in the csv or svn (or  
> whatever
> scm you use). To extend the example of eXist, it comes embedded,  
> which is
> easy for quick proof of concepting and developing in general.  
> However, in
> production like settings (especially scalable ones) you certainly do  
> not
> want to have exist running embedded, but isolated. This requires  
> alot of
> handwork to strip it out, or carry it as unused luggage.
>
> With Maven and some configuration you can add modules that could be  
> part of
> the OPS, like examples included or mimimal, together with the needed
> configuration files. That all can be solved.
>
> The solution of treating OPS as an 'isolated' WAR is appealing, but  
> is yet
> another entity that needs to be managed. It is good practise to keep a
> single website having a single WAR file. In real life, business  
> applications
> run in an application server (like JBoss, Websphere, GlassFish, name  
> the
> lot), with an apache server in front acting as proxy. Alot of virtual
> hosting is done as well. Having more WAR files means more  
> configuration, and
> raises the bar of using OPS, and adds to the EAR deployment.
>
> As for naming and versioning Jar files, that too is standarized.  
> Maven uses
> a repository for that. As for Orbeon specific libraries, you can  
> easily
> group them and still have unique names to identify their purposes.  
> This one
> of the reasons or solutions that Maven brings. I could go and if you  
> want
> me, I'll do. Heck, I am willing to contribute.
>
> Oh, have I mentioned that Maven integrates nicely with Contineous
> Integration tools such as Continuum?
>
> Anyways, this topic addresses alot more issues, but in the end of  
> the day,
> it benefits us all, at least thats my opinion.
>
> Regards,
> Mike
> --
> View this message in context: http://www.nabble.com/Maven-integration-and-Orbeon-dependency-mess-tp17203540p17230401.html
> Sent from the ObjectWeb OPS - Users mailing list archive at  
> Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email]  
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

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