Re: Can't exclude org.mortbay.jetty:servlet-api from cobertura dependency
Hi, Try with artifactIdservlet-api-2.5/artifactId spec version is in the artifactId. On Tue, Jan 28, 2014 at 6:52 PM, Andrew Pennebaker apenneba...@42six.comwrote: I want to use Cobertura for code coverage, but its dependencies are interfering with my XML parsing and Jetty serving. I'm able to resolve most of these by using exclusion's, but Maven is somehow *still* putting one dependency in particular, jetty servlet-api, on the CLASSPATH. pom.xml: ... dependencies dependency groupIdnet.sourceforge.cobertura/groupId artifactIdcobertura/artifactId version2.0.3/version exclusions exclusion groupIdorg.mortbay.jetty/groupId artifactIdservlet-api/artifactId /exclusion /exclusions /dependency /dependencies ... As confirmed by `mvn dependency:tree`, cobertura is still bringing jetty's servlet-api onto the CLASSPATH. Am I doing something wrong? -- Cheers, Andrew Pennebaker apenneba...@42six.com -- Adrien Rivard
Re: dependency plugin strangeness
The crucial detail was omitted... what version of Maven? I suspect it could be a transitive dependency with system scope causing a bug of some sort. Most likely if you switch to a different version of Maven the command will work... in which case you might be able to construct a test case to prove a regression. Touchstone versions of Maven to try are: 2.2.1, 3.0.4/3.0.5 and 3.1.1 If you see the error on all three then it is something different... but still an important data point. More of the stack trace would help... ideally include a line or two above and below... there is often crucial details therein... if you need to hide GAV details, change the groupId's to something gibberish, e.g. com.foobar:foo-manchu:1.0-SNAPSHOT and other dummy GAVs On 28 January 2014 22:55, Lyons, Roy roy.ly...@cmegroup.com wrote: So, I tried my google-fu first - and in general my google-fu is very very strong... I've been fighting with this multi-module plan for some time now with the developer who is reporting the issue to me. The issue manifested itself as part of a Sonar failure... the funny thing is, that the failure was on a dependenct tree resolution that Sonar was doing - so I had him try the dependency plugin and perform a dependency:tree dependency tree failed us... well, it probably isn't dependency plugin's fault but I am at a loss as to what it is really dying on or why. I would absolutely love it if someone saw this and said Oh yeah, I know that issue. Its a real pain. They have XXX defined incorrectly in their multimodule build so the dependency plugin is in a circular dependency loop (or something like that). I have no idea if its a dependency loop, was just an example. I can't share the poms because its all proprietary closed source stuff (and I have to be careful about what is shared). If this means that I dont have enough info to help, I can live with that - and will continue to plow forwards... I just wanted to see if theres someone on the list who knows exactly what I should be looking for to help shorten my investigation time. Here's an example of what dependency:tree is complaining about. mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X urls[38] = file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar Number of foreign imports: 1 import: Entry[import from realm ClassRealm[maven.api, parent: null]] - at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: org.apache.maven.plugin.PluginContainerException: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-dependency-plugin:2.8:tree: java.lang.AbstractMethodError: org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Sonatype CLM Integration
Morning All Ive been looking at license enforcement for Software packages in nexus repo and I notice Sonatype CLM will achieve this Is there a pom.xml and / or source available to configure Sonatype Component Lifecycle Management Plugin into maven pom.xml (via validate phase)? Thanks, Martin Gainty __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
Re: Sonatype CLM Integration
That question is much better to ask Sonatype directly. I would use their support mail address as it's a commercial product. /Anders 2014-01-29 Martin Gainty mgai...@hotmail.com Morning All Ive been looking at license enforcement for Software packages in nexus repo and I notice Sonatype CLM will achieve this Is there a pom.xml and / or source available to configure Sonatype Component Lifecycle Management Plugin into maven pom.xml (via validate phase)? Thanks, Martin Gainty __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
RE: Sonatype CLM Integration
Understood..I will ask sonatype support.. Takk Anders/ Martin Date: Wed, 29 Jan 2014 16:59:52 +0100 Subject: Re: Sonatype CLM Integration From: and...@hammar.net To: users@maven.apache.org That question is much better to ask Sonatype directly. I would use their support mail address as it's a commercial product. /Anders 2014-01-29 Martin Gainty mgai...@hotmail.com Morning All Ive been looking at license enforcement for Software packages in nexus repo and I notice Sonatype CLM will achieve this Is there a pom.xml and / or source available to configure Sonatype Component Lifecycle Management Plugin into maven pom.xml (via validate phase)? Thanks, Martin Gainty __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
Re: Can't exclude org.mortbay.jetty:servlet-api from cobertura dependency
Thanks! I'll try that. Oddly, mvn dependency:tree wasn't displaying the artifactId correctly. On Wed, Jan 29, 2014 at 4:45 AM, Adrien Rivard adrien.riv...@gmail.comwrote: Hi, Try with artifactIdservlet-api-2.5/artifactId spec version is in the artifactId. On Tue, Jan 28, 2014 at 6:52 PM, Andrew Pennebaker apenneba...@42six.com wrote: I want to use Cobertura for code coverage, but its dependencies are interfering with my XML parsing and Jetty serving. I'm able to resolve most of these by using exclusion's, but Maven is somehow *still* putting one dependency in particular, jetty servlet-api, on the CLASSPATH. pom.xml: ... dependencies dependency groupIdnet.sourceforge.cobertura/groupId artifactIdcobertura/artifactId version2.0.3/version exclusions exclusion groupIdorg.mortbay.jetty/groupId artifactIdservlet-api/artifactId /exclusion /exclusions /dependency /dependencies ... As confirmed by `mvn dependency:tree`, cobertura is still bringing jetty's servlet-api onto the CLASSPATH. Am I doing something wrong? -- Cheers, Andrew Pennebaker apenneba...@42six.com -- Adrien Rivard -- Cheers, Andrew Pennebaker apenneba...@42six.com
Re: dependency plugin strangeness
Hi, I have already seen such error. It is caused by the combination of a managed dependency (through dependencyManagement) defining a dependency with system scope + Maven 3 + Sonar. The same with Maven 2.2.1 should work. Though, I have never seen it directly in a dependency:tree execution; only through a sonar analysis. On my side, I got rid of the system scope usages. Vincent 2014-01-29 Stephen Connolly stephen.alan.conno...@gmail.com The crucial detail was omitted... what version of Maven? I suspect it could be a transitive dependency with system scope causing a bug of some sort. Most likely if you switch to a different version of Maven the command will work... in which case you might be able to construct a test case to prove a regression. Touchstone versions of Maven to try are: 2.2.1, 3.0.4/3.0.5 and 3.1.1 If you see the error on all three then it is something different... but still an important data point. More of the stack trace would help... ideally include a line or two above and below... there is often crucial details therein... if you need to hide GAV details, change the groupId's to something gibberish, e.g. com.foobar:foo-manchu:1.0-SNAPSHOT and other dummy GAVs On 28 January 2014 22:55, Lyons, Roy roy.ly...@cmegroup.com wrote: So, I tried my google-fu first - and in general my google-fu is very very strong... I've been fighting with this multi-module plan for some time now with the developer who is reporting the issue to me. The issue manifested itself as part of a Sonar failure... the funny thing is, that the failure was on a dependenct tree resolution that Sonar was doing - so I had him try the dependency plugin and perform a dependency:tree dependency tree failed us... well, it probably isn't dependency plugin's fault but I am at a loss as to what it is really dying on or why. I would absolutely love it if someone saw this and said Oh yeah, I know that issue. Its a real pain. They have XXX defined incorrectly in their multimodule build so the dependency plugin is in a circular dependency loop (or something like that). I have no idea if its a dependency loop, was just an example. I can't share the poms because its all proprietary closed source stuff (and I have to be careful about what is shared). If this means that I dont have enough info to help, I can live with that - and will continue to plow forwards... I just wanted to see if theres someone on the list who knows exactly what I should be looking for to help shorten my investigation time. Here's an example of what dependency:tree is complaining about. mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X urls[38] = file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar Number of foreign imports: 1 import: Entry[import from realm ClassRealm[maven.api, parent: null]] - at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: org.apache.maven.plugin.PluginContainerException: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-dependency-plugin:2.8:tree: java.lang.AbstractMethodError: org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency plugin strangeness
After Stephen mentioned trying different versions, I had the developer try out maven 2.2.1. I was about to report back that this worked and how strange it was -- but before sending I saw this email from Vincent. I'll pass along the system scope issue - perhaps that is the nail in the coffin. We reverted with 2.2.1, with instructions to work on making it 3.x compliant in the background. Thank you for all the input on this issue. It is very much appreciated. Thanks, Roy On 1/29/14 12:33 PM, Vincent Latombe vincent.lato...@gmail.com wrote: Hi, I have already seen such error. It is caused by the combination of a managed dependency (through dependencyManagement) defining a dependency with system scope + Maven 3 + Sonar. The same with Maven 2.2.1 should work. Though, I have never seen it directly in a dependency:tree execution; only through a sonar analysis. On my side, I got rid of the system scope usages. Vincent 2014-01-29 Stephen Connolly stephen.alan.conno...@gmail.com The crucial detail was omitted... what version of Maven? I suspect it could be a transitive dependency with system scope causing a bug of some sort. Most likely if you switch to a different version of Maven the command will work... in which case you might be able to construct a test case to prove a regression. Touchstone versions of Maven to try are: 2.2.1, 3.0.4/3.0.5 and 3.1.1 If you see the error on all three then it is something different... but still an important data point. More of the stack trace would help... ideally include a line or two above and below... there is often crucial details therein... if you need to hide GAV details, change the groupId's to something gibberish, e.g. com.foobar:foo-manchu:1.0-SNAPSHOT and other dummy GAVs On 28 January 2014 22:55, Lyons, Roy roy.ly...@cmegroup.com wrote: So, I tried my google-fu first - and in general my google-fu is very very strong... I've been fighting with this multi-module plan for some time now with the developer who is reporting the issue to me. The issue manifested itself as part of a Sonar failure... the funny thing is, that the failure was on a dependenct tree resolution that Sonar was doing - so I had him try the dependency plugin and perform a dependency:tree dependency tree failed us... well, it probably isn't dependency plugin's fault but I am at a loss as to what it is really dying on or why. I would absolutely love it if someone saw this and said Oh yeah, I know that issue. Its a real pain. They have XXX defined incorrectly in their multimodule build so the dependency plugin is in a circular dependency loop (or something like that). I have no idea if its a dependency loop, was just an example. I can't share the poms because its all proprietary closed source stuff (and I have to be careful about what is shared). If this means that I dont have enough info to help, I can live with that - and will continue to plow forwards... I just wanted to see if theres someone on the list who knows exactly what I should be looking for to help shorten my investigation time. Here's an example of what dependency:tree is complaining about. mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X urls[38] = file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons- collections/3.2.1/commons-collections-3.2.1.jar Number of foreign imports: 1 import: Entry[import from realm ClassRealm[maven.api, parent: null]] - at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuil dPluginManager.java:139) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.jav a:209) ... 19 more Caused by: org.apache.maven.plugin.PluginContainerException: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-dependency-plugin:2.8:tree: java.lang.AbstractMethodError: org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener. manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/ maven/artifact/Artifact;)V - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
cobertura-maven-plugin not creating .xml file as documented
The online documentationhttp://mojo.codehaus.org/cobertura-maven-plugin/cobertura-mojo.htmlfor cobertura-maven-plugin 2.6 says that coverage.xml is created if you specify xml format. In reality, this only happens if you specify xml format *and* run `mvn site`. `mvn cobertura:cobertura` never generates this file. Could we amend the documentation to make this more clear (or even better, go ahead and make `mvn cobertura:cobertura` generate this file)? -- Cheers, Andrew Pennebaker apenneba...@42six.com
Maven Plugins: By-Module-Logger and Current Processes Running
Hi Everyone, I was wondering if anyone knows of some plugins that could do any of the following: 1) Keep track of the number of threads currently running and what modules are running 2) Number of modules remaining to be built in the reactor 3) A logger that can separate logs of each module instead of consolidating the entire reactor into 1 log file. The project I'm working on takes a very long time to build and would be helpful if there was a way to see how much further the build has to go until it is finished. I had in mind being able to output into the log what the current status of the build is in terms of modules built and remaining. Also, when running a build with multiple threads, the log outputs of one module can overlap with another modules and can be hard to debug at times. Are there any plugins developed that can accomplish any of these? Thanks, Phillip
Re: cobertura-maven-plugin not creating .xml file as documented
That plugin is maintained by the Codehaus Mojo project. Please file a ticket as described here: http://mojo.codehaus.org/cobertura-maven-plugin/issue-tracking.html Attaching a patch to the ticket will increase the likelihood of getting this fixed quickly. (It doesn't have to be a patch file, you could just state the suggested text change in the ticket itself.) Thanks for improving the docs! /Anders On Wed, Jan 29, 2014 at 9:31 PM, Andrew Pennebaker apenneba...@42six.comwrote: The online documentation http://mojo.codehaus.org/cobertura-maven-plugin/cobertura-mojo.htmlfor cobertura-maven-plugin 2.6 says that coverage.xml is created if you specify xml format. In reality, this only happens if you specify xml format *and* run `mvn site`. `mvn cobertura:cobertura` never generates this file. Could we amend the documentation to make this more clear (or even better, go ahead and make `mvn cobertura:cobertura` generate this file)? -- Cheers, Andrew Pennebaker apenneba...@42six.com
