[jira] Closed: (MSANDBOX-31) Doxia-book broken by Doxia refactor
[ http://jira.codehaus.org/browse/MSANDBOX-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSANDBOX-31. - Assignee: Lukas Theussl Resolution: Won't Fix Already fixed Doxia-book broken by Doxia refactor --- Key: MSANDBOX-31 URL: http://jira.codehaus.org/browse/MSANDBOX-31 Project: Maven 2.x Sandbox Issue Type: Bug Components: doxia Reporter: Eric Redmond Assignee: Lukas Theussl Attachments: doxia-book.patch Fixed Doxia-Book to match doxia refactor in SNAPSHOT (sandbox) -- 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: (MWAR-62) The comma separated list of tokens doesn't work with the property warSourceExcludes.
[ http://jira.codehaus.org/browse/MWAR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MWAR-62: - Assignee: (was: Maria Odea Ching) The comma separated list of tokens doesn't work with the property warSourceExcludes. -- Key: MWAR-62 URL: http://jira.codehaus.org/browse/MWAR-62 Project: Maven 2.x War Plugin Issue Type: Bug Environment: windows XP Reporter: Alexandre Vivien The comma separated list of tokens doesn't work with the property warSourceExcludes. It doesn't understand it, this property only work with one token. example : This configuration doesn't exclude the file mail_config.propertires.dev and the file mail_config.propertires.prod from the web directory. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration warSourceDirectoryweb/warSourceDirectory warSourceExcludes**/*.dev,**/*.prod/warSourceExcludes /configuration /plugin but the configuration below exclude the file mail_config.propertires.dev plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration warSourceDirectoryweb/warSourceDirectory warSourceExcludes**/*.dev/warSourceExcludes /configuration /plugin -- 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: (MDEPLOY-64) Deploy to locale repository cuts the pom
Deploy to locale repository cuts the pom Key: MDEPLOY-64 URL: http://jira.codehaus.org/browse/MDEPLOY-64 Project: Maven 2.x Deploy Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Martin Ritz Within the release process maven deploy the artifact to my locale repository. The Build is displayed as an successfull build. But my project pom which is delivered to the locale repository is cutted off after some lines (between line 80 and 95 - depends on my project). This happens for alle project i have released yet (3). How can i fix/ avoid this error? -- 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: (CONTINUUM-1429) Initial checkout does not respect 'Use cached scm credentials' setting
[ http://jira.codehaus.org/browse/CONTINUUM-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1429. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1-beta-3 Initial checkout does not respect 'Use cached scm credentials' setting -- Key: CONTINUUM-1429 URL: http://jira.codehaus.org/browse/CONTINUUM-1429 Project: Continuum Issue Type: Bug Components: SCM Affects Versions: 1.1-beta-1 Environment: 1.1-beta-1 (?) Reporter: Wendy Smoak Assignee: Emmanuel Venisse Fix For: 1.1-beta-3 Continuum is supplying credentials when doing the initial checkout when the 'Use cached scm credentials (if available)' checkbox is checked. If that box is checked, Continuum should assume that credentials are cached, and should not pass --username and --password with the svn checkout command. -- 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-3171) performRelease=true breaks install/deploy with multimodule projects
[
http://jira.codehaus.org/browse/MNG-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106637
]
Carsten Behring commented on MNG-3171:
--
I have the same problem by doing a release with the command
mvn release:perform
As a workaround I use:
mvn deploy site site:deploy --no-plugin-updates -DupdateReleaseInfo=true
This does not add the source and javadoc jars to the build, as
-DperformRelease=true does, but I do not need them
Like this my build works.
performRelease=true breaks install/deploy with multimodule projects
---
Key: MNG-3171
URL: http://jira.codehaus.org/browse/MNG-3171
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.7
Reporter: Julien HENRY
Attachments: unTest.zip
Hi,
To build my project, I use:
mvn clean install -DperformRelease=true
In a multimodule project, it doesn't work if all dependencies are not already
in the local repository.
Step to reproduce:
1) create a multimodule project with moduleA and moduleB. moduleA depends on
moduleB.
2) Hit mvn clean install: should work
3) Clean your local repository (remove moduleA and moduleB)
4) Hit mvn clean install -DperformRelease=true:
{quote}
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
[INFO] Unnamed - com.capgemini:moduleB:jar:1.0-SNAPSHOT
[INFO] Unnamed - com.capgemini:moduleA:jar:1.0-SNAPSHOT
[INFO]
[INFO] Building Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory D:\test\unTest\target
[INFO] Deleting directory D:\test\unTest\target\classes
[INFO] Deleting directory D:\test\unTest\target\test-classes
[INFO] Deleting directory D:\test\unTest\target\site
[INFO] [site:attach-descriptor]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-sources}]
[INFO] Preparing javadoc:jar
[INFO]
[INFO] Building Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
[INFO]
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO]
[INFO] Building Unnamed - com.capgemini:moduleB:jar:1.0-SNAPSHOT
[INFO]
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO]
[INFO] Building Unnamed - com.capgemini:moduleA:jar:1.0-SNAPSHOT
[INFO]
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO] snapshot com.capgemini:moduleB:1.0-SNAPSHOT: checking for updates from
illiade-maven-repository-snapshots
Downloading:
http://illiade.sud.capgemini.fr/maven2-snapshots/com/capgemini/moduleB/1.0-SNAPSHOT/moduleB-1.0-SNAPSHOT.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) com.capgemini:moduleB:jar:1.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.capgemini -DartifactId=moduleB \
-Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) com.capgemini:moduleA:jar:1.0-SNAPSHOT
2) com.capgemini:moduleB:jar:1.0-SNAPSHOT
--
1 required artifact is missing.
for artifact:
com.capgemini:moduleA:jar:1.0-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
illiade-maven-repository-snapshots
(http://illiade.sud.capgemini.fr/maven2-snapshots)
[INFO]
[jira] Commented: (CONTINUUM-1432) Continuum doesn't start up with the startup script for x86-64
[ http://jira.codehaus.org/browse/CONTINUUM-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106639 ] Brian Cribbs commented on CONTINUUM-1432: - Resolved by upgrading to Java 5. This issue can be closed. Continuum doesn't start up with the startup script for x86-64 - Key: CONTINUUM-1432 URL: http://jira.codehaus.org/browse/CONTINUUM-1432 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-2 Environment: Fedora Core 6 x64 Reporter: Brian Cribbs Startup script fails silently but this is in the wrapper.log file INFO | jvm 1| 2007/09/05 11:12:11 | WARNING - Unable to load the Wrapper's native library 'libwrapper.so'. INFO | jvm 1| 2007/09/05 11:12:11 | The file is located on the path at the following location but INFO | jvm 1| 2007/09/05 11:12:11 | could not be loaded: INFO | jvm 1| 2007/09/05 11:12:11 | /opt/continuum-1.1-beta-2/bin/linux-x86-64/../../bin/linux-x86-64/libwrapper.so INFO | jvm 1| 2007/09/05 11:12:11 | Please verify that the file is readable by the current user INFO | jvm 1| 2007/09/05 11:12:11 | and that the file has not been corrupted in any way. INFO | jvm 1| 2007/09/05 11:12:11 | One common cause of this problem is running a 32-bit version -- 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: (CONTINUUM-1434) Again: Unable to create schedule with year
Again: Unable to create schedule with year -- Key: CONTINUUM-1434 URL: http://jira.codehaus.org/browse/CONTINUUM-1434 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.0.3 Reporter: Olaf Krische Even when CONTINUUM-494 says, the issue is solved for 1.0.2, it is not for 1.0.3. When adding a cron expression: * * * * * * 2098 i receive the error: [ You must enter a valid cron expression ] Due to: http://www.opensymphony.com/quartz/api/org/quartz/CronExpression.html that expression should be valid. Cheers. -- 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: (CONTINUUM-1432) Continuum doesn't start up with the startup script for x86-64
[ http://jira.codehaus.org/browse/CONTINUUM-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1432. --- Assignee: Emmanuel Venisse Resolution: Won't Fix Continuum doesn't start up with the startup script for x86-64 - Key: CONTINUUM-1432 URL: http://jira.codehaus.org/browse/CONTINUUM-1432 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-2 Environment: Fedora Core 6 x64 Reporter: Brian Cribbs Assignee: Emmanuel Venisse Startup script fails silently but this is in the wrapper.log file INFO | jvm 1| 2007/09/05 11:12:11 | WARNING - Unable to load the Wrapper's native library 'libwrapper.so'. INFO | jvm 1| 2007/09/05 11:12:11 | The file is located on the path at the following location but INFO | jvm 1| 2007/09/05 11:12:11 | could not be loaded: INFO | jvm 1| 2007/09/05 11:12:11 | /opt/continuum-1.1-beta-2/bin/linux-x86-64/../../bin/linux-x86-64/libwrapper.so INFO | jvm 1| 2007/09/05 11:12:11 | Please verify that the file is readable by the current user INFO | jvm 1| 2007/09/05 11:12:11 | and that the file has not been corrupted in any way. INFO | jvm 1| 2007/09/05 11:12:11 | One common cause of this problem is running a 32-bit version -- 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-3193) Unknown phase in plugin execution causes build to stop
Unknown phase in plugin execution causes build to stop
--
Key: MNG-3193
URL: http://jira.codehaus.org/browse/MNG-3193
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.1
Reporter: Stefan Seidel
In Maven 2.0.7 one could disable the execution of a plugin in child projects by
adding an id to the execution in the parent and then setting the execution
phase for this id in the child pom to some non-existent (like none). This
does not work anymore in Maven 2.1-xxx (I'm using the M2 Plugin for Eclipse).
Although it is understandable to validate the given phase, this use case should
prove that either the check should stay as forgiving as in previous maven
versions or that at last an option to disable plugin executions in child POMs
should be provided.
Parent POM:
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
executions
execution
idtest-jar/id
goals
goaltest-jar/goal
/goals
/execution
/executions
/plugin
{code}
Child POM:
{code}
plugin
artifactIdmaven-jar-plugin/artifactId
executions
execution
idtest-jar/id
phasenone/phase
/execution
/executions
/plugin
{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: (CONTINUUM-615) Add maven.scm.starteam.deleteLocal=true to DefaultContinuumScm
[ http://jira.codehaus.org/browse/CONTINUUM-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106654 ] Rick Marry commented on CONTINUUM-615: -- I noticed that if a folder is deleted from starteam (removed from view), the deleteLocal approach will not delete the local copy of it (or it's contents). This seems to be a starteam bug. I ran the stcmd delete-local from the command line and confirmed that it only deletes local artifacts if they are in a starteam, in view folder. renaming a folder is a good way to expose this bug. just posted here in case anyone is wondering why local debris is not always cleaned up. Add maven.scm.starteam.deleteLocal=true to DefaultContinuumScm -- Key: CONTINUUM-615 URL: http://jira.codehaus.org/browse/CONTINUUM-615 Project: Continuum Issue Type: Improvement Affects Versions: 1.0.2 Environment: starteam xp Reporter: Dan Tran Assignee: Emmanuel Venisse Fix For: 1.0.3 Attachments: CONTINUUM-615.patch this property is crucial for starteam operation under Continuum see http://jira.codehaus.org/browse/SCM-67 -- 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: (MANTRUN-62) line.separator property not passed properly to ant
[
http://jira.codehaus.org/browse/MANTRUN-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106663
]
Basil James Whitehouse III commented on MANTRUN-62:
---
This seems similar to my experience. I can't find any documentation or an
issue that precisely captures my issue, but this entry is the closest. Adding
my comment here rather than creating another issue.
I started prototyping delegation to an ant script by writing the ant tasks
inline with the plugins configuration. Once that worked I extracted the ant
code to a separate build.xml and delegated to it using the ant task as
suggested in the plugin documentation: ...it's encouraged to move all your Ant
tasks to a build.xml file and just call it from the POM using Ant's ant/
task..
Wanting to use Maven as the source of configuration I made heavy use of the
Maven properties (project.build.sourceDirectory, project.build.outputDirectory,
etc). The Maven property reference worked fine when I was using the inlined
task but failed once it was extracted to a build.xml file. I was hoping that
the Maven properties would be passed to the ant build transparently, or as long
as the inhertiAll attribute was true. It surprised me that they weren't and
that I'd have to essentially alias each value I needed, causing a lot of extra
work.
Is it possible to correct this behavior? Am I just missing something?
line.separator property not passed properly to ant
--
Key: MANTRUN-62
URL: http://jira.codehaus.org/browse/MANTRUN-62
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Environment: maven 2.0.4
Reporter: Corporate Gadfly
Attachments: build.xml, pom.xml
line.separator does not resolve properly inside an ant task (using
maven-antrun-plugin).
E.g., using the 2 attached files, running
{code}ant{code} produces the following output {code}Buildfile: build.xml
echo:
[echo]
[echo] line.separator: --
[echo] --
[echo] os.name: --Linux--
[echo]
BUILD SUCCESSFUL
Total time: 0 seconds{code}
which is all okay, so far (new line is being shown on the echo line).
However, when using {code}mvn initialize{code}, we get the following output
{code}[INFO] Scanning for projects...
[INFO]
[INFO] Building Maven Echo
[INFO]task-segment: [initialize]
[INFO]
[INFO] [antrun:run {execution: echo-no-properties}]
[INFO] Executing tasks
echo:
[echo]
[echo] line.separator: --${line.separator}--
[echo] os.name: --${os.name}--
[echo]
[INFO] Executed tasks
[INFO] [antrun:run {execution: echo-with-properties}]
[INFO] Executing tasks
echo:
[echo]
[echo] line.separator: -- --
[echo] os.name: --Linux--
[echo]
[INFO] Executed tasks
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Tue Nov 21 15:26:55 EST 2006
[INFO] Final Memory: 3M/508M
[INFO]
{code}
I have two questions:
# Why do I have to specify all the properties one-by-one while calling the
target?
# Why is the output for line.separator not what is expected?
--
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: (MANTRUN-62) line.separator property not passed properly to ant
[
http://jira.codehaus.org/browse/MANTRUN-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106664
]
Basil James Whitehouse III commented on MANTRUN-62:
---
Pardon my ignorance, I missed MANTRUN-40 and MANTRUN-64 which seem to describe
my issue. (Learn to search JIRA istead of using google =)
line.separator property not passed properly to ant
--
Key: MANTRUN-62
URL: http://jira.codehaus.org/browse/MANTRUN-62
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Environment: maven 2.0.4
Reporter: Corporate Gadfly
Attachments: build.xml, pom.xml
line.separator does not resolve properly inside an ant task (using
maven-antrun-plugin).
E.g., using the 2 attached files, running
{code}ant{code} produces the following output {code}Buildfile: build.xml
echo:
[echo]
[echo] line.separator: --
[echo] --
[echo] os.name: --Linux--
[echo]
BUILD SUCCESSFUL
Total time: 0 seconds{code}
which is all okay, so far (new line is being shown on the echo line).
However, when using {code}mvn initialize{code}, we get the following output
{code}[INFO] Scanning for projects...
[INFO]
[INFO] Building Maven Echo
[INFO]task-segment: [initialize]
[INFO]
[INFO] [antrun:run {execution: echo-no-properties}]
[INFO] Executing tasks
echo:
[echo]
[echo] line.separator: --${line.separator}--
[echo] os.name: --${os.name}--
[echo]
[INFO] Executed tasks
[INFO] [antrun:run {execution: echo-with-properties}]
[INFO] Executing tasks
echo:
[echo]
[echo] line.separator: -- --
[echo] os.name: --Linux--
[echo]
[INFO] Executed tasks
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Tue Nov 21 15:26:55 EST 2006
[INFO] Final Memory: 3M/508M
[INFO]
{code}
I have two questions:
# Why do I have to specify all the properties one-by-one while calling the
target?
# Why is the output for line.separator not what is expected?
--
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-3194) logging changes prevent compilation failures from being shown (in the reactor)
logging changes prevent compilation failures from being shown (in the reactor)
--
Key: MNG-3194
URL: http://jira.codehaus.org/browse/MNG-3194
Project: Maven 2
Issue Type: Bug
Components: Errors, Logging
Affects Versions: 2.1-alpha-1
Reporter: Brett Porter
Fix For: 2.1-alpha-1
The Maven build is failing today due to a compilation error, and the output
looks like:
{code}
[java] [INFO] [compiler:testCompile]
[java] [INFO] Compiling 36 source files to
/Users/brett/scm/maven/components/maven-project/target/test-classes
[java] [INFO]
[java] [INFO]
[java] [INFO]
[java] [INFO] Reactor Summary:
[java] [INFO]
[java] [INFO] Apache Maven ..
SUCCESS [19.247s]
[java] [INFO] Maven Build Context ...
SUCCESS [7.503s]
[java] [INFO] Maven Model ...
SUCCESS [8.808s]
[java] [INFO] Maven Local Settings Model
SUCCESS [1.960s]
[java] [INFO] Maven Profile Model ...
SUCCESS [1.031s]
[java] [INFO] Maven Lifecycle Model .
SUCCESS [1.659s]
[java] [INFO] Maven Project Builder .
FAILED [9.732s]
[java] [INFO] Maven Plugin API .. NOT
BUILT
[java] [INFO] Maven Core NOT
BUILT
[java] [INFO] Maven Reporting API ... NOT
BUILT
[java] [INFO] Maven Embedder NOT
BUILT
[java] [INFO]
[java] [INFO] Error for project: Maven Project Builder (during
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile)
[java] [INFO]
[java] [INFO] BUILD ERRORS
[java] [INFO]
[java] [INFO] Total time: 50 seconds
[java] [INFO] Finished at: Fri Sep 07 05:13:55 EST 2007
[java] [INFO] Final Memory: 17M/42M
[java] [INFO]
{code}
The compilation errors are missing before the summary.
I haven't tested this outside the reactor.
--
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-1706) Uploading irclib 1.10
Uploading irclib 1.10 - Key: MAVENUPLOAD-1706 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1706 Project: maven-upload-requests Issue Type: Bug Reporter: Olivier Lamy -- 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: (MANTRUN-51) Can't find plugin dependency in multiproject
[
http://jira.codehaus.org/browse/MANTRUN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106673
]
Patrick Vinograd commented on MANTRUN-51:
-
Just ran into this issue. For those encountering the same problem, Filippos's
suggestion does NOT work. All of my executions have unique id elements and
this behavior still occurs.
Can't find plugin dependency in multiproject
Key: MANTRUN-51
URL: http://jira.codehaus.org/browse/MANTRUN-51
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.0, 1.1
Environment: maven 2.0.4, antrun 1.0 1.1, jdk 1.5.0_06, windows xp
Reporter: Fredrik Vraalsen
I'm using antrun in my project to create an IzPack installation. The plugin
configuration is below.
When maven is run from the top-level project, the ant taskdef fails because
it cannot find the IzPackTask class. However, when I run maven from the
subproject itself, it works fine. Not sure if this is related to
http://jira.codehaus.org/browse/MANTRUN-49. The error message from maven is
at the bottom.
{noformat}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
configuration
tasks
taskdef name=izpack
classname=com.izforge.izpack.ant.IzPackTask/
izpack
input=${project.build.directory}/classes/izPack.xml
output=${project.build.directory}/CorasTool-${coras.version}-installer.jar
basedir=${project.build.directory}/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdizpack/groupId
artifactIdstandalone-compiler/artifactId
version3.8.0/version
/dependency
/dependencies
/plugin
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: taskdef class com.izforge.izpack.ant.IzPackTask cannot be
found
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant
tasks
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
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:585)
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.MojoExecutionException: Error executing
ant tasks
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:77)
at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:72)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
... 16 more
Caused by: taskdef class com.izforge.izpack.ant.IzPackTask
[jira] Updated: (MSITE-211) Can't deploy site using site:deploy due to a ProxyHTTP error
[ http://jira.codehaus.org/browse/MSITE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-211: -- Description: When I execute the site deployment (with version that comes with maven 2.0.5) mvn site:deploy I got an error see log en debug mode below. This used to work correctly with maven version 2.04 (so maybe site plugin version 2.0-beta-4 : [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) 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:324) 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.MojoExecutionException: Error uploading site at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.wagon.authentication.AuthenticationException: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149) ... 18 more Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: proxy error: Forbidden at com.jcraft.jsch.ProxyHTTP.connect(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) ... 20 more [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Wed Feb 21 12:00:41 CET 2007 [INFO] Final Memory: 3M/7M [INFO] was: When I execute the site deployment (with version that comes with maven 2.0.5) mvn site:deploy I got an error see log en debug mode below. This used to work correctly with maven version 2.04 (so maybe site plugin version 2.0-beta-4 : [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at
[jira] Updated: (CONTINUUM-1430) Split forms for environment variables and Ant/Maven/JDK installations
[ http://jira.codehaus.org/browse/CONTINUUM-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1430: Patch Submitted: [Yes] Attachment: CONTINUUM-1430 patch attached. Add a intermediate screen with a choice between adding tool or environment variable. Split forms for environment variables and Ant/Maven/JDK installations - Key: CONTINUUM-1430 URL: http://jira.codehaus.org/browse/CONTINUUM-1430 Project: Continuum Issue Type: Improvement Components: Web - UI Affects Versions: 1.1-beta-1, 1.1-beta-2 Reporter: Wendy Smoak Assignee: Olivier Lamy Fix For: 1.1-beta-3 Attachments: CONTINUUM-1430 As discussed on the dev list: http://www.nabble.com/Splitting-up-the-Installations-form-t4375197.html I think the form for adding a new Installation should be split up into one form for environment variables, and another for the Ant/Maven/JDK installations. The current web UI is confusing, we have a field marked as required when it usually isn't, necessitating a long field label to try to explain the situation. -- 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: (CONTINUUM-1427) Ability to choose the build definition for 'Build all projects'
[ http://jira.codehaus.org/browse/CONTINUUM-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106680 ] Olivier Lamy commented on CONTINUUM-1427: - Ok for the drop down list, but as builddefinition doesn't have a name field which fleld(s) must be displayed in the list ? the id is not very friendly :-) and some fields (like arguments) can be huge Ability to choose the build definition for 'Build all projects' --- Key: CONTINUUM-1427 URL: http://jira.codehaus.org/browse/CONTINUUM-1427 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.1-beta-2 Reporter: George Gastaldi Fix For: 1.1-beta-3 Currently the default build definition is used when the 'Build all projects' button is clicked. It should be possible to choose a different build definition. Show in the 'Group Actions' section, so only group-level build definitions should be shown. Place a drop down list right next to the 'Build all projects' button -- 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: (SCM-341) tag is not required for an scm:tag operation
tag is not required for an scm:tag operation Key: SCM-341 URL: http://jira.codehaus.org/browse/SCM-341 Project: Maven SCM Issue Type: Bug Components: maven-plugin Affects Versions: 1.0 Reporter: Mykel Alvis When performing an scm:tag operation, neither passing the tag parameter to the plugin nor configuring the tag in the pom actually fills in the tag info, resulting in a missing parameter. --- Copied from my original email With maven 2.0.7, a working subversion SCM url and a build plugin as plugin artifactIdmaven-scm-plugin/artifactId configuration tagNametag/tagName /configuration /plugin [EMAIL PROTECTED] MEFoundation-1.0.x]$ mvn scm:tag [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'scm'. WAGON_VERSION: 1.0-beta-2 [INFO] [INFO] Building DSTHS MEFoundation EJB [INFO]task-segment: [scm:tag] (aggregator-style) [INFO] [INFO] [scm:tag] [INFO] Final Tag Name: 'null' [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot run tag command : Embedded error: Exception while executing SCM command. Missing parameter: 'tagName'. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Thu Sep 06 13:27:52 CDT 2007 [INFO] Final Memory: 6M/127M [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] Issue Comment Edited: (MSITE-211) Can't deploy site using site:deploy due to a ProxyHTTP error
[ http://jira.codehaus.org/browse/MSITE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106512 ] Cyrille Le Clerc edited comment on MSITE-211 at 9/6/07 6:12 PM: Here is a proposed MSITE-211.patch patch file that : - get the proxy associated with the repository access protocol : wagonManager.getProxy( repository.getProtocol() ) - check that the reposotory host is not in proxy nonProxyHosts list - SiteDeployMojoTest JUnit test case to test proxy selection Hope this helps, Cyrille was: Here is a proposed patch that : - get the proxy asociated with the repository access protocol : wagonManager.getProxy( repository.getProtocol() ) - check that the reposotory host is not in proxy nonProxyHosts list - SiteDeployMojoTest JUnit test case to test proxy selection Hope this helps, Cyrille Can't deploy site using site:deploy due to a ProxyHTTP error Key: MSITE-211 URL: http://jira.codehaus.org/browse/MSITE-211 Project: Maven 2.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.0-beta-5 Environment: linux ubuntu dapper drake Reporter: Elid OR Priority: Blocker Attachments: MSITE-211.patch When I execute the site deployment (with version that comes with maven 2.0.5) mvn site:deploy I got an error see log en debug mode below. This used to work correctly with maven version 2.04 (so maybe site plugin version 2.0-beta-4 : [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) 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:324) 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.MojoExecutionException: Error uploading site at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.wagon.authentication.AuthenticationException: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149) ... 18 more Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: proxy error: Forbidden at com.jcraft.jsch.ProxyHTTP.connect(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) ... 20 more
[jira] Commented: (MNG-2576) Add option to find root of project tree from subproject and build required deps
[ http://jira.codehaus.org/browse/MNG-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106688 ] Brian Fox commented on MNG-2576: Seems almost exactly what I wrote in this proposal: http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode Add option to find root of project tree from subproject and build required deps --- Key: MNG-2576 URL: http://jira.codehaus.org/browse/MNG-2576 Project: Maven 2 Issue Type: New Feature Components: Command Line, Reactor and workspace Reporter: Kenney Westerhof Priority: Minor Fix For: Reviewed Pending Version Assignment Add a commandline option to enable maven to expand the reactor scope to find projects that are dependencies of the projects currently in the reactor, and add them. Currently only the current project and child projects are included in the reactor search. I'm proposing to add a commandline switch that lets maven check parent directories to find the root of the project tree, and then do a normal reactor scan, only adding projects that would normally not be added if they're needed as dependencies of the projects that would normally be built. Here's a sample project tree: * root ** p1 *** c1 (depends on p2) ** p2 (depends on c2) ** p3 *** c2 And a sample algorithm: - When building c1, the reactor would contain [c1]. - Maven would check p1, then root, etc, using the parent tags (without the versions!) to see if the project is still in the current reactor. - It would then create a second list of projects (reactor2) containing ALL projects, using the newly discovered root: [root, p1, c2, p2]. - remove all projects from reactor2 contained in reactor: reactor2 = [root, p1, p2] - resolve all direct dependencies for all projects in reactor in reactor2 and add them to reactor, taking versions into account: reactor = [p2, c1] - repeat previous step until all projects have their dependencies resolved from reactor 2. first iteration would yield reactor = [c2, p2, c1], next iteration would stop since c1 doesn't have any dependencies present in reactor2. This would ensure that when some local project's sources have changed, they'll be incorporated in the build, regardless of where you build. So you don't have to do a reactor build each time you change more than 1 project, and you don't have to remember which projects you changed and build them in the correct order yourself, manually. -- 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-1694) Build execution order control in fine grained projects.
[ http://jira.codehaus.org/browse/MNG-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106687 ] Brian Fox commented on MNG-1694: This seems to be related to this proposal: http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode Build execution order control in fine grained projects. --- Key: MNG-1694 URL: http://jira.codehaus.org/browse/MNG-1694 Project: Maven 2 Issue Type: Wish Components: Reactor and workspace Reporter: Mark Proctor Fix For: 2.x Currently in multi module projects you can only work in 2 modes. 1) Build everything 2) Build a single module, IF you have built and installed all its dependency modules I would like to be able to work the following way: 1) Build everything 2) Build an individual module, will build all the modules prior to it in the reactor list. 3) Build a module module and all modules after it in the reactor list, will build missing prior modules. Use Case 1) perform checkout and build 2) module fails 3) keep fixing module and running just its unit tests 3) once all its unit tests pass build it and all modules after it in the reactor list. I don't need to build ones prior as they are unnaffected by the changes. In large mutli module projects this will save a LOT of time especially when you are gearing up for deployment and want to check that everything works - currently this is time consuming and repetitive, with much of the repetition uneeded. -- 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-1958) we need a var that always points to the root direcotry in multi module builds
[
http://jira.codehaus.org/browse/MNG-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106686
]
Brian Fox commented on MNG-1958:
Andy, I could probably think of a few handy ones. I know I've wished for this
in the past. Lets say you want to point all your test logs to one place in the
whole build. Or in my case I wanted to use hsqlb and reuse the results but
needed a common location to point them all to.
we need a var that always points to the root direcotry in multi module builds
-
Key: MNG-1958
URL: http://jira.codehaus.org/browse/MNG-1958
Project: Maven 2
Issue Type: Improvement
Components: Reactor and workspace
Reporter: Mark Proctor
Fix For: 2.1
${basedir} always points to the local module. There are cases, when having a
local relative repository, when it would be usefull to have a var that always
pointed to the root project, ${rootdir}.
In such a case you may want to think of having the names ${rootdir}
${moduledir}
--
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-2061) DistributionManagement properties don't get copied in cloned executionProject while lifecycle fork
[ http://jira.codehaus.org/browse/MNG-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2061. - Resolution: Fixed Fix Version/s: (was: 2.0.x) 2.0.8 DistributionManagement properties don't get copied in cloned executionProject while lifecycle fork -- Key: MNG-2061 URL: http://jira.codehaus.org/browse/MNG-2061 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.2 Reporter: Max Feldman Assignee: Brett Porter Fix For: 2.0.8 Attachments: MNG-2061-maven-project.patch Define a new Maven plugin with the goal described like this: /** * @execute phase=deploy * @goal deploy-custom */ When running 'mvn deploy-custom', deploy phase execution fails with 'Class 'org.apache.maven.artifact.repository.ArtifactRepository' cannot be instantiated'. It seems the problem raises from the fact that releaseArtifactRepository/snapshotArtifactRepository don't get copied in the cloned executionProject while lifecycle fork. -- 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-3077) NullPointerException, if MojoExecutionException has no message
[ http://jira.codehaus.org/browse/MNG-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3077: --- Fix Version/s: 2.0.8 NullPointerException, if MojoExecutionException has no message -- Key: MNG-3077 URL: http://jira.codehaus.org/browse/MNG-3077 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: Johannes Konstantinidis Assignee: Brian Fox Fix For: 2.0.8 It seems, that you get a NPE, when a throwable passed to MojoExecutionExceptionDiagnoser.diagose(Throwable error) has no message, which means the message is null. java.lang.NullPointerException at org.apache.maven.usability.MojoExecutionExceptionDiagnoser.diagnose(MojoExecutionExceptionDiagnoser.java:64) at org.apache.maven.usability.diagnostics.ErrorDiagnostics.diagnose(ErrorDiagnostics.java:84) at org.apache.maven.DefaultMaven.logDiagnostics(DefaultMaven.java:727) at org.apache.maven.DefaultMaven.logError(DefaultMaven.java:672) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:131) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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:585) 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) Line 64 -- if ( directCauseMessage != null mee.getMessage().indexOf( directCauseMessage ) 0 ) (Source: Revision 495147) -- 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-3104) can not get results when i use maven eclipse plugins
[ http://jira.codehaus.org/browse/MNG-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106690 ] Brian Fox commented on MNG-3104: This sounds like some maven ide tool not maven. What eclipse plugin are you using? can not get results when i use maven eclipse plugins Key: MNG-3104 URL: http://jira.codehaus.org/browse/MNG-3104 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: robinson wang i use the artifactory as the cach repository, i have defined a Private-internal-repository and a Ibiblio-cache-repository in the artifactory . then i deploy a private jar like 'aaa.jar' to the Private-internal-repository . but when i open the repository search window and type 'aaa' in the query textfield , i can not see any results then i edit the pom.xml and add this : dependency groupIdaaa/groupId artifactIdaaa/artifactId version0.92/version /dependency when i save this file , the maven eclipse plugins can import the aaa.jar automatically. now i try to search 'aaa' in the query textfield again , there is a result. -- 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] Moved: (MRESOURCES-48) Failed to copy full contents from
[
http://jira.codehaus.org/browse/MRESOURCES-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox moved MNG-3129 to MRESOURCES-48:
--
Affects Version/s: (was: 2.0.7)
2.2
Key: MRESOURCES-48 (was: MNG-3129)
Project: Maven 2.x Resources Plugin (was: Maven 2)
Failed to copy full contents from
-
Key: MRESOURCES-48
URL: http://jira.codehaus.org/browse/MRESOURCES-48
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Thomas Hart
Priority: Blocker
Attachments: error.log
Every time i execute a maven i get the message: 'Failed to copy full
contents'. I check the code from the class FileUtils and there is a simle
File#length() compare.
{code}
if( source.length() != destination.length() )
{
final String message = Failed to copy full contents from + source +
to + destination;
throw new IOException( message );
}
{code}
mvn -version
Maven version: 2.0.7
Java version: 1.5.0_04
OS name: windows xp version: 5.1 arch: x86
--
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-3121) goal specified in execution but not found in plugin
[ http://jira.codehaus.org/browse/MNG-3121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3121. -- Resolution: Won't Fix The problem is you are specifying the phase you defined in your execution. The correct way to do this is put the configuration outside the executions block and then execute mvn xml:run goal specified in execution but not found in plugin --- Key: MNG-3121 URL: http://jira.codehaus.org/browse/MNG-3121 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: gvsg Priority: Blocker Hi all; I want to run the XML-MAVEN-Plugin when 'mvn site:run' goal has been executed. Whien doing this I receive the following exception: org.apache.maven.lifecycle.LifecycleExecutionException: 'run' was specified in an execution, but not found in the plugin at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindExecutionToLifecycle(DefaultLifecycleExecutor.java:1342) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1243) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:987) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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:324) 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) Here is a partial example of my pom.xml file build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdxml-maven-plugin/artifactId version1.0-beta-2-patched/version dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdxml-maven-plugin/artifactId version1.0-beta-2-patched/version scopeprovided/scope /dependency /dependencies executions execution idexecution1/id phasesite/phase goals goalrun/goal /goals configuration forceCreationtrue/forceCreation transformationSets transformationSet dirtarget/dir stylesheet./target/site/pmd-report-per-class.xslt/stylesheet fileMappers fileMapper implementation=org.codehaus.plexus.components.io.filemappers.FileExtensionMapper targetExtension.html/targetExtension /fileMapper /fileMappers includes includepmd.xml/include /includes outputDirtarget/site/outputDir /transformationSet /transformationSets /configuration /execution
[jira] Updated: (MNG-1983) Mojo parameters defined in abstract-mojo class not set, when concrete/abstract mojo class in different JARs
[ http://jira.codehaus.org/browse/MNG-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1983: -- Fix Version/s: (was: 2.1) 2.x Mojo parameters defined in abstract-mojo class not set, when concrete/abstract mojo class in different JARs --- Key: MNG-1983 URL: http://jira.codehaus.org/browse/MNG-1983 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.2 Environment: Maven-2.0.2 (also in Maven-2.0.1) Win-XP/Pro - Cygwin $ java -version java version 1.5.0_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) Reporter: Shash Chatterjee Fix For: 2.x Attachments: abstractmojotest.zip Have an abstract mojo class, which extends AbstractMojo. This abstract class defines some mojo parameters with expressions to set default values. Have a concrete class, in the same project (JAR) and package, which simply extends the abstract mojo class. This works fine, in that the parameter values are initialized correctly. Have an identical concrete class, but this time in a different project which defines a Maven dependency on the previous JAR. This time the parameters defined in the abstract class are not initialized correctly. Whether this second concrete mojo is in the same Java package as the abstract class, or not, does not seem to make a difference. I have attached a ZIP file which demonstrates the problem. Included are three very simple Maven modules, all created with mvn archetype:create. The first project, testplugin-one contains an abstract and a concrete Mojo class. The second project, testplugin-two contains just a concrete Mojo class. The third project testplugin-driver contains a POM that invokes the two mojos: the first time the parameters have values, the second time they are null. -- 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-1949) project-level plugin dependencies not handled correctly in multimodule builds
[ http://jira.codehaus.org/browse/MNG-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106694 ] Brett Porter commented on MNG-1949: --- is this still an issue on trunk? project-level plugin dependencies not handled correctly in multimodule builds - Key: MNG-1949 URL: http://jira.codehaus.org/browse/MNG-1949 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.1 Reporter: John Casey Fix For: 2.1 plugin containers are only initialized once per build, which means they may contain incorrect project-introduced dependencies for project Y in a multimodule build (polluted by project X predecessor). We should look at ways of dumping plugin containers with project-specific configurations, or else providing a container overlay to handle project-specific dependencies, etc. NOTE: This is tied into the notions of build extensions, which will have similar consequences on the core container. -- 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-1936) pattern: for mojo parameters which have default values in the POM we need standard usage
[
http://jira.codehaus.org/browse/MNG-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106693
]
Brett Porter commented on MNG-1936:
---
see mailing list for Jason's original proposal - to be included in the wiki
pattern: for mojo parameters which have default values in the POM we need
standard usage
Key: MNG-1936
URL: http://jira.codehaus.org/browse/MNG-1936
Project: Maven 2
Issue Type: Improvement
Components: Design, Patterns Best Practices
Reporter: Jason van Zyl
Fix For: 2.1
For mojo parameters which have default values in the POM but can be overriden
we should have a standard way of doing this:
/**
* Directory containing the generated JAR.
*
* @parameter expression=${outputDirectory}
default-value=${pom.build.outputDirectory}
* @required
*/
private File outputDirectory;
So there is a short name which can be overriden in a POM configuration or the
command line (outputDirectory), but if not specified we'll fall back to the
standard recommended value in the POM. There is some inconsistencies in a lot
of the plug-ins with respect to this.
--
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-1928) ignores pluginRepository in settings.xml, honors in POM
[ http://jira.codehaus.org/browse/MNG-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1928. - Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: 2.1) ignores pluginRepository in settings.xml, honors in POM --- Key: MNG-1928 URL: http://jira.codehaus.org/browse/MNG-1928 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.1 Environment: mvn 2.0.1, jvm 1.5.0_05, OSX 10.4.3 Reporter: Ryan Marsh Assignee: Brett Porter if specified in the POM as a plugin repo, maven can use the team.andromda.org/maven2 repo for finding, downloading, and installing plugins. however, settings.xml ignores plugin repos and only checks central if the plugin has never been downloaded before. for instance. if settings.xml has a pluginRepository entry for team.andromda.org/maven2 then: mvn andromdapp:generate should download the andromdapp plugin from our repo. but it doesn't. only central is checked and it fails to find the plugin. -- 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-3099) Profiles ignored when working with non-projects (such as archetype:create)
[ http://jira.codehaus.org/browse/MNG-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3099: -- Fix Version/s: 2.1 Profiles ignored when working with non-projects (such as archetype:create) -- Key: MNG-3099 URL: http://jira.codehaus.org/browse/MNG-3099 Project: Maven 2 Issue Type: Bug Reporter: Joakim Erdfelt Assignee: John Casey Priority: Blocker Fix For: 2.1 Attachments: MNG-2261-2.patch, MNG-2261.patch Several conditions have to be met to show this bug. 1) Be in an environment that does not have access to repo1.maven.org, (such as a corporate environment) 2) Have no content in your local repository (a fresh install of maven 2.0.4) 3) Attempt to use a plugin that has no project requirement (such as archetype:create) The plugin fails because access to repo1.maven.org cannot be accessed. Recommended solution: Create a settings.xml profile that changes the location of the 'central' repository to point to an internal resource (such as a maven-proxy installation). settings profiles profile iduse_internal/id repositories repository idcentral/id nameInternal Central Repository/name urlhttp://repo.internal.com/maven2/url releases enabledtrue/enabled /releases snapshots enabledtrue/enabled /snapshots /repository /repositories pluginRepositories pluginRepository idcentral/id nameInternal Central Repository/name urlhttp://repo.internal.com/maven2/url releases enabledtrue/enabled /releases snapshots enabledtrue/enabled /snapshots /pluginRepository /pluginRepositories /profile /profiles activeProfiles activeProfileuse_internal/activeProfile /activeProfiles /settings Try again. Still fails. The reason is that the default behaviour for non-project execution is to use the maven super pom, however there is a bug with that flow that does not allow for the merging of the settings.xml profiles. -- 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] Issue Comment Edited: (MSITE-211) Can't deploy site using site:deploy due to a ProxyHTTP error
[ http://jira.codehaus.org/browse/MSITE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106512 ] Cyrille Le Clerc edited comment on MSITE-211 at 9/6/07 6:36 PM: Here is a proposed MSITE -211.patch patch file that : - get the proxy associated with the repository access protocol : wagonManager.getProxy( repository.getProtocol() ) - check that the reposotory host is not in proxy nonProxyHosts list - SiteDeployMojoTest JUnit test case to test proxy selection Fixing this bug in wagon instead of fixing it in maven-site-deploy would impact the Wagon signature. Wagon currently ave two connect() signatures : one with ProxyInfo as parameter and another without. This implies that the calling the Wagon.connect(Repository, AuthenticationInfo, ProxyInfo) method will force usage of the given ProxyInfo even if the proxyInfo protocol or nonProxyHosts do not match. On the other side, Wagon.connect(Repository, AuthenticationInfo) implies that no proxyInfo will be deduced from settings.xml or POM. Fixing MSTE-211 in Wagon would lead to the removal of these two Wagon.connect() methods to replace them with something like Wagon.connectPossiblyUsingProxy(Repository, AuthenticationInfo). Moreover, fixing MSITE-211 in Wagon would limit possible extensions of maven-site-plugin properties to override global proxy settings by a specific plugin specific proxy configuration. Hope this helps, Cyrille was: Here is a proposed MSITE-211.patch patch file that : - get the proxy associated with the repository access protocol : wagonManager.getProxy( repository.getProtocol() ) - check that the reposotory host is not in proxy nonProxyHosts list - SiteDeployMojoTest JUnit test case to test proxy selection Hope this helps, Cyrille Can't deploy site using site:deploy due to a ProxyHTTP error Key: MSITE-211 URL: http://jira.codehaus.org/browse/MSITE-211 Project: Maven 2.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.0-beta-5 Environment: linux ubuntu dapper drake Reporter: Elid OR Priority: Blocker Attachments: MSITE-211.patch When I execute the site deployment (with version that comes with maven 2.0.5) mvn site:deploy I got an error see log en debug mode below. This used to work correctly with maven version 2.04 (so maybe site plugin version 2.0-beta-4 : [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) 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:324) 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.MojoExecutionException: Error uploading site at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) at
