Re: Google Summer of Code - Java opportunity, mentors needed
I don't believe that this is a viable scheme. Maven source artifacts are not generally buildable, but are aimed at IDEs for debugging visibility. You can't trust the SVM info, and you don't know what -P/-D options were used to make the binary. We would need a new train of metadata. This will only lead to more of the horrible pattern of distro people mis-building Maven and Maven artifacts, leading to confused users and bug reports when they expect these things to work right. Maven was not designed to facilitate the Debian pattern. If someone wants to move in that direction, they should join the dev community, watch for work on Maven 4, and advocate (and volunteer to code) solutions to provide the right metadata to do this. Thowing an inexperienced student into trying to do this with Maven 3 in a summer is a recipe for failure. On Tue, Feb 25, 2014 at 4:48 AM, Daniel Pocock dan...@pocock.com.au wrote: Hi, I recently published an idea for discovering the source code of Java projects (e.g. by exploring meta data from pom.xml) and trying to automatically and recursively build dependencies (including plugins) from source https://wiki.debian.org/SummerOfCode2014/Projects#SummerOfCode2014.2FProjects.2FRecursively_building_Java_dependencies_from_source.Recursively_building_Java_dependencies_from_source This would satisfy various objectives, for example: - automated construction of Debian/Ubuntu/RPM packages - ensuring that non-free components don't creep into the dependency tree of projects that aim to be published under a free license - ensuring that 100% of dependency code can be passed through code quality/security scanning tools (this is a common requirement for larger corporations when evaluating whether to use a free software project) I have some plans for how this project could be broken down into achievable tasks for a GSoC student but to go ahead it would need at least one additional mentor, mainly because Google has accepted the Ganglia organisation this year and I am one of the admins for Ganglia. The project has been proposed under Debian (mainly as a way of enabling the creation of more Debian packages) but it could also be completed under another organisation. Please feel free to email me privately if you may be interested. Regards, Daniel - 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
Re: Google Summer of Code - Java opportunity, mentors needed
While Benson is right about -source artifacts (not meant for rebuilding), this resembles me to M2E's Project Materialisation, where based on POM of the given project (is fetched during dependency resolution), and IF the SCM metadata are okay, etc, the project tag is checked out into workspace On Wed, Feb 26, 2014 at 12:20 PM, Benson Margulies bimargul...@gmail.comwrote: I don't believe that this is a viable scheme. Maven source artifacts are not generally buildable, but are aimed at IDEs for debugging visibility. You can't trust the SVM info, and you don't know what -P/-D options were used to make the binary. We would need a new train of metadata. This will only lead to more of the horrible pattern of distro people mis-building Maven and Maven artifacts, leading to confused users and bug reports when they expect these things to work right. Maven was not designed to facilitate the Debian pattern. If someone wants to move in that direction, they should join the dev community, watch for work on Maven 4, and advocate (and volunteer to code) solutions to provide the right metadata to do this. Thowing an inexperienced student into trying to do this with Maven 3 in a summer is a recipe for failure. On Tue, Feb 25, 2014 at 4:48 AM, Daniel Pocock dan...@pocock.com.au wrote: Hi, I recently published an idea for discovering the source code of Java projects (e.g. by exploring meta data from pom.xml) and trying to automatically and recursively build dependencies (including plugins) from source https://wiki.debian.org/SummerOfCode2014/Projects#SummerOfCode2014.2FProjects.2FRecursively_building_Java_dependencies_from_source.Recursively_building_Java_dependencies_from_source This would satisfy various objectives, for example: - automated construction of Debian/Ubuntu/RPM packages - ensuring that non-free components don't creep into the dependency tree of projects that aim to be published under a free license - ensuring that 100% of dependency code can be passed through code quality/security scanning tools (this is a common requirement for larger corporations when evaluating whether to use a free software project) I have some plans for how this project could be broken down into achievable tasks for a GSoC student but to go ahead it would need at least one additional mentor, mainly because Google has accepted the Ganglia organisation this year and I am one of the admins for Ganglia. The project has been proposed under Debian (mainly as a way of enabling the creation of more Debian packages) but it could also be completed under another organisation. Please feel free to email me privately if you may be interested. Regards, Daniel - 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
Re: How to separately configure each Mojo of a plugin executed from command line?
Don't think it's possible. I guess the idea is that if you have the same parameter in multiple goals, they would have the same configuration. If the parameter is configurable from command-line (thourgh a property), you could do it that way instead. Maybe not what you want, but it would work. /Anders On Tue, Feb 25, 2014 at 4:55 PM, Juergen Hartl juergen.ha...@jku.at wrote: Hi, with regards to the info given at: https://maven.apache.org/guides/mini/guide-default-execution-ids.html How can I configure separately each Mojo of a plugin, if these mojos are executed from command line? e.g. mvn release:clean //SomeProperty == X mvn release:prepare //SomeProperty == A mvn release:perform //SomeProperty == B both goals are executed from command line. how can I configure release:prepare in my pom differently from release:perform? Basically I would need execution Ids like default-prepare-cli, default-perform-cli etc. Grateful for ideas, thanks, Juergen ad: pom.xml plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.4.2/version configuration SomePropertyX/SomeProperty!-- shared globally-- /configuration executions execution iddefault-cli/id configuration SomePropertyA/SomeProperty !--DOES NOT WORK shared by release:perform, release:prepare, release:clean both if executed from command line-- /configuration /execution iddefault-prepare/id configuration SomePropertyA/SomeProperty !--DOES NOT WORK not used if executed from command line-- /configuration /execution execution iddefault-perform/id configuration SomePropertyB/SomeProperty !--DOES NOT WORK release:perform not bound to lifecycle, but it invokes deploy. Also not used if executed from command line-- /configuration /execution execution execution iddefault/id phasedeploy/phase goals goalprepare/goal /goals configuration SomePropertyA/SomeProperty !--DOES NOT WORK not used if executed from command line-- /configuration /execution /executions /plugin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to separately configure each Mojo of a plugin executed from command line?
Ahh yes. It won't work because you can only have one default-cli. There are ways around but they get tricky and are rather hacky. Any reason why you can't just type mvn release:clean -DsomeProperty=... mvn release:prepare -DsomeProperty=... mvn release:perform -DsomeProperty=... On 26 February 2014 11:48, Anders Hammar and...@hammar.net wrote: Don't think it's possible. I guess the idea is that if you have the same parameter in multiple goals, they would have the same configuration. If the parameter is configurable from command-line (thourgh a property), you could do it that way instead. Maybe not what you want, but it would work. /Anders On Tue, Feb 25, 2014 at 4:55 PM, Juergen Hartl juergen.ha...@jku.at wrote: Hi, with regards to the info given at: https://maven.apache.org/guides/mini/guide-default-execution-ids.html How can I configure separately each Mojo of a plugin, if these mojos are executed from command line? e.g. mvn release:clean //SomeProperty == X mvn release:prepare //SomeProperty == A mvn release:perform //SomeProperty == B both goals are executed from command line. how can I configure release:prepare in my pom differently from release:perform? Basically I would need execution Ids like default-prepare-cli, default-perform-cli etc. Grateful for ideas, thanks, Juergen ad: pom.xml plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.4.2/version configuration SomePropertyX/SomeProperty!-- shared globally-- /configuration executions execution iddefault-cli/id configuration SomePropertyA/SomeProperty !--DOES NOT WORK shared by release:perform, release:prepare, release:clean both if executed from command line-- /configuration /execution iddefault-prepare/id configuration SomePropertyA/SomeProperty !--DOES NOT WORK not used if executed from command line-- /configuration /execution execution iddefault-perform/id configuration SomePropertyB/SomeProperty !--DOES NOT WORK release:perform not bound to lifecycle, but it invokes deploy. Also not used if executed from command line-- /configuration /execution execution execution iddefault/id phasedeploy/phase goals goalprepare/goal /goals configuration SomePropertyA/SomeProperty !--DOES NOT WORK not used if executed from command line-- /configuration /execution /executions /plugin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Google Summer of Code - Java opportunity, mentors needed
From: ta...@cservenak.net Date: Wed, 26 Feb 2014 12:26:48 +0100 Subject: Re: Google Summer of Code - Java opportunity, mentors needed To: users@maven.apache.org While Benson is right about -source artifacts (not meant for rebuilding), this resembles me to M2E's Project Materialisation, where based on POM of the given project (is fetched during dependency resolution), and IF the SCM metadata are okay, etc, the project tag is checked out into workspace MGIn which case we would need a standard way for SCM Metadata / Project Tag checked out into IDE: MGEclipse? MGIdea? MGNetBeans? MGConcrete Example I need this nexus-plugin to work: MG2014-02-04 0 8:41:18 WARN [pxpool-1-thread-2] admin org.sonatype.scheduling.DefaultScheduledTask - Excein in call method of scheduled task Closing staging repositories: [stagingprofileformartinplugin-1002] java.lang.IllegalStateException: No rule evaluator configured for type: MartinPluginRuleType at com.google.common.base.Preconditions.checkState(Preconditions.java:176) ~[guava-14.0.1.jar:na] at com.sonatype.nexus.staging.internal.rules.DefaultStagingRuleFactory.createStagingRule(DefaultStagingRuleFactory.java:90) ~[na:na] at com.sonatype.nexus.staging.internal.StagingRulesHelper.evaluateRuleSet(StagingRulesHelper.java:216) ~[na:na] at com.sonatype.nexus.staging.internal.StagingRulesHelper.evaluateProfileRuleSets(StagingRulesHelper.java:133) ~[na:na] at com.sonatype.nexus.staging.internal.StagingRulesHelper.evaluate(StagingRulesHelper.java:104) ~[na:na] at com.sonatype.nexus.staging.internal.task.RepositoryCloseTask$CloseOperation.verifyItem(RepositoryCloseTask.java:90) ~[na:na] at com.sonatype.nexus.staging.internal.task.RepositoryCloseTask$CloseOperation.verifyItem(RepositoryCloseTask.java:1) ~[na:na] at com.sonatype.nexus.staging.internal.task.OperationTaskSupport$OperationSupport.verify(OperationTaskSupport.java:295) ~[na:na] at com.sonatype.nexus.staging.internal.task.OperationTaskSupport.executeOperations(OperationTaskSupport.java:426) ~[na:na] at com.sonatype.nexus.staging.internal.task.OperationTaskSupport.doCall(OperationTaskSupport.java:416) ~[na:na] at com.sonatype.nexus.staging.internal.task.TaskSupport.call(TaskSupport.java:38) ~[na:na] at com.sonatype.nexus.staging.internal.task.StagingTaskSupport.call(StagingTaskSupport.java:134) ~[na:na] at com.sonatype.nexus.staging.internal.task.StagingBackgroundTask.execute(StagingBackgroundTask.java:68) ~[na:na] at com.sonatype.nexus.staging.internal.task.NexusTaskSupport.doRun(NexusTaskSupport.java:53) ~[na:na] at com.sonatype.nexus.staging.internal.task.NexusTaskSupport.doRun(NexusTaskSupport.java:1) ~[na:na] at org.sonatype.nexus.scheduling.AbstractNexusTask.call(AbstractNexusTask.java:157) ~[nexus-core-2.7.2-03.jar:2.7.2-03] at org.sonatype.scheduling.DefaultScheduledTask.call(DefaultScheduledTask.java:419) ~[nexus-scheduler-2.7.2-03.jar:2.7.2-03] at org.sonatype.nexus.threads.MDCAwareCallable.call(MDCAwareCallable.java:45) ~[nexus-core-2.7.2-03.jar:2.7.2-03] at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) ~[shiro-core-1.2.2.jar:1.2.2] at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) ~[shiro-core-1.2.2.jar:1.2.2] at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) ~[na:1.7.0_25] at java.util.concurrent.FutureTask.run(Unknown Source) ~[na:1.7.0_25] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source) ~[na:1.7.0_25] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ~[na:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[na:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[na:1.7.0_25] at java.lang.Thread.run(Unknown Source) ~[na:1.7.0_25] MGQ1: Can I get Sonatype source code to debug Nexus? MGQ2: Could I use maven-to-idea-plugin to pull source into IDEA ? MGQ3: Should I care about -P -D options or is this not appropriate use of Profile/SystemProperty? MGI am thinking I will need Maven-4 to solve this problem On Wed, Feb 26, 2014 at 12:20 PM, Benson Margulies bimargul...@gmail.comwrote: I don't believe that this is a viable scheme. Maven source artifacts are not generally buildable, but are aimed at IDEs for debugging visibility. You can't trust the SVM info, and you don't know what -P/-D options were used to make the binary. We would need a new train of metadata. This will only lead to more of the horrible pattern of distro people mis-building Maven and Maven artifacts, leading to confused users and bug reports when they expect these things to work right. Maven was not designed to facilitate the Debian pattern. If someone wants to move in that direction, they should join the dev community, watch for work on Maven 4, and advocate (and volunteer to code)
RE: Google Summer of Code - Java opportunity, mentors needed
Nowhere in that was the sources jar mentioned - yet you seemed to have jumped directly to a solution and then said can’t be done. There is a critical need for this inside businesses as well as Debian (how do we know that org.foobar:baz:1.2.3:jar is MIT as it claims and doesn’t contain some GPL Code. This would not to be to rebuild everything (alla JBoss of old) - but to validate that what is being used is infact what we think it is. This reasons for this are (not limited to) 1) make sure the code is not tainted and its licence is what it purports to be. 2) should the licence allow and the need arise you can have a reasonable chance of getting to that source and being able to patch it. The end system could use the POM as a starting point to identify a project and source (not -sources.jar but svn/git repo...), and as such could contribute this to a database, that can be augmented/checked by a human and consumed by other tools. Right now for example if you looked at some artifacts on Central you would find stuff without any sources, or any indication from the POM. Whilst the automatic tooling would not help here - the fact that this would likely need a lookup in a db means at least someone could then record that GAV X is (or appears to be from) from source repo Y at version Z. /James -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: 26 February 2014 13:20 To: Maven Users List Subject: Re: Google Summer of Code - Java opportunity, mentors needed I don't believe that this is a viable scheme. Maven source artifacts are not generally buildable, but are aimed at IDEs for debugging visibility. You can't trust the SVM info, and you don't know what - P/-D options were used to make the binary. We would need a new train of metadata. This will only lead to more of the horrible pattern of distro people mis-building Maven and Maven artifacts, leading to confused users and bug reports when they expect these things to work right. Maven was not designed to facilitate the Debian pattern. If someone wants to move in that direction, they should join the dev community, watch for work on Maven 4, and advocate (and volunteer to code) solutions to provide the right metadata to do this. Thowing an inexperienced student into trying to do this with Maven 3 in a summer is a recipe for failure. On Tue, Feb 25, 2014 at 4:48 AM, Daniel Pocock dan...@pocock.com.au wrote: Hi, I recently published an idea for discovering the source code of Java projects (e.g. by exploring meta data from pom.xml) and trying to automatically and recursively build dependencies (including plugins) from source https://wiki.debian.org/SummerOfCode2014/Projects#SummerOfCode2014. 2FP rojects.2FRecursively_building_Java_dependencies_from_source.Recursive ly_building_Java_dependencies_from_source This would satisfy various objectives, for example: - automated construction of Debian/Ubuntu/RPM packages - ensuring that non-free components don't creep into the dependency tree of projects that aim to be published under a free license - ensuring that 100% of dependency code can be passed through code quality/security scanning tools (this is a common requirement for larger corporations when evaluating whether to use a free software project) I have some plans for how this project could be broken down into achievable tasks for a GSoC student but to go ahead it would need at least one additional mentor, mainly because Google has accepted the Ganglia organisation this year and I am one of the admins for Ganglia. The project has been proposed under Debian (mainly as a way of enabling the creation of more Debian packages) but it could also be completed under another organisation. Please feel free to email me privately if you may be interested. Regards, Daniel - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Google Summer of Code - Java opportunity, mentors needed
On Wed, Feb 26, 2014 at 9:16 AM, James Nord (jnord) jn...@cisco.com wrote: Nowhere in that was the sources jar mentioned - yet you seemed to have jumped directly to a solution and then said can’t be done. No, I discussed the two paths from the POM: -sources and scm/ There is a critical need for this inside businesses as well as Debian (how do we know that org.foobar:baz:1.2.3:jar is MIT as it claims and doesn’t contain some GPL Code. Which is a fine reason to contribute it Maven 4 where the POM could contain the necessary metadata to enable it. This would not to be to rebuild everything (alla JBoss of old) - but to validate that what is being used is infact what we think it is. This reasons for this are (not limited to) 1) make sure the code is not tainted and its licence is what it purports to be. 2) should the licence allow and the need arise you can have a reasonable chance of getting to that source and being able to patch it. The end system could use the POM as a starting point to identify a project and source (not -sources.jar but svn/git repo...), and as such could contribute this to a database, that can be augmented/checked by a human and consumed by other tools. Right now for example if you looked at some artifacts on Central you would find stuff without any sources, or any indication from the POM. Whilst the automatic tooling would not help here - the fact that this would likely need a lookup in a db means at least someone could then record that GAV X is (or appears to be from) from source repo Y at version Z. /James -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: 26 February 2014 13:20 To: Maven Users List Subject: Re: Google Summer of Code - Java opportunity, mentors needed I don't believe that this is a viable scheme. Maven source artifacts are not generally buildable, but are aimed at IDEs for debugging visibility. You can't trust the SVM info, and you don't know what - P/-D options were used to make the binary. We would need a new train of metadata. This will only lead to more of the horrible pattern of distro people mis-building Maven and Maven artifacts, leading to confused users and bug reports when they expect these things to work right. Maven was not designed to facilitate the Debian pattern. If someone wants to move in that direction, they should join the dev community, watch for work on Maven 4, and advocate (and volunteer to code) solutions to provide the right metadata to do this. Thowing an inexperienced student into trying to do this with Maven 3 in a summer is a recipe for failure. On Tue, Feb 25, 2014 at 4:48 AM, Daniel Pocock dan...@pocock.com.au wrote: Hi, I recently published an idea for discovering the source code of Java projects (e.g. by exploring meta data from pom.xml) and trying to automatically and recursively build dependencies (including plugins) from source https://wiki.debian.org/SummerOfCode2014/Projects#SummerOfCode2014. 2FP rojects.2FRecursively_building_Java_dependencies_from_source.Recursive ly_building_Java_dependencies_from_source This would satisfy various objectives, for example: - automated construction of Debian/Ubuntu/RPM packages - ensuring that non-free components don't creep into the dependency tree of projects that aim to be published under a free license - ensuring that 100% of dependency code can be passed through code quality/security scanning tools (this is a common requirement for larger corporations when evaluating whether to use a free software project) I have some plans for how this project could be broken down into achievable tasks for a GSoC student but to go ahead it would need at least one additional mentor, mainly because Google has accepted the Ganglia organisation this year and I am one of the admins for Ganglia. The project has been proposed under Debian (mainly as a way of enabling the creation of more Debian packages) but it could also be completed under another organisation. Please feel free to email me privately if you may be interested. Regards, Daniel - 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 - 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
RE: Google Summer of Code - Java opportunity, mentors needed
Nowhere in that was the sources jar mentioned - yet you seemed to have jumped directly to a solution and then said can’t be done. No, I discussed the two paths from the POM: -sources and scm/ My mistake, sorry. There is a critical need for this inside businesses as well as Debian (how do we know that org.foobar:baz:1.2.3:jar is MIT as it claims and doesn’t contain some GPL Code. Which is a fine reason to contribute it Maven 4 where the POM could contain the necessary metadata to enable it. This shouldn't prohibit something using what exists now. One commercial company has done something for some subset of artifacts - which may have been entirely human process/mixed or automated. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Google Summer of Code - Java opportunity, mentors needed
On 26/02/14 17:17, James Nord (jnord) wrote: Nowhere in that was the sources jar mentioned - yet you seemed to have jumped directly to a solution and then said can’t be done. No, I discussed the two paths from the POM: -sources and scm/ My mistake, sorry. There is a critical need for this inside businesses as well as Debian (how do we know that org.foobar:baz:1.2.3:jar is MIT as it claims and doesn’t contain some GPL Code. Which is a fine reason to contribute it Maven 4 where the POM could contain the necessary metadata to enable it. This shouldn't prohibit something using what exists now. One commercial company has done something for some subset of artifacts - which may have been entirely human process/mixed or automated. Just to clarify some aspects of this: - there is no expectation that the project will build 100% of artifacts that are available in the Central Repository - just being able to build 20% of them would still be helpful - it is expected that some projects will need manual clues to build - for example, if some project contains two binary JARs in github, and if they don't have clues about where to find source, the system will display a report (including the names of classes in the JARs) and the user will be able to tell it where to look and then the automated stuff continues. It will always keep trying to go as far as it can automatically and then display a list of all things that need manual help so the user can address them all in a batch. - I wasn't anticipating a dependency on -source JARs, although the toolkit that I am proposing may well try to build from them if it has nothing else (but without any expectation that they will build) - automatically submitting the packages to Debian is probably out of the question for now. However, the feedback from such a system would make it much easier for a Debian user to create packages in their local repository. It would also make it easier for Debian Developers (or Ubuntu or Fedora developers) to look at bigger Java projects with multiple JARs and decide if they are suitable for official uploads to a distribution. It would do some of the leg work for us (stripping out binary artifacts and building the re-packaged source tarballs that we need sometimes) and then we would still put in the finishing touches manually to make a package that is official. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Findbugs doesn't check unit tests
I added the following to my POM reporting plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdfindbugs-maven-plugin/artifactId version2.5.3/version configuration effortMax/effort thresholdLow/threshold /configuration /plugin /plugins /reporting And it works great for my main source, but it does not seem to check my test source. It seems to me it would be useful to run findbugs on test code too. Is there some simple way to configure this? Cheers, Eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Findbugs doesn't check unit tests
On 27 February 2014 09:05, Eric Kolotyluk eric.koloty...@gmail.com wrote: I added the following to my POM reporting plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdfindbugs-maven-plugin/artifactId version2.5.3/version configuration effortMax/effort thresholdLow/threshold /configuration /plugin /plugins /reporting And it works great for my main source, but it does not seem to check my test source. It seems to me it would be useful to run findbugs on test code too. Is there some simple way to configure this? I dont use FindBugs. But Umm, is this what you want? http://mojo.codehaus.org/findbugs-maven-plugin/check-mojo.html#includeTests - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Findbugs doesn't check unit tests
Yup, that does the trick. Thanks. My bad for not checking the plugin page more thoroughly. Cheers, Eric On 2/26/2014 3:34 PM, Barrie Treloar wrote: On 27 February 2014 09:05, Eric Kolotyluk eric.koloty...@gmail.com wrote: I added the following to my POM reporting plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdfindbugs-maven-plugin/artifactId version2.5.3/version configuration effortMax/effort thresholdLow/threshold /configuration /plugin /plugins /reporting And it works great for my main source, but it does not seem to check my test source. It seems to me it would be useful to run findbugs on test code too. Is there some simple way to configure this? I dont use FindBugs. But Umm, is this what you want? http://mojo.codehaus.org/findbugs-maven-plugin/check-mojo.html#includeTests - 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
RE: Google Summer of Code - Java opportunity, mentors needed
From: jn...@cisco.com To: users@maven.apache.org Subject: RE: Google Summer of Code - Java opportunity, mentors needed Date: Wed, 26 Feb 2014 16:17:29 + Nowhere in that was the sources jar mentioned - yet you seemed to have jumped directly to a solution and then said can’t be done. No, I discussed the two paths from the POM: -sources and scm/ My mistake, sorry. There is a critical need for this inside businesses as well as Debian (how do we know that org.foobar:baz:1.2.3:jar is MIT as it claims and doesn’t contain some GPL Code. Which is a fine reason to contribute it Maven 4 where the POM could contain the necessary metadata to enable it. This shouldn't prohibit something using what exists now. One commercial company has done something for some subset of artifacts - which may have been entirely human process/mixed or automated. MGHow will the aggrgeator mechanism aggreate for this subset of artifacts MGScope? MGClassifier? MGWith regards to GPLartifacts could'nt we find the necessary violations with Sonatype CLM MG(No plug for Sonatype intended) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
