[jira] (MRELEASE-719) No error when release:prepare with an already existing scm tag
[ https://jira.codehaus.org/browse/MRELEASE-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298042#comment-298042 ] Emmanuel Lécharny commented on MRELEASE-719: You're right. I had SVN in mind. It's a bit sad that some SCM consider that removing a tag == deleting it totally, but you'll have to deal with such a stupid decision. Hopefully, you have a clue about the used SCM, so the plugin can behave accordingly. Note that it will requires way more work :) No error when release:prepare with an already existing scm tag -- Key: MRELEASE-719 URL: https://jira.codehaus.org/browse/MRELEASE-719 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.1 Reporter: Tony Chemit Assignee: Olivier Lamy Fix For: 2.4 When releasing the mojo-parent (codehaus), I had to do the release twice but I forgot to remove the scm tag. The release:prepare did not complain about it (should have). -- 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-719) No error when release:prepare with an already existing scm tag
[ https://jira.codehaus.org/browse/MRELEASE-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298046#comment-298046 ] Mark Struberg commented on MRELEASE-719: I'm not worried about the additional work needed. But I'm really worried that we pack all this information in our maven-release-manager. There is already way too much hardcoded stuff which is specific for single SCMs in there. I'd rather move all this information into the scm-api instead. No error when release:prepare with an already existing scm tag -- Key: MRELEASE-719 URL: https://jira.codehaus.org/browse/MRELEASE-719 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.1 Reporter: Tony Chemit Assignee: Olivier Lamy Fix For: 2.4 When releasing the mojo-parent (codehaus), I had to do the release twice but I forgot to remove the scm tag. The release:prepare did not complain about it (should have). -- 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] (MCOMPILER-170) Regression: Compiler Plugin fails when building with multiple threads (-T...)
[
https://jira.codehaus.org/browse/MCOMPILER-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MCOMPILER-170.
--
Resolution: Fixed
implemented.
Warning will be
{code}
[WARNING] You are in a multi thread build and use reuseSame strategy this can
issues on some os/jdk, consider using reuseCreated strategy
If you env is fine with that, you can skip this warning with the configuration
field skipMultiThreadWarning or -Dmaven.compiler.skipMultiThreadWarning=true
{code}
Regression: Compiler Plugin fails when building with multiple threads (-T...)
-
Key: MCOMPILER-170
URL: https://jira.codehaus.org/browse/MCOMPILER-170
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows 7 x64, JDK 1.6.0_31, Maven 3.0.4
Reporter: Falko Modler
Assignee: Olivier Lamy
Priority: Critical
Fix For: 2.5
I just tried building my current project which is rather large and has many
sub-modules.
With version 2.3.2 (and below) of the plugin I was able to build the whole
project with multiple threads, let's say:
{{mvn clean compile -T4}}
Version 2.4 fails with random errors when using this command line!
Errors include missing closing brackets, cannot find symbol and so on. It's
also not always the same module where the errors occur.
A single-threaded build with:
{{mvn clean compile}}
*completes just fine*!
Unfortunately I cannot upload my project for copyright reasons.
So for me it looks like a classic concurrency problem. Maybe side effect of
MCOMPILER-166?
--
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] (DOXIATOOLS-16) NullPointerException when site URL is being generated
[
https://jira.codehaus.org/browse/DOXIATOOLS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Claessens reopened DOXIATOOLS-16:
--
Please also update line 1461 to check for empty site URL.
Thanks in advance.
private static String getDistMgmntSiteUrl( Model model )
{
if ( model.getDistributionManagement() != null
model.getDistributionManagement().getSite() != null
model.getDistributionManagement().getSite().getUrl() != null )
{
...
NullPointerException when site URL is being generated
-
Key: DOXIATOOLS-16
URL: https://jira.codehaus.org/browse/DOXIATOOLS-16
Project: Maven Doxia Tools
Issue Type: Bug
Components: Doxia Integration Tools
Environment: environment independent
Reporter: Marc Claessens
Assignee: Dennis Lundberg
Fix For: doxia-integration-tools-1.5
We have a parent POM where the site url is generated via the Maven Groovy
plugin, unless it is explicitly defined in the child POM
i.e.
site
idproject-sites/id
nameOur project Nexus server Site/name
!-- URL is built dynamically by groovy plugin --
/site
...
plugin
groupIdorg.codehaus.groovy.maven/groupId
artifactIdgmaven-plugin/artifactId
executions
execution
phasepre-site/phase
goals
goalexecute/goal
/goals
configuration
source
![CDATA[
if(!project.distributionManagement.site.url){
String version = new String(project.version)
String path = new String(project.artifactId)+'/'+version
project.distributionManagement.site.url
='dav:'+project.properties['siteBaseURL'] + path
}
]]
/source
/configuration
/execution
/executions
/plugin
}
This leads to a NullPointerException in DefaultSiteTool.java:
at java.io.File.init(File.java:222)
at
org.apache.maven.doxia.tools.DefaultSiteTool.urlEncode(DefaultSiteTool.java:1478)
at
org.apache.maven.doxia.tools.DefaultSiteTool.getDistMgmntSiteUrl(DefaultSiteTool.java:1451)
The if statement in getDistMgntSiteUrl (for both methods) should test for
null on project.getDistributionManagement().getSite().getUrl()
--
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] (MCOMPILER-170) Regression: Compiler Plugin fails when building with multiple threads (-T...)
[
https://jira.codehaus.org/browse/MCOMPILER-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298068#comment-298068
]
Falko Modler commented on MCOMPILER-170:
Ok, warning message now appears.
May I suggest some typo corrections and wording adjustments?
{noformat}
[WARNING] You are in a multi-thread build and compilerReuseStrategy is set to
reuseSame. This can cause issues in some environments (os/jdk)! Consider using
reuseCreated strategy.
If your env is fine with reuseSame, you can skip this warning with the
configuration field skipMultiThreadWarning or
-Dmaven.compiler.skipMultiThreadWarning=true
{noformat}
Regression: Compiler Plugin fails when building with multiple threads (-T...)
-
Key: MCOMPILER-170
URL: https://jira.codehaus.org/browse/MCOMPILER-170
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows 7 x64, JDK 1.6.0_31, Maven 3.0.4
Reporter: Falko Modler
Assignee: Olivier Lamy
Priority: Critical
Fix For: 2.5
I just tried building my current project which is rather large and has many
sub-modules.
With version 2.3.2 (and below) of the plugin I was able to build the whole
project with multiple threads, let's say:
{{mvn clean compile -T4}}
Version 2.4 fails with random errors when using this command line!
Errors include missing closing brackets, cannot find symbol and so on. It's
also not always the same module where the errors occur.
A single-threaded build with:
{{mvn clean compile}}
*completes just fine*!
Unfortunately I cannot upload my project for copyright reasons.
So for me it looks like a classic concurrency problem. Maybe side effect of
MCOMPILER-166?
--
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] (MCOMPILER-170) Regression: Compiler Plugin fails when building with multiple threads (-T...)
[
https://jira.codehaus.org/browse/MCOMPILER-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298069#comment-298069
]
Olivier Lamy commented on MCOMPILER-170:
great thanks.
Regression: Compiler Plugin fails when building with multiple threads (-T...)
-
Key: MCOMPILER-170
URL: https://jira.codehaus.org/browse/MCOMPILER-170
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows 7 x64, JDK 1.6.0_31, Maven 3.0.4
Reporter: Falko Modler
Assignee: Olivier Lamy
Priority: Critical
Fix For: 2.5
I just tried building my current project which is rather large and has many
sub-modules.
With version 2.3.2 (and below) of the plugin I was able to build the whole
project with multiple threads, let's say:
{{mvn clean compile -T4}}
Version 2.4 fails with random errors when using this command line!
Errors include missing closing brackets, cannot find symbol and so on. It's
also not always the same module where the errors occur.
A single-threaded build with:
{{mvn clean compile}}
*completes just fine*!
Unfortunately I cannot upload my project for copyright reasons.
So for me it looks like a classic concurrency problem. Maybe side effect of
MCOMPILER-166?
--
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 proxy
[ https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298075#comment-298075 ] cforce commented on MNG-5237: - We are using Windows XP and also configured proxy in settings.xml on Maven 3.04. It look likes Maven is not using the proxy settings from M2-Home/conf/settings.xml but the one from windows (Internet explorer). If its configured in ie it works, if not then not. If i configure the same in maven settings.xml it does make any difference. For notice: In oor case the m2 server (nexus mirror) is in noproxy string of our enterprise proxy config. We get some kind of socks connection error. 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 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): proxies proxy idoptional/id activetrue/active protocolhttp/protocol username/username password/password hostxxx.xx.xx.xx/host port8080/port nonProxyHostslocalhost|127.0.0.1/nonProxyHosts /proxy /proxies 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 xxx hidden xxx [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 xxx hidden xxx [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] (MECLIPSE-718) Support packaging 'bundle' from org.apache.felix:maven-bundle-plugin
[ https://jira.codehaus.org/browse/MECLIPSE-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298077#comment-298077 ] Dan Tran commented on MECLIPSE-718: --- this issue is resolved, here are comments from Barrie On Mon, May 7, 2012 at 3:51 AM, Dan Tran dant...@gmail.com wrote: Hi Barrie, Sorry about late response No sure where are here, just to recap 1. Check out http://svn.apache.org/repos/asf/karaf/branches/karaf-2.2.x and change directory to the checkout directory 2. mvn clean install 3. mvn eclipse:eclipse 4. mvn eclipse:configure-workspace -Declipse.workspace=. 5. Open the newly created workspace under checkout directory 6. Inport all generated project files You can see that lots of red mark projects, my suspect here is maven-eclipse-plugin does not know to connect reactor maven-bundle-plugin packaging project together like jar packaging project Perhaps we can do special hack to treat packing 'bundle' as 'jar package, thing may work On Fri, May 4, 2012 at 3:49 AM, Barrie Treloar baerr...@gmail.com wrote: On Fri, May 4, 2012 at 8:12 PM, Barrie Treloar baerr...@gmail.com wrote: On Thu, May 3, 2012 at 11:38 PM, Dan Tran dant...@gmail.com wrote: Hi Barrie, It is best to use http://svn.apache.org/repos/asf/karaf/branches/karaf-2.2.x which is very stable. Yes 'bundle' = felix's maven-bundle-plugin I meant to mentioned you have plenty of karma to burn from the pde-maven-plugin days :) Can you point me directly to which project is not resolving correctly? Something with not too many dependencies :) I can't find any bundle package types in the parent's dependencyManagement. And is this because apache-felix bundle just generates jar files with OSGI manifest entries anyway? So if you can point me to one that does not work, and what you would expect the .classpath entries to be etc I can investigate. This looks like an Eclipse bug See https://bugs.eclipse.org/bugs/show_bug.cgi?id=225754#c38 Essentially if * the folder is directly below the default workspace then it IGNORES the .project/name element on the import and uses the directory name instead * the folder is NOT directly below the default workspace then it correctly uses .project/name I think this is why the recommendation is to create workspace that has NO project's kept underneath it. I checked out the karaf code somewhere else, had an empty workspace and then imported the projects. There were no compilation errors. I will update the FAQ of m-e-p and put some notes in the Jira. Support packaging 'bundle' from org.apache.felix:maven-bundle-plugin Key: MECLIPSE-718 URL: https://jira.codehaus.org/browse/MECLIPSE-718 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Affects Versions: 2.9 Environment: windows, unix Reporter: Dan Tran packaging=bundle is the same as 'jar' packaging. -- 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-755) When passing aruments to undelying maven executions not all maven options are accepted
Sandy McPherson created MRELEASE-755:
Summary: When passing aruments to undelying 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
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] (ARCHETYPE-409) IntegrationTestMojo deletes project folder before test.
Jared Roberts created ARCHETYPE-409: --- Summary: IntegrationTestMojo deletes project folder before test. Key: ARCHETYPE-409 URL: https://jira.codehaus.org/browse/ARCHETYPE-409 Project: Maven Archetype Issue Type: Bug Components: Plugin Affects Versions: 2.2 Reporter: Jared Roberts Attachments: partial-archetype-example.zip I am attempting to integration test a partial archetype by including a valid POM inside the test project. The test fails to generate the expected output because prior to running the test, a call to FileUtils.deleteDirectory() is made to delete all files in the test basedir. I believe the intent of performing the deletion is to clean up prior test runs, but this makes testing partial archetypes impossible with the maven-archetype-plugin. A couple possible solutions exist. The first would be to stop deleting the basedir before testing. This might be surprising if someone forgets to clean between tests, but is that really a valid use-case? The second option that I can think of would be to add a new conventional directory (expected?) where the test project files can be placed and the Archetype plugin will check if that directory exists and copy the contents to the project folder after cleaning up. This option seems like a good compromise because it allows tests to succeed without an explicit clean between and also allows testing of partial archetypes. I've attached an example archetype that demonstrates the behavior I'm describing. Notice that the output from both the empty and existing projects are the same. -- 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-59) old velocity coordinate are not excluded
Olivier Lamy created MRRESOURCES-59: --- Summary: old velocity coordinate are not excluded Key: MRRESOURCES-59 URL: https://jira.codehaus.org/browse/MRRESOURCES-59 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Reporter: Olivier Lamy Velocity with old maven coordinate is not exclude from plexus-velocity. -- 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-60) use last velocity 1.7 version.
Olivier Lamy created MRRESOURCES-60: --- Summary: use last velocity 1.7 version. Key: MRRESOURCES-60 URL: https://jira.codehaus.org/browse/MRRESOURCES-60 Project: Maven 2.x Remote Resources Plugin Issue Type: Improvement Reporter: Olivier Lamy -- 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-54) m-r-r-p 1.2 not actually threadsafe apparently due to antique velocity version
[
https://jira.codehaus.org/browse/MRRESOURCES-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MRRESOURCES-54:
-
Description:
I tried a parallel build but ran into this. All three (identical) errors are
from pom projects.
{noformat}[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) on
project assemblies: Error rendering velocity resource. NullPointerException -
[Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) on
project assemblies: Error rendering velocity resource.
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.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error rendering
velocity resource.
at
org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1212)
at
org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:519)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 13 more
Caused by: java.lang.NullPointerException
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831)
at
org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:440)
at
org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:419)
at
org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1125)
... 16 more
{noformat}
was:
I tried a parallel build but ran into this. All three (identical) errors are
from pom projects.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) on
project assemblies: Error rendering velocity resource. NullPointerException -
[Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) on
project assemblies: Error rendering velocity resource.
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.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error rendering
velocity resource.
at
[jira] (MRRESOURCES-59) old velocity coordinate are not excluded
[ https://jira.codehaus.org/browse/MRRESOURCES-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRRESOURCES-59. --- Resolution: Fixed Fix Version/s: 1.3 Assignee: Olivier Lamy old velocity coordinate are not excluded Key: MRRESOURCES-59 URL: https://jira.codehaus.org/browse/MRRESOURCES-59 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 1.3 Velocity with old maven coordinate is not exclude from plexus-velocity. -- 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-60) use last velocity 1.7 version.
[ https://jira.codehaus.org/browse/MRRESOURCES-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRRESOURCES-60. --- Resolution: Fixed Fix Version/s: 1.3 use last velocity 1.7 version. -- Key: MRRESOURCES-60 URL: https://jira.codehaus.org/browse/MRRESOURCES-60 Project: Maven 2.x Remote Resources Plugin Issue Type: Improvement Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 1.3 -- 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-112) New property to enable shading the java text inside the sources artifact (not just shading the java source file locations)
[ https://jira.codehaus.org/browse/MSHADE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298100#comment-298100 ] Olivier Lamy commented on MSHADE-112: - Instead of adding more and more parameters to shade method (and break backward compatibility). Can you provide a patch using a ShadeRequest as parameter of shade method. Will be better for non breaking backward comp in the future. New property to enable shading the java text inside the sources artifact (not just shading the java source file locations) -- Key: MSHADE-112 URL: https://jira.codehaus.org/browse/MSHADE-112 Project: Maven 2.x Shade Plugin Issue Type: New Feature Affects Versions: 1.6 Reporter: Trask Stalnaker Attachments: shade-sources-content.patch The existing createSourcesJar property shades the source file locations, but it doesn't shade their content. This makes debugging (when using a shaded artifact) a little painful (at least in Eclipse) since the source files that Eclipse finds don't match up with the package names in the runtime environment. The attached patch performs a rather naive regular expression search/replace throughout the java source files when building the shaded sources artifact. The patch also makes the assumption that the source files are all UTF-8 encoded. This latter issue seems especially problematic, and for this reason I have made this feature a new option (shadeSourcesContent) as opposed to making it the default behavior when createSourcesJar=true. It looks like there are a couple of java libraries that attempt to do encoding detection, if something like this is required to get this patch committed I can investigate this further, or if anyone has other ideas how to handle this please let me know. Thanks. -- 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-112) New property to enable shading the java text inside the sources artifact (not just shading the java source file locations)
[ https://jira.codehaus.org/browse/MSHADE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trask Stalnaker updated MSHADE-112: --- Attachment: shade-sources-content-v2.patch Combined the many parameters of shade() into a single ShadeRequest arg. Also re-worked a part of the patch to remove the sort of unnecessary param that I had added previously (packageRelocations, which was sort of a duplicate of relocations), instead adding a method to Relocator (applyToSourceContent()). This seems cleaner to me, but I look forward to further review. Thanks Olivier. New property to enable shading the java text inside the sources artifact (not just shading the java source file locations) -- Key: MSHADE-112 URL: https://jira.codehaus.org/browse/MSHADE-112 Project: Maven 2.x Shade Plugin Issue Type: New Feature Affects Versions: 1.6 Reporter: Trask Stalnaker Attachments: shade-sources-content.patch, shade-sources-content-v2.patch The existing createSourcesJar property shades the source file locations, but it doesn't shade their content. This makes debugging (when using a shaded artifact) a little painful (at least in Eclipse) since the source files that Eclipse finds don't match up with the package names in the runtime environment. The attached patch performs a rather naive regular expression search/replace throughout the java source files when building the shaded sources artifact. The patch also makes the assumption that the source files are all UTF-8 encoded. This latter issue seems especially problematic, and for this reason I have made this feature a new option (shadeSourcesContent) as opposed to making it the default behavior when createSourcesJar=true. It looks like there are a couple of java libraries that attempt to do encoding detection, if something like this is required to get this patch committed I can investigate this further, or if anyone has other ideas how to handle this please let me know. Thanks. -- 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] (MPIR-237) Unexpected download
[
https://jira.codehaus.org/browse/MPIR-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298112#comment-298112
]
jieryn commented on MPIR-237:
-
What's going on with this one? This dramatically slows down site generation..
and seems completely useless.
Unexpected download
---
Key: MPIR-237
URL: https://jira.codehaus.org/browse/MPIR-237
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependency-management
Affects Versions: 2.4
Environment: Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100)
Maven home: D:\apache-maven-3.0.4-RC2\bin\..
Java version: 1.6.0_25, vendor: Sun Microsystems Inc.
Java home: E:\Program Files\Java\jdk1.6.0_25\jre
Default locale: nl_NL, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Robert Scholte
I was kind of surprised to see maven 3.0.5-SNAPSHOT being downloaded. Looks
like a bug to me.
This happend during a {{mvn site}} on the coberturta-maven-plugin rev. 15529
{noformat}
[INFO] Generating Dependency Management report---
maven-project-info-reports-plugin:2.4
[INFO] artifact org.apache.maven:maven-plugin-api: checking for updates from
nexus
Downloading:
http://localhost:8081/nexus/content/groups/public/org/apache/maven/maven-plugin-api/3.0.5-SNAPSHOT/maven-metadata.xml
Downloaded:
http://localhost:8081/nexus/content/groups/public/org/apache/maven/maven-plugin-api/3.0.5-SNAPSHOT/maven-metadata.xml
(782 B at 0.3 KB/sec)
Downloading:
http://localhost:8081/nexus/content/groups/public/org/apache/maven/maven-plugin-api/3.0.5-SNAPSHOT/maven-plugin-api-3.0.5-20111209.224224-4.pom
Downloaded:
http://localhost:8081/nexus/content/groups/public/org/apache/maven/maven-plugin-api/3.0.5-SNAPSHOT/maven-plugin-api-3.0.5-20111209.224224-4.pom
(3 KB at 2.3 KB/sec)
Downloading:
http://localhost:8081/nexus/content/groups/public/org/apache/maven/maven/3.0.5-SNAPSHOT/maven-metadata.xml
Downloaded:
http://localhost:8081/nexus/content/groups/public/org/apache/maven/maven/3.0.5-SNAPSHOT/maven-metadata.xml
(809 B at 0.3 KB/sec)
Downloading:
http://localhost:8081/nexus/content/groups/public/org/apache/maven/maven/3.0.5-SNAPSHOT/maven-3.0.5-20111209.224136-4.pom
Downloaded:
http://localhost:8081/nexus/content/groups/public/org/apache/maven/maven/3.0.5-SNAPSHOT/maven-3.0.5-20111209.224136-4.pom
(22 KB at 7.7 KB/sec)
[INFO] artifact junit:junit: checking for updates from nexus
{noformat}
--
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] (MECLIPSE-721) Improve documentation to explain why Eclipse sometimes does not import projects with correct project names.
Barrie Treloar created MECLIPSE-721: --- Summary: Improve documentation to explain why Eclipse sometimes does not import projects with correct project names. Key: MECLIPSE-721 URL: https://jira.codehaus.org/browse/MECLIPSE-721 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: Core : .project Affects Versions: 2.9 Reporter: Barrie Treloar See MECLIPSE-718 for a more detailed description. Update documentation so that this problem can be addressed by users. -- 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] (MECLIPSE-721) Improve documentation to explain why Eclipse sometimes does not import projects with correct project names.
[ https://jira.codehaus.org/browse/MECLIPSE-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barrie Treloar closed MECLIPSE-721. --- Resolution: Fixed Fix Version/s: 2.10 Assignee: Barrie Treloar updated documentation for FAQ and trouble shooting to link to Eclipse bug and work around needed. Improve documentation to explain why Eclipse sometimes does not import projects with correct project names. --- Key: MECLIPSE-721 URL: https://jira.codehaus.org/browse/MECLIPSE-721 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: Core : .project Affects Versions: 2.9 Reporter: Barrie Treloar Assignee: Barrie Treloar Fix For: 2.10 See MECLIPSE-718 for a more detailed description. Update documentation so that this problem can be addressed by users. -- 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
