While trying to verify the patch I'm proposing for DIGESTER-110, I tried
temporarily modifying my Maven2 POMs for Shale to pick up the new version. I noticed that the groupId for Digester is being changed from "commons-digester" (as it was before), to "org.apache.commons" (in the 1.8-RC1 version). While I can see the logic of this change, it is going to be very disruptive to downstream users who use Maven to build with. Such projects will have declared a dependency on the old combination (commons-digester:commons-digester), meaning you will often end up with two copies of Digester (one matching the old combination, one for the new) in dependent applications -- unless you explicitly exclude the old-style ones -- and those are often inherited as transitive dependencies, and are thus pretty hard to track down. I presume that this is being done as part of some Commons-wide policy change? If so, it's incumbent on us to clearly document the impact of this change on downstream users, because it is going to be pretty disruptive until all downstream users have rev'd their POMs to reflect the new versions. Craig |
On 11/24/06, Craig McClanahan <[hidden email]> wrote:
> I presume that this is being done as part of some Commons-wide policy > change? If so, it's incumbent on us to clearly document the impact of this > change on downstream users, because it is going to be pretty disruptive > until all downstream users have rev'd their POMs to reflect the new > versions. It shouldn't be disruptive at all if the artifacts are properly "relocated" in the Maven repo. ISTR Dennis Lundberg was working on it. -- Wendy --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
On 11/24/06, Wendy Smoak <[hidden email]> wrote:
> On 11/24/06, Craig McClanahan <[hidden email]> wrote: > > > I presume that this is being done as part of some Commons-wide policy > > change? If so, it's incumbent on us to clearly document the impact of this > > change on downstream users, because it is going to be pretty disruptive > > until all downstream users have rev'd their POMs to reflect the new > > versions. > > It shouldn't be disruptive at all if the artifacts are properly > "relocated" in the Maven repo. > > ISTR Dennis Lundberg was working on it. In the meantime though, we have 12 components with org.apache.commons and 22 with the original (for some value of 12 and 22). Anyone against rolling them back to the original group ids? Discovery, Digester, DbUtils and Betwixt are all close to release and it sounds like we're not ready to release that way yet. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Wendy Smoak
On 11/24/06, Wendy Smoak <[hidden email]> wrote:
> > On 11/24/06, Craig McClanahan <[hidden email]> wrote: > > > I presume that this is being done as part of some Commons-wide policy > > change? If so, it's incumbent on us to clearly document the impact of > this > > change on downstream users, because it is going to be pretty disruptive > > until all downstream users have rev'd their POMs to reflect the new > > versions. > > It shouldn't be disruptive at all if the artifacts are properly > "relocated" in the Maven repo. Does that mean that you will be able to use commons-digester:commons-digester:1.8 *or* org.apache.commons:commons-digester:1.8 after Digester 1.8 is released? For a specific example, consider an app that uses, say, Shale and MyFaces 1.1.4. Even if we update the Shale dependency to the new groupId, an application will still inherit a transitive dependency on the old version until a new MyFaces release with an updated dependency. Does the "relocation" take care of this? Craig ISTR Dennis Lundberg was working on it. > > -- > Wendy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > |
In reply to this post by Henri Yandell
Henri Yandell wrote:
> In the meantime though, we have 12 components with org.apache.commons > and 22 with the original (for some value of 12 and 22). Anyone against > rolling them back to the original group ids? Discovery, Digester, > DbUtils and Betwixt are all close to release and it sounds like we're > not ready to release that way yet. I'm +1 to rolling back. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by craigmcc
On 11/24/06, Craig McClanahan <[hidden email]> wrote:
> Does that mean that you will be able to use > commons-digester:commons-digester:1.8 *or* > org.apache.commons:commons-digester:1.8 after Digester 1.8 is released? > > For a specific example, consider an app that uses, say, Shale and MyFaces > 1.1.4. Even if we update the Shale dependency to the new groupId, an > application will still inherit a transitive dependency on the old version > until a new MyFaces release with an updated dependency. You relocate the existing releases that are already in the repository. Then Maven is able to figure out that commons-digester:commons-digester:1.7 is really org.apache.commons:commons-digester:1.7, and is "the same" artifact as org.apache.commons:commons-digester:1.8. That will stop it from including both. The whole of Commons doesn't have to switch at once. The trick is to relocate _all_ of the old artifacts for any given component, then start releasing that component under the new groupId. Maven will then print warnings that "this artifact has been relocated..." which will prompt people to switch over. -- Wendy --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Wendy Smoak
Wendy Smoak wrote:
> On 11/24/06, Craig McClanahan <[hidden email]> wrote: > >> I presume that this is being done as part of some Commons-wide policy >> change? If so, it's incumbent on us to clearly document the impact of >> this >> change on downstream users, because it is going to be pretty disruptive >> until all downstream users have rev'd their POMs to reflect the new >> versions. > > It shouldn't be disruptive at all if the artifacts are properly > "relocated" in the Maven repo. > > ISTR Dennis Lundberg was working on it. > Yes, I was. See [1] and [2] for a bit of background. Unfortunately I ran out of steam. There just didn't seem to be any real commitment to the idea from the community. Sorry to have left things in a not-quite-finished state. I did manage to write some documentation [3] on how to manage the "relocation" that Wendy speaks of. My stand on this at the moment is to await the transition to Maven 2 as the main build platform for Commons. When we start using Maven 2 to build our binary releases, they should at the same time change the groupId. However, if someone feels that we should go ahead with the migration using Maven 1 I'll help in any way I can. [1]http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200605.mbox/%3c1147518485.8876.4.camel@...%3e [2]http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200605.mbox/%3c4474BB7F.9060006@...%3e [3]http://maven.apache.org/guides/mini/guide-relocation.html -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Wendy Smoak
On 11/24/06, Wendy Smoak <[hidden email]> wrote:
> > On 11/24/06, Craig McClanahan <[hidden email]> wrote: > > > Does that mean that you will be able to use > > commons-digester:commons-digester:1.8 *or* > > org.apache.commons:commons-digester:1.8 after Digester 1.8 is released? > > > > For a specific example, consider an app that uses, say, Shale and > MyFaces > > 1.1.4. Even if we update the Shale dependency to the new groupId, an > > application will still inherit a transitive dependency on the old > version > > until a new MyFaces release with an updated dependency. > > You relocate the existing releases that are already in the repository. > Then Maven is able to figure out that > commons-digester:commons-digester:1.7 is really > org.apache.commons:commons-digester:1.7, and is "the same" artifact as > org.apache.commons:commons-digester:1.8. That will stop it from > including both. > > The whole of Commons doesn't have to switch at once. The trick is to > relocate _all_ of the old artifacts for any given component, then > start releasing that component under the new groupId. > > Maven will then print warnings that "this artifact has been > relocated..." which will prompt people to switch over. If we can get the relocation to work as Wendy described, then I'm +1 on doing the groupId migration piecemeal, as Commons packages get released. This addresses my concern. -- > Wendy Craig --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > |
Free forum by Nabble | Edit this page |