[jira] (MNG-5237) Cannot download maven dependencies through proxy
[ https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312510#comment-312510 ] Frederic Jecker commented on MNG-5237: -- @Philip Singer : I removed the wagon-httpd-lightweight-2.2 from my lib/ext and tested the provided solution (run with -Djava.net.preferIPv4Stack=true) It did not work (could not download artifact: Proxy Authentication Required) > Cannot download maven dependencies through proxy > > > Key: MNG-5237 > URL: https://jira.codehaus.org/browse/MNG-5237 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 > Environment: windows xp64 using cygwin >Reporter: Niels Mordt-Ostergaard >Assignee: Jason van Zyl > > Using proxy in settings.xml, I was able to download maven dependencies in > 3.0.3, but this seems to be broken with 3.0.4: > Proxy definition in settings.xml (hidden ip adress below, but correct proxy > ip on my system): > > > optional > true > http > > > xxx.xx.xx.xx > 8080 > localhost|127.0.0.1 > > > Output from 3.0.3: > $ mvn -V clean > Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) > Maven home: C:\Program Files\apache-maven-3.0.3 > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: no_NO, platform encoding: Cp1252 > OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows" > [INFO] Scanning for projects... > [INFO] > [INFO] > > [INFO] Building > [INFO] > > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom > Downloaded: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom > (5 KB at 4.9 KB/sec) > . and so on... > Output from 3.0.4: > $ mvn -V clean > Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) > Maven home: C:\Program Files\apache-maven-3.0.4 > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: no_NO, platform encoding: Cp1252 > OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows" > [INFO] Scanning for projects... > [INFO] > [INFO] > > [INFO] Building > [INFO] > > Downloading: > http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 0.390s > [INFO] Finished at: Fri Feb 03 13:14:35 CET 2012 > [INFO] Final Memory: 5M/490M > [INFO] > > [ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.4.1 or one of > its dependencies could not be resolved: Failed to read artifact descriptor > for org.apache.maven.plugins:maven-clean-plugin:jar:2.4.1: Could not transfer > artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.4.1 from/to > central (http://repo.maven.apache.org/maven2): Access denied to: > http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom, > ReasonPhrase:Forbidden. -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-236) Refactor utility classes of shared components into an own utility package
[ https://jira.codehaus.org/browse/MSHARED-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MSHARED-236: --- Component/s: maven-shared-utils > Refactor utility classes of shared components into an own utility package > - > > Key: MSHARED-236 > URL: https://jira.codehaus.org/browse/MSHARED-236 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: maven-shared-utils-0.1 > > Attachments: MSHARED-236-krosenvold-original-work.patch > > > DirectoryScanner in maven-verifier is one example. > We should introcude a new shared-utils module which doesn't contain any > external dependencies if possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-243) add a way to calculate diffs of a directory at 2 different times
[ https://jira.codehaus.org/browse/MSHARED-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MSHARED-243: --- Fix Version/s: maven-shared-utils-0.1 > add a way to calculate diffs of a directory at 2 different times > > > Key: MSHARED-243 > URL: https://jira.codehaus.org/browse/MSHARED-243 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-utils >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: maven-shared-utils-0.1 > > > For implementing the incremental build it should be possible to detect which > files got created by a certain mojo execution. > An example would be the maven-compiler-plugin which currently doesn't remove > class files for Java sources which got deleted. > The idea is to introduce a helper which can capture a snapshot of a certain > directory (e.g. target/classes), then you do the mojo work (javac invocation > with all source files) and take a capture of that very directory again. > The tool will allow you to take a 'diff' and store the names of all the added > files to a file in target/... > The next time you invoke a build you can delete all those created classes by > this very mojo-execution and so you do not have any left-overs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-244) Add EMPTY_xxxx_ARRAY from commons-lang to our CollectionsUtils
[ https://jira.codehaus.org/browse/MSHARED-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MSHARED-244: --- Fix Version/s: maven-shared-utils-0.1 > Add EMPTY__ARRAY from commons-lang to our CollectionsUtils > -- > > Key: MSHARED-244 > URL: https://jira.codehaus.org/browse/MSHARED-244 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-utils >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: maven-shared-utils-0.1 > > > There are a lot of Classes which need constants for empty arrays like > String[0]. > We shall add such constants to our CollectionUtils. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-917) [junit] category simple name matching fails throwing ClassNotFoundException
[
https://jira.codehaus.org/browse/SUREFIRE-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312515#comment-312515
]
Anders Hammar commented on SUREFIRE-917:
Executing with an incorrect category name would be a configuration error and I
think it's important to signal this to the user. So just ignoring this it not a
good solution IMO. Possibly, having a very visible warning displayed in the
console could work.
> [junit] category simple name matching fails throwing ClassNotFoundException
> ---
>
> Key: SUREFIRE-917
> URL: https://jira.codehaus.org/browse/SUREFIRE-917
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.12.4
>Reporter: Peter Lynch
> Attachments: fix_support_for_junit_simple_group_name_matching.patch
>
>
> According to a [unit test I
> found|https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-grouper/src/test/java/org/apache/maven/surefire/group/parse/GroupMatcherParserTest.java;h=e92595a09de1eb706f54c70b8efe8df592e40ec5;hb=HEAD#l134]
> JUnit categories/group support should allow matching groups by the category
> interface simple name along with the fully qualified name.
> Example , given category interfaces:
> {noformat}
> category.Fast
> category.Slow
> {noformat}
> The following commands should be equivalent:
> {noformat}
> mvn test -Dgroups="Slow,Fast"
> mvn test -Dgroups="category.Slow,category.Fast"
> mvn test -Dgroups="category.Slow.class,category.Fast.class"
> {noformat}
> In my testing, the first command does not work. Instead I get the following
> exception:
> {noformat}
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category: Fast
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> at
> org.apache.maven.surefire.group.match.JoinGroupMatcher.loadGroupClasses(JoinGroupMatcher.java:44)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException: Fast
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> ... 13 more
> {noformat}
> It seems like if a category name cannot be loaded, it should just be ignored.
> I added an integration test that proves the failure and supplied a patch
> which avoids the problem to allow specifying the simple class name for
> matching.
> It would be great to have this working to allow a developer to easily run
> specific groups of tests in a concise manner.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-79) help:active-profiles does not list active inherited profiles
[ https://jira.codehaus.org/browse/MPH-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312517#comment-312517 ] Andrew Logvinov commented on MPH-79: Also affects version 2.1.1. > help:active-profiles does not list active inherited profiles > > > Key: MPH-79 > URL: https://jira.codehaus.org/browse/MPH-79 > Project: Maven 2.x Help Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100) > Windows (XP,2003,2008), Java 1.6 >Reporter: Xavier D. >Priority: Minor > > The code fix for http://jira.codehaus.org/browse/MPH-16 appears to have been > removed and the test now breaks. > Refer to http://jira.codehaus.org/browse/MPH-16 for the Testcase zip file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-229) don't use Plexus' Xpp3 in generated HelpMojo to read XML files: parsers in JDK would be sufficient
Herve Boutemy created MPLUGIN-229: - Summary: don't use Plexus' Xpp3 in generated HelpMojo to read XML files: parsers in JDK would be sufficient Key: MPLUGIN-229 URL: https://jira.codehaus.org/browse/MPLUGIN-229 Project: Maven 2.x Plugin Tools Issue Type: Improvement Components: Plugin Plugin Affects Versions: 3.1 Reporter: Herve Boutemy part of MNG-2255, easy to do -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-229) don't use Plexus' Xpp3 in generated HelpMojo to read XML files: parsers in JDK are sufficient
[ https://jira.codehaus.org/browse/MPLUGIN-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPLUGIN-229: -- Description: replacing a dependency on plexus-utils with JDK is a Good Thing (TM) part of MNG-2255, easy to do was:part of MNG-2255, easy to do Summary: don't use Plexus' Xpp3 in generated HelpMojo to read XML files: parsers in JDK are sufficient (was: don't use Plexus' Xpp3 in generated HelpMojo to read XML files: parsers in JDK would be sufficient) > don't use Plexus' Xpp3 in generated HelpMojo to read XML files: parsers in > JDK are sufficient > - > > Key: MPLUGIN-229 > URL: https://jira.codehaus.org/browse/MPLUGIN-229 > Project: Maven 2.x Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Affects Versions: 3.1 >Reporter: Herve Boutemy > > replacing a dependency on plexus-utils with JDK is a Good Thing (TM) > part of MNG-2255, easy to do -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-229) don't use Plexus' Xpp3 in generated HelpMojo to read XML files: XML parser in JDK is sufficient
[ https://jira.codehaus.org/browse/MPLUGIN-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold reassigned MPLUGIN-229: -- Assignee: Kristian Rosenvold > don't use Plexus' Xpp3 in generated HelpMojo to read XML files: XML parser in > JDK is sufficient > --- > > Key: MPLUGIN-229 > URL: https://jira.codehaus.org/browse/MPLUGIN-229 > Project: Maven 2.x Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Affects Versions: 3.1 >Reporter: Herve Boutemy >Assignee: Kristian Rosenvold > > replacing a dependency on plexus-utils with JDK is a Good Thing (TM) > part of MNG-2255, easy to do -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-229) don't use Plexus' Xpp3 in generated HelpMojo to read XML files: XML parser in JDK is sufficient
[ https://jira.codehaus.org/browse/MPLUGIN-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPLUGIN-229: -- Summary: don't use Plexus' Xpp3 in generated HelpMojo to read XML files: XML parser in JDK is sufficient (was: don't use Plexus' Xpp3 in generated HelpMojo to read XML files: parsers in JDK are sufficient) > don't use Plexus' Xpp3 in generated HelpMojo to read XML files: XML parser in > JDK is sufficient > --- > > Key: MPLUGIN-229 > URL: https://jira.codehaus.org/browse/MPLUGIN-229 > Project: Maven 2.x Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Affects Versions: 3.1 >Reporter: Herve Boutemy > > replacing a dependency on plexus-utils with JDK is a Good Thing (TM) > part of MNG-2255, easy to do -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-60) Use a external XML Pull parser instead of plexus one
[
https://jira.codehaus.org/browse/DOXIA-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated DOXIA-60:
---
Description:
To avoid maintaining the plexus XMLPullParser we should move to a standard
implementation like Codehaus StaX http://stax.codehaus.org
{code:xml}
stax
stax
1.2.0_rc2-dev
{code}
was:
To avoid maintaining the plexus XMLPullParser we should move to a standard
implementation like Codehaus StaX http://stax.codehaus.org
stax
stax
1.2.0_rc2-dev
> Use a external XML Pull parser instead of plexus one
>
>
> Key: DOXIA-60
> URL: https://jira.codehaus.org/browse/DOXIA-60
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Reporter: Carlos Sanchez
>Priority: Critical
> Fix For: 2.0
>
>
> To avoid maintaining the plexus XMLPullParser we should move to a standard
> implementation like Codehaus StaX http://stax.codehaus.org
> {code:xml}
> stax
> stax
> 1.2.0_rc2-dev
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-386) Split purge-local-repository into manual and transitive
[ https://jira.codehaus.org/browse/MDEP-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier reopened MDEP-386: > Split purge-local-repository into manual and transitive > --- > > Key: MDEP-386 > URL: https://jira.codehaus.org/browse/MDEP-386 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 2.6 > > > There doesn't seem to be a good way to resolve/purge/re-resolve from the > local repository in a reliable way that works with both Maven 2 and 3. So to > simplify the code for this goal, it could be split into a manual mode goal > which doesn't required dependency resolution, and a transitive mode which > uses the plugin configuration for the initial dependency resolution. > The manual mode simply deletes a set of directories from the local repository. > The automated mode first resolves to the project dependencies to get the full > information about them, then purges a filtered list from the local > repository, then optionally re-resolves any dependencies that were purged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-386) Split purge-local-repository into manual and transitive
[ https://jira.codehaus.org/browse/MDEP-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MDEP-386. -- Resolution: Won't Fix Splitting the two features into separate goals didn't resolve the issue related to re-resolving dependencies in Maven 3.0.4. So the goals were merged back into a single mojo along with some additional refactoring in [r1401967|http://svn.apache.org/viewvc?view=revision&revision=1401976]. > Split purge-local-repository into manual and transitive > --- > > Key: MDEP-386 > URL: https://jira.codehaus.org/browse/MDEP-386 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 2.6 > > > There doesn't seem to be a good way to resolve/purge/re-resolve from the > local repository in a reliable way that works with both Maven 2 and 3. So to > simplify the code for this goal, it could be split into a manual mode goal > which doesn't required dependency resolution, and a transitive mode which > uses the plugin configuration for the initial dependency resolution. > The manual mode simply deletes a set of directories from the local repository. > The automated mode first resolves to the project dependencies to get the full > information about them, then purges a filtered list from the local > repository, then optionally re-resolves any dependencies that were purged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5169) New checksumPolicy: strict_if_exists
[ https://jira.codehaus.org/browse/MNG-5169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312541#comment-312541 ] Alejandro E commented on MNG-5169: -- I have the same problem + a similar problem when using the Bundle Maker (https://docs.sonatype.org/display/Nexus/Nexus+OSGi+Experimental+Features+-+Bundle+Maker) plugin in a maven central proxy. The generated bundles don't have checksum so I also can't use fail An alternate suggestion instead of a new checksum policy is a Task to generate missing checksums. Not to update existing checksums, since we don't want to lose the mismatch since it might be important, just generating checksums for artifacts that don't have them > New checksumPolicy: strict_if_exists > > > Key: MNG-5169 > URL: https://jira.codehaus.org/browse/MNG-5169 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Settings >Reporter: Julien HENRY > > Hi, > We have enabled fail to prevent corruption > of local repository. But it seems it is nearly unusable because in my company > we are proxying some external repos where there is no checksum so the > download fails. I would like to have a > strict_if_exists where the build fails when > the checksum does not match but only log a warning when there is no remote > checksum. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-917) [junit] category simple name matching fails throwing ClassNotFoundException
[
https://jira.codehaus.org/browse/SUREFIRE-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312549#comment-312549
]
Peter Lynch commented on SUREFIRE-917:
--
Not sure if it is suitable to warn. Consider that in a multimodule
configuration I am sharing surefire config, and define a set of groups to run.
Some modules may have tests with this category, some not. This is perfectly
reasonably and I don't want a bunch of noise from Maven about a problem which
is totally by intention and supported by group pattern matching.
The most I could see is at Maven debug level, mentioning the list of single
group name patterns which did not contribute to selecting tests to execute.
This could help one diagnose a potential problem should someone be curious why
certain tests were not being run by surefire.
However I am personally unclear where I could add such code to the group
matching logic and print it to Maven logs.
> [junit] category simple name matching fails throwing ClassNotFoundException
> ---
>
> Key: SUREFIRE-917
> URL: https://jira.codehaus.org/browse/SUREFIRE-917
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.12.4
>Reporter: Peter Lynch
> Attachments: fix_support_for_junit_simple_group_name_matching.patch
>
>
> According to a [unit test I
> found|https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-grouper/src/test/java/org/apache/maven/surefire/group/parse/GroupMatcherParserTest.java;h=e92595a09de1eb706f54c70b8efe8df592e40ec5;hb=HEAD#l134]
> JUnit categories/group support should allow matching groups by the category
> interface simple name along with the fully qualified name.
> Example , given category interfaces:
> {noformat}
> category.Fast
> category.Slow
> {noformat}
> The following commands should be equivalent:
> {noformat}
> mvn test -Dgroups="Slow,Fast"
> mvn test -Dgroups="category.Slow,category.Fast"
> mvn test -Dgroups="category.Slow.class,category.Fast.class"
> {noformat}
> In my testing, the first command does not work. Instead I get the following
> exception:
> {noformat}
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category: Fast
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> at
> org.apache.maven.surefire.group.match.JoinGroupMatcher.loadGroupClasses(JoinGroupMatcher.java:44)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException: Fast
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> ... 13 more
> {noformat}
> It seems like if a category name cannot be loaded, it should just be ignored.
> I added an integration test that proves the failure and supplied a patch
> which avoids the problem to allow specifying the simple class name for
> matching.
> It would be great to have this working to allow a develo
[jira] (SUREFIRE-917) [junit] category simple name matching fails throwing ClassNotFoundException
[
https://jira.codehaus.org/browse/SUREFIRE-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312551#comment-312551
]
Anders Hammar commented on SUREFIRE-917:
But the ClassNotFoundException is due to a misconfiguration where a
group/category classname is specified that doesn't exist. Surefire is not
failing because it can't find any tests marked with this group.
> [junit] category simple name matching fails throwing ClassNotFoundException
> ---
>
> Key: SUREFIRE-917
> URL: https://jira.codehaus.org/browse/SUREFIRE-917
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.12.4
>Reporter: Peter Lynch
> Attachments: fix_support_for_junit_simple_group_name_matching.patch
>
>
> According to a [unit test I
> found|https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-grouper/src/test/java/org/apache/maven/surefire/group/parse/GroupMatcherParserTest.java;h=e92595a09de1eb706f54c70b8efe8df592e40ec5;hb=HEAD#l134]
> JUnit categories/group support should allow matching groups by the category
> interface simple name along with the fully qualified name.
> Example , given category interfaces:
> {noformat}
> category.Fast
> category.Slow
> {noformat}
> The following commands should be equivalent:
> {noformat}
> mvn test -Dgroups="Slow,Fast"
> mvn test -Dgroups="category.Slow,category.Fast"
> mvn test -Dgroups="category.Slow.class,category.Fast.class"
> {noformat}
> In my testing, the first command does not work. Instead I get the following
> exception:
> {noformat}
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category: Fast
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> at
> org.apache.maven.surefire.group.match.JoinGroupMatcher.loadGroupClasses(JoinGroupMatcher.java:44)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException: Fast
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> ... 13 more
> {noformat}
> It seems like if a category name cannot be loaded, it should just be ignored.
> I added an integration test that proves the failure and supplied a patch
> which avoids the problem to allow specifying the simple class name for
> matching.
> It would be great to have this working to allow a developer to easily run
> specific groups of tests in a concise manner.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5366) [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4
Paul Gier created MNG-5366: -- Summary: [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4 Key: MNG-5366 URL: https://jira.codehaus.org/browse/MNG-5366 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.4 Reporter: Paul Gier Using Maven 3.0.4, artifacts can only be resolved a single time during the build lifecycle using the Maven 2.x dependency resolution API. Using resolver.resolveAlways() should force re-resolution of the artifact, however if the artifact was already resolved once during the build, then it will not be re-resolved even when calling resolveAlways(). This works as expected in Maven 3.0.0-3.0.3, and the artifact is re-resolved. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5366) [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4
[ https://jira.codehaus.org/browse/MNG-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MNG-5366: --- Fix Version/s: 3.1 > [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4 > -- > > Key: MNG-5366 > URL: https://jira.codehaus.org/browse/MNG-5366 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.4 >Reporter: Paul Gier > Fix For: 3.1 > > > Using Maven 3.0.4, artifacts can only be resolved a single time during the > build lifecycle using the Maven 2.x dependency resolution API. Using > resolver.resolveAlways() should force re-resolution of the artifact, however > if the artifact was already resolved once during the build, then it will not > be re-resolved even when calling resolveAlways(). > This works as expected in Maven 3.0.0-3.0.3, and the artifact is re-resolved. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-917) [junit] category simple name matching fails throwing ClassNotFoundException
[
https://jira.codehaus.org/browse/SUREFIRE-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312554#comment-312554
]
Peter Lynch commented on SUREFIRE-917:
--
Anders, if I give surefire {{-Dgroups=Slow}} ( using class simple name matching
) and the actual group interface used in my test is
{{some.long.package.name.not.in.groups.config.Slow}}, how is it reasonable that
surefire fails with ClassNotFoundException for a class called {{Slow}}?
The point is surefire is supposed to ( according to existing tests ) support
matching with
{{some.long.package.name.not.in.groups.config.Slow.getSimpleName().endsWith("Slow")}},
but before it was getting to that check, was trying to look up class name
called "Slow" in the default package.
> [junit] category simple name matching fails throwing ClassNotFoundException
> ---
>
> Key: SUREFIRE-917
> URL: https://jira.codehaus.org/browse/SUREFIRE-917
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.12.4
>Reporter: Peter Lynch
> Attachments: fix_support_for_junit_simple_group_name_matching.patch
>
>
> According to a [unit test I
> found|https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-grouper/src/test/java/org/apache/maven/surefire/group/parse/GroupMatcherParserTest.java;h=e92595a09de1eb706f54c70b8efe8df592e40ec5;hb=HEAD#l134]
> JUnit categories/group support should allow matching groups by the category
> interface simple name along with the fully qualified name.
> Example , given category interfaces:
> {noformat}
> category.Fast
> category.Slow
> {noformat}
> The following commands should be equivalent:
> {noformat}
> mvn test -Dgroups="Slow,Fast"
> mvn test -Dgroups="category.Slow,category.Fast"
> mvn test -Dgroups="category.Slow.class,category.Fast.class"
> {noformat}
> In my testing, the first command does not work. Instead I get the following
> exception:
> {noformat}
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category: Fast
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> at
> org.apache.maven.surefire.group.match.JoinGroupMatcher.loadGroupClasses(JoinGroupMatcher.java:44)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException: Fast
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> ... 13 more
> {noformat}
> It seems like if a category name cannot be loaded, it should just be ignored.
> I added an integration test that proves the failure and supplied a patch
> which avoids the problem to allow specifying the simple class name for
> matching.
> It would be great to have this working to allow a developer to easily run
> specific groups of tests in a concise manner.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA a
[jira] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://jira.codehaus.org/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar updated MNG-5359: --- Attachment: MNG-5359-IT.patch IT attached. Need to add to the test suite as well, and also possibly alter the Maven version range it should be performed on depending on when fixed. > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://jira.codehaus.org/browse/MNG-5359 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar >Assignee: Anders Hammar > Attachments: binding-test.zip, MNG-5359-IT.patch > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://jira.codehaus.org/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar reassigned MNG-5359: -- Assignee: (was: Anders Hammar) Unfortunately it looks like this issues will require some larger code fix in core. I don't really have this in-depth core knowledge currently, so I'm unassigning myself. > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://jira.codehaus.org/browse/MNG-5359 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar > Attachments: binding-test.zip, MNG-5359-IT.patch > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-917) [junit] category simple name matching fails throwing ClassNotFoundException
[
https://jira.codehaus.org/browse/SUREFIRE-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312558#comment-312558
]
Anders Hammar commented on SUREFIRE-917:
I see. As the documentation doesn't state anything else (like what you say the
tests say) I supposed you had to specify the full class name. But I just
recently ran into this one as well so I can agree that simple name would be
good to support as well. But "endsWith"? I would guess that could cause
problems unless people are aware of that.
So, I agree that the ClassNotFound needs to be fixed. Also, the docs for the
groups param needs to clearly specify what is supported. And maybe an
example...:-) I could help with the docs at least if I only knew what we should
support.
> [junit] category simple name matching fails throwing ClassNotFoundException
> ---
>
> Key: SUREFIRE-917
> URL: https://jira.codehaus.org/browse/SUREFIRE-917
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.12.4
>Reporter: Peter Lynch
> Attachments: fix_support_for_junit_simple_group_name_matching.patch
>
>
> According to a [unit test I
> found|https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-grouper/src/test/java/org/apache/maven/surefire/group/parse/GroupMatcherParserTest.java;h=e92595a09de1eb706f54c70b8efe8df592e40ec5;hb=HEAD#l134]
> JUnit categories/group support should allow matching groups by the category
> interface simple name along with the fully qualified name.
> Example , given category interfaces:
> {noformat}
> category.Fast
> category.Slow
> {noformat}
> The following commands should be equivalent:
> {noformat}
> mvn test -Dgroups="Slow,Fast"
> mvn test -Dgroups="category.Slow,category.Fast"
> mvn test -Dgroups="category.Slow.class,category.Fast.class"
> {noformat}
> In my testing, the first command does not work. Instead I get the following
> exception:
> {noformat}
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category: Fast
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> at
> org.apache.maven.surefire.group.match.JoinGroupMatcher.loadGroupClasses(JoinGroupMatcher.java:44)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException: Fast
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> ... 13 more
> {noformat}
> It seems like if a category name cannot be loaded, it should just be ignored.
> I added an integration test that proves the failure and supplied a patch
> which avoids the problem to allow specifying the simple class name for
> matching.
> It would be great to have this working to allow a developer to easily run
> specific groups of tests in a concise manner.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
[jira] (MPLUGIN-220) Can not use regex in @Parameter(defaultValue)
[
https://jira.codehaus.org/browse/MPLUGIN-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MPLUGIN-220:
-
Comment: was deleted
(was: moving to anno must fix.)
> Can not use regex in @Parameter(defaultValue)
> -
>
> Key: MPLUGIN-220
> URL: https://jira.codehaus.org/browse/MPLUGIN-220
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.0
>Reporter: Tony Chemit
>Assignee: Robert Scholte
> Fix For: 3.1.1
>
>
> When transform a javadoc default value
> {code}
> default-value="[a-zA-Z]{2,}-\\d+"
> {code}
> to
> {code}
> defaultValue = "[a-zA-Z]{2,}-d+"
> {code}
> I have when building :
> {code}
> Caused by: com.thoughtworks.qdox.parser.ParseException: Illegal escape
> character 'd' @[295,85] in
> file:/home/tchemit/projets/apache/maven/plugins/maven-changelog-plugin/src/main/java/org/apache/maven/plugin/changelog/ChangeLogReport.java
> at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:1018)
> at
> com.thoughtworks.qdox.parser.impl.Parser.convertString(Parser.java:1126)
> at com.thoughtworks.qdox.parser.impl.Parser.toString(Parser.java:1233)
> at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:1800)
> at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:999)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:353)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:381)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:377)
> at
> com.thoughtworks.qdox.JavaDocBuilder$2.visitFile(JavaDocBuilder.java:467)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:43)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.scan(DirectoryScanner.java:52)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSourceTree(JavaDocBuilder.java:464)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSourceTree(JavaDocBuilder.java:453)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClasses(JavaAnnotationsMojoDescriptorExtractor.java:453)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClasses(JavaAnnotationsMojoDescriptorExtractor.java:443)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClasses(JavaAnnotationsMojoDescriptorExtractor.java:422)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.scanJavadoc(JavaAnnotationsMojoDescriptorExtractor.java:188)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.execute(JavaAnnotationsMojoDescriptorExtractor.java:106)
> at
> org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:108)
> at
> org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:233)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-220) Can not use regex in @Parameter(defaultValue)
[
https://jira.codehaus.org/browse/MPLUGIN-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312562#comment-312562
]
Olivier Lamy commented on MPLUGIN-220:
--
moving to anno must fix.
> Can not use regex in @Parameter(defaultValue)
> -
>
> Key: MPLUGIN-220
> URL: https://jira.codehaus.org/browse/MPLUGIN-220
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.0
>Reporter: Tony Chemit
>Assignee: Robert Scholte
> Fix For: 3.1.1
>
>
> When transform a javadoc default value
> {code}
> default-value="[a-zA-Z]{2,}-\\d+"
> {code}
> to
> {code}
> defaultValue = "[a-zA-Z]{2,}-d+"
> {code}
> I have when building :
> {code}
> Caused by: com.thoughtworks.qdox.parser.ParseException: Illegal escape
> character 'd' @[295,85] in
> file:/home/tchemit/projets/apache/maven/plugins/maven-changelog-plugin/src/main/java/org/apache/maven/plugin/changelog/ChangeLogReport.java
> at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:1018)
> at
> com.thoughtworks.qdox.parser.impl.Parser.convertString(Parser.java:1126)
> at com.thoughtworks.qdox.parser.impl.Parser.toString(Parser.java:1233)
> at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:1800)
> at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:999)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:353)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:381)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:377)
> at
> com.thoughtworks.qdox.JavaDocBuilder$2.visitFile(JavaDocBuilder.java:467)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:43)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
> at
> com.thoughtworks.qdox.directorywalker.DirectoryScanner.scan(DirectoryScanner.java:52)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSourceTree(JavaDocBuilder.java:464)
> at
> com.thoughtworks.qdox.JavaDocBuilder.addSourceTree(JavaDocBuilder.java:453)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClasses(JavaAnnotationsMojoDescriptorExtractor.java:453)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClasses(JavaAnnotationsMojoDescriptorExtractor.java:443)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClasses(JavaAnnotationsMojoDescriptorExtractor.java:422)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.scanJavadoc(JavaAnnotationsMojoDescriptorExtractor.java:188)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.execute(JavaAnnotationsMojoDescriptorExtractor.java:106)
> at
> org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:108)
> at
> org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:233)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-133) DontIncludeResourceTransformer only recognizes a single resource element
Clinton Foster created MSHADE-133:
-
Summary: DontIncludeResourceTransformer only recognizes a single
resource element
Key: MSHADE-133
URL: https://jira.codehaus.org/browse/MSHADE-133
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: Clinton Foster
Priority: Minor
When I code the following, only one of the two resources is excluded:
{code:xml}
myConfig.yml
logback.xml
{code}
It only works if the DontIncludeResourceTransformer transfer element is
repeated for each resource:
{code:xml}
myConfig.yml
logback.xml
{code}
Is this working as designed?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-917) [junit] category simple name matching fails throwing ClassNotFoundException
[
https://jira.codehaus.org/browse/SUREFIRE-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312565#comment-312565
]
Peter Lynch commented on SUREFIRE-917:
--
IMO this whole thing is missing surefire killer feature that is not documented.
;)
> [junit] category simple name matching fails throwing ClassNotFoundException
> ---
>
> Key: SUREFIRE-917
> URL: https://jira.codehaus.org/browse/SUREFIRE-917
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.12.4
>Reporter: Peter Lynch
> Attachments: fix_support_for_junit_simple_group_name_matching.patch
>
>
> According to a [unit test I
> found|https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-grouper/src/test/java/org/apache/maven/surefire/group/parse/GroupMatcherParserTest.java;h=e92595a09de1eb706f54c70b8efe8df592e40ec5;hb=HEAD#l134]
> JUnit categories/group support should allow matching groups by the category
> interface simple name along with the fully qualified name.
> Example , given category interfaces:
> {noformat}
> category.Fast
> category.Slow
> {noformat}
> The following commands should be equivalent:
> {noformat}
> mvn test -Dgroups="Slow,Fast"
> mvn test -Dgroups="category.Slow,category.Fast"
> mvn test -Dgroups="category.Slow.class,category.Fast.class"
> {noformat}
> In my testing, the first command does not work. Instead I get the following
> exception:
> {noformat}
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category: Fast
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> at
> org.apache.maven.surefire.group.match.JoinGroupMatcher.loadGroupClasses(JoinGroupMatcher.java:44)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException: Fast
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> ... 13 more
> {noformat}
> It seems like if a category name cannot be loaded, it should just be ignored.
> I added an integration test that proves the failure and supplied a patch
> which avoids the problem to allow specifying the simple class name for
> matching.
> It would be great to have this working to allow a developer to easily run
> specific groups of tests in a concise manner.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-786) -Darguments doesn't allow -T to be passed to forked builds for multi threading
[
https://jira.codehaus.org/browse/MRELEASE-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-786.
---
Resolution: Fixed
Fix Version/s: 2.4
Assignee: Robert Scholte
Fixed in [r1403533|http://svn.apache.org/viewvc?rev=1403533&view=rev]
> -Darguments doesn't allow -T to be passed to forked builds for multi threading
> --
>
> Key: MRELEASE-786
> URL: https://jira.codehaus.org/browse/MRELEASE-786
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3.2
>Reporter: Tom Clark
>Assignee: Robert Scholte
> Fix For: 2.4
>
>
> I would like to be able to use -T with the release plugin for the compiling
> phase, as the plugin is thread safe, which would allow for about half the
> release time.
> I've tried:
> {code}
> -Darguments='-T 3'
> {code}
> which doesn't throw an error but doesn't actually trigger multi threading.
> also:
> {code}
> -Darguments='-T3'
> -Darguments='"-T 3"'
> {code}
> Both throws an error saying that -T isn't parsable
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
> project parent: Failed to re-parse additional arguments for Maven invocation.
> Unrecognized option: -T -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare
> (default-cli) on project parent: Failed to re-parse additional arguments for
> Maven invocation.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to re-parse
> additional arguments for Maven invocation.
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:295)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Failed
> to re-parse additional arguments for Maven invocation.
> at
> org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:89)
> at
> org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:44)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:234)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:169)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:146)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:107)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRele
[jira] (MRELEASE-755) When passing arguments to underlying maven executions not all maven options are accepted
[
https://jira.codehaus.org/browse/MRELEASE-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-755.
---
Resolution: Fixed
Fix Version/s: 2.4
Assignee: Robert Scholte
Fixed in [r1403537|http://svn.apache.org/viewvc?rev=1403537&view=rev]
> When passing arguments to underlying maven executions not all maven options
> are accepted
>
>
> Key: MRELEASE-755
> URL: https://jira.codehaus.org/browse/MRELEASE-755
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.2.2
>Reporter: Sandy McPherson
>Assignee: Robert Scholte
> Fix For: 2.4
>
>
> The command
> {code}
> + /opt/imc/maven3/bin/mvn -B -PStaged-distribution --settings
> ../corrie/settings-build-release.xml -gs ../corrie/settings-global.xml
> '-Darguments=-PStaged-distribution -s ../corrie/settings-build-release.xml
> -gs ../corrie/settings-global.xml' release:prepare -DreleaseVersion=10.3765
> {code}
> Produces the following error:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.2.2:prepare (default-cli) on
> project corrie: Failed to re-parse additional arguments for Maven invocation.
> Unrecognized option: -g -> [Help 1]
> [ERROR]
> {code}
> Also tried with --global-settings and this also failed with an anrecocgnized
> option --global-settings
> Would seem pointless for the plugin to do any additional parsing, just pass
> it to maven and let the underlying execution complain.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-629) -gs is not passed to forked execution of release:prepare
[ https://jira.codehaus.org/browse/MRELEASE-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-629. --- Resolution: Duplicate Assignee: Robert Scholte I discovered a bit too late that this issue is actually older then MRELEASE-755 > -gs is not passed to forked execution of release:prepare > > > Key: MRELEASE-629 > URL: https://jira.codehaus.org/browse/MRELEASE-629 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.1 >Reporter: Benson Margulies >Assignee: Robert Scholte > > Invoking release:prepare with a -gs, those global settings are not passed > into the forked execution of maven. If, for example, the project needs to > retrieve deps from a repo defined only in the global settings, the build will > fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-120) Username is completely ignored
[ https://jira.codehaus.org/browse/MRELEASE-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-120. --- Resolution: Incomplete Assignee: Robert Scholte > Username is completely ignored > -- > > Key: MRELEASE-120 > URL: https://jira.codehaus.org/browse/MRELEASE-120 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: documentation, scm >Affects Versions: 2.0-beta-4 >Reporter: Matthew Beermann >Assignee: Robert Scholte >Priority: Critical > Labels: scrub-review-started > > When I run something like "mvn release:prepare -DdryRun=true > -Dusername=mb011000", the resulting contents of release.properties suggest > that the username is being completely ignored when forming the scm.url: > scm.username=mb011000 > scm.url=scm\:cvs\:pserver\:anonymous\:@prdwebdev17\:/projects\:system-core > Note that the "anonymous" has stuck around for some reason. This may be > related to MRELEASE-83 and/or MRELEASE-107, but I don't think it's a > duplicate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-143) Update Maven Invoker to 2.1
Robert Scholte created MINVOKER-143: --- Summary: Update Maven Invoker to 2.1 Key: MINVOKER-143 URL: https://jira.codehaus.org/browse/MINVOKER-143 Project: Maven 2.x Invoker Plugin Issue Type: Bug Affects Versions: 1.7 Reporter: Robert Scholte -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5237) Cannot download maven dependencies through NTLM proxy
[ https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-5237: -- Summary: Cannot download maven dependencies through NTLM proxy (was: Cannot download maven dependencies through proxy) > Cannot download maven dependencies through NTLM proxy > - > > Key: MNG-5237 > URL: https://jira.codehaus.org/browse/MNG-5237 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 > Environment: windows xp64 using cygwin >Reporter: Niels Mordt-Ostergaard >Assignee: Jason van Zyl > > Using proxy in settings.xml, I was able to download maven dependencies in > 3.0.3, but this seems to be broken with 3.0.4: > Proxy definition in settings.xml (hidden ip adress below, but correct proxy > ip on my system): > > > optional > true > http > > > xxx.xx.xx.xx > 8080 > localhost|127.0.0.1 > > > Output from 3.0.3: > $ mvn -V clean > Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) > Maven home: C:\Program Files\apache-maven-3.0.3 > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: no_NO, platform encoding: Cp1252 > OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows" > [INFO] Scanning for projects... > [INFO] > [INFO] > > [INFO] Building > [INFO] > > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom > Downloaded: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom > (5 KB at 4.9 KB/sec) > . and so on... > Output from 3.0.4: > $ mvn -V clean > Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) > Maven home: C:\Program Files\apache-maven-3.0.4 > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: no_NO, platform encoding: Cp1252 > OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows" > [INFO] Scanning for projects... > [INFO] > [INFO] > > [INFO] Building > [INFO] > > Downloading: > http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 0.390s > [INFO] Finished at: Fri Feb 03 13:14:35 CET 2012 > [INFO] Final Memory: 5M/490M > [INFO] > > [ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.4.1 or one of > its dependencies could not be resolved: Failed to read artifact descriptor > for org.apache.maven.plugins:maven-clean-plugin:jar:2.4.1: Could not transfer > artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.4.1 from/to > central (http://repo.maven.apache.org/maven2): Access denied to: > http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom, > ReasonPhrase:Forbidden. -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-662) jetty listens on port 0
[ https://jira.codehaus.org/browse/MSITE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSITE-662: --- Assignee: Olivier Lamy > jetty listens on port 0 > --- > > Key: MSITE-662 > URL: https://jira.codehaus.org/browse/MSITE-662 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:run >Affects Versions: 3.2 >Reporter: Christian Schlichtherle >Assignee: Olivier Lamy > > site:run doesn't work since version 3.2 of the plugin. When I use it, Jetty > reports to listen on socket 0 (!). This doesn't work, although Jetty silently > accepts it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-662) jetty listens on port 0
[ https://jira.codehaus.org/browse/MSITE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSITE-662. -- Resolution: Fixed Fix Version/s: 3.3 fixed http://svn.apache.org/r1403569 > jetty listens on port 0 > --- > > Key: MSITE-662 > URL: https://jira.codehaus.org/browse/MSITE-662 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:run >Affects Versions: 3.2 >Reporter: Christian Schlichtherle >Assignee: Olivier Lamy > Fix For: 3.3 > > > site:run doesn't work since version 3.2 of the plugin. When I use it, Jetty > reports to listen on socket 0 (!). This doesn't work, although Jetty silently > accepts it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-662) jetty listens on port 0
[ https://jira.codehaus.org/browse/MSITE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312574#comment-312574 ] Christian Schlichtherle commented on MSITE-662: --- Thanx! > jetty listens on port 0 > --- > > Key: MSITE-662 > URL: https://jira.codehaus.org/browse/MSITE-662 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:run >Affects Versions: 3.2 >Reporter: Christian Schlichtherle >Assignee: Olivier Lamy > Fix For: 3.3 > > > site:run doesn't work since version 3.2 of the plugin. When I use it, Jetty > reports to listen on socket 0 (!). This doesn't work, although Jetty silently > accepts it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-61) processed resources are added to main and test resources
[ https://jira.codehaus.org/browse/MRRESOURCES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312578#comment-312578 ] Mark Derricutt commented on MRRESOURCES-61: --- +1 for this. In my instance I'm only wanting the remote resources to be in my test resources. I have several projects that all want to reuse/share a set of test files so using remote-resources works well, if only they didn't end up in my production jar :) > processed resources are added to main and test resources > > > Key: MRRESOURCES-61 > URL: https://jira.codehaus.org/browse/MRRESOURCES-61 > Project: Maven 2.x Remote Resources Plugin > Issue Type: Bug >Affects Versions: 1.3 > Environment: Windows 7 >Reporter: David Tombs >Priority: Minor > Attachments: mrreserouces-61-project.zip > > > When is set to true, Maven Remote Resources Plugin adds processed > resources to both the main and test resources directories. I see no reason to > add the resources to the test directory unless explicitly specified because > the test classpath by default includes the main resources as well. The > disadvantage to including the resources in both the main and test directories > is that you end up with duplicate files on the class path which, for example, > can make logback complain about multiple "logback.xml" files. > The code in question is on lines 533-534 of ProcessRemoteResourcesMojo.java. > If you need an example project I can make one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
