www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: How do I relocate an artifact?
Date Tue, 04 Jul 2006 00:17:19 GMT
Carlos Sanchez wrote:
> On 7/3/06, Dennis Lundberg <dennisl@apache.org> wrote:
>> Carlos Sanchez wrote:
>> > On 7/3/06, Dennis Lundberg <dennisl@apache.org> wrote:
>> >> Hello list
>> >>
>> >> This is my first post to this list. Please let me know if these
>> >> questions are inappropriate for this list.
>> >>
>> >> Being a committer at jakarta-commons, I have started the work on
>> >> relocating the artifacts for commons to a new groupId. At present all
>> >> released artifacts for commons components are deployed to the ASF
>> >> java-repository (from here on I will call it the Maven 1 repository).
>> >> The artifacts are deployed there in a commons-<component_name> 
>> directory.
>> >>
>> >> We would like to relocate our artifacts to the new structure and use a
>> >> groupId of org.apache.commons. Discussions about this has been held 
>> [1]
>> >> on commons-dev@jakarta.apache.org. Brett Porter and Carlos Sanchez 
>> have
>> >> been helpful in the discussions and have recommended what needs to be
>> >> tested.
>> >>
>> >> I have done the necessary testing and would now like to take the next
>> >> step. There is one question that remains unanswered, and that is which
>> >> repository to make the change in: Maven 1 or Maven 2.
>> >
>> > You would need to put the relocation poms in the Maven 2 one, I'll
>> > sync it to ibiblio overriding what it was previously there.
>>
>> OK, but there are no Maven 2 poms for commons components in the ASF
>> Maven 2 repo, because commons components are built using Maven 1. I
>> understand that the Maven 1 poms are converted before they are synced to
>> the Maven 2 repo at ibiblio. Are they built and kept somewhere on ASF
>> hardware, so that I can get my hands on them? This would be needed for
>> re-signing the poms as well.
> 
> create them just with groupId, artifactId, version and the relocation
> info, the real info goes into the destination pom

I see.

Should these files be deployed to 
people.apache.org:/www/www.apache.org/dist/maven-repository/commons-lang/commons-lang/<version>/commons-lang-<version>.pom

Would these poms also need to be signed?

>> > Artifacts go to the repository of the Maven version they are build
>> > with, so things built with maven1 go to the maven1 repo (directory
>> > org.apache.commons) and things built with maven2 go to the maven2 repo
>> > (directory org/apache/commons)
>>
>> Yes.
>>
>> >>
>> >> The tests I have made have all been done using Maven 2 and a local 
>> Maven
>> >> 2 repository. How would I go about relocation something in the Maven 1
>> >> repo? The Maven 1 pom does not seem to have a relocation element, like
>> >> the Maven 2 pom have.
>> >
>> > Maven 1 users using old group will work as always as artifacts won't
>> > be removed, just poms, but they need to explicitly change the groupId
>> > of their commons dependencies to use the new releases.
>> > Maven 2 users using the old groupId will get a warning to remember
>> > updating the groupid. Note that it'd be helpful to add a relocation
>> > pom for the next release of every commons library to the old group so
>> > people get the warning when trying to update only version, as they may
>> > have cached poms of the current ones.
>>
>> So, when we release the next version of, say commons-lang (2.2), we
>> should publish a Maven 2 pom with a groupId of commons-lang, a version
>> of 2.2 and include a relocation section? In addition to publishing the
>> Maven 1 pom as we have always done. This step would be a one time thing
>> to do for the first release of every component after the change of
>> groupId is made, right?
> 
> yes, so people already using the last version get a warning when they
> try to upgrade. If you want to do it for the x next releases better,
> but it's up to you. Once is a good idea.

OK, good.

<snip>

I'm trying to put together a how-to document for this. At the moment it 
is very commons-oriented, but that could be changed easily. What would 
be a good home for such a document? Jakarta commons, Maven or 
www.apache.org/dev/somewhere?

-- 
Dennis Lundberg

Mime
View raw message