[jira] Created: (MNG-4529) maven fails on IBM JDK 1.5.0 with exception IllegalAccessException: Field is final
maven fails on IBM JDK 1.5.0 with exception IllegalAccessException: Field is final -- Key: MNG-4529 URL: http://jira.codehaus.org/browse/MNG-4529 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 2.2.1 Environment: Windows XP, IBM JDK 1.5.0 Reporter: Thai Ha Attachments: ibm.output.txt, myapp.zip, sun.output.txt On Windows XP, and IBM JDK 1.5.0, maven 2.2.1 fails with the exception IllegalAccessException: Field is final. (See the complete stacktrace is at the end) How to duplicate: 1. (IMPORTANT) Delete maven local repository at \.m2\repository directory completely! 2. Unzip myapp.zip 3. Run command "mvn package -e" More info: The exception will happen when maven trying to set value to some static final fields. Re-run the command will see another new exception (old exception will not happend again). If you try maven in debug mode (to debug it with Eclipse), the exception will NOT appear. The complete information about maven, JDK, etc. are in the attached file: ibm.output.txt. The other output file (sun.output.txt) is the successful result when running using Sun JDK 1.5.0 Root cause: In StringSearchModelInterpolator.java of maven 2.2.1, there is a code snippet that tries to using Reflection to change values of fields (even if the fields are final) Line 175: fields[i].setAccessible( true ); Line 189: fields[i].set( target, interpolated ); If fields[i] is a final field, on Sun JDK 1.5.0, the operation is successful but on IBM JDK 1.5.0, an exception will be thrown. Complete stacktrace == org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build project for plugin 'org.apache.maven.plugins:maven-compiler-plugin': Failed to interpolate field: public static final java.lang.String org.codehaus.plexus.util.xml.Xpp3Dom.CHILDREN_COMBINATION_MODE_ATTRIBUTE on class: org.codehaus.plexus.util.xml.Xpp3Dom for project unknown:maven-compiler-plugin at Artifact [org.apache.maven.plugins:maven-compiler-plugin:pom:2.0.2] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1557) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1851) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:1275) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.InvalidPluginException: Unable to build project for plugin 'org.apache.maven.plugins:maven-compiler-plugin': Failed to interpolate field: public static final java.lang.String org.codehaus.plexus.util.xml.Xpp3Dom.CHILDREN_COMBINATION_MODE_ATTRIBUTE on class: org.codehaus.plexus.util.xml.Xpp3Dom for project unknown:maven-compiler-plugin at Artifact [org.apache.maven.plugins:maven-compiler-plugin:pom:2.0.2] at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:293) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:205) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:184) at org.apache.maven.plugin.DefaultPluginManager.loadPluginDescriptor(DefaultPluginManager.java:1642) at org.apache.maven.lifecycle.DefaultLifec
[jira] Commented: (MNG-4529) maven fails on IBM JDK 1.5.0 with exception IllegalAccessException: Field is final
[ http://jira.codehaus.org/browse/MNG-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206746#action_206746 ] Thai Ha commented on MNG-4529: -- Sorry this sentence is wrong (I cannot edit the ticket after posting it): "If fields[i] is a final field, on Sun JDK 1.5.0, the operation is successful but on IBM JDK 1.5.0, an exception will be thrown." I rechecked and see that changing a static final field will always generate an exception on both IBM JDK and Sun JDK. So I guess that on Sun JDK, somehow the line 189 is not executed (maybe another control flow?), and because of that I didn't receive the error on Sun JDK. > maven fails on IBM JDK 1.5.0 with exception IllegalAccessException: Field is > final > -- > > Key: MNG-4529 > URL: http://jira.codehaus.org/browse/MNG-4529 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: Windows XP, IBM JDK 1.5.0 >Reporter: Thai Ha > Attachments: ibm.output.txt, myapp.zip, sun.output.txt > > > On Windows XP, and IBM JDK 1.5.0, maven 2.2.1 fails with the exception > IllegalAccessException: Field is final. (See the complete stacktrace is at > the end) > How to duplicate: > 1. (IMPORTANT) Delete maven local repository at \.m2\repository > directory completely! > 2. Unzip myapp.zip > 3. Run command "mvn package -e" > More info: > The exception will happen when maven trying to set value to some static final > fields. Re-run the command will see another new exception (old exception will > not happend again). If you try maven in debug mode (to debug it with > Eclipse), the exception will NOT appear. The complete information about > maven, JDK, etc. are in the attached file: ibm.output.txt. The other output > file (sun.output.txt) is the successful result when running using Sun JDK > 1.5.0 > Root cause: > In StringSearchModelInterpolator.java of maven 2.2.1, there is a code snippet > that tries to using Reflection to change values of fields (even if the fields > are final) > Line 175: > fields[i].setAccessible( true ); > Line 189: > fields[i].set( target, interpolated ); > If fields[i] is a final field, on Sun JDK 1.5.0, the operation is successful > but on IBM JDK 1.5.0, an exception will be thrown. > Complete stacktrace == > org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build > project for plugin 'org.apache.maven.plugins:maven-compiler-plugin': Failed > to interpolate field: public static final java.lang.String > org.codehaus.plexus.util.xml.Xpp3Dom.CHILDREN_COMBINATION_MODE_ATTRIBUTE on > class: org.codehaus.plexus.util.xml.Xpp3Dom for project > unknown:maven-compiler-plugin at Artifact > [org.apache.maven.plugins:maven-compiler-plugin:pom:2.0.2] > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1557) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1851) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:1275) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.InvalidPluginException: Unable to build > project for plugin 'org.apache.maven.plugins:m
[jira] Created: (MSHARED-141) MavenCommandLineBuilder incorrectly adds system properties
MavenCommandLineBuilder incorrectly adds system properties
--
Key: MSHARED-141
URL: http://jira.codehaus.org/browse/MSHARED-141
Project: Maven Shared Components
Issue Type: Bug
Components: maven-invoker
Affects Versions: maven-invoker 2.0.11, maven-invoker 2.0.10, maven-invoker
2.0.9, maven-invoker 2.0.8, maven-invoker 2.0.7
Reporter: Andrei Solntsev
Priority: Minor
Class MavenCommandLineBuilder adds system properties with spaces.
For example, given the following properties: {skipTests=true, listScmChanges=}
MavenCommandLineBuilder generates the following command line:
cmd.exe /X /C "C:\Programs\apache-maven-2.2.1\bin\mvn.bat -B -N -e -D
skipTests=true -D listScmChanges="
The correct form is without spaces: "-DskipTests=true -DlistScmChanges"
--
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: (MSHARED-141) MavenCommandLineBuilder incorrectly adds system properties
[
http://jira.codehaus.org/browse/MSHARED-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Solntsev updated MSHARED-141:
Attachment: MSHARED-141-maven-invoker.patch
Patch is provided
> MavenCommandLineBuilder incorrectly adds system properties
> --
>
> Key: MSHARED-141
> URL: http://jira.codehaus.org/browse/MSHARED-141
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-invoker
>Affects Versions: maven-invoker 2.0.7, maven-invoker 2.0.8, maven-invoker
> 2.0.9, maven-invoker 2.0.10, maven-invoker 2.0.11
>Reporter: Andrei Solntsev
>Priority: Minor
> Attachments: MSHARED-141-maven-invoker.patch
>
>
> Class MavenCommandLineBuilder adds system properties with spaces.
> For example, given the following properties: {skipTests=true, listScmChanges=}
> MavenCommandLineBuilder generates the following command line:
> cmd.exe /X /C "C:\Programs\apache-maven-2.2.1\bin\mvn.bat -B -N -e -D
> skipTests=true -D listScmChanges="
> The correct form is without spaces: "-DskipTests=true -DlistScmChanges"
--
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: (SUREFIRE-597) Surefire report creation fails on processing absent optional JUnit xml attributes
Surefire report creation fails on processing absent optional JUnit xml attributes - Key: SUREFIRE-597 URL: http://jira.codehaus.org/browse/SUREFIRE-597 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Report Plugin Affects Versions: 2.4.3 Reporter: Maksym Symonov Priority: Minor Surefire report creation fails when JUnit XML source for report doesn't contain optional attributes. I use Clojure with junit xml output, it produces xml with subnode of . It has no "message" and "type" attributes specified for it. But has error message as nested text. Plugin processes this xml and fails with NullPointerException SurefireReportGenerator.java:676, as i see in the code, it's not possible for it to have node without "type" attribute. Maybe it would be better to add null checking at that method? -- 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: (MRELEASE-297) release doesn't bump versions in properties to the next dev iteration
[
http://jira.codehaus.org/browse/MRELEASE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206779#action_206779
]
Martin Zeltner commented on MRELEASE-297:
-
Hi
It affects also version 2.0-beta-9
Further the version xml element of "release-module1" is changed from
"${module1.version}" to the fixed version "0.0.3-SNAPSHOT".
Cheers
Martin
> release doesn't bump versions in properties to the next dev iteration
> -
>
> Key: MRELEASE-297
> URL: http://jira.codehaus.org/browse/MRELEASE-297
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-6, 2.0-beta-7
>Reporter: Brian Fox
>Assignee: Maria Odea Ching
>
> Properties used as versions are correctly updated to the release version and
> committed, but they are not bumped to the next snapshot after.
--
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: (MAVENUPLOAD-2716) Upload Stripes-1.5.3 to Maven Repository
Upload Stripes-1.5.3 to Maven Repository - Key: MAVENUPLOAD-2716 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2716 Project: Maven Upload Requests Issue Type: Wish Reporter: Freddy Daoud Could you please upload the stripes-1.5.3 bundle to the public maven repository. Thanks! -- 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-4530) Add alias feature for moved/renamed dependencies
Add alias feature for moved/renamed dependencies
Key: MNG-4530
URL: http://jira.codehaus.org/browse/MNG-4530
Project: Maven 2 & 3
Issue Type: New Feature
Components: Dependencies
Reporter: Paul Gier
There should be an option to link multiple dependency groupId/artifactIds so
that the dependency resolver knows they refer to the same artifact. There are
many dependencies that get renamed to a new groupId/artifactId. This causes
problems because many times the old groupId/artifactId is still pulled in
transitively from other projects. Currently, the only way to do this is with a
tedious combination of tags and enforcer rules. It would be much
simpler if there were a mechanism in the pom and dependency manager to treat
two IDs as the same dependency.
{code:xml}
org.mycomp
log4j
1.0
log4j
log4j
{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-4531) Add option to use a profile of a dependency
Add option to use a profile of a dependency
---
Key: MNG-4531
URL: http://jira.codehaus.org/browse/MNG-4531
Project: Maven 2 & 3
Issue Type: New Feature
Components: Dependencies
Reporter: Paul Gier
Some projects require two or more sets of dependencies with each set contained
in a profile. Unfortunately, it can be difficult to consume the correct
dependency set. It would be useful to have an option to select a profile for a
certain dependency.
{code:xml}
org.mycompany
projectA
1.0
jdk1.4
{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] Commented: (MASSEMBLY-436) assembly id not available as property for filtering
[
http://jira.codehaus.org/browse/MASSEMBLY-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206795#action_206795
]
Sergio M C Figueiredo commented on MASSEMBLY-436:
-
I would like to get some assembly information in my resource files by
filtering. Maybe something like:
${assembly.descriptorId} or ${assembly.id} -> ex. 'swing' or
'jar-with-dependencies' ...
${assembly.finalName} -> ex. 'my-project-5.5-swing'
${assemblyArchive.format} -> 'zip' or 'dir' ...
I am assuming 'assemblyArchive' has one instance by assembly descriptor format.
> assembly id not available as property for filtering
> ---
>
> Key: MASSEMBLY-436
> URL: http://jira.codehaus.org/browse/MASSEMBLY-436
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.2-beta-4
> Environment: all
>Reporter: Bjorn
>
> I'm building a project for multiple platforms (using multiple assembly
> descriptors) and need the assembly information (for example one of my
> assemblies is called "gtk-linux-x86_64") in the deployment package.
> Preferably by resource filtering. This information is available in my
> descriptors as the assembly id. Unfortunately this id is not accessible.
> Besides resource filtering the assembly id could also be used in the
> descriptor itself and could reduce duplication of information.
> Example where ID is used as a platform classifier:
>
> gtk-linux-x86_64
> dir
>
>
> /lib
>
>
>
> org.eclipse:org.eclipse.swt:jar:${assembly.id}
>
>
>
>
--
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: (JXR-79) NPE on source XREF
[ http://jira.codehaus.org/browse/JXR-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206800#action_206800 ] Johannes Schneider commented on JXR-79: --- I just have a complex sample project here... > NPE on source XREF > -- > > Key: JXR-79 > URL: http://jira.codehaus.org/browse/JXR-79 > Project: Maven JXR > Issue Type: Bug > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > Java version: 1.6.0_16 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.31-17-generic" arch: "amd64" Family: "unix" >Reporter: Johannes Schneider > > [INFO] Generating "Source Xref" report. > [DEBUG] Scanning > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java > [DEBUG] parsing... com/cedarsoft/VersionRange.java > [DEBUG] parsing... com/cedarsoft/Version.java > [DEBUG] parsing... com/cedarsoft/UnsupportedVersionRangeException.java > [DEBUG] parsing... com/cedarsoft/VersionMismatchException.java > [DEBUG] parsing... com/cedarsoft/UnsupportedVersionException.java > [DEBUG] parsing... com/cedarsoft/VersionException.java > [DEBUG] > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionRange.java > -> > /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionRange.html > [DEBUG] > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/Version.java > -> > /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/Version.html > [DEBUG] > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionRangeException.java > -> > /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionRangeException.html > [DEBUG] > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionMismatchException.java > -> > /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionMismatchException.html > [DEBUG] > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionException.java > -> > /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionException.html > [DEBUG] > /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionException.java > -> > /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionException.html > [DEBUG] ** > [DEBUG] Starting Jakarta Velocity v1.4 > [DEBUG] RuntimeInstance initializing. > [DEBUG] Default Properties File: > org/apache/velocity/runtime/defaults/velocity.properties > [DEBUG] Trying to use logger class org.apache.maven.jxr.log.VelocityLogger > [DEBUG] Using logger class org.apache.maven.jxr.log.VelocityLogger > [DEBUG] Default ResourceManager initializing. (class > org.apache.velocity.runtime.resource.ResourceManagerImpl) > [DEBUG] Resource Loader Instantiated: > org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader > [DEBUG] ClasspathResourceLoader : initialization starting. > [DEBUG] ClasspathResourceLoader : initialization complete. > [DEBUG] ResourceCache : initialized. (class > org.apache.velocity.runtime.resource.ResourceCacheImpl) > [DEBUG] Default ResourceManager initialization complete. > [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal > [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro > [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse > [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include > [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach > [DEBUG] Created: 20 parsers. > [DEBUG] Velocimacro : initialization starting. > [DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in > templates > [DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may > NOT replace previous VM definitions > [DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be > global in scope if allowed. > [DEBUG] Velocimacro : messages on : VM system will output logging messages > [DEBUG] Velocimacro : autoload off : VM system will not automatically reload > global library macros > [DEBUG] Velocimacro : initialization complete. > [DEBUG] Velocity successfully started. > [DEBUG] ResourceManager : found templates/index.vm with loader > org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader > [DEBUG] ResourceManager : found templates/overview-frame.vm with loader > org.apache.velocity.runtime.resource.loader.ClasspathResourceLo
[jira] Commented: (MNG-3078) artifact of packaging 'tar.gz' / dependency of type 'tar.gz downloaded, but not saved to local repository
[ http://jira.codehaus.org/browse/MNG-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206808#action_206808 ] Peter Lynch commented on MNG-3078: -- I did create an integration test but using Maven 2.2.9 and Maven 3 i could not reproduce the problem. Files get downloaded and stored in local repo no problem. Somewhere along the line it seems fixed - so I agree - close it. > artifact of packaging 'tar.gz' / dependency of type 'tar.gz downloaded, but > not saved to local repository > - > > Key: MNG-3078 > URL: http://jira.codehaus.org/browse/MNG-3078 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 2.0.6, 2.0.7 >Reporter: Peter Lynch >Priority: Critical > > Using mvn deploy:deploy-file you can successfully upload a 'tar.gz' artifact > to a repository. > Example without classifier: > mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat > -Dversion=6.0.13 -Dpackaging=tar.gz -DrepositoryId=repo-central > -Durl=dav:http://repo.example.com:4000/maven-repos/repo-central/ > -Dfile=apache-tomcat-6.0.13.tar.gz > Example with classifier > mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat > -Dversion=6.0.13 -Dpackaging=tar.gz -Dclassifier=bin > -DrepositoryId=repo-central > -Durl=dav:http://repo.example.com:4000/maven-repos/repo-central/ > -Dfile=apache-tomcat-6.0.13.tar.gz > Once uploaded define a dependency in your pom to it. > Example without classifier > > pom > ... > > ... > > org.apache.tomcat > apache-tomcat > 6.0.13 > tar.gz > true > > ... > > ... > > Example with classifier > > pom > ... > > ... > > org.apache.tomcat > apache-tomcat > 6.0.13 > tar.gz > bin > true > > ... > > ... > > Now to reproduce the problem you could either do > mvn dependency:resolve > or > mvn assembly:assembly > (if the maven assembly plugin is configured with a dependency set that > unpacks this dependency for example) > > The reason I think this is a core bug and not an maven assembly plugin or > maven-dependency-plugin bug is because the problem happens in both of these > independent plugins. > When you run 'mvn dependency:resolve' you'll see that the dependency appears > downloaded but then the build fails with : > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.tomcat > -DartifactId=apache-tomcat \ > -Dversion=6.0.13 -Dclassifier=bin -Dpackaging=tar.gz > -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file there: > mvn deploy:deploy-file -DgroupId=org.apache.tomcat > -DartifactId=apache-tomcat \ > -Dversion=6.0.13 -Dclassifier=bin -Dpackaging=tar.gz > -Dfile=/path/to/file \ >-Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.example:core:pom:1.0.0-A1-SNAPSHOT > 2) org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13 > -- > 1 required artifact is missing. > ... > ... and even stranger here is the log which proves the dependency was found > in the repo and downloaded, but NOT saved to local repository. > ... > [DEBUG] Trying repository repo-central > Downloading: > http://repo.example.com:4000/maven-repos/repo-central/org/apache/tomcat/apache-tomcat/6.0.13/apache-tomcat-6.0.13-bin.tar.gz > 5826K downloaded > [DEBUG] Unable to get resource > 'org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13' from repository > repo-central (http://repo.example.com:4000/maven-repos/repo-central) > [DEBUG] Unable to download the artifact from any repository > ..and YOU MAY GET FOOLED into thinking all is well. mvn deploy:deploy-file > also installs the same artifact into your local repo. So if you follow above > steps and don't get an error it is because the deploy-file goal installed it > in your local repo. However when someone else tries to use your project they > will get above error. > So, first delete from your local repo. example: > rm -rf ~/.m2/repository/org/apache/tomcat/apache-tomcat > and then try to execute mvn dependency:resolve and it should fail as > described. > ...and finally I'll mention that doing the same thing with a 'zip' > type/packaging there is NO PROBLEM. > Ultimately when using the
[jira] Commented: (MRELEASE-484) release:rollback fails after branch with NPE and complaint about missing scm URL
[ http://jira.codehaus.org/browse/MRELEASE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206821#action_206821 ] Dennis Kieselhorst commented on MRELEASE-484: - Have a look at MOJO-1463. This issue occurs when the developerConnection is missing. > release:rollback fails after branch with NPE and complaint about missing scm > URL > > > Key: MRELEASE-484 > URL: http://jira.codehaus.org/browse/MRELEASE-484 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.0-beta-9 >Reporter: Benson Margulies > > After a problem with release:branch (possibly the 'remoteTagging' problem) an > attempt to run rollback got me the following. The SCM urls are indeed in the > POM. > [INFO] Trace > java.lang.NullPointerException: The scm url cannot be null. > at > org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository(AbstractScmManager.java:181) > at > org.apache.maven.shared.release.scm.DefaultScmRepositoryConfigurator.getConfiguredRepository(DefaultScmRepositoryConfigurator.java:62) > at > org.apache.maven.shared.release.phase.RestoreBackupPomsPhase.restorePomBackup(RestoreBackupPomsPhase.java:100) > at > org.apache.maven.shared.release.phase.RestoreBackupPomsPhase.execute(RestoreBackupPomsPhase.java:69) > at > org.apache.maven.shared.release.DefaultReleaseManager.rollback(DefaultReleaseManager.java:250) > at > org.apache.maven.shared.release.DefaultReleaseManager.rollback(DefaultReleaseManager.java:227) > at > org.apache.maven.plugins.release.RollbackReleaseMojo.execute(RollbackReleaseMojo.java:54) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > 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.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > -- 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: (SUREFIRE-598) run maven test with customized classpath
run maven test with customized classpath Key: SUREFIRE-598 URL: http://jira.codehaus.org/browse/SUREFIRE-598 Project: Maven Surefire Issue Type: New Feature Components: Maven Surefire Plugin Affects Versions: 2.5 Reporter: A Attachments: surefire.diff I have modified the plug-in to allow customizing the classpath used when running tests. The idea is that sometimes one needs to know everything works with the libraries as shipped with another project that is using (and includes) the maven project currently under tests. But at the moment one cannot override the maven test classpath. I hope this functionality will be useful to others tasked to test releases of big projects bundling lots of smaller projects and willing to make sure the smaller projects are still operating flawlessly in this environment. So I'm attaching a patch against trunk r898286 that I hope to be included in future maven-surefire-plugin releases. There are two configurable additional parameters - ignoreClasspathElements and debugClasspath. The former one selects what to remove from the original maven test classpath and the second outputs classpath information to the INFO level so one doesn't need to dig into the DEBUG output and/or TEST-X.xml Basically how I use it is like: 1. ignoreClasspathElements=runtime (remove runtime artifacts from test classpath) 2. additionalClasspathElements= 3. debugClasspath=true (so I can easily verify classpath elements are what I expect them to be) There are two more options for ignoreClasspathElements - none and all. First is the default so classpath is what it has always used to be. Latter is to nuke the whole test classpath in case somebody needs full control and wants to specify even the test scoped classpath elements. I've put "@since 2.5.1" but that of course is not something I insist on. Please change it to whatever fits best your release rules. -- 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-1683) type zip for packaging ?
[ http://jira.codehaus.org/browse/MNG-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206834#action_206834 ] Gabe Beged-Dov commented on MNG-1683: - what is the status of this issue? What does the fix version of "3.X (to be reviewed)" mean? > type zip for packaging ? > > > Key: MNG-1683 > URL: http://jira.codehaus.org/browse/MNG-1683 > Project: Maven 2 & 3 > Issue Type: Improvement > Environment: not significant >Reporter: Olivier Lamy > Fix For: 3.x (to be reviewed) > > Attachments: archive+file-plugins.tar.bz2, maven-war-plugin.tar.gz, > maven-zip-plugin.tar.gz, MNG-1683.tar.gz, patch1, temp-test_version.zip > > > Hi, > I don't know if the artifact type zip exists (I think not after few test). > But I want to separate the html content and the webapp content (classes, > configuration files and so on). > The use case is to separate this different works (html designer and java > developpement) and production installation (one is to an http server and the > other is on an app server) in two artifacts with separate versionning. > But the zip is not recognized. > Then I would like to use it as an artifact with maven's features (snapshot, > pom, version, goals : install, deploy release and all others). > Add it to the webapp dependencies (needed only for developpment or unit > tests). > With this type of dependency the zip content could be unpacked to a directory > in the exploded webapp. (certainly need hack on the maven-war-plugin). > I have certainly the workaround to declare this as jar and using the assembly > plugin to generate a zip. > But I can't use install release deploy or something else to manage the > generated zip which is not an artifact. > Thanks for help or workaround. > - Olivier -- 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-1683) type zip for packaging ?
[ http://jira.codehaus.org/browse/MNG-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206839#action_206839 ] Brett Porter commented on MNG-1683: --- issues that haven't been looked at recently have been marked for review so we can schedule them (and close those that aren't reproducible / already fixed / etc). The issue history still shows the current 'status' > type zip for packaging ? > > > Key: MNG-1683 > URL: http://jira.codehaus.org/browse/MNG-1683 > Project: Maven 2 & 3 > Issue Type: Improvement > Environment: not significant >Reporter: Olivier Lamy > Fix For: 3.x (to be reviewed) > > Attachments: archive+file-plugins.tar.bz2, maven-war-plugin.tar.gz, > maven-zip-plugin.tar.gz, MNG-1683.tar.gz, patch1, temp-test_version.zip > > > Hi, > I don't know if the artifact type zip exists (I think not after few test). > But I want to separate the html content and the webapp content (classes, > configuration files and so on). > The use case is to separate this different works (html designer and java > developpement) and production installation (one is to an http server and the > other is on an app server) in two artifacts with separate versionning. > But the zip is not recognized. > Then I would like to use it as an artifact with maven's features (snapshot, > pom, version, goals : install, deploy release and all others). > Add it to the webapp dependencies (needed only for developpment or unit > tests). > With this type of dependency the zip content could be unpacked to a directory > in the exploded webapp. (certainly need hack on the maven-war-plugin). > I have certainly the workaround to declare this as jar and using the assembly > plugin to generate a zip. > But I can't use install release deploy or something else to manage the > generated zip which is not an artifact. > Thanks for help or workaround. > - Olivier -- 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-4528) [regression] mvn deploy ignores proxy settings
[
http://jira.codehaus.org/browse/MNG-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4528.
--
Resolution: Fixed
Fix Version/s: 3.0-alpha-7
Assignee: Benjamin Bentmann
Fixed in [r899004|http://svn.apache.org/viewvc?view=revision&revision=899004].
The root problem are the transitive dependencies of the Deploy Plugin versions
before 2.5 which under the revised class loading take precedence over the
default wagons from the distro. This made any bug of the old wagons come back.
> [regression] mvn deploy ignores proxy settings
> --
>
> Key: MNG-4528
> URL: http://jira.codehaus.org/browse/MNG-4528
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.0-alpha-6
> Environment: Vista, maven 3.0-alpha-6
>Reporter: Fred Bricon
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-7
>
>
> Running "mvn deploy" fails when behind a proxy (connection refused) in maven
> 3.0-alpha6, even though the proxy settings have been configured in
> settings.xml.
> Deploying the same artifact succeeds when using maven 2.0.10 -> 2.2.1, using
> the same settings.xml.
> As a workaround, I had to add pass the proxy parameters in the command line:
> {noformat}
> mvn deploy -Dhttp.proxyHost=proxy.ip -Dhttp.proxyPort=8080
> -Dhttp.proxyUser=username -Dhttp.proxyPassword=password
> {noformat}
> regards,
> Fred Bricon
--
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: (MRELEASE-512) SCM information should be validated
SCM information should be validated
---
Key: MRELEASE-512
URL: http://jira.codehaus.org/browse/MRELEASE-512
Project: Maven 2.x Release Plugin
Issue Type: Wish
Components: perform, prepare, rollback
Affects Versions: 2.0-beta-8
Reporter: Paul Benedict
The plugin does not currently validate the SCM connection info. When preparing
a release with invalid info, the project gets built, the transformed POM is
committed, but the branching/tagging is doomed -- leaving the user having to
perform a rollback.
I would like this plugin to automatically invoke {{scm:validate}}:
http://maven.apache.org/scm/maven-scm-plugin/validate-mojo.html
The earlier phase the better for validation. There's no point in compiling the
project if the connection strings are wrong.
--
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
