Re: scopeperi/scope
Stan Devitt, Platform Group - Original Message - From: Jörg Schaible [mailto:joerg.schai...@scalaris.com] Sent: Tuesday, June 28, 2011 02:40 AM To: dev@maven.apache.org dev@maven.apache.org Subject: Re: scopeperi/scope Brett Porter wrote: On 28/06/2011, at 7:46 AM, Benson Margulies wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Right - you should be declaring a new type in a plugin that can turn off addedToClasspath/ A component descriptor is normally enough. A plugin is only needed if such an archive requires a very special handling that cannot be accomplished easily with the dependency or assembly plugin. - or use a packaging type like zip which wasn't already. Just as a side node: ZIP *is* added to the classpath - unfortunately. We use therefore a simple jar file with a plexus component descriptor that turns that off: % = component-set components component roleorg.apache.maven.artifact.handler.ArtifactHandler/role role-hintzip/role-hint implementationorg.apache.maven.artifact.handler.DefaultArtifactHandler/implementation configuration typezip/type addedToClasspathfalse/addedToClasspath includesDependenciestrue/includesDependencies /configuration /component /components /component-set % = This jar is added as extension to our global parent POM. Additionally you have to set the extensions flag for all plugins to true that have to respect this (e.g. compiler plugin) which is also done in this parent POM in the pluginMgmt section. [snip] - Jörg - 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: scopeperi/scope
Apologies: I hit the wrong button. I am enjoying this thread. My main observation so far is that if you need one custom scope (and I think you do) then you will need more. Provided is not enough. The custom scope seems to let you get at lists of dependencies that have a special purpose. They seem to do this without breaking anything or interfering with the existing classpaths.. There can be more than one special purpose. There is more than just Java. Stan Stan Devitt, Platform Group - 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
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
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
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
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: User's project-specific properties ability disabled after MNG-4060
A major difference is that the settings.xml file is not stored with the project source. If your project depends on the profile(s) in some crucial way the information should be archived with the project. In that case the settings.xml is not an option. Stan - Original Message - From: Brian Fox bri...@infinity.nu To: Maven Developers List dev@maven.apache.org Sent: Wed Jun 24 12:22:33 2009 Subject: Re: User's project-specific properties ability disabled after MNG-4060 Why not just put those values into the settings.xml? On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholterfscho...@codehaus.org wrote: I heard some time ago that the profiles.xml were removed in Maven3. Although I'm still using 2.1.0 I want to be prepared for such changes. IMHO I think it's a bad choice to remove this option. Maven should provide some sort of way where developers can set/change project properties without having to change the pom.xml. I believe the pom should not contain developer-specific properties and which can or will end up in any scm. Think of datasource-properties. There are three degrees of properties: - the global properties (combined with the activeByDefault-profile) - profile-properties (where profiles cover multiple users. By OS, 'stage') - personal properties. These personal properties can only be used with a personal profile. A personal profile is the best example of data which doesn´t belong in a pom but in a separate file (and probably not in scm). Personal properties should be somewhere close to the project, like in the root of the project (yes, like the profiles.xml). The both settings.xml is too far from the project and there's no option in the (user's) settings.xml to set project-specific properties. I think that if there was a vote concerning this issue it might result in a long discussion. It's never too late for that, so let's give it a try. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ - 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
