Dependencies, Maven, again

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Dependencies, Maven, again

Tim Pizey
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
Reply | Threaded
Open this post in threaded view
|

Re: Dependencies, Maven, again

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