Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
OK, I'm finally getting back to this. I've run the tests in my local M2
repo and, using the (slightly modified, see below) recipe below, I've
managed to get it to work as expected.
To get this show on the road I will subscribe to repository@ and ask for
some guidance. Will post back here later.
Carlos Sanchez wrote:
Are you thinking about doing it in the m1 or m2 repo?
see below
On 6/7/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
So, in the simple example below, covering commons-lang, the procedure
would be:
1. Copy all files from /commons-lang/ to
/org/apache/commons/commons-lang/ in the *Apache* repo
2. Change the groupId of all the pom files under
/org/apache/commons/commons-lang/ so that they use the
org.apache.commons groupId
3. Add relocation elements to all pom files in /commons-lang/ pointing
them to org.apache.commons like this:
relocation
groupIdorg.apache.commons/groupId
/relocation
Just a note that this is in the distributionManagement section of the pom.
If I understand the model documentation correctly, we shouldn't have to
use artifactId or version since they are the same. But should we add a
message ?
I never did.
4. Wait for a sync between the Apache repo and ibiblio, or is this
something that we need to ping someone about?
m1 repo - wait
m2 repo - ping
Is that correct so far?
When we later decide to release our first artifact using the new
groupId, should we also copy it to the repo using the groupId? My gut
feeling says no, but it's best to ask.
no
If I want to try this out locally first, can I test it in my local repo
${user.home}/.m2/repository/... or do I need to use a local httpd
serving as a central repo?
local is ok
--
Dennis Lundberg
Carlos Sanchez wrote:
You are right. This would involve copying all the old group sutff to
the new group and add the relocation poms.
On 6/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
AFAIK there is a way in maven repo to relocate dependencies, so
that a
POM for any commons can be published at commons-xxx groupId, that
relocates to org.apache.commons groupId.
Servletapi for example is now under javax.servlet
http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom
Using this, when maven2 search for the latest release of any commons
it will look at the relocated one.
Torsten Curdt a écrit :
Brett,
any comments on this?
cheers
--
Torsten
On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Brett, I did the test that you suggested.
1. Installed commons-lang 1.0.1 into my local repo with
groupId=org.apache.commons
mvn install:install-file -DgroupId=org.apache.commons
-DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar
-Dfile=/path/to/commons-lang-1.0.1.jar
2. Created Maven 2 projects a, b and c with the dependencies
mentioned
below.
3. Installed projects a and b into my local repo
mvn install
4. packaged project c as a war
mvn package
The resulting war file includes both commons-lang-1.0.1.jar and
commons-lang-2.1.jar which was what you thought would happen.
So this is bad, I guess. Anyone who uses commons components
transitively
in a Maven 2 environment are likely to be bitten by this. They must
keep
the same groupId for all commons-lang dependencies, as an
example, in
the entire chain of transitive dependencies. I.e. they can't mix
groupId=commons-lang and groupId=org.apache.commons. This can be a
PITA
since some of the dependencies are most likely out of the
projects own
control.
What do you suggest we do? Should we wait with this relocation
until a
version of Maven 2 is released that can handle these kind of
dependencies?
--
Dennis Lundberg
Brett Porter wrote:
an extensive test should be something along the lines of:
project A depends on commons-lang:commons-lang 2.1
project B depends on o.a.c:commons-lang 1.0
project C is a webapp that depends on A and B
webapp should have only one commons-lang.
You could do this with your own repository (and something
completely
artificial instead of commons-lang if it makes it easier).
- Brett
Dennis Lundberg wrote:
Hi Brett
Sorry, I misunderstood you regarding when to do the testing. So,
no I
haven't done the test, yet. Can you elaborate a bit more on what
needs
to be tested? Perhaps you know of an artifact that has been
relocated
that we can have a look at, to see how they have done.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate,
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Whats the state of play with this - I was just about to do the release for Chain 1.1 - it has been modified to have groupIdorg.apache.commons/groupId - is it OK to release with this or should I revert to groupIdcommons-chain/groupId? Niall On 6/5/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Brett, I did the test that you suggested. 1. Installed commons-lang 1.0.1 into my local repo with groupId=org.apache.commons mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/commons-lang-1.0.1.jar 2. Created Maven 2 projects a, b and c with the dependencies mentioned below. 3. Installed projects a and b into my local repo mvn install 4. packaged project c as a war mvn package The resulting war file includes both commons-lang-1.0.1.jar and commons-lang-2.1.jar which was what you thought would happen. So this is bad, I guess. Anyone who uses commons components transitively in a Maven 2 environment are likely to be bitten by this. They must keep the same groupId for all commons-lang dependencies, as an example, in the entire chain of transitive dependencies. I.e. they can't mix groupId=commons-lang and groupId=org.apache.commons. This can be a PITA since some of the dependencies are most likely out of the projects own control. What do you suggest we do? Should we wait with this relocation until a version of Maven 2 is released that can handle these kind of dependencies? -- Dennis Lundberg Brett Porter wrote: an extensive test should be something along the lines of: project A depends on commons-lang:commons-lang 2.1 project B depends on o.a.c:commons-lang 1.0 project C is a webapp that depends on A and B webapp should have only one commons-lang. You could do this with your own repository (and something completely artificial instead of commons-lang if it makes it easier). - Brett Dennis Lundberg wrote: Hi Brett Sorry, I misunderstood you regarding when to do the testing. So, no I haven't done the test, yet. Can you elaborate a bit more on what needs to be tested? Perhaps you know of an artifact that has been relocated that we can have a look at, to see how they have done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Niall Pemberton wrote: Whats the state of play with this - I was just about to do the release for Chain 1.1 - it has been modified to have groupIdorg.apache.commons/groupId - is it OK to release with this or should I revert to groupIdcommons-chain/groupId? Niall, I haven't had time yet to make the relocations tests in my local repo yet. Please revert the groupId to commons-chain before releasing Chain 1.1. Sorry for the inconvenience. -- Dennis Lundberg Niall On 6/5/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Brett, I did the test that you suggested. 1. Installed commons-lang 1.0.1 into my local repo with groupId=org.apache.commons mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/commons-lang-1.0.1.jar 2. Created Maven 2 projects a, b and c with the dependencies mentioned below. 3. Installed projects a and b into my local repo mvn install 4. packaged project c as a war mvn package The resulting war file includes both commons-lang-1.0.1.jar and commons-lang-2.1.jar which was what you thought would happen. So this is bad, I guess. Anyone who uses commons components transitively in a Maven 2 environment are likely to be bitten by this. They must keep the same groupId for all commons-lang dependencies, as an example, in the entire chain of transitive dependencies. I.e. they can't mix groupId=commons-lang and groupId=org.apache.commons. This can be a PITA since some of the dependencies are most likely out of the projects own control. What do you suggest we do? Should we wait with this relocation until a version of Maven 2 is released that can handle these kind of dependencies? -- Dennis Lundberg Brett Porter wrote: an extensive test should be something along the lines of: project A depends on commons-lang:commons-lang 2.1 project B depends on o.a.c:commons-lang 1.0 project C is a webapp that depends on A and B webapp should have only one commons-lang. You could do this with your own repository (and something completely artificial instead of commons-lang if it makes it easier). - Brett Dennis Lundberg wrote: Hi Brett Sorry, I misunderstood you regarding when to do the testing. So, no I haven't done the test, yet. Can you elaborate a bit more on what needs to be tested? Perhaps you know of an artifact that has been relocated that we can have a look at, to see how they have done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
AFAIK maven1 repo is simply a rewriteRule on maven2 repo, so that new
artifacts under org.apache.commons groupId in maven2 repo will be
available in maven1 repo under org.apache.commons/jars/artifact.jar
This may suggest to use a more specific groupId for commons, like
org.apache.commons.*lang*
to keep commons separation in maven1 repo.
Dennis Lundberg a écrit :
Carlos Sanchez wrote:
Are you thinking about doing it in the m1 or m2 repo?
I really don't have a clue. Since I have not acted as release manager
for any component, I haven't really done my homework on what the
difference between the two is. I know about the M1 an M2 repos at
ibiblio, and that there is some sort of conversion between them, but
don't know what it looks like at the Apache end.
Do you have any suggestions on which is better?
see below
On 6/7/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
So, in the simple example below, covering commons-lang, the procedure
would be:
1. Copy all files from /commons-lang/ to
/org/apache/commons/commons-lang/ in the *Apache* repo
2. Change the groupId of all the pom files under
/org/apache/commons/commons-lang/ so that they use the
org.apache.commons groupId
3. Add relocation elements to all pom files in /commons-lang/ pointing
them to org.apache.commons like this:
relocation
groupIdorg.apache.commons/groupId
/relocation
If I understand the model documentation correctly, we shouldn't have to
use artifactId or version since they are the same. But should we add a
message ?
I never did.
4. Wait for a sync between the Apache repo and ibiblio, or is this
something that we need to ping someone about?
m1 repo - wait
m2 repo - ping
OK
Is that correct so far?
When we later decide to release our first artifact using the new
groupId, should we also copy it to the repo using the groupId? My gut
feeling says no, but it's best to ask.
no
OK
If I want to try this out locally first, can I test it in my local repo
${user.home}/.m2/repository/... or do I need to use a local httpd
serving as a central repo?
local is ok
Cool, I'll have a go at it, to see it I can get it right. It'll have
to wait until this weekend though.
--
Dennis Lundberg
Carlos Sanchez wrote:
You are right. This would involve copying all the old group sutff to
the new group and add the relocation poms.
On 6/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
AFAIK there is a way in maven repo to relocate dependencies, so
that a
POM for any commons can be published at commons-xxx groupId, that
relocates to org.apache.commons groupId.
Servletapi for example is now under javax.servlet
http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom
Using this, when maven2 search for the latest release of any
commons
it will look at the relocated one.
Torsten Curdt a écrit :
Brett,
any comments on this?
cheers
--
Torsten
On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Brett, I did the test that you suggested.
1. Installed commons-lang 1.0.1 into my local repo with
groupId=org.apache.commons
mvn install:install-file -DgroupId=org.apache.commons
-DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar
-Dfile=/path/to/commons-lang-1.0.1.jar
2. Created Maven 2 projects a, b and c with the dependencies
mentioned
below.
3. Installed projects a and b into my local repo
mvn install
4. packaged project c as a war
mvn package
The resulting war file includes both commons-lang-1.0.1.jar and
commons-lang-2.1.jar which was what you thought would happen.
So this is bad, I guess. Anyone who uses commons components
transitively
in a Maven 2 environment are likely to be bitten by this. They
must
keep
the same groupId for all commons-lang dependencies, as an
example, in
the entire chain of transitive dependencies. I.e. they can't mix
groupId=commons-lang and groupId=org.apache.commons. This can
be a
PITA
since some of the dependencies are most likely out of the
projects own
control.
What do you suggest we do? Should we wait with this relocation
until a
version of Maven 2 is released that can handle these kind of
dependencies?
--
Dennis Lundberg
Brett Porter wrote:
an extensive test should be something along the lines of:
project A depends on commons-lang:commons-lang 2.1
project B depends on o.a.c:commons-lang 1.0
project C is a webapp that depends on A and B
webapp should have only one commons-lang.
You could do this with your own repository (and something
completely
artificial instead of commons-lang if it makes it easier).
- Brett
Dennis Lundberg wrote:
Hi Brett
Sorry, I misunderstood you regarding when to do the
testing. So,
no I
haven't done the test, yet. Can you elaborate a bit more on
what
needs
to be tested? Perhaps you know of an artifact that has been
relocated
that we can have a
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Brett, any comments on this? cheers -- Torsten On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Brett, I did the test that you suggested. 1. Installed commons-lang 1.0.1 into my local repo with groupId=org.apache.commons mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/commons-lang-1.0.1.jar 2. Created Maven 2 projects a, b and c with the dependencies mentioned below. 3. Installed projects a and b into my local repo mvn install 4. packaged project c as a war mvn package The resulting war file includes both commons-lang-1.0.1.jar and commons-lang-2.1.jar which was what you thought would happen. So this is bad, I guess. Anyone who uses commons components transitively in a Maven 2 environment are likely to be bitten by this. They must keep the same groupId for all commons-lang dependencies, as an example, in the entire chain of transitive dependencies. I.e. they can't mix groupId=commons-lang and groupId=org.apache.commons. This can be a PITA since some of the dependencies are most likely out of the projects own control. What do you suggest we do? Should we wait with this relocation until a version of Maven 2 is released that can handle these kind of dependencies? -- Dennis Lundberg Brett Porter wrote: an extensive test should be something along the lines of: project A depends on commons-lang:commons-lang 2.1 project B depends on o.a.c:commons-lang 1.0 project C is a webapp that depends on A and B webapp should have only one commons-lang. You could do this with your own repository (and something completely artificial instead of commons-lang if it makes it easier). - Brett Dennis Lundberg wrote: Hi Brett Sorry, I misunderstood you regarding when to do the testing. So, no I haven't done the test, yet. Can you elaborate a bit more on what needs to be tested? Perhaps you know of an artifact that has been relocated that we can have a look at, to see how they have done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
AFAIK there is a way in maven repo to relocate dependencies, so that a POM for any commons can be published at commons-xxx groupId, that relocates to org.apache.commons groupId. Servletapi for example is now under javax.servlet http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom Using this, when maven2 search for the latest release of any commons it will look at the relocated one. Torsten Curdt a écrit : Brett, any comments on this? cheers -- Torsten On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Brett, I did the test that you suggested. 1. Installed commons-lang 1.0.1 into my local repo with groupId=org.apache.commons mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/commons-lang-1.0.1.jar 2. Created Maven 2 projects a, b and c with the dependencies mentioned below. 3. Installed projects a and b into my local repo mvn install 4. packaged project c as a war mvn package The resulting war file includes both commons-lang-1.0.1.jar and commons-lang-2.1.jar which was what you thought would happen. So this is bad, I guess. Anyone who uses commons components transitively in a Maven 2 environment are likely to be bitten by this. They must keep the same groupId for all commons-lang dependencies, as an example, in the entire chain of transitive dependencies. I.e. they can't mix groupId=commons-lang and groupId=org.apache.commons. This can be a PITA since some of the dependencies are most likely out of the projects own control. What do you suggest we do? Should we wait with this relocation until a version of Maven 2 is released that can handle these kind of dependencies? -- Dennis Lundberg Brett Porter wrote: an extensive test should be something along the lines of: project A depends on commons-lang:commons-lang 2.1 project B depends on o.a.c:commons-lang 1.0 project C is a webapp that depends on A and B webapp should have only one commons-lang. You could do this with your own repository (and something completely artificial instead of commons-lang if it makes it easier). - Brett Dennis Lundberg wrote: Hi Brett Sorry, I misunderstood you regarding when to do the testing. So, no I haven't done the test, yet. Can you elaborate a bit more on what needs to be tested? Perhaps you know of an artifact that has been relocated that we can have a look at, to see how they have done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
You are right. This would involve copying all the old group sutff to the new group and add the relocation poms. On 6/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote: AFAIK there is a way in maven repo to relocate dependencies, so that a POM for any commons can be published at commons-xxx groupId, that relocates to org.apache.commons groupId. Servletapi for example is now under javax.servlet http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom Using this, when maven2 search for the latest release of any commons it will look at the relocated one. Torsten Curdt a écrit : Brett, any comments on this? cheers -- Torsten On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Brett, I did the test that you suggested. 1. Installed commons-lang 1.0.1 into my local repo with groupId=org.apache.commons mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/commons-lang-1.0.1.jar 2. Created Maven 2 projects a, b and c with the dependencies mentioned below. 3. Installed projects a and b into my local repo mvn install 4. packaged project c as a war mvn package The resulting war file includes both commons-lang-1.0.1.jar and commons-lang-2.1.jar which was what you thought would happen. So this is bad, I guess. Anyone who uses commons components transitively in a Maven 2 environment are likely to be bitten by this. They must keep the same groupId for all commons-lang dependencies, as an example, in the entire chain of transitive dependencies. I.e. they can't mix groupId=commons-lang and groupId=org.apache.commons. This can be a PITA since some of the dependencies are most likely out of the projects own control. What do you suggest we do? Should we wait with this relocation until a version of Maven 2 is released that can handle these kind of dependencies? -- Dennis Lundberg Brett Porter wrote: an extensive test should be something along the lines of: project A depends on commons-lang:commons-lang 2.1 project B depends on o.a.c:commons-lang 1.0 project C is a webapp that depends on A and B webapp should have only one commons-lang. You could do this with your own repository (and something completely artificial instead of commons-lang if it makes it easier). - Brett Dennis Lundberg wrote: Hi Brett Sorry, I misunderstood you regarding when to do the testing. So, no I haven't done the test, yet. Can you elaborate a bit more on what needs to be tested? Perhaps you know of an artifact that has been relocated that we can have a look at, to see how they have done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
So, in the simple example below, covering commons-lang, the procedure
would be:
1. Copy all files from /commons-lang/ to
/org/apache/commons/commons-lang/ in the *Apache* repo
2. Change the groupId of all the pom files under
/org/apache/commons/commons-lang/ so that they use the
org.apache.commons groupId
3. Add relocation elements to all pom files in /commons-lang/ pointing
them to org.apache.commons like this:
relocation
groupIdorg.apache.commons/groupId
/relocation
If I understand the model documentation correctly, we shouldn't have to
use artifactId or version since they are the same. But should we add a
message ?
4. Wait for a sync between the Apache repo and ibiblio, or is this
something that we need to ping someone about?
Is that correct so far?
When we later decide to release our first artifact using the new
groupId, should we also copy it to the repo using the groupId? My gut
feeling says no, but it's best to ask.
If I want to try this out locally first, can I test it in my local repo
${user.home}/.m2/repository/... or do I need to use a local httpd
serving as a central repo?
--
Dennis Lundberg
Carlos Sanchez wrote:
You are right. This would involve copying all the old group sutff to
the new group and add the relocation poms.
On 6/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
AFAIK there is a way in maven repo to relocate dependencies, so that a
POM for any commons can be published at commons-xxx groupId, that
relocates to org.apache.commons groupId.
Servletapi for example is now under javax.servlet
http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom
Using this, when maven2 search for the latest release of any commons
it will look at the relocated one.
Torsten Curdt a écrit :
Brett,
any comments on this?
cheers
--
Torsten
On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Brett, I did the test that you suggested.
1. Installed commons-lang 1.0.1 into my local repo with
groupId=org.apache.commons
mvn install:install-file -DgroupId=org.apache.commons
-DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar
-Dfile=/path/to/commons-lang-1.0.1.jar
2. Created Maven 2 projects a, b and c with the dependencies mentioned
below.
3. Installed projects a and b into my local repo
mvn install
4. packaged project c as a war
mvn package
The resulting war file includes both commons-lang-1.0.1.jar and
commons-lang-2.1.jar which was what you thought would happen.
So this is bad, I guess. Anyone who uses commons components
transitively
in a Maven 2 environment are likely to be bitten by this. They must
keep
the same groupId for all commons-lang dependencies, as an example, in
the entire chain of transitive dependencies. I.e. they can't mix
groupId=commons-lang and groupId=org.apache.commons. This can be a
PITA
since some of the dependencies are most likely out of the projects own
control.
What do you suggest we do? Should we wait with this relocation until a
version of Maven 2 is released that can handle these kind of
dependencies?
--
Dennis Lundberg
Brett Porter wrote:
an extensive test should be something along the lines of:
project A depends on commons-lang:commons-lang 2.1
project B depends on o.a.c:commons-lang 1.0
project C is a webapp that depends on A and B
webapp should have only one commons-lang.
You could do this with your own repository (and something completely
artificial instead of commons-lang if it makes it easier).
- Brett
Dennis Lundberg wrote:
Hi Brett
Sorry, I misunderstood you regarding when to do the testing. So,
no I
haven't done the test, yet. Can you elaborate a bit more on what
needs
to be tested? Perhaps you know of an artifact that has been
relocated
that we can have a look at, to see how they have done.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Are you thinking about doing it in the m1 or m2 repo?
see below
On 6/7/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
So, in the simple example below, covering commons-lang, the procedure
would be:
1. Copy all files from /commons-lang/ to
/org/apache/commons/commons-lang/ in the *Apache* repo
2. Change the groupId of all the pom files under
/org/apache/commons/commons-lang/ so that they use the
org.apache.commons groupId
3. Add relocation elements to all pom files in /commons-lang/ pointing
them to org.apache.commons like this:
relocation
groupIdorg.apache.commons/groupId
/relocation
If I understand the model documentation correctly, we shouldn't have to
use artifactId or version since they are the same. But should we add a
message ?
I never did.
4. Wait for a sync between the Apache repo and ibiblio, or is this
something that we need to ping someone about?
m1 repo - wait
m2 repo - ping
Is that correct so far?
When we later decide to release our first artifact using the new
groupId, should we also copy it to the repo using the groupId? My gut
feeling says no, but it's best to ask.
no
If I want to try this out locally first, can I test it in my local repo
${user.home}/.m2/repository/... or do I need to use a local httpd
serving as a central repo?
local is ok
--
Dennis Lundberg
Carlos Sanchez wrote:
You are right. This would involve copying all the old group sutff to
the new group and add the relocation poms.
On 6/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
AFAIK there is a way in maven repo to relocate dependencies, so that a
POM for any commons can be published at commons-xxx groupId, that
relocates to org.apache.commons groupId.
Servletapi for example is now under javax.servlet
http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom
Using this, when maven2 search for the latest release of any commons
it will look at the relocated one.
Torsten Curdt a écrit :
Brett,
any comments on this?
cheers
--
Torsten
On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Brett, I did the test that you suggested.
1. Installed commons-lang 1.0.1 into my local repo with
groupId=org.apache.commons
mvn install:install-file -DgroupId=org.apache.commons
-DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar
-Dfile=/path/to/commons-lang-1.0.1.jar
2. Created Maven 2 projects a, b and c with the dependencies mentioned
below.
3. Installed projects a and b into my local repo
mvn install
4. packaged project c as a war
mvn package
The resulting war file includes both commons-lang-1.0.1.jar and
commons-lang-2.1.jar which was what you thought would happen.
So this is bad, I guess. Anyone who uses commons components
transitively
in a Maven 2 environment are likely to be bitten by this. They must
keep
the same groupId for all commons-lang dependencies, as an example, in
the entire chain of transitive dependencies. I.e. they can't mix
groupId=commons-lang and groupId=org.apache.commons. This can be a
PITA
since some of the dependencies are most likely out of the projects own
control.
What do you suggest we do? Should we wait with this relocation until a
version of Maven 2 is released that can handle these kind of
dependencies?
--
Dennis Lundberg
Brett Porter wrote:
an extensive test should be something along the lines of:
project A depends on commons-lang:commons-lang 2.1
project B depends on o.a.c:commons-lang 1.0
project C is a webapp that depends on A and B
webapp should have only one commons-lang.
You could do this with your own repository (and something completely
artificial instead of commons-lang if it makes it easier).
- Brett
Dennis Lundberg wrote:
Hi Brett
Sorry, I misunderstood you regarding when to do the testing. So,
no I
haven't done the test, yet. Can you elaborate a bit more on what
needs
to be tested? Perhaps you know of an artifact that has been
relocated
that we can have a look at, to see how they have done.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Carlos Sanchez wrote:
Are you thinking about doing it in the m1 or m2 repo?
I really don't have a clue. Since I have not acted as release manager
for any component, I haven't really done my homework on what the
difference between the two is. I know about the M1 an M2 repos at
ibiblio, and that there is some sort of conversion between them, but
don't know what it looks like at the Apache end.
Do you have any suggestions on which is better?
see below
On 6/7/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
So, in the simple example below, covering commons-lang, the procedure
would be:
1. Copy all files from /commons-lang/ to
/org/apache/commons/commons-lang/ in the *Apache* repo
2. Change the groupId of all the pom files under
/org/apache/commons/commons-lang/ so that they use the
org.apache.commons groupId
3. Add relocation elements to all pom files in /commons-lang/ pointing
them to org.apache.commons like this:
relocation
groupIdorg.apache.commons/groupId
/relocation
If I understand the model documentation correctly, we shouldn't have to
use artifactId or version since they are the same. But should we add a
message ?
I never did.
4. Wait for a sync between the Apache repo and ibiblio, or is this
something that we need to ping someone about?
m1 repo - wait
m2 repo - ping
OK
Is that correct so far?
When we later decide to release our first artifact using the new
groupId, should we also copy it to the repo using the groupId? My gut
feeling says no, but it's best to ask.
no
OK
If I want to try this out locally first, can I test it in my local repo
${user.home}/.m2/repository/... or do I need to use a local httpd
serving as a central repo?
local is ok
Cool, I'll have a go at it, to see it I can get it right. It'll have to
wait until this weekend though.
--
Dennis Lundberg
Carlos Sanchez wrote:
You are right. This would involve copying all the old group sutff to
the new group and add the relocation poms.
On 6/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
AFAIK there is a way in maven repo to relocate dependencies, so
that a
POM for any commons can be published at commons-xxx groupId, that
relocates to org.apache.commons groupId.
Servletapi for example is now under javax.servlet
http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom
Using this, when maven2 search for the latest release of any commons
it will look at the relocated one.
Torsten Curdt a écrit :
Brett,
any comments on this?
cheers
--
Torsten
On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Brett, I did the test that you suggested.
1. Installed commons-lang 1.0.1 into my local repo with
groupId=org.apache.commons
mvn install:install-file -DgroupId=org.apache.commons
-DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar
-Dfile=/path/to/commons-lang-1.0.1.jar
2. Created Maven 2 projects a, b and c with the dependencies
mentioned
below.
3. Installed projects a and b into my local repo
mvn install
4. packaged project c as a war
mvn package
The resulting war file includes both commons-lang-1.0.1.jar and
commons-lang-2.1.jar which was what you thought would happen.
So this is bad, I guess. Anyone who uses commons components
transitively
in a Maven 2 environment are likely to be bitten by this. They must
keep
the same groupId for all commons-lang dependencies, as an
example, in
the entire chain of transitive dependencies. I.e. they can't mix
groupId=commons-lang and groupId=org.apache.commons. This can be a
PITA
since some of the dependencies are most likely out of the
projects own
control.
What do you suggest we do? Should we wait with this relocation
until a
version of Maven 2 is released that can handle these kind of
dependencies?
--
Dennis Lundberg
Brett Porter wrote:
an extensive test should be something along the lines of:
project A depends on commons-lang:commons-lang 2.1
project B depends on o.a.c:commons-lang 1.0
project C is a webapp that depends on A and B
webapp should have only one commons-lang.
You could do this with your own repository (and something
completely
artificial instead of commons-lang if it makes it easier).
- Brett
Dennis Lundberg wrote:
Hi Brett
Sorry, I misunderstood you regarding when to do the testing. So,
no I
haven't done the test, yet. Can you elaborate a bit more on what
needs
to be tested? Perhaps you know of an artifact that has been
relocated
that we can have a look at, to see how they have done.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Brett, I did the test that you suggested. 1. Installed commons-lang 1.0.1 into my local repo with groupId=org.apache.commons mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/commons-lang-1.0.1.jar 2. Created Maven 2 projects a, b and c with the dependencies mentioned below. 3. Installed projects a and b into my local repo mvn install 4. packaged project c as a war mvn package The resulting war file includes both commons-lang-1.0.1.jar and commons-lang-2.1.jar which was what you thought would happen. So this is bad, I guess. Anyone who uses commons components transitively in a Maven 2 environment are likely to be bitten by this. They must keep the same groupId for all commons-lang dependencies, as an example, in the entire chain of transitive dependencies. I.e. they can't mix groupId=commons-lang and groupId=org.apache.commons. This can be a PITA since some of the dependencies are most likely out of the projects own control. What do you suggest we do? Should we wait with this relocation until a version of Maven 2 is released that can handle these kind of dependencies? -- Dennis Lundberg Brett Porter wrote: an extensive test should be something along the lines of: project A depends on commons-lang:commons-lang 2.1 project B depends on o.a.c:commons-lang 1.0 project C is a webapp that depends on A and B webapp should have only one commons-lang. You could do this with your own repository (and something completely artificial instead of commons-lang if it makes it easier). - Brett Dennis Lundberg wrote: Hi Brett Sorry, I misunderstood you regarding when to do the testing. So, no I haven't done the test, yet. Can you elaborate a bit more on what needs to be tested? Perhaps you know of an artifact that has been relocated that we can have a look at, to see how they have done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
an extensive test should be something along the lines of: project A depends on commons-lang:commons-lang 2.1 project B depends on o.a.c:commons-lang 1.0 project C is a webapp that depends on A and B webapp should have only one commons-lang. You could do this with your own repository (and something completely artificial instead of commons-lang if it makes it easier). - Brett Dennis Lundberg wrote: Hi Brett Sorry, I misunderstood you regarding when to do the testing. So, no I haven't done the test, yet. Can you elaborate a bit more on what needs to be tested? Perhaps you know of an artifact that has been relocated that we can have a look at, to see how they have done. -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Since I see these are all being changed now, I thought it would be a good idea to check if anyone did the test I mentioned to make sure it will work? - Brett Brett Porter wrote: In Maven 2.1, it will be able to correlate between the two, but currently they'll end up in there twice. I'd suggest when a release first does this, it's going to need to move all the old versions to the new group ID, and add a relocation for the original group IDs to get it to work, as you've indicated here. It would be a good idea to do a test on this first, of course. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Hi Brett Sorry, I misunderstood you regarding when to do the testing. So, no I haven't done the test, yet. Can you elaborate a bit more on what needs to be tested? Perhaps you know of an artifact that has been relocated that we can have a look at, to see how they have done. -- Dennis Lundberg Brett Porter wrote: Since I see these are all being changed now, I thought it would be a good idea to check if anyone did the test I mentioned to make sure it will work? - Brett Brett Porter wrote: In Maven 2.1, it will be able to correlate between the two, but currently they'll end up in there twice. I'd suggest when a release first does this, it's going to need to move all the old versions to the new group ID, and add a relocation for the original group IDs to get it to work, as you've indicated here. It would be a good idea to do a test on this first, of course. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Henri Yandell wrote: On 5/18/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Henri Yandell wrote: On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? Opening this up again. groupId: org.apache.commons or groupId: org.apache.commons.X ?? As one of the goals in the commons charter (12) is to have one jar (=one artifact) per subproject, I believe that org.apache.commons will work nicely. The M2 repository has a better hierarchical structure, so I'm not sure we have to worry about jamming X in place. Here's the m2 repo for my commons-alike testing project: http://www.ibiblio.org/maven2/genjava/ I'm thinking a group id of org.apache.commons for each component would work well. We've got both logging and collections in need of deployment. Also need to start putting the javadoc and sources in there too if possible. What would be the best way to do this? Should we try to cram this into the Apache Maven 1 repo or should we start to provide Maven 2 POMs for all commons components instead? The Maven 2 repo has better support for these kinds of extras. Maven 1 repo; until we start doing it automatically from an m2 build system. Less chance of us messing up the m2 repo that way. So, should we go ahead and do this or does it require a vote? snip/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On Thu, 2006-05-18 at 11:02 +1000, Torsten Curdt wrote: Opening this up again. groupId: org.apache.commons +1!! ditto - robet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Henri Yandell wrote: On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? Opening this up again. groupId: org.apache.commons or groupId: org.apache.commons.X ?? As one of the goals in the commons charter (12) is to have one jar (=one artifact) per subproject, I believe that org.apache.commons will work nicely. The M2 repository has a better hierarchical structure, so I'm not sure we have to worry about jamming X in place. Here's the m2 repo for my commons-alike testing project: http://www.ibiblio.org/maven2/genjava/ I'm thinking a group id of org.apache.commons for each component would work well. We've got both logging and collections in need of deployment. Also need to start putting the javadoc and sources in there too if possible. What would be the best way to do this? Should we try to cram this into the Apache Maven 1 repo or should we start to provide Maven 2 POMs for all commons components instead? The Maven 2 repo has better support for these kinds of extras. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On 5/18/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Henri Yandell wrote: On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? Opening this up again. groupId: org.apache.commons or groupId: org.apache.commons.X ?? As one of the goals in the commons charter (12) is to have one jar (=one artifact) per subproject, I believe that org.apache.commons will work nicely. The M2 repository has a better hierarchical structure, so I'm not sure we have to worry about jamming X in place. Here's the m2 repo for my commons-alike testing project: http://www.ibiblio.org/maven2/genjava/ I'm thinking a group id of org.apache.commons for each component would work well. We've got both logging and collections in need of deployment. Also need to start putting the javadoc and sources in there too if possible. What would be the best way to do this? Should we try to cram this into the Apache Maven 1 repo or should we start to provide Maven 2 POMs for all commons components instead? The Maven 2 repo has better support for these kinds of extras. Maven 1 repo; until we start doing it automatically from an m2 build system. Less chance of us messing up the m2 repo that way. I'm working on deploying a lot of the javadoc.jars for commons versions; then will do sources. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On 5/18/06, Henri Yandell [EMAIL PROTECTED] wrote: On 5/18/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Henri Yandell wrote: On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? Opening this up again. groupId: org.apache.commons or groupId: org.apache.commons.X ?? As one of the goals in the commons charter (12) is to have one jar (=one artifact) per subproject, I believe that org.apache.commons will work nicely. The M2 repository has a better hierarchical structure, so I'm not sure we have to worry about jamming X in place. Here's the m2 repo for my commons-alike testing project: http://www.ibiblio.org/maven2/genjava/ I'm thinking a group id of org.apache.commons for each component would work well. We've got both logging and collections in need of deployment. Also need to start putting the javadoc and sources in there too if possible. What would be the best way to do this? Should we try to cram this into the Apache Maven 1 repo or should we start to provide Maven 2 POMs for all commons components instead? The Maven 2 repo has better support for these kinds of extras. Maven 1 repo; until we start doing it automatically from an m2 build system. Less chance of us messing up the m2 repo that way. I'm working on deploying a lot of the javadoc.jars for commons versions; then will do sources. Out of curiousity, why exactly do we want to duplicate the distribution of these things? What exactly does it buy us or our users? What is so hard / onerous about just downloading the official distros? I understand (and depend on) the practical value of the maven repo for binary jars, but don't see the compelling reason to duplicate src and javadoc distros. Until we have good automated signing and distribution from tags in place, I think we should avoid unnecessary duplication and as much as possible hold onto the connection tag - vote - distro - sig Breaking things apart and redistributing manually is asking for trouble, IMHO. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Sources and javadocs are great for maven users because when maven generates the IDE projects it will check the repo for them, download and link inside the IDE, enabling debugging through third party sources or reading the javadocs while coding. On 5/18/06, Phil Steitz [EMAIL PROTECTED] wrote: On 5/18/06, Henri Yandell [EMAIL PROTECTED] wrote: On 5/18/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Henri Yandell wrote: On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? Opening this up again. groupId: org.apache.commons or groupId: org.apache.commons.X ?? As one of the goals in the commons charter (12) is to have one jar (=one artifact) per subproject, I believe that org.apache.commons will work nicely. The M2 repository has a better hierarchical structure, so I'm not sure we have to worry about jamming X in place. Here's the m2 repo for my commons-alike testing project: http://www.ibiblio.org/maven2/genjava/ I'm thinking a group id of org.apache.commons for each component would work well. We've got both logging and collections in need of deployment. Also need to start putting the javadoc and sources in there too if possible. What would be the best way to do this? Should we try to cram this into the Apache Maven 1 repo or should we start to provide Maven 2 POMs for all commons components instead? The Maven 2 repo has better support for these kinds of extras. Maven 1 repo; until we start doing it automatically from an m2 build system. Less chance of us messing up the m2 repo that way. I'm working on deploying a lot of the javadoc.jars for commons versions; then will do sources. Out of curiousity, why exactly do we want to duplicate the distribution of these things? What exactly does it buy us or our users? What is so hard / onerous about just downloading the official distros? I understand (and depend on) the practical value of the maven repo for binary jars, but don't see the compelling reason to duplicate src and javadoc distros. Until we have good automated signing and distribution from tags in place, I think we should avoid unnecessary duplication and as much as possible hold onto the connection tag - vote - distro - sig Breaking things apart and redistributing manually is asking for trouble, IMHO. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
It's also good for providing a standard way of doing things. Our .zip files are terribly unstandard. We have source in /src/ /src/java /src/share and /src/main (at least), and javadoc in /api /apidocs /api/docs and others. I was under the understanding that regardless of maven usage, the src and javadoc jars were more useful for users of the IDEs. That the IDE could point at those jars when it can't point at the zips. Hen On 5/18/06, Carlos Sanchez [EMAIL PROTECTED] wrote: Sources and javadocs are great for maven users because when maven generates the IDE projects it will check the repo for them, download and link inside the IDE, enabling debugging through third party sources or reading the javadocs while coding. On 5/18/06, Phil Steitz [EMAIL PROTECTED] wrote: On 5/18/06, Henri Yandell [EMAIL PROTECTED] wrote: On 5/18/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Henri Yandell wrote: On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? Opening this up again. groupId: org.apache.commons or groupId: org.apache.commons.X ?? As one of the goals in the commons charter (12) is to have one jar (=one artifact) per subproject, I believe that org.apache.commons will work nicely. The M2 repository has a better hierarchical structure, so I'm not sure we have to worry about jamming X in place. Here's the m2 repo for my commons-alike testing project: http://www.ibiblio.org/maven2/genjava/ I'm thinking a group id of org.apache.commons for each component would work well. We've got both logging and collections in need of deployment. Also need to start putting the javadoc and sources in there too if possible. What would be the best way to do this? Should we try to cram this into the Apache Maven 1 repo or should we start to provide Maven 2 POMs for all commons components instead? The Maven 2 repo has better support for these kinds of extras. Maven 1 repo; until we start doing it automatically from an m2 build system. Less chance of us messing up the m2 repo that way. I'm working on deploying a lot of the javadoc.jars for commons versions; then will do sources. Out of curiousity, why exactly do we want to duplicate the distribution of these things? What exactly does it buy us or our users? What is so hard / onerous about just downloading the official distros? I understand (and depend on) the practical value of the maven repo for binary jars, but don't see the compelling reason to duplicate src and javadoc distros. Until we have good automated signing and distribution from tags in place, I think we should avoid unnecessary duplication and as much as possible hold onto the connection tag - vote - distro - sig Breaking things apart and redistributing manually is asking for trouble, IMHO. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? Opening this up again. groupId: org.apache.commons or groupId: org.apache.commons.X ?? The M2 repository has a better hierarchical structure, so I'm not sure we have to worry about jamming X in place. Here's the m2 repo for my commons-alike testing project: http://www.ibiblio.org/maven2/genjava/ I'm thinking a group id of org.apache.commons for each component would work well. We've got both logging and collections in need of deployment. Also need to start putting the javadoc and sources in there too if possible. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Opening this up again. groupId: org.apache.commons +1!! cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On 5/17/06, Henri Yandell [EMAIL PROTECTED] wrote: On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? Opening this up again. groupId: org.apache.commons or groupId: org.apache.commons.X The former. -- Martin Cooper ?? The M2 repository has a better hierarchical structure, so I'm not sure we have to worry about jamming X in place. Here's the m2 repo for my commons-alike testing project: http://www.ibiblio.org/maven2/genjava/ I'm thinking a group id of org.apache.commons for each component would work well. We've got both logging and collections in need of deployment. Also need to start putting the javadoc and sources in there too if possible. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On Sun, 2006-05-14 at 12:32 -0700, Phil Steitz wrote: On 5/14/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sat, 2006-05-13 at 15:21 -0700, Henri Yandell wrote:# snip I feel that we should be using ACL's on the maven repository on minotaur such that only a PMC can release their code onto the maven repository - but there hasn't seemed much interest in trying to do such. IMHO bit pointless ATM. need to remove shell from the distribution machine before changes like this are worthwhile. but definitely worth bringing up again in a month or two. i've been thinking about using subversion to manage distributions. in addition to better ACLs, this would allow scripts to be run that could verify signatures. be a good thing to move to henk's system of key management as well. What is that system? many months ago, henk penning presented a system for ASF OpenPGP key management but i can't find a reference right now. with a bit of luck i might be able to catch up with henk at apachecon europe... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On 5/15/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sun, 2006-05-14 at 12:32 -0700, Phil Steitz wrote: On 5/14/06, robert burrell donkin [EMAIL PROTECTED] wrote: be a good thing to move to henk's system of key management as well. What is that system? many months ago, henk penning presented a system for ASF OpenPGP key management but i can't find a reference right now. with a bit of luck i might be able to catch up with henk at apachecon europe... Some of it is here: http://people.apache.org/~henkp/trust/ Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On Sat, 2006-05-13 at 15:21 -0700, Henri Yandell wrote:# snip I feel that we should be using ACL's on the maven repository on minotaur such that only a PMC can release their code onto the maven repository - but there hasn't seemed much interest in trying to do such. IMHO bit pointless ATM. need to remove shell from the distribution machine before changes like this are worthwhile. but definitely worth bringing up again in a month or two. i've been thinking about using subversion to manage distributions. in addition to better ACLs, this would allow scripts to be run that could verify signatures. be a good thing to move to henk's system of key management as well. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On 5/14/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sat, 2006-05-13 at 15:21 -0700, Henri Yandell wrote:# snip I feel that we should be using ACL's on the maven repository on minotaur such that only a PMC can release their code onto the maven repository - but there hasn't seemed much interest in trying to do such. IMHO bit pointless ATM. need to remove shell from the distribution machine before changes like this are worthwhile. but definitely worth bringing up again in a month or two. i've been thinking about using subversion to manage distributions. in addition to better ACLs, this would allow scripts to be run that could verify signatures. be a good thing to move to henk's system of key management as well. What is that system? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? how much hassle would this change be for downstream consumers? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
robert burrell donkin wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? I think we should do it, but I remember that Henri had some reservations when this was discussed last time. It had something to do with the local Apache repo and where Jakarta artifact should be in that repo. Perhaps he can fill us in on that situation. If it is decided that this should be done I volunteer to help out with the move. how much hassle would this change be for downstream consumers? Not much. When a downstream consumer wants to upgrade a Jakarta Commons dependency they will have to change groupId as well as version, instead of just the version. This move has already been made for several other (Apache) jars and is the right way to go. Have a look at http://www.ibiblio.org/maven2/org/apache/ to see the current status. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? I would be in favour of that. The sooner all ASF projects use a consistent groupId scheme, the better. how much hassle would this change be for downstream consumers? Virtually none, as long as we make the change obvious, e.g. by including the groupId and artifactId in release announcements and download pages, or somewhere of that sort. -- Martin Cooper - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On 5/13/06, Dennis Lundberg [EMAIL PROTECTED] wrote: robert burrell donkin wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? I think we should do it, but I remember that Henri had some reservations when this was discussed last time. It had something to do with the local Apache repo and where Jakarta artifact should be in that repo. Perhaps he can fill us in on that situation. +1 to making the change. My only question is whether we use Java package naming (org.apache.commons) or Apache structure (org.apache.jakarta or org.apache.jakarta.commons). I feel that we should be using ACL's on the maven repository on minotaur such that only a PMC can release their code onto the maven repository - but there hasn't seemed much interest in trying to do such. So I'm fine with org.apache.commons. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On Sat, 2006-05-13 at 11:30 -0700, Martin Cooper wrote: On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? I would be in favour of that. The sooner all ASF projects use a consistent groupId scheme, the better. how much hassle would this change be for downstream consumers? Virtually none, as long as we make the change obvious, e.g. by including the groupId and artifactId in release announcements and download pages, or somewhere of that sort. What happens if someone has a project that has the following dependencies: project depends on A, B A depends on group=commons-lang, artifact=commons-lang B depends on group=org.apache.commons.lang, artifact=commons-lang Is maven smart enough to avoid putting lang in the dependencies twice? There is a special POM entry that can indicate a relocation of the target. I don't know the details of how this works though. http://maven.apache.org/ref/current/maven-model/maven.html#class_relocation In general, though, I'm in favour of the move to a properly structured group-id. As maven gets more popular (the repo gains more entries), the existing flattish structure becomes harder to manage. And from the volume of messages on the maven lists, its popularity is growing fast.. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
In Maven 2.1, it will be able to correlate between the two, but currently they'll end up in there twice. I'd suggest when a release first does this, it's going to need to move all the old versions to the new group ID, and add a relocation for the original group IDs to get it to work, as you've indicated here. It would be a good idea to do a test on this first, of course. - Brett Simon Kitching wrote: On Sat, 2006-05-13 at 11:30 -0700, Martin Cooper wrote: On 5/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Thu, 2006-04-06 at 08:51 +0200, Nicolas De Loof wrote: I agree about NOT making non-final jars available on ibiblio (httpclient beeing an exception) So could the next RC be uploaded to http://cvs.apache.org/maven-snapshot-repository/ ? Please also consider using the new groupId recommandation for apache commons-X : org.apache.commons.X should we make this change for the whole of the commons? I would be in favour of that. The sooner all ASF projects use a consistent groupId scheme, the better. how much hassle would this change be for downstream consumers? Virtually none, as long as we make the change obvious, e.g. by including the groupId and artifactId in release announcements and download pages, or somewhere of that sort. What happens if someone has a project that has the following dependencies: project depends on A, B A depends on group=commons-lang, artifact=commons-lang B depends on group=org.apache.commons.lang, artifact=commons-lang Is maven smart enough to avoid putting lang in the dependencies twice? There is a special POM entry that can indicate a relocation of the target. I don't know the details of how this works though. http://maven.apache.org/ref/current/maven-model/maven.html#class_relocation In general, though, I'm in favour of the move to a properly structured group-id. As maven gets more popular (the repo gains more entries), the existing flattish structure becomes harder to manage. And from the volume of messages on the maven lists, its popularity is growing fast.. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
