Hi,
We have adopted Orbeon for our current project and so I am simultaneously trying to understand XForms and the XML ecosystem, which I only have a trivial understanding of and also trying to understand the build system so please bear with me is I seem a bit out of my depth. I have been able to find one previous discussion of Maven on the list, but it appears that Maven is not highly thought of here. For myself the absence of Maven on a project is a big barrier to entry on a project. My main concern is the management of dependencies, specifically we need to use more current versions of common dependencies such as eXist. We have created a version of Orbeon which uses a current eXist (see http://code.google.com/p/atombeat/wiki/OrbeonForms) and this work has been improved by nixj14 (thanks nixj14, just makes you love open source) However the patch script contains hard coded versions of jar files and so is necessarily fragile. What is at the root of this strategy? Why does Orbeon, which is not a young project, still need non-standard versions of other project's artefacts? These projects are OpenSource so any changes you need can be fed back into these projects. If you are feeding your changes back to the projects you are using then why are they not being accepted by those projects? What is the current view on Maven? cheers Tim -- 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 |
Administrator
|
Hi Tim,
Seriously, we have nothing against Maven ;). It just turns out neither we or any of our clients needed Maven enough to justify spending enough time on this. In most cases, the problem that people want to solve is one of integration with their own app: you have an app that requires version X of library L, but Orbeon Forms comes with version Y. Part of the solution consists in replacing L.Y that comes with Orbeon Forms by L.X. Maven makes putting the right jar in the right place easier. But in most cases, this is not the hard part. The hard part is making sure that Orbeon Forms can use L.X. This might require changes to Orbeon Forms and extensive testing. Unless Orbeon Forms itself gets some benefit out of using L.X instead of L.Y, going through this exercise is generally not worth the effort. This especially true since there is a simpler solution to that integration problem: deploy the application that requires L.X as a separate web app, and let that app use L.X and Orbeon Forms use L.Y This brings us to the question of changes to libraries. Most libraries can be used without any changes. This is of course our preference, as it makes upgrading to new versions much easier. Some libraries have to rerooted to avoid issues with certain application servers. Finally, other libraries have significant changes. When we have to go through this, we do our best to document the changes, and report those changes back to the authors so they can be considered for inclusion. On example of this is YUI (http://wiki.orbeon.com/forms/doc/contributor-guide/yahoo-ui-library-yui). Of course, this is not to say that we're doing a perfect job; far from it! If you see area that can be improved, please let us know; or even better: maybe you can help, say improving our documentation of the changes we did to 3rd party libraries (http://wiki.orbeon.com/forms/doc/contributor-guide/third-party-java-libraries). Or make sure that all the changes are on separate projects on GitHub (e.g. the changes to Saxon and Xerces are, but the changes to YUI and eXist aren't there yet). I hope this helps, Alex On Fri, May 7, 2010 at 7:30 AM, Tim Pizey <[hidden email]> wrote: > Hi, > > We have adopted Orbeon for our current project and so I am simultaneously > trying to understand XForms and the XML ecosystem, which I only have a > trivial understanding of and also trying to understand the build > system so please > bear with me is I seem a bit out of my depth. > > I have been able to find one previous discussion of Maven on the list, but > it appears that Maven is not highly thought of here. > For myself the absence of Maven on a project is a big barrier to entry > on a project. > > My main concern is the management of dependencies, specifically we need to use > more current versions of common dependencies such as eXist. > > We have created a version of Orbeon which uses a current eXist > (see http://code.google.com/p/atombeat/wiki/OrbeonForms) and this work has been > improved by nixj14 (thanks nixj14, just makes you love open source) > > However the patch script contains hard coded versions of jar files and > so is necessarily fragile. > > What is at the root of this strategy? > > Why does Orbeon, which is not a young project, still need non-standard > versions of other project's artefacts? > These projects are OpenSource so any changes you need can be fed back > into these projects. > If you are feeding your changes back to the projects you are using > then why are they not being accepted by > those projects? > > What is the current view on Maven? > > cheers > Tim > > > -- > 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 > > -- Orbeon Forms - Web forms, open-source, for the Enterprise - http://www.orbeon.com/ My Twitter: http://twitter.com/avernet -- 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
--
Follow Orbeon on Twitter: @orbeon Follow me on Twitter: @avernet |
Free forum by Nabble | Edit this page |