[jira] Created: (SUREFIRE-713) Allow setting of excludes and includes via text files
Allow setting of excludes and includes via text files - Key: SUREFIRE-713 URL: http://jira.codehaus.org/browse/SUREFIRE-713 Project: Maven Surefire Issue Type: New Feature Components: Maven Failsafe Plugin, Maven Surefire Plugin Affects Versions: Backlog Reporter: Andrew Bayer Attachments: excludeIncludeFile.patch It'd be handy in some circumstances to be able to read the excludes (and includes) from text files. This would allow for dynamically determining which tests to skip or include (for whatever reason) before the tests are executed, or for pulling in a list of tests to exclude/include from an external source, etc. We're planning to use this at Cloudera for segregating "flaky" tests from our primary test runs (and vice versa). Patch attached, though I'm sure it could still use work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-690) testSetCompleted called before testSetStarting when using m3 parallel builds
[
http://jira.codehaus.org/browse/SUREFIRE-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260106#action_260106
]
Gin-Ting Chen commented on SUREFIRE-690:
I got this again in 2.8.
I should note, however, that I also turned the timeout back on when I updated
to 2.8.
Do you need a stack trace? I can probably get one pretty quickly with the
frequency of this bug
{noformat}
[18:16:29]: [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.8:test (default-test) on
project chameleon-main: Error while executing forked tests.; nested exception
is java.lang.IllegalStateException: testSetStarting called twice -> [Help 1]
[18:16:29]: [ERROR]
[18:16:29]: [ERROR] To see the full stack trace of the errors, re-run Maven
with the -e switch.
[18:16:29]: [ERROR] Re-run Maven using the -X switch to enable full debug
logging.
[18:16:29]: [ERROR]
[18:16:29]: [ERROR] For more information about the errors and possible
solutions, please read the following articles:
[18:16:29]: [ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[18:16:29]: [ERROR]
[18:16:29]: [ERROR] After correcting the problems, you can resume the build
with the command
[18:16:29]: [ERROR] mvn -rf :chameleon-main
{noformat}
> testSetCompleted called before testSetStarting when using m3 parallel builds
>
>
> Key: SUREFIRE-690
> URL: http://jira.codehaus.org/browse/SUREFIRE-690
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.7.1
>Reporter: Gin-Ting Chen
>Assignee: Kristian Rosenvold
>
> This is running m3 with -T 1C (8 core build machine).
> [17:52:38]: [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test) on
> project hornet-stinger: Error while executing forked tests.; nested exception
> is java.lang.IllegalStateException: testSetCompleted called before
> testSetStarting -> [Help 1]
> Seems like it doesn't happen as frequently as previously
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5044) use maven-reporting-api 3.0 instead of creating another new 2.2.x version
[ http://jira.codehaus.org/browse/MNG-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNG-5044. -- Resolution: Fixed Fix Version/s: 2.2.2 Assignee: Herve Boutemy done is [r1081596|http://svn.apache.org/viewvc?rev=1081596&view=rev] > use maven-reporting-api 3.0 instead of creating another new 2.2.x version > - > > Key: MNG-5044 > URL: http://jira.codehaus.org/browse/MNG-5044 > Project: Maven 2 & 3 > Issue Type: Wish > Components: Sites & Reporting >Affects Versions: 2.2.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 2.2.2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5044) use maven-reporting-api 3.0 instead of creating another new 2.2.x version
use maven-reporting-api 3.0 instead of creating another new 2.2.x version - Key: MNG-5044 URL: http://jira.codehaus.org/browse/MNG-5044 Project: Maven 2 & 3 Issue Type: Wish Components: Sites & Reporting Affects Versions: 2.2.1 Reporter: Herve Boutemy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5043) maven-compat should be excluded like other internal Maven component
[ http://jira.codehaus.org/browse/MNG-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNG-5043. -- Resolution: Fixed Fix Version/s: 2.2.2 Assignee: Herve Boutemy fixed in [r1081574|http://svn.apache.org/viewvc?rev=1081574&view=rev] > maven-compat should be excluded like other internal Maven component > --- > > Key: MNG-5043 > URL: http://jira.codehaus.org/browse/MNG-5043 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 2.2.2 > > > maven-compat is not in the [list in > MavenArtifactFilterManager|http://maven.apache.org/ref/2.2.1/maven-core/xref/org/apache/maven/MavenArtifactFilterManager.html#66] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5043) maven-compat should be excluded like other internal Maven component
maven-compat should be excluded like other internal Maven component --- Key: MNG-5043 URL: http://jira.codehaus.org/browse/MNG-5043 Project: Maven 2 & 3 Issue Type: Bug Components: Dependencies Affects Versions: 2.2.1 Reporter: Herve Boutemy maven-compat is not in the [list in MavenArtifactFilterManager|http://maven.apache.org/ref/2.2.1/maven-core/xref/org/apache/maven/MavenArtifactFilterManager.html#66] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-130) extra empty lines are preserved when writing Manifest.mf file
[ http://jira.codehaus.org/browse/MECLIPSE-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260087#action_260087 ] Richard Eggert commented on MECLIPSE-130: - It's been over a year with no action on this (even though a patch was submitted). The problem still exists with version 2.8. > extra empty lines are preserved when writing Manifest.mf file > - > > Key: MECLIPSE-130 > URL: http://jira.codehaus.org/browse/MECLIPSE-130 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: OSGi, Manifest >Affects Versions: 2.3 > Environment: Windows Xp, eclipse 3.2.0, jdk 1.5, maven 2.0.4 >Reporter: stephane bouchet >Priority: Minor > Attachments: EclipseOSGiManifestWriter.java.patch, > MECLIPSE_130.patch, MECLIPSE_130_patch.diff > > > Hi, > when i use the last snapshot in pde projects, i notice that bug : > the Bundle:Classpath entry is written in the end of the file, but if there is > empty line before writing this entry, they are not removed. > So eclipse complains about it. > To resolve this, i had to manually delete these empty lines. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-449) Permissions on directories in a zipped archive incorrect
[
http://jira.codehaus.org/browse/MASSEMBLY-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260084#action_260084
]
Andreas Veithen commented on MASSEMBLY-449:
---
A workaround for this issue is to add the following configuration to the plugin:
{code}
420
493
493
{code}
Tested with 2.2-beta-5.
> Permissions on directories in a zipped archive incorrect
>
>
> Key: MASSEMBLY-449
> URL: http://jira.codehaus.org/browse/MASSEMBLY-449
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-4
>Reporter: James Kavanagh
>
> Using the following assembly plugin:
> {code:xml}
>
> target-packaged
>
> zip
>
> false
>
>
>
> *:core-env
>
>
> env
> false
> true
>
>
>
>
> *:data-bridge
>
>
> target
> false
> true
>
>
>
>
> *:web
>
>
> web
> false
> true
>
>
>
>
> {code}
> When unzipping the result on a Linux host all the directory permissions have
> been set to 777.
> If I revert the plugin version to 2.2-beta-3 the issue goes away.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5042) Regression: CloningClassLoader causes StackOverflowError in groovy
[
http://jira.codehaus.org/browse/MNG-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260056#action_260056
]
Stuart McCulloch commented on MNG-5042:
---
If you could attach a test project that recreates the error that would be great
(improves the odds of getting this fixed).
> Regression: CloningClassLoader causes StackOverflowError in groovy
> --
>
> Key: MNG-5042
> URL: http://jira.codehaus.org/browse/MNG-5042
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3
>Reporter: Patrick Staton
>
> I am unable to use a groovy class as a plexus component in maven 3 because
> groovy's metaclass mechanism calls Introspector.getBeanInfo() in constructors
> which in turn calls classloader.loadClass(beanClass.getName() +
> BEANINFO_SUFFIX) (the class name is "FooBar$__plexus2") which in turn causes
> CloningClassLoader to create a new clone of the class named
> "FooBar$__plexus2BeanInfo". When "FooBar$__plexusBeanInfo" is instantiated
> groovy's the meta class mechanism again calls
> Introspector.getBeanInfo() on "FooBar$__plexus2".
> Example stack trace:
> {code}at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
> at java.beans.Introspector.(Introspector.java:380)
> at java.beans.Introspector.getBeanInfo(Introspector.java:167)
> at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
> at java.security.AccessController.doPrivileged(Native Method)
> at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
> at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
> at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
> at java.beans.Introspector.(Introspector.java:380)
> at java.beans.Introspector.getBeanInfo(Introspector.java:167)
> at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
> at java.security.AccessController.doPrivileged(Native Method)
> at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
> at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
> at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
[jira] Issue Comment Edited: (SUREFIRE-712) [REGRESSION] ignored
[
http://jira.codehaus.org/browse/SUREFIRE-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260054#action_260054
]
Kristian Rosenvold edited comment on SUREFIRE-712 at 3/14/11 1:42 PM:
--
Fixed in r1081511.
Integration test for Surefire-570 was only testing aggregated reports, updated
IT to also check unaggregated.
was (Author: krosenvold):
Fixed in r1081511.
Integration test for Surefire-570 was only testing aggregated tests, updated IT
to also check unaggregated.
> [REGRESSION] ignored
> -
>
> Key: SUREFIRE-712
> URL: http://jira.codehaus.org/browse/SUREFIRE-712
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.8
> Environment: Vista SP2 x64, JDK 6u24, Maven 3.0.3, site-plugin
> 3.0-beta-3
>Reporter: André Fügenschuh
>Assignee: Kristian Rosenvold
> Fix For: 2.8.1
>
>
> Running {{mvn site}} with surefire-reports-plugin enabled and configured
> generates an empty {{surefire-report.html}}.
> Using the (new and *recommended*) {{}} works with version
> 2.7.1, but is broken with 2.7.2 and 2.8!
> The (now *deprecated*) {{}} works with all versions.
> *site-plugin 3* configuration:
> {code}
> ...
>
> org.apache.maven.plugins
> maven-surefire-report-plugin
>
> ...
>
>
>
>
> ${test.reportsDirectory}
>
>
> ...
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-706) Global lock to serialize tests even if maven runs in parallel mode
[ http://jira.codehaus.org/browse/SUREFIRE-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-706: Priority: Minor (was: Major) > Global lock to serialize tests even if maven runs in parallel mode > -- > > Key: SUREFIRE-706 > URL: http://jira.codehaus.org/browse/SUREFIRE-706 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin > Environment: all >Reporter: Frank Meilinger >Priority: Minor > > It would be nice to serialize unit tests globally in the surefire plugin, > even if maven 3 runs with parallel mode. I know that some test providers are > able to do parallel testing itself (e.g. Junit47 provider) without running > maven in parallel or not. These test provider parallel mode can be configured > with surefire plugin configuration. E.g. none can be > used to serialize unit tests even if using the JUnit47 provider. But when > running maven 3 with -T option, the tests are still running in parallel, > depending on the parallel decision of maven 3. For code which is not able to > run in parallel (while unit tests are running, this will happen), this is a > problem. In this case the provider option none won't > help. I think it would be great (and maybe easy to implement) to have a > global surefire plugin option to globally lock the surefire plugin's > execute() method to serialize all unit tests over all parallel maven builds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-712) [REGRESSION] ignored
[
http://jira.codehaus.org/browse/SUREFIRE-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-712.
---
Resolution: Fixed
Fix Version/s: 2.8.1
Assignee: Kristian Rosenvold
Fixed in r1081511.
Integration test for Surefire-570 was only testing aggregated tests, updated IT
to also check unaggregated.
> [REGRESSION] ignored
> -
>
> Key: SUREFIRE-712
> URL: http://jira.codehaus.org/browse/SUREFIRE-712
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.8
> Environment: Vista SP2 x64, JDK 6u24, Maven 3.0.3, site-plugin
> 3.0-beta-3
>Reporter: André Fügenschuh
>Assignee: Kristian Rosenvold
> Fix For: 2.8.1
>
>
> Running {{mvn site}} with surefire-reports-plugin enabled and configured
> generates an empty {{surefire-report.html}}.
> Using the (new and *recommended*) {{}} works with version
> 2.7.1, but is broken with 2.7.2 and 2.8!
> The (now *deprecated*) {{}} works with all versions.
> *site-plugin 3* configuration:
> {code}
> ...
>
> org.apache.maven.plugins
> maven-surefire-report-plugin
>
> ...
>
>
>
>
> ${test.reportsDirectory}
>
>
> ...
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5042) Regression: CloningClassLoader causes StackOverflowError in groovy
Regression: CloningClassLoader causes StackOverflowError in groovy
--
Key: MNG-5042
URL: http://jira.codehaus.org/browse/MNG-5042
Project: Maven 2 & 3
Issue Type: Bug
Components: Class Loading
Affects Versions: 3.0.3, 3.0.2, 3.0.1, 3.0
Reporter: Patrick Staton
I am unable to use a groovy class as a plexus component in maven 3 because
groovy's metaclass mechanism calls Introspector.getBeanInfo() in constructors
which in turn calls classloader.loadClass(beanClass.getName() +
BEANINFO_SUFFIX) (the class name is "FooBar$__plexus2") which in turn causes
CloningClassLoader to create a new clone of the class named
"FooBar$__plexus2BeanInfo". When "FooBar$__plexusBeanInfo" is instantiated
groovy's the meta class mechanism again calls
Introspector.getBeanInfo() on "FooBar$__plexus2".
Example stack trace:
{code}at
sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
at sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown
Source)
at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at java.beans.Introspector.instantiate(Introspector.java:1449)
at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
at java.beans.Introspector.(Introspector.java:380)
at java.beans.Introspector.getBeanInfo(Introspector.java:167)
at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
at java.security.AccessController.doPrivileged(Native Method)
at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
at
sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
at sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown
Source)
at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at java.beans.Introspector.instantiate(Introspector.java:1449)
at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
at java.beans.Introspector.(Introspector.java:380)
at java.beans.Introspector.getBeanInfo(Introspector.java:167)
at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
at java.security.AccessController.doPrivileged(Native Method)
at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
at
sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
at sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown
Source)
at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at java.beans.Introspector.instantiate(Introspector.java:1449)
at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
at java.beans.Introspector.(Introspector.java:380)
at java.beans.Introspector.getBeanInfo(Introspector.java:167)
at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
at java.security.AccessController.doPrivileged(Native Method)
at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
at
[jira] Commented: (MNG-4952) [regression] RELEASE field of repository metadata is not updated upon repeated deployments
[ http://jira.codehaus.org/browse/MNG-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260044#action_260044 ] Benjamin Bentmann commented on MNG-4952: LATEST is only ever used for plugins. This metaversion is an internal impl detail, ordinary dependency resolution should use version ranges. > [regression] RELEASE field of repository metadata is not updated upon > repeated deployments > -- > > Key: MNG-4952 > URL: http://jira.codehaus.org/browse/MNG-4952 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.1 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann > Fix For: 3.0.2 > > > As reported by [Marcin Kuthan on the user > list|http://www.mail-archive.com/users@maven.apache.org/msg115404.html], the > g:a-level metadata's release field is not updated upon redeployments, i.e. > the value is stuck at its initial value. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4952) [regression] RELEASE field of repository metadata is not updated upon repeated deployments
[ http://jira.codehaus.org/browse/MNG-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260042#action_260042 ] Frank Prumbaum commented on MNG-4952: - I can confirm the fix in 3.0.3. What is still not updated is the LATEST-Tag. Our problem with this is the Nexus-repository manager, because there the LATEST-Tag is inserted when you (re-)create maven metadata (v.1.9.0.1). We deploy your software querying nexus with the v=LATEST parameter which takes into account the RELEASE and LATEST-Tag. If maven never updates LATEST but nexus does, we can never be sure what version will be deployed. What is sonatype's strategy on this type of metadata? > [regression] RELEASE field of repository metadata is not updated upon > repeated deployments > -- > > Key: MNG-4952 > URL: http://jira.codehaus.org/browse/MNG-4952 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.1 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann > Fix For: 3.0.2 > > > As reported by [Marcin Kuthan on the user > list|http://www.mail-archive.com/users@maven.apache.org/msg115404.html], the > g:a-level metadata's release field is not updated upon redeployments, i.e. > the value is stuck at its initial value. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5041) Scope of dependecies defined in Dependecy Management can't be overriden
[ http://jira.codehaus.org/browse/MNG-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-5041. -- Resolution: Cannot Reproduce Assignee: Benjamin Bentmann > Scope of dependecies defined in Dependecy Management can't be overriden > --- > > Key: MNG-5041 > URL: http://jira.codehaus.org/browse/MNG-5041 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.2, 3.0.3 > Environment: Linux x64 JDK 1.60_24 >Reporter: Emmanuel Hugonnet >Assignee: Benjamin Bentmann >Priority: Blocker > Attachments: MNG-5041.zip > > > If I define a dependency with in a parent pom using dependency management I > can't override the scope of the dependency management declaration in a child > pom. > If I use the dependency plugin the tree is as expected (the child override > the parent) but if I use the effective-pom I get what is declared in the > dependency management. > This seems a Maven 3.0.x bug -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5041) Scope of dependecies defined in Dependecy Management can't be overriden
[
http://jira.codehaus.org/browse/MNG-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-5041:
---
Attachment: MNG-5041.zip
Using this example project yields:
{noformat}
>mvn help:effective-pom -V
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
junit
junit
3.8.2
provided
junit
junit
3.8.2
compile
{noformat}
i.e. the scope from the parent's dependency management was successfully
overriden by the child.
> Scope of dependecies defined in Dependecy Management can't be overriden
> ---
>
> Key: MNG-5041
> URL: http://jira.codehaus.org/browse/MNG-5041
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2, 3.0.3
> Environment: Linux x64 JDK 1.60_24
>Reporter: Emmanuel Hugonnet
>Priority: Blocker
> Attachments: MNG-5041.zip
>
>
> If I define a dependency with in a parent pom using dependency management I
> can't override the scope of the dependency management declaration in a child
> pom.
> If I use the dependency plugin the tree is as expected (the child override
> the parent) but if I use the effective-pom I get what is declared in the
> dependency management.
> This seems a Maven 3.0.x bug
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5041) Scope of dependecies defined in Dependecy Management can't be overriden
Scope of dependecies defined in Dependecy Management can't be overriden --- Key: MNG-5041 URL: http://jira.codehaus.org/browse/MNG-5041 Project: Maven 2 & 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.3, 3.0.2 Environment: Linux x64 JDK 1.60_24 Reporter: Emmanuel Hugonnet Priority: Blocker If I define a dependency with in a parent pom using dependency management I can't override the scope of the dependency management declaration in a child pom. If I use the dependency plugin the tree is as expected (the child override the parent) but if I use the effective-pom I get what is declared in the dependency management. This seems a Maven 3.0.x bug -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-374) Unable to upload to the site using sftp
[ http://jira.codehaus.org/browse/MSITE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260005#action_260005 ] Thorsten Glaser commented on MSITE-374: --- +1, high urgency We can deploy to our server with sftp the build result but not the documentation. In the Jenkins build logs it shows that it hangs at this point: [JENKINS] Archiving site from /var/lib/hudson/jobs/(jobname)/workspace/target/site to /var/lib/hudson/jobs/(jobname)/site [INFO] [site:deploy] Using private key: /var/lib/hudson/.ssh/id_rsa sftp://(servername)/var/www/maven_repo/sites - Session: Opened Executing command: mkdir -p /var/www/maven_repo/sites/. Then nothing. On the server side, I just see an open PAM session with no activity. I suspect the mkdir call may be faulty, SFTP doesnt allow shell commands. > Unable to upload to the site using sftp > --- > > Key: MSITE-374 > URL: http://jira.codehaus.org/browse/MSITE-374 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.0-beta-7 > Environment: Windows visa professionnal french > eclipse plugin >Reporter: Jean-Philippe Gravel > > Unable to connect to remote repository using sftp or scp. Conecting to > shell.sourceforge.net. Tried to connect using Putty before the using mvn > site:deploy without success. Tried to connect using ssh in Cygwin and then > copied the file "known_hosts" to "C:\Users\jpgravel\.ssh" without success too. > * Note that my private key have been exported to the OpenSSH format using > Putty. > The following error occurs: > Using private key: C:\Users\jpgravel\.ssh\sourceforge_priv > sftp://web.sourceforge.net/home/groups/b/bt/btb/htdocs - Session: > Disconnecting > sftp://web.sourceforge.net/home/groups/b/bt/btb/htdocs - Session: Disconnected > [ERROR] > The following mojo encountered an error while executing: > Group-Id: org.apache.maven.plugins > Artifact-Id: maven-site-plugin > Version: 2.0-beta-7 > Mojo: deploy > brought in via: Direct invocation > While building project: > Group-Id: net.sf.btb > Artifact-Id: bridge > Version: 1.1.0 > From file: C:\Users\jpgravel\workspace\java\BridgeToBabylon\pom.xml > Reason: Error uploading site > When run wih "-e" I get the following exception: > org.apache.maven.wagon.providers.ssh.knownhost.UnknownHostException: The host > was not known and was not accepted by the configuration: web.sourceforge.net > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:178) > at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:106) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149) > at > org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223) > at > org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) > at > org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904) > at > org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304) > at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:63) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:52) > Caused by: com.jcraft.jsch.JSchException: reject HostKey: web.sourceforge.net > at com.jcraft.jsch.Session.checkHost(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) > ... 17 more > Error stacktrace: > org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the > plugin manager executing goal > 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-7:deploy': Mojo > execution failed. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndH
