[Digester] Change of Maven Group Id

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

[Digester] Change of Maven Group Id

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

Re: [Digester] Change of Maven Group Id

Wendy Smoak
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]

Reply | Threaded
Open this post in threaded view
|

Re: [Digester] Change of Maven Group Id

Henri Yandell
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]

Reply | Threaded
Open this post in threaded view
|

Re: [Digester] Change of Maven Group Id

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

Re: [Digester] Change of Maven Group Id

Stephen Colebourne
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]

Reply | Threaded
Open this post in threaded view
|

Re: [Digester] Change of Maven Group Id

Wendy Smoak
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]

Reply | Threaded
Open this post in threaded view
|

Re: [Digester] Change of Maven Group Id

Dennis Lundberg-2
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]

Reply | Threaded
Open this post in threaded view
|

Re: [Digester] Change of Maven Group Id

craigmcc
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]
>
>