commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject RE: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Date Thu, 08 Feb 2007 08:50:24 GMT
Hi Dennis,

Dennis Lundberg wrote on Wednesday, February 07, 2007 9:39 PM:

>>> I put together this document when I was trying to pull through the
>>> whole groupId change last time: 
>>> 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
> 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:
For additional commands, e-mail:

View raw message