Hi Dennis,
Dennis Lundberg wrote on Wednesday, February 07, 2007 9:39 PM:
[snip]
>>> I put together this document when I was trying to pull through the
>>> whole groupId change last time:
>>>
>>> http://maven.apache.org/guides/mini/guide-relocation.html
>>>
>>> There is never a good time to change the groupId. My view is that we
>>> should do it when we move to M2, both as a build tool and as the
>>> target repository.
>>
>> Yes, I tried to use this description for a M1 -> M2 situation. In
>> the end Carlos' advice was to ignore all the old versions and simply
>> start with the new M2 releases also to use the new groupId and add
>> for those releases only a relocation POM.
>
> That is a much easier way to do it. I'm starting to think
> that this is
> the way to go for Commons. Just change the groupId when we release
> with M2 and don't relocate older versions.
Yep. If we agree all on this, we can immediately start to use the new groupId. It's just,
that the release & deploy process will not automatically create those relocation POMs.
>> The problem with adjusting the old releases is, that the
>> location for the relocation POMs is already occupied by the
>> automatically generated POMs for M2 on the global M2 repo (see
>>
> http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-logging/
> commons-logging/1.1/).
>> And since they're already published, they cannot be changed anymore.
>
> I think you are allowed to add a relocation section to an already
> published pom. I vaguely remember discussing this with Carlos back
> then.
Well, it seems, they become more strict since then. I got definitely a negative answer from
him as to replace the old POMs from ibiblio with the ones including the relocation section
available on a synchronized site.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org