[jira] (MDEP-408) Verbose=true on dependency:analyze-only does not output used dependencies
Domen S created MDEP-408: Summary: Verbose=true on dependency:analyze-only does not output used dependencies Key: MDEP-408 URL: https://jira.codehaus.org/browse/MDEP-408 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: analyze Affects Versions: 2.7 Environment: Windows Reporter: Domen S Priority: Minor If I run "mvn dependency:analyze-only -Dverbose=true", the used dependencies are not shown. Line 268 in file "AbstractAnalyzeMojo.java", where the used dependencies enabled by verbose=true ought to be printed, should probably contain: logArtifacts( usedDeclared, true ); instead of logArtifacts( analysis.getUsedDeclaredArtifacts(), false ); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-205) maven-compiler-plugin: incremental compilation broken
[
https://jira.codehaus.org/browse/MCOMPILER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
osman izbat updated MCOMPILER-205:
--
Attachment: hello.tgz
> maven-compiler-plugin: incremental compilation broken
> -
>
> Key: MCOMPILER-205
> URL: https://jira.codehaus.org/browse/MCOMPILER-205
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Lukas Fryc
> Attachments: hello.tgz, no-class-in-java-file.zip
>
>
> When we do {{clean}} -> {{compile}} -> {{compile}}, all Java sources are
> re-compiled for second compilation steps:
> {code}
> [framework]$ mvn clean
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> {code}
> The source code of the affected project:
> https://github.com/richfaces/richfaces5/tree/077dcfc0a46d03d7ba9a7ac3e701a4adfb834c71
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-205) maven-compiler-plugin: incremental compilation broken
[
https://jira.codehaus.org/browse/MCOMPILER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324380#comment-324380
]
osman izbat commented on MCOMPILER-205:
---
I've a similar problem. I've attached hello as a sample project.
When i do mvn clean compile; mvn compile nothing compiles as expected.
But when i change only one java file, plugin compiles all module.
hello$ mvn clean compile
...
hello$ echo " " >> src/main/java/com/mycompany/hello/Hello.java
hello$ mvn -X compile
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
15:51:28+0200)
Maven home: /home/osman/dev/tools/maven
Java version: 1.7.0_21, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.5.0-27-generic", arch: "amd64", family: "unix"
[INFO] Error stacktraces are turned on.
[DEBUG] Reading global settings from
/home/osman/dev/tools/maven/conf/settings.xml
[DEBUG] Reading user settings from /home/osman/.m2/settings.xml
[DEBUG] Using local repository at /home/osman/.m2/repository
[DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10 for
/home/osman/.m2/repository
[INFO] Scanning for projects...
[DEBUG] Extension realms for project com.mycompany:hello:jar:1.0-SNAPSHOT:
(none)
[DEBUG] Looking up lifecyle mappings for packaging jar from
ClassRealm[plexus.core, parent: null]
[DEBUG] === REACTOR BUILD PLAN
[DEBUG] Project: com.mycompany:hello:jar:1.0-SNAPSHOT
[DEBUG] Tasks: [compile]
[DEBUG] Style: Regular
[DEBUG] ===
[INFO]
[INFO]
[INFO] Building hello 1.0-SNAPSHOT
[INFO]
[DEBUG] Lifecycle default -> [validate, initialize, generate-sources,
process-sources, generate-resources, process-resources, compile,
process-classes, generate-test-sources, process-test-sources,
generate-test-resources, process-test-resources, test-compile,
process-test-classes, test, prepare-package, package, pre-integration-test,
integration-test, post-integration-test, verify, install, deploy]
[DEBUG] Lifecycle clean -> [pre-clean, clean, post-clean]
[DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
[DEBUG] Lifecycle default -> [validate, initialize, generate-sources,
process-sources, generate-resources, process-resources, compile,
process-classes, generate-test-sources, process-test-sources,
generate-test-resources, process-test-resources, test-compile,
process-test-classes, test, prepare-package, package, pre-integration-test,
integration-test, post-integration-test, verify, install, deploy]
[DEBUG] Lifecycle clean -> [pre-clean, clean, post-clean]
[DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
[DEBUG] Lifecycle default -> [validate, initialize, generate-sources,
process-sources, generate-resources, process-resources, compile,
process-classes, generate-test-sources, process-test-sources,
generate-test-resources, process-test-resources, test-compile,
process-test-classes, test, prepare-package, package, pre-integration-test,
integration-test, post-integration-test, verify, install, deploy]
[DEBUG] Lifecycle clean -> [pre-clean, clean, post-clean]
[DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
[DEBUG] === PROJECT BUILD PLAN
[DEBUG] Project: com.mycompany:hello:1.0-SNAPSHOT
[DEBUG] Dependencies (collect): []
[DEBUG] Dependencies (resolve): [compile]
[DEBUG] Repositories (dependencies): [central
(http://repo.maven.apache.org/maven2, releases)]
[DEBUG] Repositories (plugins) : [central
(http://repo.maven.apache.org/maven2, releases)]
[DEBUG] ---
[DEBUG] Goal:
org.apache.maven.plugins:maven-resources-plugin:2.5:resources
(default-resources)
[DEBUG] Style: Regular
[DEBUG] Configuration:
${encoding}
${maven.resources.escapeString}
${maven.resources.escapeWindowsPaths}
${maven.resources.includeEmptyDirs}
${maven.resources.overwrite}
${maven.resources.supportMultiLineFiltering}
[DEBUG] ---
[DEBUG] Goal:
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile)
[DEBUG] Style: Regular
[DEBUG] Configuration:
${maven.compiler.compilerId}
${maven.compiler.compilerReuseStrategy}
${maven.compiler.compilerVersion}
${maven.compiler.debug}
${maven.compiler.debuglevel}
UTF-8
${maven.compiler.executable}
${maven.compiler.failOnError}
true
${ma
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324384#comment-324384
]
Lennart Jorelid commented on MSITE-669:
---
Hello again, Herve and Lukas.
Just a friendly reminder that this bug/patch/misconception is a real pain for
at least 3 projects within which I am working.
Neither of these projects can use released versions of the m-s-p to generate
staged documentation.
Basically, this bug boils down to Maven's assumption that POMs always plays two
roles (reactor and parent), whereas there are
many good reasons to let some POMs be only reactor POMs (defining the reactor
build order) and other POMs only parent
POMs (defining mainly plugins, configuration and versions). This is
particularly apparent when your build reactor contains
stereotype projects (such as projects defining entities), having a set of
common needs/properties/build definitions but being
scattered in several places over the build reactor. This concept clashes with
the way that the m-s-p defines its staging and
site generation.
Have you had any chance to do a review of the patch I supplied in february?
Is anyone else involved in reviewing this [concept and patch], in case you
don't have the cycles yourself?
As far as I have been able to tell, no feedback other than the comments on the
MSITE-669 issue have been given. Am I missing something here?
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jorelid
>Assignee: Lukas Theussl
> Attachments: msite_669.patch, msite_669_v2.patch, msite_669_v3.patch,
> msite_669_v4.patch, nazgul_tools_project_dependencies.png,
> nazgul_tools_project_dependencies.png, nazgul_tools_reactor_structure.png,
> sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324384#comment-324384
]
Lennart Jorelid edited comment on MSITE-669 at 4/29/13 4:37 AM:
Hello again, Herve and Lukas.
Just a friendly reminder that this bug/misconception is a real pain for at
least 3 projects within which I am working.
Neither of these projects can use released versions of the m-s-p to generate
staged documentation.
Basically, this issue boils down to Maven's assumption that POMs always plays
two roles (reactor and parent), whereas there are
many good reasons to let some POMs be only reactor POMs (defining the reactor
build order) and other POMs only parent
POMs (defining mainly plugins, configuration and versions). This is
particularly apparent when your build reactor contains
stereotype projects (such as projects defining entities), having a set of
common needs/properties/build definitions but being
scattered in several places over the build reactor. This concept clashes with
the way that the m-s-p defines its staging and
site generation.
Have you had any chance to do a review of the patch I supplied in february?
Is anyone else involved in reviewing this [concept and patch], in case you
don't have the cycles yourself?
As far as I have been able to tell, no feedback other than the comments on the
MSITE-669 issue have been given. Am I missing something here?
was (Author: l...@jguru.se):
Hello again, Herve and Lukas.
Just a friendly reminder that this bug/patch/misconception is a real pain for
at least 3 projects within which I am working.
Neither of these projects can use released versions of the m-s-p to generate
staged documentation.
Basically, this bug boils down to Maven's assumption that POMs always plays two
roles (reactor and parent), whereas there are
many good reasons to let some POMs be only reactor POMs (defining the reactor
build order) and other POMs only parent
POMs (defining mainly plugins, configuration and versions). This is
particularly apparent when your build reactor contains
stereotype projects (such as projects defining entities), having a set of
common needs/properties/build definitions but being
scattered in several places over the build reactor. This concept clashes with
the way that the m-s-p defines its staging and
site generation.
Have you had any chance to do a review of the patch I supplied in february?
Is anyone else involved in reviewing this [concept and patch], in case you
don't have the cycles yourself?
As far as I have been able to tell, no feedback other than the comments on the
MSITE-669 issue have been given. Am I missing something here?
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jorelid
>Assignee: Lukas Theussl
> Attachments: msite_669.patch, msite_669_v2.patch, msite_669_v3.patch,
> msite_669_v4.patch, nazgul_tools_project_dependencies.png,
> nazgul_tools_project_dependencies.png, nazgul_tools_reactor_structure.png,
> sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-650) Include/exclude path format is uncodumented
Tuure Laurinolli created MASSEMBLY-650: -- Summary: Include/exclude path format is uncodumented Key: MASSEMBLY-650 URL: https://jira.codehaus.org/browse/MASSEMBLY-650 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: Tuure Laurinolli Priority: Minor It appears that the format for include/exclude descriptos in fileSets and elsewhere where paths are filtered is undocumented. For example, '*' apparently means "any file directly" under the directory being filtered and '**/*' "any file however deep" under the directory being filtered. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNGSITE-177) Annotation not existing
David Georg Reichelt created MNGSITE-177: Summary: Annotation not existing Key: MNGSITE-177 URL: https://jira.codehaus.org/browse/MNGSITE-177 Project: Maven Project Web Site Issue Type: Bug Environment: Ubuntu 12.10 Reporter: David Georg Reichelt Priority: Minor On http://maven.apache.org/guides/plugin/guide-java-plugin-development.html the Code for a plugin seems to be wrong: at least at my environment, I can't use the annotation @Mojo( name = "sayhi"). Instead (copied from another site) I can specify the name of a new mojo via the annotation /** * Goal which touches a timestamp file. * * @goal touch * * @phase process-sources */ As I copied the dependency, my version of the Mojo-API should be up-to-date, and I can't find a @Mojo annotation in http://maven.apache.org/developers/mojo-api-specification.html anyway, so the problem seems to be the documentation at the site. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5075) MavenProject.getParent throws undocumented ISE
[
https://jira.codehaus.org/browse/MNG-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324402#comment-324402
]
Jesse Glick commented on MNG-5075:
--
[JENKINS-17775|https://issues.jenkins-ci.org/browse/JENKINS-17775] is another
victim.
> MavenProject.getParent throws undocumented ISE
> --
>
> Key: MNG-5075
> URL: https://jira.codehaus.org/browse/MNG-5075
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 3.0.3
>Reporter: Jesse Glick
> Fix For: 3.1.x
>
> Attachments: MavenProject-getParent-ISE.diff
>
>
> http://bugzilla-attachments-197994.netbeans.org/bugzilla/attachment.cgi?id=107899
> shows a stack trace encountered when calling {{MavenProject.getParent}} on a
> project with some errors (probably POMs missing in the local repository).
> This method has no Javadoc comment, so it is hard to know exactly what it is
> permitted/supposed to do, but {{hasParent}} implies that {{null}} is a valid
> return value, and there is no {{throws IllegalStateException}} clause. The
> attached patch brings the behavior in line with that signature. (I think I
> got the {{PlexusTestCase}} infrastructure working with all the required
> wiring but it may be possible to simplify the test case.)
> Cleaner might be to just declare {{getParent}} (and also {{hasParent}}?) to
> throw {{ProjectBuildingException}}, though this would be a
> source-incompatible change. (Only binary-incompatible for clients which are
> already catching {{IllegalStateException}}!)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5075) MavenProject.getParent throws undocumented ISE
[
https://jira.codehaus.org/browse/MNG-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324403#comment-324403
]
Jesse Glick commented on MNG-5075:
--
Pull request: https://github.com/apache/maven/pull/8
> MavenProject.getParent throws undocumented ISE
> --
>
> Key: MNG-5075
> URL: https://jira.codehaus.org/browse/MNG-5075
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 3.0.3
>Reporter: Jesse Glick
> Fix For: 3.1.x
>
> Attachments: MavenProject-getParent-ISE.diff
>
>
> http://bugzilla-attachments-197994.netbeans.org/bugzilla/attachment.cgi?id=107899
> shows a stack trace encountered when calling {{MavenProject.getParent}} on a
> project with some errors (probably POMs missing in the local repository).
> This method has no Javadoc comment, so it is hard to know exactly what it is
> permitted/supposed to do, but {{hasParent}} implies that {{null}} is a valid
> return value, and there is no {{throws IllegalStateException}} clause. The
> attached patch brings the behavior in line with that signature. (I think I
> got the {{PlexusTestCase}} infrastructure working with all the required
> wiring but it may be possible to simplify the test case.)
> Cleaner might be to just declare {{getParent}} (and also {{hasParent}}?) to
> throw {{ProjectBuildingException}}, though this would be a
> source-incompatible change. (Only binary-incompatible for clients which are
> already catching {{IllegalStateException}}!)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2802) Concurrent-safe access to local Maven repository
[ https://jira.codehaus.org/browse/MNG-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324404#comment-324404 ] Marc Guenther commented on MNG-2802: Is this still something we need to do manually, or has this been incorporated into an official maven release? Can someone confirm that this actually works, or does this have other side effects that prevent this from being released? > Concurrent-safe access to local Maven repository > > > Key: MNG-2802 > URL: https://jira.codehaus.org/browse/MNG-2802 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Stepan Roh >Assignee: John Casey > Fix For: Issues to be reviewed for 3.x > > > It seems that access to local Maven repository is not concurrent-safe that is > multiple Mavens running in parallel may damage contents of local Maven > repository. It would be a nice improvement, because sharing of local > repository will lower the need for contacting any other repository. I know > that Maven proxy can be used, but that adds another layer which may > unnecessarily stress the machine it runs on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-717) Perforce Provider Add/Remove functions do not work correctly with ** wildcard.
Benjamin Irwin created SCM-717: -- Summary: Perforce Provider Add/Remove functions do not work correctly with ** wildcard. Key: SCM-717 URL: https://jira.codehaus.org/browse/SCM-717 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-perforce Affects Versions: 1.8.1 Environment: Windows 7 Reporter: Benjamin Irwin I ran the following maven command: mvn -DworkingDirectory=src -Dincludes=**/* scm:add I expected this to add all the files under a given directory (say src) to perforce. The perforce provider finds all the files, but it tries to add them to the "src" directory instead of adding them to the directory where the file actually exists. E.g. suppose src/main/java/sample/Example.java exists, after I run the command above perforce will attempt to add the file Example.java to the src directory. I read through the code, and I'm pretty confident I found the bug. In org.apache.maven.scm.provider.perforce.command.add.PerforceAddCommand.createCommandLine (line 87): this line says file.getName(), which per the java spec will return just the file name, but not the path. I believe if this call were changed to file.getPath(), that it would resolve the problem. While finding this problem, I noticed that PerforceRemoveCommand:90 has exactly the same bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPDF-61) Change Maven prerequisite to 2.2.1
Robert Scholte created MPDF-61: -- Summary: Change Maven prerequisite to 2.2.1 Key: MPDF-61 URL: https://jira.codehaus.org/browse/MPDF-61 Project: Maven 2.x PDF Plugin Issue Type: Task Affects Versions: 1.2 Reporter: Robert Scholte The version of plexus-utils is locked to 1.5.7 in this project, while other dependencies already are depending on a more recent version. Upgrading only the version of plexus-utils causes tests to fail due to plexus-container issues. Upgrade the prerequisite for better maintainability. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPDF-61) Change Maven prerequisite to 2.2.1
[ https://jira.codehaus.org/browse/MPDF-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MPDF-61. -- Resolution: Fixed Fix Version/s: 1.3 Assignee: Robert Scholte Fixed in [r1477262|http://svn.apache.org/r1477262] > Change Maven prerequisite to 2.2.1 > -- > > Key: MPDF-61 > URL: https://jira.codehaus.org/browse/MPDF-61 > Project: Maven 2.x PDF Plugin > Issue Type: Task >Affects Versions: 1.2 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 1.3 > > > The version of plexus-utils is locked to 1.5.7 in this project, while other > dependencies already are depending on a more recent version. > Upgrading only the version of plexus-utils causes tests to fail due to > plexus-container issues. > Upgrade the prerequisite for better maintainability. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPDF-25) Use interface instead of impl due to DOXIASITETOOLS-30
[ https://jira.codehaus.org/browse/MPDF-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MPDF-25: --- Summary: Use interface instead of impl due to DOXIASITETOOLS-30 (was: Use inteface instead of impl due to DOXIASITETOOLS-30) > Use interface instead of impl due to DOXIASITETOOLS-30 > -- > > Key: MPDF-25 > URL: https://jira.codehaus.org/browse/MPDF-25 > Project: Maven 2.x PDF Plugin > Issue Type: Sub-task >Affects Versions: 1.1 >Reporter: Vincent Siveton > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-192) Conflict with workspace resoutlion in m2eclipse
[ https://jira.codehaus.org/browse/MWAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324415#comment-324415 ] Richard Sand commented on MWAR-192: --- Is this issue going to be addressed? Does the patch attached to the case work? > Conflict with workspace resoutlion in m2eclipse > --- > > Key: MWAR-192 > URL: https://jira.codehaus.org/browse/MWAR-192 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 > Environment: windows vista >Reporter: Max Powers > Attachments: maven-war-plugin-2.1.1-patch.jar, maven-war-plugin.patch > > > While building my webapp in eclipse using a launch configuration (goals clean > install) and having 'Resolve Workspace Artifacts' checked, the war plugin > cant assemble the war file properly. Note that disabled 'Resolve Workspace > Artifacts' and the war is assembled fine > [DEBUG] Processing: nexus-lvo-plugin-1.3.3-SNAPSHOT.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to copy file for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > > Embedded error: > C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes > (Access is denied) > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to copy file > for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java: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: Failed to copy > file for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > at > org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:125) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleArtifacts(WarProjectPackagingTask.java:183) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:103) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 16 more > Caused by: java.io.FileNotFoundException: > C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes > (Access is denied) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:106) > at > org.codehaus.plexus.util.io.FileInputStreamFacade.getInputStream(FileInputStreamFacade.java:78) > at > org.codehaus.plexus.util.FileUtils.copyStreamToFile(FileUtils.java:1057) >
[jira] (MWAR-269) war fails to build while using m2e in workspace resolution mode
[ https://jira.codehaus.org/browse/MWAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324416#comment-324416 ] Richard Sand commented on MWAR-269: --- Is this issue a duplicate of MWAR-192? There's a patch thats been contributed to that issue > war fails to build while using m2e in workspace resolution mode > --- > > Key: MWAR-269 > URL: https://jira.codehaus.org/browse/MWAR-269 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement >Affects Versions: 2.1.1 >Reporter: Chris Gamache > Attachments: maven-war-plugin.patch, screenshot-1.png > > > This is my first time for an issue/patch submission. Apologies if I'm doing > it wrong > When building in Eclipse using m2e in workspace resolution mode, the > maven-war-plugin is not prepared for a "dependency" which isn't an assembly > but is instead a folder containing the compiled classes from within the local > workspace. I propose that if the incoming dependency happens to be a > directory that it get packaged up and copied to the destination instead of > blowing up with an exception. > See attached patch for your review... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-489) Please add support for {HTMLcomment}
Jordan Zimmerman created DOXIA-489:
--
Summary: Please add support for {HTMLcomment}
Key: DOXIA-489
URL: https://jira.codehaus.org/browse/DOXIA-489
Project: Maven Doxia
Issue Type: Improvement
Components: Module - Confluence
Reporter: Jordan Zimmerman
It's not currently possible to add a license header or similar comments to
.confluence files. Please add support for {HTMLcomment} or some other way to
add comments to files.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
