« Return to Thread: Maven integration and Orbeon dependency mess
Re: Maven integration and Orbeon dependency mess
by Mike Ahlers
::
Rate this Message:
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
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
« Return to Thread: Maven integration and Orbeon dependency mess
| Free Forum Powered by Nabble | Forum Help |