You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Nicolas De Loof <ni...@capgemini.com> on 2006/04/05 10:05:15 UTC
[logging] RC on ibiblio ?
Hello,
Can someone upload commons-logging RC on Maven2 ibiblio repository ?
It would be very cool to also upload a POM and the sources jar...
Nico.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] RC on ibiblio ?
Posted by Henri Yandell <fl...@gmail.com>.
On 4/5/06, Martin Cooper <ma...@apache.org> wrote:
> On 4/5/06, Carlos Sanchez <ca...@apache.org> wrote:
> >
> > On 4/5/06, robert burrell donkin <ro...@blueyonder.co.uk>
> > wrote:
> > > sadly policy dictates that we can't upload release candidates to ibiblio
> >
> > AFAIK is PMC decision what gets uploaded
>
>
> No, this is bigger than any individual PMC. Only official releases can be
> deployed outside of ASF infrastructure, meaning that RCs cannot be deployed
> to ibiblio or made available via mirrors.
+1.
>From this I infer:
* If it goes in the maven release repo, it should be available as a
zip/tar.gz too.
* The PMC has to consider it to be an official release.
I think that a beta can be an official release - that's the decision a
PMC would be having to decide upon - but you can't be doing partial
releases (to maven repo only). There are lots of betas and alphas on
the mirrors.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] RC on ibiblio ?
Posted by Martin Cooper <ma...@apache.org>.
On 4/5/06, Carlos Sanchez <ca...@apache.org> wrote:
>
> On 4/5/06, robert burrell donkin <ro...@blueyonder.co.uk>
> wrote:
> > sadly policy dictates that we can't upload release candidates to ibiblio
>
> AFAIK is PMC decision what gets uploaded
No, this is bigger than any individual PMC. Only official releases can be
deployed outside of ASF infrastructure, meaning that RCs cannot be deployed
to ibiblio or made available via mirrors.
--
Martin Cooper
---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [logging] RC on ibiblio ?
Posted by Henri Yandell <fl...@gmail.com>.
On 4/5/06, Carlos Sanchez <ca...@apache.org> wrote:
> On 4/5/06, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
> > sadly policy dictates that we can't upload release candidates to ibiblio
>
> AFAIK is PMC decision what gets uploaded
Yep. You can't upload snapshots to ibiblio - RC is a vague grey area
and I think it comes down to the lifetime expected of it. HttpClient
has had RC candidates out there for many months at a time (and thus on
ibiblio), with people dependent on them in production etc. Most other
Commons components just use 'RC' to mean a test-build for the real
thing; should never appear in a user product.
So - what does this RC mean? Is there a better name (so as not to
confuse with the general RC usage)?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] RC on ibiblio ?
Posted by Carlos Sanchez <ca...@apache.org>.
On 4/5/06, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
> sadly policy dictates that we can't upload release candidates to ibiblio
AFAIK is PMC decision what gets uploaded
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Martin Cooper <ma...@apache.org>.
On 5/13/06, robert burrell donkin <ro...@blueyonder.co.uk>
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Henri Yandell <fl...@gmail.com>.
On 5/15/06, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
> On Sun, 2006-05-14 at 12:32 -0700, Phil Steitz wrote:
> > On 5/14/06, robert burrell donkin <ro...@blueyonder.co.uk> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2006-05-14 at 12:32 -0700, Phil Steitz wrote:
> On 5/14/06, robert burrell donkin <ro...@blueyonder.co.uk> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Phil Steitz <ph...@gmail.com>.
On 5/14/06, robert burrell donkin <ro...@blueyonder.co.uk> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Henri Yandell <fl...@gmail.com>.
On 5/13/06, Dennis Lundberg <de...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Dennis Lundberg <de...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Torsten Curdt <tc...@apache.org>.
> Opening this up again.
>
> groupId: org.apache.commons
+1!!
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Martin Cooper <ma...@apache.org>.
On 5/17/06, Henri Yandell <fl...@gmail.com> wrote:
>
> On 5/13/06, robert burrell donkin <ro...@blueyonder.co.uk>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Henri Yandell <fl...@gmail.com>.
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 <ca...@apache.org> 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 <ph...@gmail.com> wrote:
> > On 5/18/06, Henri Yandell <fl...@gmail.com> wrote:
> > > On 5/18/06, Dennis Lundberg <de...@apache.org> wrote:
> > > > Henri Yandell wrote:
> > > > > On 5/13/06, robert burrell donkin <ro...@blueyonder.co.uk>
> > > > > 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Carlos Sanchez <ca...@apache.org>.
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 <ph...@gmail.com> wrote:
> On 5/18/06, Henri Yandell <fl...@gmail.com> wrote:
> > On 5/18/06, Dennis Lundberg <de...@apache.org> wrote:
> > > Henri Yandell wrote:
> > > > On 5/13/06, robert burrell donkin <ro...@blueyonder.co.uk>
> > > > 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Phil Steitz <ph...@gmail.com>.
On 5/18/06, Henri Yandell <fl...@gmail.com> wrote:
> On 5/18/06, Dennis Lundberg <de...@apache.org> wrote:
> > Henri Yandell wrote:
> > > On 5/13/06, robert burrell donkin <ro...@blueyonder.co.uk>
> > > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Dennis Lundberg <de...@apache.org>.
Henri Yandell wrote:
> On 5/18/06, Dennis Lundberg <de...@apache.org> wrote:
>> Henri Yandell wrote:
>> > On 5/13/06, robert burrell donkin
>> <ro...@blueyonder.co.uk>
>> > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Henri Yandell <fl...@gmail.com>.
On 5/18/06, Dennis Lundberg <de...@apache.org> wrote:
> Henri Yandell wrote:
> > On 5/13/06, robert burrell donkin <ro...@blueyonder.co.uk>
> > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Dennis Lundberg <de...@apache.org>.
Henri Yandell wrote:
> On 5/13/06, robert burrell donkin <ro...@blueyonder.co.uk>
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Henri Yandell <fl...@gmail.com>.
On 5/13/06, robert burrell donkin <ro...@blueyonder.co.uk> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Nicolas De Loof <ni...@capgemini.com>.
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 <de...@apache.org> 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>
>>> <groupId>org.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 <ni...@capgemini.com> 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 <de...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
>>> >> > For additional commands, e-mail:
>>> commons-dev-help@jakarta.apache.org
>>> >> >
>>> >>
>>> >> 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: commons-dev-unsubscribe@jakarta.apache.org
>>> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>
>
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Dennis Lundberg <de...@apache.org>.
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 <de...@apache.org> 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>
>> <groupId>org.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 <ni...@capgemini.com> 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 <de...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
>> >> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>> >> >
>> >>
>> >> 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: commons-dev-unsubscribe@jakarta.apache.org
>> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>> >>
>> >>
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Dennis Lundberg <de...@apache.org>.
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 <de...@apache.org> 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>
>> <groupId>org.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 <ni...@capgemini.com> 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 <de...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
>> >> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>> >> >
>> >>
>> >> 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: commons-dev-unsubscribe@jakarta.apache.org
>> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>> >>
>> >>
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Carlos Sanchez <ca...@apache.org>.
Are you thinking about doing it in the m1 or m2 repo?
see below
On 6/7/06, Dennis Lundberg <de...@apache.org> 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>
> <groupId>org.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 <ni...@capgemini.com> 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 <de...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
> >> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >> >
> >>
> >> 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: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Dennis Lundberg <de...@apache.org>.
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>
<groupId>org.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 <ni...@capgemini.com> 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 <de...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>> >
>>
>> 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Carlos Sanchez <ca...@apache.org>.
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 <ni...@capgemini.com> 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 <de...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Niall Pemberton <ni...@gmail.com>.
On 6/14/06, Dennis Lundberg <de...@apache.org> wrote:
> 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
> > <groupId>org.apache.commons</groupId> - is it OK to release with this
> > or should I revert to <groupId>commons-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.
OK
> Sorry for the inconvenience.
No problem, thanks for the quick response.
Niall
> --
> Dennis Lundberg
>
> >
> > Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Nicolas De Loof <ni...@capgemini.com>.
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 <de...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Torsten Curdt <tc...@apache.org>.
Brett,
any comments on this?
cheers
--
Torsten
On 6/6/06, Dennis Lundberg <de...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Dennis Lundberg <de...@apache.org>.
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
> <groupId>org.apache.commons</groupId> - is it OK to release with this
> or should I revert to <groupId>commons-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 <de...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Niall Pemberton <ni...@gmail.com>.
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
<groupId>org.apache.commons</groupId> - is it OK to release with this
or should I revert to <groupId>commons-chain</groupId>?
Niall
On 6/5/06, Dennis Lundberg <de...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Dennis Lundberg <de...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Brett Porter <br...@apache.org>.
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 <br...@apache.org>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Dennis Lundberg <de...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Brett Porter <br...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Brett Porter <br...@apache.org>.
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 <ro...@blueyonder.co.uk>
>> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by Simon Kitching <sk...@apache.org>.
On Sat, 2006-05-13 at 11:30 -0700, Martin Cooper wrote:
> On 5/13/06, robert burrell donkin <ro...@blueyonder.co.uk>
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] RC on ibiblio ?
Posted by Nicolas De Loof <ni...@capgemini.com>.
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
Martin Cooper a écrit :
> On 4/5/06, Wendy Smoak <ws...@gmail.com> wrote:
>
>> On 4/5/06, Martin Cooper <ma...@apache.org> wrote:
>>
>>
>>> Right. But is there any reason we couldn't create a Maven 2 parallel to
>>>
>> the
>>
>>> Maven 1 repo we have at http://cvs.apache.org/repository/? We could
>>>
>> deploy
>>
>>> RCs there.
>>>
>> It's already there:
>> http://cvs.apache.org/maven-snapshot-repository
>>
>
>
> Oh, that's what that is. ;-) The name threw me.
>
> --
> Martin Cooper
>
>
> You can use 'mvn deploy:deploy-file' to deploy the RC, and Maven will
>
>> generate a pom for it. That should be fine since Logging has no
>> required dependencies.
>>
>> --
>> Wendy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>
>
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] RC on ibiblio ?
Posted by Martin Cooper <ma...@apache.org>.
On 4/5/06, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 4/5/06, Martin Cooper <ma...@apache.org> wrote:
>
> > Right. But is there any reason we couldn't create a Maven 2 parallel to
> the
> > Maven 1 repo we have at http://cvs.apache.org/repository/? We could
> deploy
> > RCs there.
>
> It's already there:
> http://cvs.apache.org/maven-snapshot-repository
Oh, that's what that is. ;-) The name threw me.
--
Martin Cooper
You can use 'mvn deploy:deploy-file' to deploy the RC, and Maven will
> generate a pom for it. That should be fine since Logging has no
> required dependencies.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [logging] RC on ibiblio ?
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/5/06, Martin Cooper <ma...@apache.org> wrote:
> Right. But is there any reason we couldn't create a Maven 2 parallel to the
> Maven 1 repo we have at http://cvs.apache.org/repository/? We could deploy
> RCs there.
It's already there:
http://cvs.apache.org/maven-snapshot-repository
You can use 'mvn deploy:deploy-file' to deploy the RC, and Maven will
generate a pom for it. That should be fine since Logging has no
required dependencies.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] RC on ibiblio ?
Posted by Martin Cooper <ma...@apache.org>.
On 4/5/06, robert burrell donkin <ro...@blueyonder.co.uk>
wrote:
>
> On Wed, 2006-04-05 at 20:41 +1200, Simon Kitching wrote:
> > On Wed, 2006-04-05 at 10:05 +0200, Nicolas De Loof wrote:
> > > Hello,
> > >
> > > Can someone upload commons-logging RC on Maven2 ibiblio repository ?
> > > It would be very cool to also upload a POM and the sources jar...
> >
> > That would be a good idea.
>
> sadly policy dictates that we can't upload release candidates to ibiblio
Right. But is there any reason we couldn't create a Maven 2 parallel to the
Maven 1 repo we have at http://cvs.apache.org/repository/? We could deploy
RCs there.
--
Martin Cooper
> We should also provide a link on the downloads page or something
> > similar. Just today a work colleague was looking for a later version
> > than 1.0.4 in order to get log4j TRACE support. I told him there was an
> > RC out, but there was just no way for him to locate it...
>
> i've been at work off list and things look good. i think i'm just about
> ready to cut the final release candidate this weekend and try a release
> vote.
>
> > By the way, there is still an outstanding discussion about whether to
> > add JDK14Logger back into the commons-logging-api.jar file. It was there
> > in the previous release. It probably shouldn't be; it's not logical.
> > However it does no harm as far as I can see, and the point was made that
> > because the current RC doesn't include it, it isn't a drop-in
> > replacement.
>
> yep
>
> i agree that it's not logical but ATM it would be good to ship a fixed
> replacement. it's likely that tomcat 6 will ship a JCL library created
> by costin which is static bound to java.util.logging.
>
> > So I'm +1 on adding JDK14Logger back to the api jar, then cutting a new
> > RC and uploading to ibiblio + linking from useful places.
> >
> > Alternatively, we could just make the above change then hold a release
> > vote. I think we've given this RC enough time for feedback.
>
> i've got the feedback i wanted now (off list) so i think the time is
> right to cut another release candidate and hold a release vote next
> week. i'll probably give the vote two weeks this time.
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [logging] RC on ibiblio ?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Wed, 2006-04-05 at 20:41 +1200, Simon Kitching wrote:
> On Wed, 2006-04-05 at 10:05 +0200, Nicolas De Loof wrote:
> > Hello,
> >
> > Can someone upload commons-logging RC on Maven2 ibiblio repository ?
> > It would be very cool to also upload a POM and the sources jar...
>
> That would be a good idea.
sadly policy dictates that we can't upload release candidates to ibiblio
> We should also provide a link on the downloads page or something
> similar. Just today a work colleague was looking for a later version
> than 1.0.4 in order to get log4j TRACE support. I told him there was an
> RC out, but there was just no way for him to locate it...
i've been at work off list and things look good. i think i'm just about
ready to cut the final release candidate this weekend and try a release
vote.
> By the way, there is still an outstanding discussion about whether to
> add JDK14Logger back into the commons-logging-api.jar file. It was there
> in the previous release. It probably shouldn't be; it's not logical.
> However it does no harm as far as I can see, and the point was made that
> because the current RC doesn't include it, it isn't a drop-in
> replacement.
yep
i agree that it's not logical but ATM it would be good to ship a fixed
replacement. it's likely that tomcat 6 will ship a JCL library created
by costin which is static bound to java.util.logging.
> So I'm +1 on adding JDK14Logger back to the api jar, then cutting a new
> RC and uploading to ibiblio + linking from useful places.
>
> Alternatively, we could just make the above change then hold a release
> vote. I think we've given this RC enough time for feedback.
i've got the feedback i wanted now (off list) so i think the time is
right to cut another release candidate and hold a release vote next
week. i'll probably give the vote two weeks this time.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] RC on ibiblio ?
Posted by Simon Kitching <sk...@apache.org>.
On Wed, 2006-04-05 at 10:05 +0200, Nicolas De Loof wrote:
> Hello,
>
> Can someone upload commons-logging RC on Maven2 ibiblio repository ?
> It would be very cool to also upload a POM and the sources jar...
That would be a good idea.
We should also provide a link on the downloads page or something
similar. Just today a work colleague was looking for a later version
than 1.0.4 in order to get log4j TRACE support. I told him there was an
RC out, but there was just no way for him to locate it...
By the way, there is still an outstanding discussion about whether to
add JDK14Logger back into the commons-logging-api.jar file. It was there
in the previous release. It probably shouldn't be; it's not logical.
However it does no harm as far as I can see, and the point was made that
because the current RC doesn't include it, it isn't a drop-in
replacement.
So I'm +1 on adding JDK14Logger back to the api jar, then cutting a new
RC and uploading to ibiblio + linking from useful places.
Alternatively, we could just make the above change then hold a release
vote. I think we've given this RC enough time for feedback.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org