RE: Depending on Artifacts not in central
Here is some feedback on http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repositor y+discovery Of the 4 requirements listed: 1. ability to checkout and build with no prior setup (extremely important) 3. separate plugin dependency resolution from project dependency resolution. and 4. Use URL's as ids are clear. However, I have concerns about the requirement 2. bypass transitive resolution to depend directly on a jar It is apparently justified by concern over cost of searching a growing and unpredictable list of repositories, but I think it misses the real problem and is also (I believe) in direct conflict with 1. The real problem is not the cost, but the risk inherent in searching additional repositories. The main risk is that you may have two or more deployments of the same artifact and they may not be the same. In fact, this is almost guaranteed to happen in the presence of historic jar deployment policies forcing every user site to deploy on their own a copy or a rebuilt copy of certain artifacts. (At very least the poms will often differ.) So, the two extremely important missing requirements are: 5. If inconsistent deployments of an artifact are encountered (and they will be) during the search (pom and/or jar) this must be flagged. And 6. There must be reproducible way of choosing a specific repository for an artifact in such circumstances. Addressing this is hard but very important. Failing on conflict discovery is a good start. Attempts to solve it beyond that leads you directly into the territory of repository management.(so maybe you defer to the proxy/repo manager, or maybe you provide a way to specify an artifact specific preferred repository in the dependency management section ... ) Preventing the corrupt deployments is even harder. It is political. Stan - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
I've long thought that the repository entry in the poms (or wherever it moves to) and mirrors in settings.xml should have some sort of filters on it. Like: repository idjava.net/id urlhttp://download.java.net/maven/1//url includes includecom.sun.*:*/include /includes excludes excludejavax.xml.*:*/exclude /excludes /repository That would allow limiting searches there to very specific artifacts. Currently, if I have that repository configured, it ALWAYS searches there for things like org.apache stuff and other things that I KNOW are not there. That slows down the build, increases net traffic, and adds a BUNCH of 404 errors in their httpd logs. Dan On Thu July 9 2009 10:03:41 am Stan Devitt wrote: Here is some feedback on http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repositor y+discovery Of the 4 requirements listed: 1. ability to checkout and build with no prior setup (extremely important) 3. separate plugin dependency resolution from project dependency resolution. and 4. Use URL's as ids are clear. However, I have concerns about the requirement 2. bypass transitive resolution to depend directly on a jar It is apparently justified by concern over cost of searching a growing and unpredictable list of repositories, but I think it misses the real problem and is also (I believe) in direct conflict with 1. The real problem is not the cost, but the risk inherent in searching additional repositories. The main risk is that you may have two or more deployments of the same artifact and they may not be the same. In fact, this is almost guaranteed to happen in the presence of historic jar deployment policies forcing every user site to deploy on their own a copy or a rebuilt copy of certain artifacts. (At very least the poms will often differ.) So, the two extremely important missing requirements are: 5. If inconsistent deployments of an artifact are encountered (and they will be) during the search (pom and/or jar) this must be flagged. And 6. There must be reproducible way of choosing a specific repository for an artifact in such circumstances. Addressing this is hard but very important. Failing on conflict discovery is a good start. Attempts to solve it beyond that leads you directly into the territory of repository management.(so maybe you defer to the proxy/repo manager, or maybe you provide a way to specify an artifact specific preferred repository in the dependency management section ... ) Preventing the corrupt deployments is even harder. It is political. Stan - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
We could have this also for mirrors.Another thing we could have in mirror definition is to say if this is for releases, snapshots or both. Arnaud On Thu, Jul 9, 2009 at 4:13 PM, Daniel Kulp dk...@apache.org wrote: I've long thought that the repository entry in the poms (or wherever it moves to) and mirrors in settings.xml should have some sort of filters on it. Like: repository idjava.net/id urlhttp://download.java.net/maven/1//url includes includecom.sun.*:*/include /includes excludes excludejavax.xml.*:*/exclude /excludes /repository That would allow limiting searches there to very specific artifacts. Currently, if I have that repository configured, it ALWAYS searches there for things like org.apache stuff and other things that I KNOW are not there. That slows down the build, increases net traffic, and adds a BUNCH of 404 errors in their httpd logs. Dan On Thu July 9 2009 10:03:41 am Stan Devitt wrote: Here is some feedback on http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repositor y+discovery Of the 4 requirements listed: 1. ability to checkout and build with no prior setup (extremely important) 3. separate plugin dependency resolution from project dependency resolution. and 4. Use URL's as ids are clear. However, I have concerns about the requirement 2. bypass transitive resolution to depend directly on a jar It is apparently justified by concern over cost of searching a growing and unpredictable list of repositories, but I think it misses the real problem and is also (I believe) in direct conflict with 1. The real problem is not the cost, but the risk inherent in searching additional repositories. The main risk is that you may have two or more deployments of the same artifact and they may not be the same. In fact, this is almost guaranteed to happen in the presence of historic jar deployment policies forcing every user site to deploy on their own a copy or a rebuilt copy of certain artifacts. (At very least the poms will often differ.) So, the two extremely important missing requirements are: 5. If inconsistent deployments of an artifact are encountered (and they will be) during the search (pom and/or jar) this must be flagged. And 6. There must be reproducible way of choosing a specific repository for an artifact in such circumstances. Addressing this is hard but very important. Failing on conflict discovery is a good start. Attempts to solve it beyond that leads you directly into the territory of repository management.(so maybe you defer to the proxy/repo manager, or maybe you provide a way to specify an artifact specific preferred repository in the dependency management section ... ) Preventing the corrupt deployments is even harder. It is political. Stan - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
Arnaud HERITIER schrieb: For the repository constraint I agree.But what can we recommend to jboss and others company which have this need to be a good maven citizen ? I'll have the same issue soon with my company exoplatform. We are interested to deploy nexus and push some of our artifacts in central but what to do with : - artifacts deployed on repositories not synched with central (java.net co) - modified oss libraires No matter how many locations a class can be downloaded from, there must only be one entity claiming authority for that class. Just like DNS works. dig maven.apache.org SOA etc. -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
Jason van Zyl wrote: On 8-Jul-09, at 6:57 PM, Stan Devitt wrote: The only thing that halfway works for rebuilt / modified artifacts is to modify the version number (e.g. 3.5-mod-by-NameOModifier). I agree. As once the patches reach the OSS project it is much easier to make the change to use the updated library. Paul, but do you rebuild the whole transitive chain? If you actually rebuild everything -- which I though was your policy -- then you are really the maintainer of the transitive chain for your users. Even if you take a tag and rebuild it yourself you've tampered with a released version someone has signed and then becomes your responsibility. If you break it, you buy it. You rebuild it, you own it. We don't currently rebuild the whole tree, but that is the goal in the future AFAIK. For RHEL, the whole tree is built from source, so there is some drive to do the same for all JBoss projects/products. I agree with you that if we rebuild it and republish it it's our responsibility. And for our products, the goal is that if we sell you support, we have control over all the source used to create the product. So I don't really know if/how this can work with also making it easy for users of our projects to depend on our artifacts without using our repository. I would be fine with changing the groupId (maybe prefixing org.jboss) for rebuilt jars if there was an easier way to sync with the original groupId in the dependency tree. Stan - Original Message - From: Brian Fox bri...@infinity.nu To: Maven Developers List dev@maven.apache.org Sent: Wed Jul 08 17:36:55 2009 Subject: Re: Depending on Artifacts not in central BTW, we already wrote a proposal on this that got relatively little feedback: http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery On Wed, Jul 8, 2009 at 5:29 PM, Paul Gierpg...@redhat.com wrote: Daniel Kulp wrote: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Yes, this is the major problem that we would have with changing the groupId for rebuilt artifacts. It works fine for small projects, but for a large dependency tree it is currently a big hassle to try to track down and exclude every place where the original groupId/artifactId is included transitively. Allowing some kind of global exclusions would be a good start (MNG-1977, MNG-3196). We currently use the enforcer plugin, but I still have to add in exclusions every time the same dependency is reintroduced in a new location in the tree. Also, anyone depending on the JBoss project might then have to add exclusions to their projects to get only the correct dependencies. But ideally there would be some way to link groupId:artifactId combinations as suggested by Stephen and Carlos. This would also help resolve artifacts that are renamed between versions which happens occasionally. Is there any work to handle this use case in Mercury? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete
Re: Depending on Artifacts not in central
I think for most changes the intent is to get the patch back into the upstream OSS project. But it's kind of dependent on who made the patch and whether the upstream project would accept it. Jason van Zyl wrote: Paul, Does JBoss never intend to get the patches back to the respective OSS projects? You plan to maintain these forks indefinitely? On 8-Jul-09, at 6:57 PM, Stan Devitt wrote: The only thing that halfway works for rebuilt / modified artifacts is to modify the version number (e.g. 3.5-mod-by-NameOModifier). Stan - Original Message - From: Brian Fox bri...@infinity.nu To: Maven Developers List dev@maven.apache.org Sent: Wed Jul 08 17:36:55 2009 Subject: Re: Depending on Artifacts not in central BTW, we already wrote a proposal on this that got relatively little feedback: http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery On Wed, Jul 8, 2009 at 5:29 PM, Paul Gierpg...@redhat.com wrote: Daniel Kulp wrote: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Yes, this is the major problem that we would have with changing the groupId for rebuilt artifacts. It works fine for small projects, but for a large dependency tree it is currently a big hassle to try to track down and exclude every place where the original groupId/artifactId is included transitively. Allowing some kind of global exclusions would be a good start (MNG-1977, MNG-3196). We currently use the enforcer plugin, but I still have to add in exclusions every time the same dependency is reintroduced in a new location in the tree. Also, anyone depending on the JBoss project might then have to add exclusions to their projects to get only the correct dependencies. But ideally there would be some way to link groupId:artifactId combinations as suggested by Stephen and Carlos. This would also help resolve artifacts that are renamed between versions which happens occasionally. Is there any work to handle this use case in Mercury? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Depending on Artifacts not in central
The only thing preventing changing the groupId/ArtifactId is that if you do, it breaks dependency resolution and hence the maven model. That is pretty serious. Now, ... perhaps if there were some sort of alias facility so that dependency resolution could be told that two different Artifact coordinate sets were really the same up to version number ? Until then - all you have is version number to play with. Stan -Original Message- From: Paul Gier [mailto:pg...@redhat.com] Sent: Thursday, July 09, 2009 11:54 AM To: Maven Developers List Subject: Re: Depending on Artifacts not in central [stuff deleted ... ] So I don't really know if/how this can work with also making it easy for users of our projects to depend on our artifacts without using our repository. I would be fine with changing the groupId (maybe prefixing org.jboss) for rebuilt jars if there was an easier way to sync with the original groupId in the dependency tree. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
If in the new pom with another groupId we add the relocation info with old group, doesn't it solve the problem ? I didn't test. On Thu, Jul 9, 2009 at 6:04 PM, Stan Devitt sdev...@rim.com wrote: The only thing preventing changing the groupId/ArtifactId is that if you do, it breaks dependency resolution and hence the maven model. That is pretty serious. Now, ... perhaps if there were some sort of alias facility so that dependency resolution could be told that two different Artifact coordinate sets were really the same up to version number ? Until then - all you have is version number to play with. Stan -Original Message- From: Paul Gier [mailto:pg...@redhat.com] Sent: Thursday, July 09, 2009 11:54 AM To: Maven Developers List Subject: Re: Depending on Artifacts not in central [stuff deleted ... ] So I don't really know if/how this can work with also making it easy for users of our projects to depend on our artifacts without using our repository. I would be fine with changing the groupId (maybe prefixing org.jboss) for rebuilt jars if there was an easier way to sync with the original groupId in the dependency tree. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Depending on Artifacts not in central
Hi Everyone I recently found out that the buildhelper-maven-plugin has a transitive dependency not located in the central maven repository (MOJO-1401). This causes problems with a strict repository setup (using mirror settings, etc). But most users probably don't notice this because the dependency introduces the needed repository into builds through the repo listed in the dependency's POM. Is there a policy or guideline that any artifacts in central should have all their dependencies available in central? Is there any way to enforce this? This is also related to the issue of dependencies being able to introduce repositories into the build (MNG-3056). Will this be fixed in 3.0? In my opinion, the repositories section should be removed from the POM completely. I realize this causes a useability problem in that you have to configure all repositories in settings.xml before building the project. Maybe we can allow a project specific settings.xml located in the same directory as the POM that could be checked into svn and allow project specific settings. Thanks! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
As far as the JBoss stuff in central, we've been trying to get automatic synching going between repositories for a while. The artifacts that are there now were uploaded manually. The synching will probably happen someday, but jboss.org is undergoing a long painful migration process and the repository stuff has been low priority for the people working on it. One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository, then we run into a problem with synching. We can't publish this jar to central because we are not the owner of the project, and we can't publish our own projects because they depend on a jar that's only in our repository. Stephen Connolly wrote: AFAIK, repository and pluginRepository entries are banned from artifacts published to central (unless they are for snapshots only, or unless they are in an inactive by default profile) I do not think anything is enforcing this ban though. I would agree with this policy. Having repository or pluginRepository definitions in a pom.xml can have a massive performance impact... as eery artifact then gets checked in these extra repositories. The biggest issues I see are that two big java companies are very poor at pushing artifacts to central... 1. This company called Sun are very poor when it comes to pushing artifacts to central, preferring to keep all their artifacts in a repo that has *both* snapshots and non-snapshots... EEK!!! 2. This other company called RedHat have a subsidiary called JBoss that maintain their own repository with a whole pile of really useful artifacts as well as a pile of stuff from central. If you happen to know somebody in either of these companies, I would suggest applying some pressure to maintain artifacts in central ;-) I also think that somebody needs to put in place a means of policing the (perhaps informal) rules about artifacts in central or we will have much bigger problems going forward. -Stephen 2009/7/8 Paul Gier pg...@redhat.com: Hi Everyone I recently found out that the buildhelper-maven-plugin has a transitive dependency not located in the central maven repository (MOJO-1401). This causes problems with a strict repository setup (using mirror settings, etc). But most users probably don't notice this because the dependency introduces the needed repository into builds through the repo listed in the dependency's POM. Is there a policy or guideline that any artifacts in central should have all their dependencies available in central? Is there any way to enforce this? This is also related to the issue of dependencies being able to introduce repositories into the build (MNG-3056). Will this be fixed in 3.0? In my opinion, the repositories section should be removed from the POM completely. I realize this causes a useability problem in that you have to configure all repositories in settings.xml before building the project. Maybe we can allow a project specific settings.xml located in the same directory as the POM that could be checked into svn and allow project specific settings. Thanks! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
AFAIK, repository and pluginRepository entries are banned from artifacts published to central (unless they are for snapshots only, or unless they are in an inactive by default profile) I do not think anything is enforcing this ban though. I would agree with this policy. Having repository or pluginRepository definitions in a pom.xml can have a massive performance impact... as eery artifact then gets checked in these extra repositories. The biggest issues I see are that two big java companies are very poor at pushing artifacts to central... 1. This company called Sun are very poor when it comes to pushing artifacts to central, preferring to keep all their artifacts in a repo that has *both* snapshots and non-snapshots... EEK!!! 2. This other company called RedHat have a subsidiary called JBoss that maintain their own repository with a whole pile of really useful artifacts as well as a pile of stuff from central. If you happen to know somebody in either of these companies, I would suggest applying some pressure to maintain artifacts in central ;-) I also think that somebody needs to put in place a means of policing the (perhaps informal) rules about artifacts in central or we will have much bigger problems going forward. -Stephen 2009/7/8 Paul Gier pg...@redhat.com: Hi Everyone I recently found out that the buildhelper-maven-plugin has a transitive dependency not located in the central maven repository (MOJO-1401). This causes problems with a strict repository setup (using mirror settings, etc). But most users probably don't notice this because the dependency introduces the needed repository into builds through the repo listed in the dependency's POM. Is there a policy or guideline that any artifacts in central should have all their dependencies available in central? Is there any way to enforce this? This is also related to the issue of dependencies being able to introduce repositories into the build (MNG-3056). Will this be fixed in 3.0? In my opinion, the repositories section should be removed from the POM completely. I realize this causes a useability problem in that you have to configure all repositories in settings.xml before building the project. Maybe we can allow a project specific settings.xml located in the same directory as the POM that could be checked into svn and allow project specific settings. Thanks! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
Benjamin is right, if you rebuild something it should be under your groupId On Wed, Jul 8, 2009 at 1:13 PM, Benjamin Bentmannbenjamin.bentm...@udo.edu wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
But it creates many issues to resolve transitive dependencies. With that you can have in a tree org.jboss.log4j:log4j:1.2.36 and log4j:log4j:1.2.12Is it working fine if in the pom of org.jboss.log4j:log4j:1.2.36 we set a relocation ? Can it have some others impacts ? Arnaud On Wed, Jul 8, 2009 at 10:13 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
if they rebuild it then it must have something different and they would need to handle the differences in some way. I can't imagine they rebuild the jars just for the sake of doing it. On Wed, Jul 8, 2009 at 1:18 PM, Arnaud HERITIERaherit...@gmail.com wrote: But it creates many issues to resolve transitive dependencies. With that you can have in a tree org.jboss.log4j:log4j:1.2.36 and log4j:log4j:1.2.12Is it working fine if in the pom of org.jboss.log4j:log4j:1.2.36 we set a relocation ? Can it have some others impacts ? Arnaud On Wed, Jul 8, 2009 at 10:13 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
we really need some sort of provides groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version /provides another option would be to add a new scope, e.g. implemented dependency groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version scopeimplemented/scope /dependency that way we can filter out any artifacts which are implemented from the tree... e.g. if I depend on org.jboss.thirdparty:log4j Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that it does not need to be pulled in via transative dependencies 2009/7/8 Daniel Kulp dk...@apache.org: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
other possible names for the scope could be encapsulated, or bundled 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: we really need some sort of provides groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version /provides another option would be to add a new scope, e.g. implemented dependency groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version scopeimplemented/scope /dependency that way we can filter out any artifacts which are implemented from the tree... e.g. if I depend on org.jboss.thirdparty:log4j Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that it does not need to be pulled in via transative dependencies 2009/7/8 Daniel Kulp dk...@apache.org: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
Hmmm, how would this work w.r.t. resolving... If I add log4j:log4j and org.jboss.thirdparty:log4j as dependencies, then I would get both artifacts on my classpath with a warning from Maven. If I add log4j:log4j as a direct, and org.jboss.thirdparty:log4j as a transitive via another dependency, then I get both artitfacts and Maven would print a warning If I add org.jboss.thirdparty:log4j as a direct, and log4j:log4j as a transitive via another dependency, then I get only org.jboss.thirdparty:log4j as the transitive dependency has already been provided by a nearer dependency 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: other possible names for the scope could be encapsulated, or bundled 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: we really need some sort of provides groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version /provides another option would be to add a new scope, e.g. implemented dependency groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version scopeimplemented/scope /dependency that way we can filter out any artifacts which are implemented from the tree... e.g. if I depend on org.jboss.thirdparty:log4j Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that it does not need to be pulled in via transative dependencies 2009/7/8 Daniel Kulp dk...@apache.org: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
OK, a problem... what if I have both org.jboss.thirdparty:log4j *and* com.sun.thirdparty:log4j on my classpath? we have to give a warning of some sort... perhaps fail the build and let the user resolve this through exclusions in this regard a scope of relocation might be better... as we would not want people bundling several artifacts into the one artifact. 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: Hmmm, how would this work w.r.t. resolving... If I add log4j:log4j and org.jboss.thirdparty:log4j as dependencies, then I would get both artifacts on my classpath with a warning from Maven. If I add log4j:log4j as a direct, and org.jboss.thirdparty:log4j as a transitive via another dependency, then I get both artitfacts and Maven would print a warning If I add org.jboss.thirdparty:log4j as a direct, and log4j:log4j as a transitive via another dependency, then I get only org.jboss.thirdparty:log4j as the transitive dependency has already been provided by a nearer dependency 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: other possible names for the scope could be encapsulated, or bundled 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: we really need some sort of provides groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version /provides another option would be to add a new scope, e.g. implemented dependency groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version scopeimplemented/scope /dependency that way we can filter out any artifacts which are implemented from the tree... e.g. if I depend on org.jboss.thirdparty:log4j Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that it does not need to be pulled in via transative dependencies 2009/7/8 Daniel Kulp dk...@apache.org: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
see MNG-2316 about handling this issue, it has been there for a long time but talking about the repository it is impossible for jboss to publish their builds under the log4j group On Wed, Jul 8, 2009 at 1:43 PM, Stephen Connollystephen.alan.conno...@gmail.com wrote: Hmmm, how would this work w.r.t. resolving... If I add log4j:log4j and org.jboss.thirdparty:log4j as dependencies, then I would get both artifacts on my classpath with a warning from Maven. If I add log4j:log4j as a direct, and org.jboss.thirdparty:log4j as a transitive via another dependency, then I get both artitfacts and Maven would print a warning If I add org.jboss.thirdparty:log4j as a direct, and log4j:log4j as a transitive via another dependency, then I get only org.jboss.thirdparty:log4j as the transitive dependency has already been provided by a nearer dependency 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: other possible names for the scope could be encapsulated, or bundled 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: we really need some sort of provides groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version /provides another option would be to add a new scope, e.g. implemented dependency groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version scopeimplemented/scope /dependency that way we can filter out any artifacts which are implemented from the tree... e.g. if I depend on org.jboss.thirdparty:log4j Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that it does not need to be pulled in via transative dependencies 2009/7/8 Daniel Kulp dk...@apache.org: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: OK, a problem... what if I have both org.jboss.thirdparty:log4j *and* com.sun.thirdparty:log4j on my classpath? we have to give a warning of some sort... perhaps fail the build and let the user resolve this through exclusions in this regard a scope of relocation might be better... as we would not want people bundling several artifacts into the one artifact. Or we could blow up the build if you try to have more than one implements scope dependency in any one project... that'll solve it! 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: Hmmm, how would this work w.r.t. resolving... If I add log4j:log4j and org.jboss.thirdparty:log4j as dependencies, then I would get both artifacts on my classpath with a warning from Maven. If I add log4j:log4j as a direct, and org.jboss.thirdparty:log4j as a transitive via another dependency, then I get both artitfacts and Maven would print a warning If I add org.jboss.thirdparty:log4j as a direct, and log4j:log4j as a transitive via another dependency, then I get only org.jboss.thirdparty:log4j as the transitive dependency has already been provided by a nearer dependency 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: other possible names for the scope could be encapsulated, or bundled 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: we really need some sort of provides groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version /provides another option would be to add a new scope, e.g. implemented dependency groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version scopeimplemented/scope /dependency that way we can filter out any artifacts which are implemented from the tree... e.g. if I depend on org.jboss.thirdparty:log4j Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that it does not need to be pulled in via transative dependencies 2009/7/8 Daniel Kulp dk...@apache.org: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
On Wed, Jul 8, 2009 at 10:23 PM, Daniel Kulp dk...@apache.org wrote: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan yes it was the case I had in mind Arnaud
Re: Depending on Artifacts not in central
For the repository constraint I agree.But what can we recommend to jboss and others company which have this need to be a good maven citizen ? I'll have the same issue soon with my company exoplatform. We are interested to deploy nexus and push some of our artifacts in central but what to do with : - artifacts deployed on repositories not synched with central (java.net co) - modified oss libraires Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net On Wed, Jul 8, 2009 at 10:46 PM, Carlos Sanchez car...@apache.org wrote: see MNG-2316 about handling this issue, it has been there for a long time but talking about the repository it is impossible for jboss to publish their builds under the log4j group On Wed, Jul 8, 2009 at 1:43 PM, Stephen Connollystephen.alan.conno...@gmail.com wrote: Hmmm, how would this work w.r.t. resolving... If I add log4j:log4j and org.jboss.thirdparty:log4j as dependencies, then I would get both artifacts on my classpath with a warning from Maven. If I add log4j:log4j as a direct, and org.jboss.thirdparty:log4j as a transitive via another dependency, then I get both artitfacts and Maven would print a warning If I add org.jboss.thirdparty:log4j as a direct, and log4j:log4j as a transitive via another dependency, then I get only org.jboss.thirdparty:log4j as the transitive dependency has already been provided by a nearer dependency 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: other possible names for the scope could be encapsulated, or bundled 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: we really need some sort of provides groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version /provides another option would be to add a new scope, e.g. implemented dependency groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version scopeimplemented/scope /dependency that way we can filter out any artifacts which are implemented from the tree... e.g. if I depend on org.jboss.thirdparty:log4j Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that it does not need to be pulled in via transative dependencies 2009/7/8 Daniel Kulp dk...@apache.org: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
Daniel Kulp wrote: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Yes, this is the major problem that we would have with changing the groupId for rebuilt artifacts. It works fine for small projects, but for a large dependency tree it is currently a big hassle to try to track down and exclude every place where the original groupId/artifactId is included transitively. Allowing some kind of global exclusions would be a good start (MNG-1977, MNG-3196). We currently use the enforcer plugin, but I still have to add in exclusions every time the same dependency is reintroduced in a new location in the tree. Also, anyone depending on the JBoss project might then have to add exclusions to their projects to get only the correct dependencies. But ideally there would be some way to link groupId:artifactId combinations as suggested by Stephen and Carlos. This would also help resolve artifacts that are renamed between versions which happens occasionally. Is there any work to handle this use case in Mercury? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
BTW, we already wrote a proposal on this that got relatively little feedback: http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery On Wed, Jul 8, 2009 at 5:29 PM, Paul Gierpg...@redhat.com wrote: Daniel Kulp wrote: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Yes, this is the major problem that we would have with changing the groupId for rebuilt artifacts. It works fine for small projects, but for a large dependency tree it is currently a big hassle to try to track down and exclude every place where the original groupId/artifactId is included transitively. Allowing some kind of global exclusions would be a good start (MNG-1977, MNG-3196). We currently use the enforcer plugin, but I still have to add in exclusions every time the same dependency is reintroduced in a new location in the tree. Also, anyone depending on the JBoss project might then have to add exclusions to their projects to get only the correct dependencies. But ideally there would be some way to link groupId:artifactId combinations as suggested by Stephen and Carlos. This would also help resolve artifacts that are renamed between versions which happens occasionally. Is there any work to handle this use case in Mercury? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
1. maintain the ability for a user to checkout your code and run mvn install and have it work with no prior setup on their part. Hmmm... there are +++'s and ---'s with this one 1. 2. be able to depend on some jar and not worry about any repositories required for transitive resolution (ie discover the repositories transitively as dependencies are processed) *(this is controversial and may be eliminated. First it contributes to the Problem #4 above in that SAT can't be done on a bounded list of repositories. It also doesn't work normally behind a repository manager because the list of repos is usually controlled in the repo manager and thus autodiscovery is intentionally blocked, usually via a mirrorOf * to circumvent the repos maven finds in the poms.)* Not sure i agree with this one 1. ** 2. be able to separate the dependencies needed by maven plugins from those needed by the build. This means not only where they are resolved from, but also how they are stored locally to prevent cross-contamination. I am less convinced this is necessary these days... better is separation of repo caches in local 1. 2. Repository identification: at this point we are pretty much in agreement that the URL should be the unique identifier for a repository. People who care about what they are publishing either need to use canonical repositories like Maven central or need to guarantee the existence of the repositories or have decent pointers. In a fully distributed system the relocation mechanism we have does not work in a fully distributed system without a master to manage relocations. +1 2009/7/8 Brian Fox bri...@infinity.nu: BTW, we already wrote a proposal on this that got relatively little feedback: http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery On Wed, Jul 8, 2009 at 5:29 PM, Paul Gierpg...@redhat.com wrote: Daniel Kulp wrote: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Yes, this is the major problem that we would have with changing the groupId for rebuilt artifacts. It works fine for small projects, but for a large dependency tree it is currently a big hassle to try to track down and exclude every place where the original groupId/artifactId is included transitively. Allowing some kind of global exclusions would be a good start (MNG-1977, MNG-3196). We currently use the enforcer plugin, but I still have to add in exclusions every time the same dependency is reintroduced in a new location in the tree. Also, anyone depending on the JBoss project might then have to add exclusions to their projects to get only the correct dependencies. But ideally there would be some way to link groupId:artifactId combinations as suggested by Stephen and Carlos. This would also help resolve artifacts that are renamed between versions which happens occasionally. Is there any work to handle this use case in Mercury? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
A solution I am tending towards is a repositories.xml file adjacent to the pom.xml This covers #1 and makes #2 redundant #3 and #4 are separate issues IMHO 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com 1. maintain the ability for a user to checkout your code and run mvn install and have it work with no prior setup on their part. Hmmm... there are +++'s and ---'s with this one I see this as a separate problem from repositories in the pom 1. 2. be able to depend on some jar and not worry about any repositories required for transitive resolution (ie discover the repositories transitively as dependencies are processed) *(this is controversial and may be eliminated. First it contributes to the Problem #4 above in that SAT can't be done on a bounded list of repositories. It also doesn't work normally behind a repository manager because the list of repos is usually controlled in the repo manager and thus autodiscovery is intentionally blocked, usually via a mirrorOf * to circumvent the repos maven finds in the poms.)* Not sure i agree with this one I think this is a bad plan. It's your build, you specify where dependencies can come from. If somebody else depends on your artifact, they specify where dependencies can come from. We should provide tools to make it easy for them to grab the repos you specified (assuming they trust you ;-) ) 1. ** 2. be able to separate the dependencies needed by maven plugins from those needed by the build. This means not only where they are resolved from, but also how they are stored locally to prevent cross-contamination. I am less convinced this is necessary these days... better is separation of repo caches in local 1. 2. Repository identification: at this point we are pretty much in agreement that the URL should be the unique identifier for a repository. People who care about what they are publishing either need to use canonical repositories like Maven central or need to guarantee the existence of the repositories or have decent pointers. In a fully distributed system the relocation mechanism we have does not work in a fully distributed system without a master to manage relocations. +1 2009/7/8 Brian Fox bri...@infinity.nu: BTW, we already wrote a proposal on this that got relatively little feedback: http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery On Wed, Jul 8, 2009 at 5:29 PM, Paul Gierpg...@redhat.com wrote: Daniel Kulp wrote: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Yes, this is the major problem that we would have with changing the groupId for rebuilt artifacts. It works fine for small projects, but for a large dependency tree it is currently a big hassle to try to track down and exclude every place where the original groupId/artifactId is included transitively. Allowing some kind of global exclusions would be a good start (MNG-1977, MNG-3196). We currently use the enforcer plugin, but I still have to add in exclusions every time the same dependency is reintroduced in a new location in the tree. Also, anyone depending on the JBoss project might then have to add exclusions to their projects to get only the correct dependencies. But ideally there would be some way to link groupId:artifactId combinations as suggested by Stephen and Carlos. This would also help resolve artifacts that are renamed between versions which happens occasionally. Is there any work to handle this use case in Mercury? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional
Re: Depending on Artifacts not in central
The only thing that halfway works for rebuilt / modified artifacts is to modify the version number (e.g. 3.5-mod-by-NameOModifier). Stan - Original Message - From: Brian Fox bri...@infinity.nu To: Maven Developers List dev@maven.apache.org Sent: Wed Jul 08 17:36:55 2009 Subject: Re: Depending on Artifacts not in central BTW, we already wrote a proposal on this that got relatively little feedback: http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery On Wed, Jul 8, 2009 at 5:29 PM, Paul Gierpg...@redhat.com wrote: Daniel Kulp wrote: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Yes, this is the major problem that we would have with changing the groupId for rebuilt artifacts. It works fine for small projects, but for a large dependency tree it is currently a big hassle to try to track down and exclude every place where the original groupId/artifactId is included transitively. Allowing some kind of global exclusions would be a good start (MNG-1977, MNG-3196). We currently use the enforcer plugin, but I still have to add in exclusions every time the same dependency is reintroduced in a new location in the tree. Also, anyone depending on the JBoss project might then have to add exclusions to their projects to get only the correct dependencies. But ideally there would be some way to link groupId:artifactId combinations as suggested by Stephen and Carlos. This would also help resolve artifacts that are renamed between versions which happens occasionally. Is there any work to handle this use case in Mercury? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
Paul, Does JBoss never intend to get the patches back to the respective OSS projects? You plan to maintain these forks indefinitely? On 8-Jul-09, at 6:57 PM, Stan Devitt wrote: The only thing that halfway works for rebuilt / modified artifacts is to modify the version number (e.g. 3.5-mod-by-NameOModifier). Stan - Original Message - From: Brian Fox bri...@infinity.nu To: Maven Developers List dev@maven.apache.org Sent: Wed Jul 08 17:36:55 2009 Subject: Re: Depending on Artifacts not in central BTW, we already wrote a proposal on this that got relatively little feedback: http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery On Wed, Jul 8, 2009 at 5:29 PM, Paul Gierpg...@redhat.com wrote: Daniel Kulp wrote: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Yes, this is the major problem that we would have with changing the groupId for rebuilt artifacts. It works fine for small projects, but for a large dependency tree it is currently a big hassle to try to track down and exclude every place where the original groupId/artifactId is included transitively. Allowing some kind of global exclusions would be a good start (MNG-1977, MNG-3196). We currently use the enforcer plugin, but I still have to add in exclusions every time the same dependency is reintroduced in a new location in the tree. Also, anyone depending on the JBoss project might then have to add exclusions to their projects to get only the correct dependencies. But ideally there would be some way to link groupId:artifactId combinations as suggested by Stephen and Carlos. This would also help resolve artifacts that are renamed between versions which happens occasionally. Is there any work to handle this use case in Mercury? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Depending on Artifacts not in central
On 8-Jul-09, at 6:57 PM, Stan Devitt wrote: The only thing that halfway works for rebuilt / modified artifacts is to modify the version number (e.g. 3.5-mod-by-NameOModifier). I agree. As once the patches reach the OSS project it is much easier to make the change to use the updated library. Paul, but do you rebuild the whole transitive chain? If you actually rebuild everything -- which I though was your policy -- then you are really the maintainer of the transitive chain for your users. Even if you take a tag and rebuild it yourself you've tampered with a released version someone has signed and then becomes your responsibility. If you break it, you buy it. You rebuild it, you own it. Stan - Original Message - From: Brian Fox bri...@infinity.nu To: Maven Developers List dev@maven.apache.org Sent: Wed Jul 08 17:36:55 2009 Subject: Re: Depending on Artifacts not in central BTW, we already wrote a proposal on this that got relatively little feedback: http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery On Wed, Jul 8, 2009 at 5:29 PM, Paul Gierpg...@redhat.com wrote: Daniel Kulp wrote: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Yes, this is the major problem that we would have with changing the groupId for rebuilt artifacts. It works fine for small projects, but for a large dependency tree it is currently a big hassle to try to track down and exclude every place where the original groupId/artifactId is included transitively. Allowing some kind of global exclusions would be a good start (MNG-1977, MNG-3196). We currently use the enforcer plugin, but I still have to add in exclusions every time the same dependency is reintroduced in a new location in the tree. Also, anyone depending on the JBoss project might then have to add exclusions to their projects to get only the correct dependencies. But ideally there would be some way to link groupId:artifactId combinations as suggested by Stephen and Carlos. This would also help resolve artifacts that are renamed between versions which happens occasionally. Is there any work to handle this use case in Mercury? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going
Re: Depending on Artifacts not in central
Note that even changing the pom (say the dependency section, but really anythng in the pom) is enough to trigger the need for a version change even if the jars remain untouched. Stan - Original Message - From: Jason van Zyl jvan...@sonatype.com To: Maven Developers List dev@maven.apache.org Sent: Wed Jul 08 20:58:43 2009 Subject: Re: Depending on Artifacts not in central On 8-Jul-09, at 6:57 PM, Stan Devitt wrote: The only thing that halfway works for rebuilt / modified artifacts is to modify the version number (e.g. 3.5-mod-by-NameOModifier). I agree. As once the patches reach the OSS project it is much easier to make the change to use the updated library. Paul, but do you rebuild the whole transitive chain? If you actually rebuild everything -- which I though was your policy -- then you are really the maintainer of the transitive chain for your users. Even if you take a tag and rebuild it yourself you've tampered with a released version someone has signed and then becomes your responsibility. If you break it, you buy it. You rebuild it, you own it. Stan - Original Message - From: Brian Fox bri...@infinity.nu To: Maven Developers List dev@maven.apache.org Sent: Wed Jul 08 17:36:55 2009 Subject: Re: Depending on Artifacts not in central BTW, we already wrote a proposal on this that got relatively little feedback: http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery On Wed, Jul 8, 2009 at 5:29 PM, Paul Gierpg...@redhat.com wrote: Daniel Kulp wrote: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Yes, this is the major problem that we would have with changing the groupId for rebuilt artifacts. It works fine for small projects, but for a large dependency tree it is currently a big hassle to try to track down and exclude every place where the original groupId/artifactId is included transitively. Allowing some kind of global exclusions would be a good start (MNG-1977, MNG-3196). We currently use the enforcer plugin, but I still have to add in exclusions every time the same dependency is reintroduced in a new location in the tree. Also, anyone depending on the JBoss project might then have to add exclusions to their projects to get only the correct dependencies. But ideally there would be some way to link groupId:artifactId combinations as suggested by Stephen and Carlos. This would also help resolve artifacts that are renamed between versions which happens occasionally. Is there any work to handle this use case in Mercury? Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks
Re: Depending on Artifacts not in central
On 09/07/2009, at 7:36 AM, Brian Fox wrote: BTW, we already wrote a proposal on this that got relatively little feedback: http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery In case it got drowned out: http://mail-archives.apache.org/mod_mbox/maven-dev/200907.mbox/%3c415cc13b-4f80-4782-9a0f-5f0051a93...@apache.org%3e - Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
