From dev-return-88260-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Wed Jul 05 08:31:47 2006 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 64090 invoked from network); 5 Jul 2006 08:31:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Jul 2006 08:31:47 -0000 Received: (qmail 93061 invoked by uid 500); 5 Jul 2006 08:31:44 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 92998 invoked by uid 500); 5 Jul 2006 08:31:44 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 92987 invoked by uid 99); 5 Jul 2006 08:31:43 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jul 2006 01:31:43 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [203.59.1.195] (HELO mail-ihug.icp-qv1-irony1.iinet.net.au) (203.59.1.195) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jul 2006 01:31:42 -0700 Received: from 203-206-245-195.dyn.iinet.net.au (HELO [192.168.237.213]) ([203.206.245.195]) by mail-ihug.icp-qv1-irony1.iinet.net.au with ESMTP; 05 Jul 2006 16:31:19 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,206,1149436800"; d="scan'208"; a="552322549:sNHT78675490" Message-ID: <44AB78CA.4030000@apache.org> Date: Wed, 05 Jul 2006 18:31:06 +1000 From: Brett Porter User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Maven Developers List CC: dev@cocoon.apache.org Subject: Re: [RANT] This Maven thing is killing us.... References: <98e4f1cd0607040434k1c0f7ddeo8e9ddf0899c15b7e@mail.gmail.com> <1a5b6c410607040553r6c20b441j81ec638465d9f10d@mail.gmail.com> <44AAD6C3.3050107@dslextreme.com> <44AB0710.4090708@apache.org> <44AB610A.9010901@dslextreme.com> In-Reply-To: <44AB610A.9010901@dslextreme.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/