yep, but to be clear, if we had relocated that version it'd
potentially break people using it as their binary would change.
I wouldn't like you to think that I screwed you for any reason.
FWIW i'm not fan of relocations anyway, they have potentially bad
effects. If an artifact moves to other place
On 2/14/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
Maven should give here better support. If it ever downloads a relocation POM it
should keep the relocation information in a separate DB/storage and take it
always into account when resolving aritfacts no matter which version. Scenario
1 woul
nicolas de loof wrote on Wednesday, February 14, 2007 9:19 AM:
> That would'nt work anyway
>
> If you allready downloaded commons-cc:1.1 and get (maybe
> transitiviely) a dependency on org.apache.commons:cc:1.2, you will
> get both in
> your classpath
> as maven will not kwon those tow groupIds
That would'nt work anyway
If you allready downloaded commons-cc:1.1 and get (maybe transitiviely) a
dependency on org.apache.commons:cc:1.2, you will get both in your classpath
as maven will not kwon those tow groupIds are for the same artifact.
We can't expect maven to reload the 1.1 POM that i
Carlos Sanchez wrote on Wednesday, February 14, 2007 8:40 AM:
> iirc you have very different jars in the two groupids, that's not
> relocation, that would actually change the binaries for users
This was for one single release only (because we did not realize, that the M1
and M2 repos are "comple
Hi Carlos,
Carlos Sanchez wrote on Wednesday, February 14, 2007 8:25 AM:
> right a relocate pom for ALL versions is required to avoid
> duplication on classpath BUT as I said almost everybody will have
> cached previous versions of commons so they won't see the relocation
> until they delete loca
On 2/13/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
According to this, when relocation projectX for new release N+1
option 1 : making dependency to oldGroupId:N+1 will work, but making
dependency to newGroupId:N+1 will introduce duplicate jars issues if other
dependencies introduce transitive
iirc you have very different jars in the two groupids, that's not
relocation, that would actually change the binaries for users
On 2/13/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
Hi Carlos,
Carlos Sanchez wrote on Tuesday, February 13, 2007 7:29 PM:
> you can change the old poms to relocate
According to this, when relocation projectX for new release N+1
option 1 : making dependency to oldGroupId:N+1 will work, but making
dependency to newGroupId:N+1 will introduce duplicate jars issues if other
dependencies introduce transitive-dependency to oldGroupId:N
option 2 : relocating all P
Hi Carlos,
Carlos Sanchez wrote on Tuesday, February 13, 2007 7:29 PM:
> you can change the old poms to relocate to a new location as long as
> the new location has the same old jars and poms (just groupId
> change). IIRC your case was different.
>
> So, I' see two options for relocation:
>
>
right a relocate pom for ALL versions is required to avoid duplication
on classpath
BUT as I said almost everybody will have cached previous versions of
commons so they won't see the relocation until they delete local repo
and the poms with relocation info get downloaded.
On 2/13/07, nicolas de l
What in such a scenario :
My project depends commons-xxx-1.2, relocated at org.apache.commons.xxx-1.2
My pom get transitive commons-xxx-1.1
If I DON't update my POM maven2 will find the relocated artifact and exclude
1.1 - that's fine
If 1.1 has no relocated POM, and if I update my POM, maven2
scenario 3 is with no relocation pom at all, so users get involved by
having to explicitly change the groupId
On 2/13/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
I don't understand the distinction you make between scenario 1 and 3 :
if new release use a relocation pom under commons-xxx and D
I don't understand the distinction you make between scenario 1 and 3 :
if new release use a relocation pom under commons-xxx and DOESN'T deploy a
jar under this group
- maven2 users will get relocated artifact + a warning to update
dependencies
- maven1 users will not get the new version, may ask
oh there's a 3rd option that I even like more
3) make new releases in new groupid, no relocations at all
+ easiest ;)
+ users trying to upgrade will need to know that the groupId has
changed and act by themselves, so they will be involved, and in case
of classpath problems they will know what has
you can change the old poms to relocate to a new location as long as
the new location has the same old jars and poms (just groupId change).
IIRC your case was different.
So, I' see two options for relocation:
1) when new version is out with new groupId add relocation pom in old
location just for
Thanks for bringing this up Henri.
Here's my view on this:
1. Maven 1 builds stay as commons-foo (like you said)
2. Maven 2 builds change to org.apache.commons once the component moves
to using M2 to build the component *and* putting the artifacts into the
M2 repo. This should be done one com
You need to create a relocation POM for the release that does relocation to
avoid hundred users to ask for upload on ibilio.
The relocation POM will produce a warning on console for maven users. You
can expect users to consider warnings and update groupId.
The relocation POM will not be required
On 2/13/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
Hi Hen,
Henri Yandell wrote on Tuesday, February 13, 2007 7:00 AM:
> Second try - having had it explained to me on #maven why relocating is
> important [so commons-lang:commons-lang 2.1 and
> org.apache.commons:commons-lang 3.0 are considered
Hi Hen,
Henri Yandell wrote on Tuesday, February 13, 2007 7:00 AM:
> Second try - having had it explained to me on #maven why relocating is
> important [so commons-lang:commons-lang 2.1 and
> org.apache.commons:commons-lang 3.0 are considered the same and a
> transitive clash can be recognized].
Second try - having had it explained to me on #maven why relocating is
important [so commons-lang:commons-lang 2.1 and
org.apache.commons:commons-lang 3.0 are considered the same and a
transitive clash can be recognized].
So, second suggestion:
We declare a point after which we won't do any more
21 matches
Mail list logo
