cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: [RANT] This Maven thing is killing us....
Date Wed, 05 Jul 2006 08:31:06 GMT
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


-- 
Brett Porter <brett@apache.org>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

Mime
View raw message