Re: [all] maven group ids
Dennis Lundberg wrote: Tomasz Pik wrote: On 8/21/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Tomasz Pik wrote: Maven won't 'redownload' commons-lang:commons-lang:2.1 and if threre'll be something that depends on org.apache.commons:commons-lang:2.2. Maven won't know that it's only a version difference, for Maven those components are a completly different packages so both will be added to classpath, packaged into wars and so on. And for example for most servlet containers I've observed, that they added jars in alphabetized order, so commons-lang:2.1 will 'win'. Do you have a suggestion for how we should handle this in commons? This cann't be handled/solved in general in commons. My point is that it would be better to avoid some kind of 'propagation' of this problem. Whole disussion starts around new release of commnons-collections which for example depends on commons-lang:2.1 And all I'm suggesting is that those packages should be relocated first, so commons-collections will depend on org.apache.commons:commons-lang:2.1, not commons-lang:commons-lang:2.1. So, if there'll be a org.apache.commons: commons-lang:2.2 and I want to use this because there's something new and neat, I can just add this dependency to my project and this will win over transitive 2.1 depenency from commons-collections. Other solution will be not relocate anything (which probably won't be accepted by repository manages...) or do not define those dependencies in pom.xml files (also not the best solution). One more thing: having this commons-lang:commons-lang:2.1 dependency in org.apache.commons:commons-colletions as a dependency will make a bit strange situation: there'll be a commons package in http://people.apache.org/repo/m2-ibiblio-rsync-repository/ that will depend on other commons project, which is not available there. I know there's a lot of packages, that depends on commons-xx;commons-xx packages (which are on ibiblio) but veryPersonalOpiononIMHO it's not a good situation/veryPersonalOpinion Having let your comments sink in, I now understand what your point is. I think that the best solution would be to switch groupId:s for all components in-between releases. Say that we switch groupId:s today (only as an example). Then every release after today needs to update the groupId:s for all dependencies on other commons components. How does that sound? I found the top-10-list link I was talking about earlier in this thread. It's actually a top-25-list featuring commons-logging, commons-collections, commons-lang and commons-beanutils: http://www.mvnregistry.com/search/depended_upon_artifacts How do we proceed here? Do all agree with this proposed solution? And if so: when would this change happen? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Tomasz Pik wrote: On 8/21/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Tomasz Pik wrote: Maven won't 'redownload' commons-lang:commons-lang:2.1 and if threre'll be something that depends on org.apache.commons:commons-lang:2.2. Maven won't know that it's only a version difference, for Maven those components are a completly different packages so both will be added to classpath, packaged into wars and so on. And for example for most servlet containers I've observed, that they added jars in alphabetized order, so commons-lang:2.1 will 'win'. Do you have a suggestion for how we should handle this in commons? This cann't be handled/solved in general in commons. My point is that it would be better to avoid some kind of 'propagation' of this problem. Whole disussion starts around new release of commnons-collections which for example depends on commons-lang:2.1 And all I'm suggesting is that those packages should be relocated first, so commons-collections will depend on org.apache.commons:commons-lang:2.1, not commons-lang:commons-lang:2.1. So, if there'll be a org.apache.commons: commons-lang:2.2 and I want to use this because there's something new and neat, I can just add this dependency to my project and this will win over transitive 2.1 depenency from commons-collections. Other solution will be not relocate anything (which probably won't be accepted by repository manages...) or do not define those dependencies in pom.xml files (also not the best solution). One more thing: having this commons-lang:commons-lang:2.1 dependency in org.apache.commons:commons-colletions as a dependency will make a bit strange situation: there'll be a commons package in http://people.apache.org/repo/m2-ibiblio-rsync-repository/ that will depend on other commons project, which is not available there. I know there's a lot of packages, that depends on commons-xx;commons-xx packages (which are on ibiblio) but veryPersonalOpiononIMHO it's not a good situation/veryPersonalOpinion Having let your comments sink in, I now understand what your point is. I think that the best solution would be to switch groupId:s for all components in-between releases. Say that we switch groupId:s today (only as an example). Then every release after today needs to update the groupId:s for all dependencies on other commons components. How does that sound? I found the top-10-list link I was talking about earlier in this thread. It's actually a top-25-list featuring commons-logging, commons-collections, commons-lang and commons-beanutils: http://www.mvnregistry.com/search/depended_upon_artifacts -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Tomasz Pik wrote: On 8/20/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Tomasz Pik wrote: On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. What would we gain from this? A transition of component A will not include updating existing commons-dependencies in component A to the new ones with the new groupId. That will require a new release of that component A. If fact we don't even have to wait for a release of a component to do this. There is a good reason for *not* picking commons-lang or commons-logging, two components without dependencies on other commons components, as the first component to transition. That is that both are on ibiblio's top 10 downloads list. I had link to it before but can't seem to find it now, sorry. If we do it wrong there then all hell will break loose. It'd be better to choose a medium used component. But this means, that all of those users, that downloading those top10 jars in near future will have obosolete jars. They are *not* obsolete. They are relocated. They still function in exactly the same way as before. The only difference is that there is a relocation section in the pom that indicates to Maven 2 that this project has changed one or more of groupId, artifactId or version. Maven is not re-downloading nonSNAPSHOT artifacts so... Let's imagine I'm a new maven user having project with a dependency on commons-lang:commons-lang-2.1 and maven will download it for me. Some time later this package will be relocated to org.apache.commons.lang:commons-lang:2.1 (or similar). After that there'll be new, let's say acegi v1.4 depending on this 'new' commons-lang (org.apache:commons-lang:2.1) and I need this acegi in my project. So after adding dependency on acegi maven will download org.apache.commons.lang:commons-lang:2.1 and won't download commons-lang:commons-lang:2.1 (which should result as relocation info) and finally, maven will be adding those two commons-lang jars into classpath, copy into WEB-INF/lib and so on. This was one of the tests that I performed when testing this. It is a problem only for Maven 1 which does not handle relocations at all. In Maven 2 this is handled transparently and you will not get two jars in your WEB-INF/lib, only one. All of this till the time I'll manually remove commons-lang:commons-lang:2.1 from my repository so maven will be forced to reload them (and will download relocation info then). It is true that Maven 2 does not re-download something once it has successfully downloaded it, but that has no impact on this discussion. It has some impact for final users... Maven won't 'redownload' commons-lang:commons-lang:2.1 and if threre'll be something that depends on org.apache.commons:commons-lang:2.2. Maven won't know that it's only a version difference, for Maven those components are a completly different packages so both will be added to classpath, packaged into wars and so on. And for example for most servlet containers I've observed, that they added jars in alphabetized order, so commons-lang:2.1 will 'win'. Do you have a suggestion for how we should handle this in commons? snip/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/21/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Tomasz Pik wrote: Maven won't 'redownload' commons-lang:commons-lang:2.1 and if threre'll be something that depends on org.apache.commons:commons-lang:2.2. Maven won't know that it's only a version difference, for Maven those components are a completly different packages so both will be added to classpath, packaged into wars and so on. And for example for most servlet containers I've observed, that they added jars in alphabetized order, so commons-lang:2.1 will 'win'. Do you have a suggestion for how we should handle this in commons? This cann't be handled/solved in general in commons. My point is that it would be better to avoid some kind of 'propagation' of this problem. Whole disussion starts around new release of commnons-collections which for example depends on commons-lang:2.1 And all I'm suggesting is that those packages should be relocated first, so commons-collections will depend on org.apache.commons:commons-lang:2.1, not commons-lang:commons-lang:2.1. So, if there'll be a org.apache.commons: commons-lang:2.2 and I want to use this because there's something new and neat, I can just add this dependency to my project and this will win over transitive 2.1 depenency from commons-collections. Other solution will be not relocate anything (which probably won't be accepted by repository manages...) or do not define those dependencies in pom.xml files (also not the best solution). One more thing: having this commons-lang:commons-lang:2.1 dependency in org.apache.commons:commons-colletions as a dependency will make a bit strange situation: there'll be a commons package in http://people.apache.org/repo/m2-ibiblio-rsync-repository/ that will depend on other commons project, which is not available there. I know there's a lot of packages, that depends on commons-xx;commons-xx packages (which are on ibiblio) but veryPersonalOpiononIMHO it's not a good situation/veryPersonalOpinion Regards, Tomek snip/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Tomasz Pik wrote: On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. What would we gain from this? A transition of component A will not include updating existing commons-dependencies in component A to the new ones with the new groupId. That will require a new release of that component A. If fact we don't even have to wait for a release of a component to do this. There is a good reason for *not* picking commons-lang or commons-logging, two components without dependencies on other commons components, as the first component to transition. That is that both are on ibiblio's top 10 downloads list. I had link to it before but can't seem to find it now, sorry. If we do it wrong there then all hell will break loose. It'd be better to choose a medium used component. But this means, that all of those users, that downloading those top10 jars in near future will have obosolete jars. They are *not* obsolete. They are relocated. They still function in exactly the same way as before. The only difference is that there is a relocation section in the pom that indicates to Maven 2 that this project has changed one or more of groupId, artifactId or version. Maven is not re-downloading nonSNAPSHOT artifacts so... Let's imagine I'm a new maven user having project with a dependency on commons-lang:commons-lang-2.1 and maven will download it for me. Some time later this package will be relocated to org.apache.commons.lang:commons-lang:2.1 (or similar). After that there'll be new, let's say acegi v1.4 depending on this 'new' commons-lang (org.apache:commons-lang:2.1) and I need this acegi in my project. So after adding dependency on acegi maven will download org.apache.commons.lang:commons-lang:2.1 and won't download commons-lang:commons-lang:2.1 (which should result as relocation info) and finally, maven will be adding those two commons-lang jars into classpath, copy into WEB-INF/lib and so on. This was one of the tests that I performed when testing this. It is a problem only for Maven 1 which does not handle relocations at all. In Maven 2 this is handled transparently and you will not get two jars in your WEB-INF/lib, only one. All of this till the time I'll manually remove commons-lang:commons-lang:2.1 from my repository so maven will be forced to reload them (and will download relocation info then). It is true that Maven 2 does not re-download something once it has successfully downloaded it, but that has no impact on this discussion. So finally I think that sooner those jars will be relocated there'll be less users having problems like this. As I said before I'm all for a quick transition, but since commons components are very widely used, we have to make sure that we do everything correctly. Regards, Tomek -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Oliver Heger wrote: Dennis Lundberg wrote: snip/ I had a look at the Apache Maven 1 repo at http://people.apache.org/repo/m1-ibiblio-rsync-repository/ There doesn't seem to be any consistency when looking at different components. I had a look at a few: configuration: - older jars have md5 - newer jars have md5 and asc - older poms have no md5 or asc - newer poms have md5 lang: - jars have md5 - poms have md5 logging: - older jars have md5 - newer jars have md5 and asc - older poms have md5 - newer poms have md5 and asc snip/ Section 8 of the Commons releasing components guide [1] demands that all files placed in the ASF Java Respository need to be signed. I think that this part is relative new, which explains why newer poms are signed while older ones are not. Thanks for that pointer Oliver. I guess this section is to comply with the ASF release signing policy. I still think that we should sign the poms (with the relocation element added) only if they were signed when they were released. By the way the Jakarta document needs to be updated as the java-repository has moved on people.o.a. I will try to patch that. Oliver [1] http://jakarta.apache.org/commons/releases/release.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/20/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Tomasz Pik wrote: On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. What would we gain from this? A transition of component A will not include updating existing commons-dependencies in component A to the new ones with the new groupId. That will require a new release of that component A. If fact we don't even have to wait for a release of a component to do this. There is a good reason for *not* picking commons-lang or commons-logging, two components without dependencies on other commons components, as the first component to transition. That is that both are on ibiblio's top 10 downloads list. I had link to it before but can't seem to find it now, sorry. If we do it wrong there then all hell will break loose. It'd be better to choose a medium used component. But this means, that all of those users, that downloading those top10 jars in near future will have obosolete jars. They are *not* obsolete. They are relocated. They still function in exactly the same way as before. The only difference is that there is a relocation section in the pom that indicates to Maven 2 that this project has changed one or more of groupId, artifactId or version. Maven is not re-downloading nonSNAPSHOT artifacts so... Let's imagine I'm a new maven user having project with a dependency on commons-lang:commons-lang-2.1 and maven will download it for me. Some time later this package will be relocated to org.apache.commons.lang:commons-lang:2.1 (or similar). After that there'll be new, let's say acegi v1.4 depending on this 'new' commons-lang (org.apache:commons-lang:2.1) and I need this acegi in my project. So after adding dependency on acegi maven will download org.apache.commons.lang:commons-lang:2.1 and won't download commons-lang:commons-lang:2.1 (which should result as relocation info) and finally, maven will be adding those two commons-lang jars into classpath, copy into WEB-INF/lib and so on. This was one of the tests that I performed when testing this. It is a problem only for Maven 1 which does not handle relocations at all. In Maven 2 this is handled transparently and you will not get two jars in your WEB-INF/lib, only one. All of this till the time I'll manually remove commons-lang:commons-lang:2.1 from my repository so maven will be forced to reload them (and will download relocation info then). It is true that Maven 2 does not re-download something once it has successfully downloaded it, but that has no impact on this discussion. It has some impact for final users... Maven won't 'redownload' commons-lang:commons-lang:2.1 and if threre'll be something that depends on org.apache.commons:commons-lang:2.2. Maven won't know that it's only a version difference, for Maven those components are a completly different packages so both will be added to classpath, packaged into wars and so on. And for example for most servlet containers I've observed, that they added jars in alphabetized order, so commons-lang:2.1 will 'win'. So finally I think that sooner those jars will be relocated there'll be less users having problems like this. As I said before I'm all for a quick transition, but since commons components are very widely used, we have to make sure that we do everything correctly. 100% agree :) Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Dennis Lundberg wrote: snip/ I had a look at the Apache Maven 1 repo at http://people.apache.org/repo/m1-ibiblio-rsync-repository/ There doesn't seem to be any consistency when looking at different components. I had a look at a few: configuration: - older jars have md5 - newer jars have md5 and asc - older poms have no md5 or asc - newer poms have md5 lang: - jars have md5 - poms have md5 logging: - older jars have md5 - newer jars have md5 and asc - older poms have md5 - newer poms have md5 and asc snip/ Section 8 of the Commons releasing components guide [1] demands that all files placed in the ASF Java Respository need to be signed. I think that this part is relative new, which explains why newer poms are signed while older ones are not. Oliver [1] http://jakarta.apache.org/commons/releases/release.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Tomasz Pik wrote: On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. What would we gain from this? A transition of component A will not include updating existing commons-dependencies in component A to the new ones with the new groupId. That will require a new release of that component A. If fact we don't even have to wait for a release of a component to do this. There is a good reason for *not* picking commons-lang or commons-logging, two components without dependencies on other commons components, as the first component to transition. That is that both are on ibiblio's top 10 downloads list. I had link to it before but can't seem to find it now, sorry. If we do it wrong there then all hell will break loose. It'd be better to choose a medium used component. But this means, that all of those users, that downloading those top10 jars in near future will have obosolete jars. Maven is not re-downloading nonSNAPSHOT artifacts so... Let's imagine I'm a new maven user having project with a dependency on commons-lang:commons-lang-2.1 and maven will download it for me. Some time later this package will be relocated to org.apache.commons.lang:commons-lang:2.1 (or similar). After that there'll be new, let's say acegi v1.4 depending on this 'new' commons-lang (org.apache:commons-lang:2.1) and I need this acegi in my project. So after adding dependency on acegi maven will download org.apache.commons.lang:commons-lang:2.1 and won't download commons-lang:commons-lang:2.1 (which should result as relocation info) and finally, maven will be adding those two commons-lang jars into classpath, copy into WEB-INF/lib and so on. All of this till the time I'll manually remove commons-lang:commons-lang:2.1 from my repository so maven will be forced to reload them (and will download relocation info then). So finally I think that sooner those jars will be relocated there'll be less users having problems like this. Regards, Tomek -- Dennis Lundberg There are good reasons in this thread from both sides. Being no maven expert I cannot judge which ones are better. But as long as this point is open I don't want to cut the next release candidate for [configuration]. So can we come to a consensus? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/19/06, Oliver Heger [EMAIL PROTECTED] wrote: Tomasz Pik wrote: On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. What would we gain from this? A transition of component A will not include updating existing commons-dependencies in component A to the new ones with the new groupId. That will require a new release of that component A. If fact we don't even have to wait for a release of a component to do this. There is a good reason for *not* picking commons-lang or commons-logging, two components without dependencies on other commons components, as the first component to transition. That is that both are on ibiblio's top 10 downloads list. I had link to it before but can't seem to find it now, sorry. If we do it wrong there then all hell will break loose. It'd be better to choose a medium used component. But this means, that all of those users, that downloading those top10 jars in near future will have obosolete jars. Maven is not re-downloading nonSNAPSHOT artifacts so... Let's imagine I'm a new maven user having project with a dependency on commons-lang:commons-lang-2.1 and maven will download it for me. Some time later this package will be relocated to org.apache.commons.lang:commons-lang:2.1 (or similar). After that there'll be new, let's say acegi v1.4 depending on this 'new' commons-lang (org.apache:commons-lang:2.1) and I need this acegi in my project. So after adding dependency on acegi maven will download org.apache.commons.lang:commons-lang:2.1 and won't download commons-lang:commons-lang:2.1 (which should result as relocation info) and finally, maven will be adding those two commons-lang jars into classpath, copy into WEB-INF/lib and so on. All of this till the time I'll manually remove commons-lang:commons-lang:2.1 from my repository so maven will be forced to reload them (and will download relocation info then). So finally I think that sooner those jars will be relocated there'll be less users having problems like this. Regards, Tomek -- Dennis Lundberg There are good reasons in this thread from both sides. Being no maven expert I cannot judge which ones are better. But as long as this point is open I don't want to cut the next release candidate for [configuration]. So can we come to a consensus? FWIW, I am planning to provide both .asc and .sha1 signing keys on the upcoming Shale release I'm working on. The .md5 files aren't really a signature ... they're just a checksum useful in determining whether the download has been corrupted or not (it is based solely on the content, not on any private key of the signer). Oliver Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. What would we gain from this? A transition of component A will not include updating existing commons-dependencies in component A to the new ones with the new groupId. That will require a new release of that component A. If fact we don't even have to wait for a release of a component to do this. There is a good reason for *not* picking commons-lang or commons-logging, two components without dependencies on other commons components, as the first component to transition. That is that both are on ibiblio's top 10 downloads list. I had link to it before but can't seem to find it now, sorry. If we do it wrong there then all hell will break loose. It'd be better to choose a medium used component. But this means, that all of those users, that downloading those top10 jars in near future will have obosolete jars. Maven is not re-downloading nonSNAPSHOT artifacts so... Let's imagine I'm a new maven user having project with a dependency on commons-lang:commons-lang-2.1 and maven will download it for me. Some time later this package will be relocated to org.apache.commons.lang:commons-lang:2.1 (or similar). After that there'll be new, let's say acegi v1.4 depending on this 'new' commons-lang (org.apache:commons-lang:2.1) and I need this acegi in my project. So after adding dependency on acegi maven will download org.apache.commons.lang:commons-lang:2.1 and won't download commons-lang:commons-lang:2.1 (which should result as relocation info) and finally, maven will be adding those two commons-lang jars into classpath, copy into WEB-INF/lib and so on. All of this till the time I'll manually remove commons-lang:commons-lang:2.1 from my repository so maven will be forced to reload them (and will download relocation info then). So finally I think that sooner those jars will be relocated there'll be less users having problems like this. Regards, Tomek -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/15/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: On 8/12/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Oliver Heger wrote: Hi, just wanted to ask if there is already a resolution related to the groupIds of commons components. snip/ Everything is set to make the transition to the new groupId. I was hoping that we could use the upcoming release of configuration as the first release with the new groupId. snap/ Do we want to do this? Shouldn't we transition all of Commons together (as Tomasz implies in previous post, and just like we did with the JIRA transition). Suboptimal if folks have to look up which components have migrated yet, there are different groupIds for Commons components in the same POM etc. We should do all of commons, I agree, but I think it would be wise to start with one component and see that everything works as expected. Then we do the rest all in one big transition. Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/15/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: snip/ Do we want to do this? Shouldn't we transition all of Commons together (as Tomasz implies in previous post, and just like we did with the JIRA transition). Suboptimal if folks have to look up which components have migrated yet, there are different groupIds for Commons components in the same POM etc. We should do all of commons, I agree, but I think it would be wise to start with one component and see that everything works as expected. Then we do the rest all in one big transition. snap/ OK, I know there was a talk about a test repo, has that come about? We could also deploy the previous release (old groupId) and current RC (new groupId) to such a test repo as a dry run, if one is available. Now, the relocation guide below (thanks for that!) talks about resigning POMs etc., which basically means we need everyone who has signed a Commons release (POM) to participate here? While writing the guide I talked to Carlos about re-signing poms, and he had never done that. So I don't think that it is necessary for us either. What we do is add a relocation section to the pom, nothing else is touched. Do we sign commons poms that goes to the Maven repo? I had a look in the repo before and got mixed results. snip/ AFAIK, nothing should go into any of the Apache Maven repos unless its summed and signed. Commons has no particular privilege here, in fact, we should ensure that all artifacts are accompanied by appropriate metadata (I don't mean metadata.xml in the m2 sense). There are existing sums and sigs on some POMs atleast. It appears that even if its just a relocation section, it needs a resum and resign. If the consensus is that this adds an overhead for too many people, and is hence optional, thats another thing. -Rahul -- Dennis Lundberg -Rahul I will do the necessary work to relocate this and previous releases of configuration, once the release has been made, so that the transition is as transparent as possible to downstream users. More info on what steps need to be taken can be found here: http://maven.apache.org/guides/mini/guide-relocation.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Rahul Akolkar wrote: On 8/15/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: snip/ Do we want to do this? Shouldn't we transition all of Commons together (as Tomasz implies in previous post, and just like we did with the JIRA transition). Suboptimal if folks have to look up which components have migrated yet, there are different groupIds for Commons components in the same POM etc. We should do all of commons, I agree, but I think it would be wise to start with one component and see that everything works as expected. Then we do the rest all in one big transition. snap/ OK, I know there was a talk about a test repo, has that come about? We could also deploy the previous release (old groupId) and current RC (new groupId) to such a test repo as a dry run, if one is available. I don't think so. I'm subscribed to [EMAIL PROTECTED] and monitor that list. Now, the relocation guide below (thanks for that!) talks about resigning POMs etc., which basically means we need everyone who has signed a Commons release (POM) to participate here? While writing the guide I talked to Carlos about re-signing poms, and he had never done that. So I don't think that it is necessary for us either. What we do is add a relocation section to the pom, nothing else is touched. Do we sign commons poms that goes to the Maven repo? I had a look in the repo before and got mixed results. snip/ AFAIK, nothing should go into any of the Apache Maven repos unless its summed and signed. Commons has no particular privilege here, in fact, we should ensure that all artifacts are accompanied by appropriate metadata (I don't mean metadata.xml in the m2 sense). There are existing sums and sigs on some POMs atleast. It appears that even if its just a relocation section, it needs a resum and resign. If the consensus is that this adds an overhead for too many people, and is hence optional, thats another thing. Checksums (md5 and/or sha1) yes, definitely. Signing, hmm well I'm not sure. I haven't cut a release yet, so other will need to fill me in on the current policy for signing or not signing poms. If this is documented somewhere at Apache, please let me know, so that I can add a link in the relocation guide. -Rahul -- Dennis Lundberg -Rahul I will do the necessary work to relocate this and previous releases of configuration, once the release has been made, so that the transition is as transparent as possible to downstream users. More info on what steps need to be taken can be found here: http://maven.apache.org/guides/mini/guide-relocation.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: snip/ AFAIK, nothing should go into any of the Apache Maven repos unless its summed and signed. Commons has no particular privilege here, in fact, we should ensure that all artifacts are accompanied by appropriate metadata (I don't mean metadata.xml in the m2 sense). There are existing sums and sigs on some POMs atleast. It appears that even if its just a relocation section, it needs a resum and resign. If the consensus is that this adds an overhead for too many people, and is hence optional, thats another thing. Checksums (md5 and/or sha1) yes, definitely. Signing, hmm well I'm not sure. I haven't cut a release yet, so other will need to fill me in on the current policy for signing or not signing poms. If this is documented somewhere at Apache, please let me know, so that I can add a link in the relocation guide. snap/ From the Apache wide release signing policy [1] (I understand the document is still in the works): quote Every artifact distributed by the Apache Software Foundation should and every new one must be accompanied by one file containing an OpenPGP compatible ASCII armored detached signature and another file containing an MD5 checksum. /quote And, Henk will complain [2] if we miss sigs. -Rahul [1] http://www.apache.org/dev/release-signing.html#policy [2] http://people.apache.org/~henkp/checker/sig.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Tomasz Pik wrote: On 8/15/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: On 8/12/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Oliver Heger wrote: Hi, just wanted to ask if there is already a resolution related to the groupIds of commons components. snip/ Everything is set to make the transition to the new groupId. I was hoping that we could use the upcoming release of configuration as the first release with the new groupId. snap/ Do we want to do this? Shouldn't we transition all of Commons together (as Tomasz implies in previous post, and just like we did with the JIRA transition). Suboptimal if folks have to look up which components have migrated yet, there are different groupIds for Commons components in the same POM etc. We should do all of commons, I agree, but I think it would be wise to start with one component and see that everything works as expected. Then we do the rest all in one big transition. Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. What would we gain from this? A transition of component A will not include updating existing commons-dependencies in component A to the new ones with the new groupId. That will require a new release of that component A. If fact we don't even have to wait for a release of a component to do this. There is a good reason for *not* picking commons-lang or commons-logging, two components without dependencies on other commons components, as the first component to transition. That is that both are on ibiblio's top 10 downloads list. I had link to it before but can't seem to find it now, sorry. If we do it wrong there then all hell will break loose. It'd be better to choose a medium used component. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Rahul Akolkar wrote: On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: snip/ AFAIK, nothing should go into any of the Apache Maven repos unless its summed and signed. Commons has no particular privilege here, in fact, we should ensure that all artifacts are accompanied by appropriate metadata (I don't mean metadata.xml in the m2 sense). There are existing sums and sigs on some POMs atleast. It appears that even if its just a relocation section, it needs a resum and resign. If the consensus is that this adds an overhead for too many people, and is hence optional, thats another thing. Checksums (md5 and/or sha1) yes, definitely. Signing, hmm well I'm not sure. I haven't cut a release yet, so other will need to fill me in on the current policy for signing or not signing poms. If this is documented somewhere at Apache, please let me know, so that I can add a link in the relocation guide. snap/ From the Apache wide release signing policy [1] (I understand the document is still in the works): quote Every artifact distributed by the Apache Software Foundation should and every new one must be accompanied by one file containing an OpenPGP compatible ASCII armored detached signature and another file containing an MD5 checksum. /quote And, Henk will complain [2] if we miss sigs. -Rahul [1] http://www.apache.org/dev/release-signing.html#policy [2] http://people.apache.org/~henkp/checker/sig.html Thanks for those pointers Rahul. I'll be sure to add, at least the first one to the guide. I had a look at the Apache Maven 1 repo at http://people.apache.org/repo/m1-ibiblio-rsync-repository/ There doesn't seem to be any consistency when looking at different components. I had a look at a few: configuration: - older jars have md5 - newer jars have md5 and asc - older poms have no md5 or asc - newer poms have md5 lang: - jars have md5 - poms have md5 logging: - older jars have md5 - newer jars have md5 and asc - older poms have md5 - newer poms have md5 and asc How do we handle this? If the previous pom is signed then the relocated one should also be signed, is one way to go. And a more philosophical question: is a pom an artifact? Henk's page does not seem to look at the Maven repos at all, only in /dist/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: snip/ [1] http://www.apache.org/dev/release-signing.html#policy [2] http://people.apache.org/~henkp/checker/sig.html Thanks for those pointers Rahul. I'll be sure to add, at least the first one to the guide. I had a look at the Apache Maven 1 repo at http://people.apache.org/repo/m1-ibiblio-rsync-repository/ There doesn't seem to be any consistency when looking at different components. I had a look at a few: snap/ Yes, unfortunately. Thats why the language in [1] above differentiates between existing artifacts and new ones. We (Jakarta) must aim to be consistent for new releases. How do we handle this? If the previous pom is signed then the relocated one should also be signed, is one way to go. snip/ My opinion as well. And as a corollary, if the previous POM isn't signed, we leave it at that after the mods. And a more philosophical question: is a pom an artifact? snap/ Traditionally, release artifacts have been source (and binary, where applicable) distributions. With central repositories, things such as jars and project metadata (poms) have begun to be distributed individually, which gives them a flavor of being a release artifact. Parent poms are routinely voted on and released, in many Apache projects. Therefore, IMO, its best to have them summed and signed. However, as always, I'm open to other views. Henk's page does not seem to look at the Maven repos at all, only in /dist/ snip/ Correct, I realized that after I closed the door, but wanted to make it to the Yankee stadium in time for the game ;-) -Rahul -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/12/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Oliver Heger wrote: Hi, just wanted to ask if there is already a resolution related to the groupIds of commons components. snip/ Everything is set to make the transition to the new groupId. I was hoping that we could use the upcoming release of configuration as the first release with the new groupId. snap/ Do we want to do this? Shouldn't we transition all of Commons together (as Tomasz implies in previous post, and just like we did with the JIRA transition). Suboptimal if folks have to look up which components have migrated yet, there are different groupIds for Commons components in the same POM etc. Now, the relocation guide below (thanks for that!) talks about resigning POMs etc., which basically means we need everyone who has signed a Commons release (POM) to participate here? -Rahul I will do the necessary work to relocate this and previous releases of configuration, once the release has been made, so that the transition is as transparent as possible to downstream users. More info on what steps need to be taken can be found here: http://maven.apache.org/guides/mini/guide-relocation.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Rahul Akolkar wrote: On 8/12/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Oliver Heger wrote: Hi, just wanted to ask if there is already a resolution related to the groupIds of commons components. snip/ Everything is set to make the transition to the new groupId. I was hoping that we could use the upcoming release of configuration as the first release with the new groupId. snap/ Do we want to do this? Shouldn't we transition all of Commons together (as Tomasz implies in previous post, and just like we did with the JIRA transition). Suboptimal if folks have to look up which components have migrated yet, there are different groupIds for Commons components in the same POM etc. We should do all of commons, I agree, but I think it would be wise to start with one component and see that everything works as expected. Then we do the rest all in one big transition. Now, the relocation guide below (thanks for that!) talks about resigning POMs etc., which basically means we need everyone who has signed a Commons release (POM) to participate here? While writing the guide I talked to Carlos about re-signing poms, and he had never done that. So I don't think that it is necessary for us either. What we do is add a relocation section to the pom, nothing else is touched. Do we sign commons poms that goes to the Maven repo? I had a look in the repo before and got mixed results. -- Dennis Lundberg -Rahul I will do the necessary work to relocate this and previous releases of configuration, once the release has been made, so that the transition is as transparent as possible to downstream users. More info on what steps need to be taken can be found here: http://maven.apache.org/guides/mini/guide-relocation.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] maven group ids
Hi, just wanted to ask if there is already a resolution related to the groupIds of commons components. [configuration] is preparing for the next release. ATM the pom defines the new groupId org.apache.commons. Should we go with that (which additional work would this cause?) or would it be better to revert to commons-configuration? Thanks Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Oliver Heger wrote: Hi, just wanted to ask if there is already a resolution related to the groupIds of commons components. [configuration] is preparing for the next release. ATM the pom defines the new groupId org.apache.commons. Should we go with that (which additional work would this cause?) or would it be better to revert to commons-configuration? Thanks Oliver Everything is set to make the transition to the new groupId. I was hoping that we could use the upcoming release of configuration as the first release with the new groupId. I will do the necessary work to relocate this and previous releases of configuration, once the release has been made, so that the transition is as transparent as possible to downstream users. More info on what steps need to be taken can be found here: http://maven.apache.org/guides/mini/guide-relocation.html -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Dennis Lundberg wrote: Oliver Heger wrote: Hi, just wanted to ask if there is already a resolution related to the groupIds of commons components. [configuration] is preparing for the next release. ATM the pom defines the new groupId org.apache.commons. Should we go with that (which additional work would this cause?) or would it be better to revert to commons-configuration? Thanks Oliver Everything is set to make the transition to the new groupId. I was hoping that we could use the upcoming release of configuration as the first release with the new groupId. I will do the necessary work to relocate this and previous releases of configuration, once the release has been made, so that the transition is as transparent as possible to downstream users. More info on what steps need to be taken can be found here: http://maven.apache.org/guides/mini/guide-relocation.html Okay, then the release should happen in the normal way with the new groupId, and the relocation comes after that, right? That's fine. I will probably publish RC2 in the next days and then, after a while, call out the release vote. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Oliver Heger wrote: Dennis Lundberg wrote: Oliver Heger wrote: Hi, just wanted to ask if there is already a resolution related to the groupIds of commons components. [configuration] is preparing for the next release. ATM the pom defines the new groupId org.apache.commons. Should we go with that (which additional work would this cause?) or would it be better to revert to commons-configuration? Thanks Oliver Everything is set to make the transition to the new groupId. I was hoping that we could use the upcoming release of configuration as the first release with the new groupId. I will do the necessary work to relocate this and previous releases of configuration, once the release has been made, so that the transition is as transparent as possible to downstream users. More info on what steps need to be taken can be found here: http://maven.apache.org/guides/mini/guide-relocation.html Okay, then the release should happen in the normal way with the new groupId, and the relocation comes after that, right? That's correct. That's fine. I will probably publish RC2 in the next days and then, after a while, call out the release vote. We should have a note about the change of groupId somewhere on the configuration site, probably on the start page. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Everything is set to make the transition to the new groupId. I was hoping that we could use the upcoming release of configuration as the first release with the new groupId. I will do the necessary work to relocate this and previous releases of configuration, once the release has been made, so that the transition is as transparent as possible to downstream users Configuration depends on many commons components: * commons-collections * commons-lang * commons-logging-api * commons-beanutils-core * commons-codec * commons-jxpath maybe it will be better to relocate them first, make configuration depending on relocated (final?) group/artifact Ids instead of releasing pom, that will depend on something, which will be obsoleted some time later (as I understand, releases of next versions of commons packages will mean 'release new version under new groupId and relocate previous version). just my 5cents, regards, Tomek . Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
