Hi Ralph,
You've got a general versioning problem here, and you'll find the answer
to "how do I do this with Maven?" will be more straightforward once
considering the question of how you should generally deal with them. As
you've said, this is already a problem for you as you don't know where
they really came from.
Ignoring Maven for a moment, there's a couple of questions I'd consider
(bear in mind I'm not a Cocoon user so I may be misunderstanding how
they eventually get used):
- how would a user that used one of these dependencies themselves in
addition to that Cocoon component select which version of the dependency
to use? Would they use the Cocoon-supplied one, one they select, or both?
- are the changes Cocoon specific? Will you always be using a custom
release, or will you pick up the next release when it is available?
There are a couple of options for addressing this use case in Maven.
- include the JARs in SVN, and reference it as an additional repository
file://localhost/${basedir}/extra-jar-repo
- host your own repository of these artifacts (this is basically
equivalent to the above and probably easier to work with, and could be
accommodated in a general ASF repository of such things, once taking
into account the licensing guidelines)
- ask projects to do a beta/point release for you (it should be easy to
make a case for this if the version you are using is both stable and
contains critical fixes)
- "fork" the code (taking into consideration licensing guidelines)
either temporarily or permanently in your own repository (ie
http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html). Make
it part of your build, and do the custom group ID thing. We really need
the "provides" functionality planned for Maven 2.1 to make this feasible
if it is intended to be a drop in replacement of the original JAR (so
that you don't get duplicates in the dependency chain), but it can
certainly work.
BTW, I also think we need specific support for this type of artifact (it
is essentially a "vendor" release), and it is under consideration for
Maven 2.1.
Your point about never being a Cocoon release while waiting for
dependencies to release is something I'm familiar with and there's
definitely a need for this. However, is it possible to reduce the impact
of it by being able to release individual components at different times
so that they can track the release cycles of their dependencies? This
sounds very similar to the scenario of Maven plugins, where it works
quite successfully.
HTH,
Brett
On 5/07/2006 4:49 PM, Ralph Goers wrote:
Brett Porter wrote:
It depends on how you use them as to the best solution here. I assume
that they are customised for cocoon, so they shouldn't be considered
to be the same as the original. In that case, I'd suggest you release
them under your own groupID (maybe org.apache.cocoon.thirdparty) so
that they don't conflict (bearing in mind that someone will
transitively receive both that and the original if they are both
used). I'm assuming this isn't the case as you are only bundling these
modified versions into a distributable app, not as part of a reusable
component?
Hope this helps,
Brett
Actually, I'm not exactly sure why non-released jars are currently
included, but I'm almost certain that in most cases it is not because it
is customized for Cocoon. In looking in our latest 2.1.9 release (which
isn't built with Maven) I see that jcs, chaperon, jackrabbit, deli,
dojo, jing, joost, myfaces, poi, wsrp4j, xmldb and xreporter were all
included in the release from some interim version that is probably
unknown to those projects. I suspect for many of them this was done
because they included critical fixes. Since Cocoon contains so many
third party jars we would either have to make releases knowing that some
things are broken or never put out a release.
However, your point about naming them o.a.c.thirdparty is well taken (at
least by me). A complaint I frequently have had is that it is often
difficult to locate the exact source that was used to create the jar.
Sometimes they are named with the svn revision with makes it easy.
Sometimes they have a datestamp, which isn't necessarily guaranteed to
get you the exact source, and sometimes they have a name like
wsrp4j-shared-0.3-dev.jar (wsrp4j is in inclubator and I don't believe
it has ever done a release, but this version number is really bad since
there is no tag in svn matching 0.3-dev that I can see). In wsrp4j's
case, I'm fairly sure Cocoon's usage of it is considered experimental -
it gives users a way to have early access to it for experimentation
purposes.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
