[jira] (MTOOLCHAINS-5) Look for toolchains.xml in some central place
[
https://jira.codehaus.org/browse/MTOOLCHAINS-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327701#comment-327701
]
Jörg Sesterhenn commented on MTOOLCHAINS-5:
---
I second this proposal. I'd expect this configuration to be handled in the same
way as settings.xml, or just to be part of the settings.xml since this is just
another environment setting.
Look for toolchains.xml in some central place
-
Key: MTOOLCHAINS-5
URL: https://jira.codehaus.org/browse/MTOOLCHAINS-5
Project: Maven 2.x Toolchains Plugin
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Göran Uddeborg
From what I understand, the {{toolchains.xml}} file is _only_ looked for in
{{$\{user.home\}/.m2}}. This is quite inconvenient if you want to provide a
central configuration for a large development team. I suggest to look for it
in some central place too. {{$M2_HOME/conf}} would seem to be a natural
place, following the model of {{settings.xml}}.
--
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-5487) Missing NOTICE and LICENSE files at top level of SCM trees
[ https://jira.codehaus.org/browse/MNG-5487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327705#comment-327705 ] SebbASF commented on MNG-5487: -- The SCM urls are published beyond the developer community (and are in poms etc) so must contain the NL files in an obvious location. Missing NOTICE and LICENSE files at top level of SCM trees -- Key: MNG-5487 URL: https://jira.codehaus.org/browse/MNG-5487 Project: Maven 2 3 Issue Type: Bug Reporter: SebbASF Priority: Critical There should be a NOTICE and LICENSE file in an obvious place in every published source release. Since the SVN / GIT repos are published, AIUI they should have N L files. I would expect to find N L files alongside the pom.xml files. The only such files I could find were under apache-maven: https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;f=apache-maven;h=b1f7f0b63f3617a55381ccaa2ee25b7050e218fc;hb=master The NOTICE file there is also incorrect; the leading 5 lines should be removed; the NOTICE file MUST start with something like: === Apache Maven Copyright 2001-2013 The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). Note also that the correct phrase is developed at - *not* developed by - the distinction is important. See: http://www.apache.org/legal/src-headers.html#notice-text -- 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-5487) Missing NOTICE and LICENSE files at top level of SCM trees
[ https://jira.codehaus.org/browse/MNG-5487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SebbASF reopened MNG-5487: -- Missing NOTICE and LICENSE files at top level of SCM trees -- Key: MNG-5487 URL: https://jira.codehaus.org/browse/MNG-5487 Project: Maven 2 3 Issue Type: Bug Reporter: SebbASF Priority: Critical There should be a NOTICE and LICENSE file in an obvious place in every published source release. Since the SVN / GIT repos are published, AIUI they should have N L files. I would expect to find N L files alongside the pom.xml files. The only such files I could find were under apache-maven: https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;f=apache-maven;h=b1f7f0b63f3617a55381ccaa2ee25b7050e218fc;hb=master The NOTICE file there is also incorrect; the leading 5 lines should be removed; the NOTICE file MUST start with something like: === Apache Maven Copyright 2001-2013 The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). Note also that the correct phrase is developed at - *not* developed by - the distinction is important. See: http://www.apache.org/legal/src-headers.html#notice-text -- 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-tabpanelfocusedCommentId=327706#comment-327706
]
Lennart Jorelid commented on MSITE-669:
---
With the release of m-s-p 3.1, this issue can be regarded as partially closed.
m-s-p 3.1 provides the means to handle this problem, but not the information
about *how* this should be done (i.e. what steps should be done to acquire a
working multisite staged site).
This is particularly nasty since the steps to a fully functional staged
multisite (using both site:stage and site:stage-deploy) are far from trivial or
self-evident, IMHO. There were many partial pitfalls encountered on the way to
a smoothly functioning site.
I will supply a documentation patch, which is fairly detailed and -
unfortunately - rather big.
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_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}
modules
module../../validation/validation-api/module
module../../validation/validation-aspect/module
module../parent/module
/modules
{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] (SCM-681) Git blame fails to report line authors on windows with core.autocrlf = true
[ https://jira.codehaus.org/browse/SCM-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327709#comment-327709 ] Jorge Costa commented on SCM-681: - Please see, https://github.com/apache/maven-scm/pull/4 Git blame fails to report line authors on windows with core.autocrlf = true --- Key: SCM-681 URL: https://jira.codehaus.org/browse/SCM-681 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.7 Environment: Windows git configured with core.autocrlf = true Reporter: David Gageot Assignee: Olivier Lamy Fix For: 1.8 Git blame cannot report line authors when each line is modified locally by the autocrlf parameter. It thinks every line is Not Yet Committed. The fix is to use git blame -w instead of plain git blame, to ignore whitespaces. See discussion here: http://stackoverflow.com/questions/4638500/git-blame-showing-no-history -- 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] (MPMD-168) Skip report generation if results are empty
[
https://jira.codehaus.org/browse/MPMD-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MPMD-168:
--
Fix Version/s: 3.1
Assignee: Olivier Lamy
Skip report generation if results are empty
---
Key: MPMD-168
URL: https://jira.codehaus.org/browse/MPMD-168
Project: Maven 2.x PMD Plugin
Issue Type: Bug
Reporter: Michael Osipov
Assignee: Olivier Lamy
Fix For: 3.1
Most report plugin simply skip report generation if there is nothing to
display. This plugin should do the same. A parameter like {{skipIfEmpty}}
should be added with default value {{true}}. The evaluation should happen in
the {{canGenerate}} method.
--
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] (MPMD-168) Skip report generation if results are empty
[
https://jira.codehaus.org/browse/MPMD-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MPMD-168.
-
Resolution: Fixed
Applied.
Thanks!
Skip report generation if results are empty
---
Key: MPMD-168
URL: https://jira.codehaus.org/browse/MPMD-168
Project: Maven 2.x PMD Plugin
Issue Type: Bug
Reporter: Michael Osipov
Assignee: Olivier Lamy
Fix For: 3.1
Most report plugin simply skip report generation if there is nothing to
display. This plugin should do the same. A parameter like {{skipIfEmpty}}
should be added with default value {{true}}. The evaluation should happen in
the {{canGenerate}} method.
--
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] (MANTRUN-91) Cannot run javac from tasks
[ https://jira.codehaus.org/browse/MANTRUN-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327716#comment-327716 ] Adrian Wilkins commented on MANTRUN-91: --- I too have just wasted a few hours on this problem, and applied the horrible workaround. What's the design rationale behind mangling the JAVA_HOME variable / classpath / whatever for plugin executions? To me it seems silly to do this - Maven is a build system... why would you want to hobble it's plugins by preventing them from building things (without special measures)? In my opinion this completely violates the principle of least surprise - if I set JAVA_HOME to a JDK, I expect plugins to behave in a way consistent with that, unless I explicitly state otherwise. Cannot run javac from tasks --- Key: MANTRUN-91 URL: https://jira.codehaus.org/browse/MANTRUN-91 Project: Maven 2.x Antrun Plugin Issue Type: Bug Reporter: Thomas Diesler Assignee: Benson Margulies Embedded error: The following error occurred while executing this line: /home/tdiesler/svn/jbossws/stack/native/trunk/modules/testsuite/native-tests/scripts/antrun-wstools.xml:65: Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK -- 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] (WAGON-399) Fix for SFTP on windows machine
Olivier Lamy created WAGON-399: -- Summary: Fix for SFTP on windows machine Key: WAGON-399 URL: https://jira.codehaus.org/browse/WAGON-399 Project: Maven Wagon Issue Type: Bug Components: wagon-ftp Affects Versions: 2.4 Reporter: Olivier Lamy I encountered a problem with SFTP on windows (using bitvise ssh server). The following change has resolved the problem for me. -- 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] (WAGON-399) Fix for SFTP on windows machine
[ https://jira.codehaus.org/browse/WAGON-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated WAGON-399: --- Description: I encountered a problem with SFTP on windows (using bitvise ssh server). The following change has resolved the problem for me. https://github.com/apache/maven-wagon/pull/2 was: I encountered a problem with SFTP on windows (using bitvise ssh server). The following change has resolved the problem for me. Fix for SFTP on windows machine --- Key: WAGON-399 URL: https://jira.codehaus.org/browse/WAGON-399 Project: Maven Wagon Issue Type: Bug Components: wagon-ftp Affects Versions: 2.4 Reporter: Olivier Lamy I encountered a problem with SFTP on windows (using bitvise ssh server). The following change has resolved the problem for me. https://github.com/apache/maven-wagon/pull/2 -- 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] (WAGON-399) Fix for SFTP on windows machine
[ https://jira.codehaus.org/browse/WAGON-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed WAGON-399. -- Resolution: Fixed Fix Version/s: 2.5 Assignee: Olivier Lamy Fix for SFTP on windows machine --- Key: WAGON-399 URL: https://jira.codehaus.org/browse/WAGON-399 Project: Maven Wagon Issue Type: Bug Components: wagon-ftp Affects Versions: 2.4 Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 2.5 I encountered a problem with SFTP on windows (using bitvise ssh server). The following change has resolved the problem for me. https://github.com/apache/maven-wagon/pull/2 -- 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] (WAGON-399) Fix for SFTP on windows machine
[ https://jira.codehaus.org/browse/WAGON-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327718#comment-327718 ] Olivier Lamy commented on WAGON-399: fixed. Fix for SFTP on windows machine --- Key: WAGON-399 URL: https://jira.codehaus.org/browse/WAGON-399 Project: Maven Wagon Issue Type: Bug Components: wagon-ftp Affects Versions: 2.4 Reporter: Olivier Lamy I encountered a problem with SFTP on windows (using bitvise ssh server). The following change has resolved the problem for me. https://github.com/apache/maven-wagon/pull/2 -- 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-142) custom manifest and war overlays
[ https://jira.codehaus.org/browse/MWAR-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MWAR-142. - Resolution: Not A Bug Assignee: Olivier Lamy close issue as requested by reporter. custom manifest and war overlays Key: MWAR-142 URL: https://jira.codehaus.org/browse/MWAR-142 Project: Maven 2.x WAR Plugin Issue Type: Improvement Components: manifest, overlay Affects Versions: 2.0.2, 2.1-alpha-1 Environment: maven 2.0.7 Reporter: Rémy Sanlaville Assignee: Olivier Lamy Attachments: custom-manifest-war-overlays.zip Despite the fact that it is possible to generate a custom manifest as described in [war-manifest-guide|http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html], it's not good enough when using the overlays mechanism. The maven-war-plugin can't take into account an existing manifest. It can just generate a new one with the corresponding configuration in the pom. However, if you use the overlays mechanism, you rather want to keep the manifest from your common war (see custom-manifest-war-overlays.zip in attachment). -- 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-29) includes/excludes should extend to generated stuff
[ https://jira.codehaus.org/browse/MWAR-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MWAR-29. Resolution: Won't Fix Assignee: Olivier Lamy not anymore an issue includes/excludes should extend to generated stuff -- Key: MWAR-29 URL: https://jira.codehaus.org/browse/MWAR-29 Project: Maven 2.x WAR Plugin Issue Type: Improvement Reporter: Felipe Leme Assignee: Olivier Lamy I'm working on a war project where we decided to include some mock classes on the source directory, so the developers can work on the Structs actions without worrying with the backend. As such, these classes should not be included in the 'official' war file (they are only used by the jetty6 plugin). So, I tried to use the excludes configuration to exclude then but failed to do so. After struggling for a while with the -X option, google and jira, I realized such configuration only excludes files from the warSource directory (i.e, the stuff that goes in the web application root, like JSP pages). I've seen some bug entries regarding filtering resources and the includes/excludes not working a while ago, but I believe those are other issues... -- 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] (MDEP-422) Support version ranges in get
stanislav bashkirtsev created MDEP-422:
--
Summary: Support version ranges in get
Key: MDEP-422
URL: https://jira.codehaus.org/browse/MDEP-422
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Components: get
Affects Versions: 2.8
Reporter: stanislav bashkirtsev
{code}mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get
-DgroupId=some.group.id -DartifactId=some-artifact -Dversion=[8.2.0,8.2.9)
-Dpackaging=zip{code}*Expected Result*: the latest artifact between 8.2.0 and
8.2.8 should be downloaded.
--
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-4996) Maven3 parallel build fails occasionally for classpath problems.
[
https://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327724#comment-327724
]
Dimitri BAELI commented on MNG-4996:
Sorry for the late response, thank you for your try but it's still failing
occasionnaly, even with old version of the compiler.
After merging your proposal on the sample build it failed also (but passed
as pull request)... strange but sad.
Dimitri
Maven3 parallel build fails occasionally for classpath problems.
Key: MNG-4996
URL: https://jira.codehaus.org/browse/MNG-4996
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.0.1
Environment: maven 3.0.1, maven 3.0
Reporter: Kari J. Niemi
Assignee: Kristian Rosenvold
In a multimodule (120 modules) maven build, the compiler plug-in would seem
to fail in creating a correct class-path every now and then.
Instead of this entry in maven -X logs for a single module build:
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
configurator --
..
[DEBUG] (f) classpathElements =
[/home/karniemi/mymodulepath/target/classes,
/home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
/home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
/home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
/home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
/home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
/home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
every now and then I get this in the parallel build:
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
configurator --
...
[DEBUG] (f) classpathElements =
[/home/karniemi/mymodulepath/target/classes]
And of course the compilation fails because none of the dependencies are
added to the classpath. Sometimes it goes fine in the multi-module build, but
every now and then it fails for this.
In both maven runs I can see that the dependencies are resolved fine:
--
[DEBUG] mymodule:jar:DYNAMIC-SNAPSHOT
[DEBUG]junit:junit:jar:4.7:test
[DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
[DEBUG]
org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
[DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
[DEBUG]
org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
(scope managed from compile) (version managed from 1.1.0)
[DEBUG]
org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
[DEBUG]log4j:log4j:jar:1.2.14:provided
---
The pluginArtifactMap looks like this:
[DEBUG] (s) pluginArtifactMap =
{org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile,
junit:junit=junit:junit:jar:3.8.1:compile,
org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
I'm really using jbi-maven-plugin for most of the modules, and that plugin
binds the other plugins -also the compiler-plugin -to maven life-cycle phases.
--
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-280) Big performance hit in overlay
[
https://jira.codehaus.org/browse/MWAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327740#comment-327740
]
Jeff Black commented on MWAR-280:
-
I tested with 2.4-SNAP, and got comparable build times, but I was unable to
duplicate the original issue with version 2.2. I would be interested to know
if other can still duplicate this issue.
War project with one overlay, goals: clean install:
Maven 3.0.5
- war plugin 2.1.1,build time 54s avg.
- war plugin 2.2, build time 58s avg.
- war plugin 2.4-SNAP, build time 40s avg.
Maven 2.2.1
- war plugin 2.1.1,build time 54s avg.
- war plugin 2.2, build time 54s avg.
- war plugin 2.4-SNAP, build time 52s avg.
Big performance hit in overlay
--
Key: MWAR-280
URL: https://jira.codehaus.org/browse/MWAR-280
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Components: overlay
Affects Versions: 2.2
Reporter: Simone Bordet
Fix For: 2.4
Here is the output of version 2.1.1 of the maven war plugin when overlaying
org.cometd.javascript:cometd-javascript-dojo:
{code}
[INFO] --- maven-war-plugin:2.1.1:war (default-war) @ tutorials-skeleton ---
[INFO] Packaging webapp
[INFO] Assembling webapp [tutorials-skeleton] in
[/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
[INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [7026 msecs]
{code}
Note how it took 7026 ms.
This is the output for the same project, but using version 2.2 of the maven
war plugin:
{code}
[INFO] --- maven-war-plugin:2.2:war (default-war) @ tutorials-skeleton ---
[INFO] Packaging webapp
[INFO] Assembling webapp [tutorials-skeleton] in
[/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
[INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [24151 msecs]
{code}
Note how it took 24151 ms, i.e. a 3-4 times performance hit.
--
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-280) Big performance hit in overlay
[
https://jira.codehaus.org/browse/MWAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327741#comment-327741
]
Jeff Black commented on MWAR-280:
-
Same thing when building Simone's project, unable to duplicate the original
version 2.2 issue. Very strange.
- war plugin 2.1.1,build time 2:54 avg.
- war plugin 2.2, build time 2:55 avg.
- war plugin 2.4-SNAP, build time 2:44 avg.
Big performance hit in overlay
--
Key: MWAR-280
URL: https://jira.codehaus.org/browse/MWAR-280
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Components: overlay
Affects Versions: 2.2
Reporter: Simone Bordet
Fix For: 2.4
Here is the output of version 2.1.1 of the maven war plugin when overlaying
org.cometd.javascript:cometd-javascript-dojo:
{code}
[INFO] --- maven-war-plugin:2.1.1:war (default-war) @ tutorials-skeleton ---
[INFO] Packaging webapp
[INFO] Assembling webapp [tutorials-skeleton] in
[/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
[INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [7026 msecs]
{code}
Note how it took 7026 ms.
This is the output for the same project, but using version 2.2 of the maven
war plugin:
{code}
[INFO] --- maven-war-plugin:2.2:war (default-war) @ tutorials-skeleton ---
[INFO] Packaging webapp
[INFO] Assembling webapp [tutorials-skeleton] in
[/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
[INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [24151 msecs]
{code}
Note how it took 24151 ms, i.e. a 3-4 times performance hit.
--
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-256) it's not possible to create classes attachment without classifier
[
https://jira.codehaus.org/browse/MWAR-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MWAR-256.
---
Resolution: Won't Fix
Assignee: Robert Scholte
As said by Stéphane and Dennis: if you want to reuse the classes, it should be
a separate project. If classes and webapp are very close related, make a small
multimodule of it:
{noformat}
acme-project
+ acme-classes
+ acme-webapp
{noformat}
Even though both artifacts have their own extension, they share the same
{{pom.xml}}, which says that the packaging-type is {{war}}. Maven and
maven-plugins _can_ depend on the packaging-type specified in the pom, so you'd
better keep those artifacts apart if you don't accept a classifier.
it's not possible to create classes attachment without classifier
-
Key: MWAR-256
URL: https://jira.codehaus.org/browse/MWAR-256
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Rafal Krzewski
Assignee: Robert Scholte
I would like to package classes in my war-packaged project into a jar, but I
don't want to use default 'classes' classifier assigned by the plugin. The
generated artifacts have distinct packaging types, so there is no conflict
and the classifier provides no useful additional information. Using the
following configuration:
{quote}
{{configuration}}
{{classesClassifier/}}
{{/configuration}}
{quote}
Results in classes classifier being used anyway. If I understand the
behavior correctly Plexus assigns the variable it's default value, when
presented an empty input. I don't think this can be fixed in way that is both
clean and backward compatible. Either the default value will change, which
would break existing builds that don't specify plugin version explicitly, or
some clunky additional parameter like
{{useClassesClassifierfalse/useClassesClassifier}}, or magic value like
{{classesClassifierNONE/classesClassifier}} need to be introduced.
--
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-255) Negative time
[
https://jira.codehaus.org/browse/MWAR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MWAR-255:
Description:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project
library: Execution default-war of goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Negative time -
[Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project
library: Execution default-war of goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Negative time
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed:
Negative time
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.IllegalArgumentException: Negative time
at java.io.File.setLastModified(File.java:1258)
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:295)
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask$1.registered(AbstractWarPackagingTask.java:150)
at
org.apache.maven.plugin.war.util.WebappStructure.registerFile(WebappStructure.java:211)
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:145)
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFiles(AbstractWarPackagingTask.java:103)
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFiles(AbstractWarPackagingTask.java:125)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handeWebAppSourceDirectory(WarProjectPackagingTask.java:168)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:93)
at
org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:472)
at
org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:404)
at
org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:197)
at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:159)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
[ERROR]
[ERROR]
{noformat}
This occurs when I have in src/main/webapp/ files with date 1970-01-01 and it's
a rather hard to discover this.
was:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project
library: Execution default-war of goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Negative time -
[Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project
library: Execution
[jira] (MWAR-279) WAR plugin fails during incremental build with JDK7
[
https://jira.codehaus.org/browse/MWAR-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MWAR-279:
Description:
Same error for war-plugin 2.2 and 2.1.1
Appears when running incremental build with jdk 7.
Build from clean works fine.
From the log:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project
xxx-web: Execution default-war of goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args
constructor : Cannot construct org.apache.maven.plugin.war.util.WebappStructure
as it does not have a no-args constructor
[ERROR] Debugging information
[ERROR] message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args
constructor
[ERROR] cause-exception :
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
[ERROR] cause-message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args
constructor
[ERROR] class : org.apache.maven.plugin.war.util.WebappStructure
[ERROR] required-type : org.apache.maven.plugin.war.util.WebappStructure
[ERROR] path: /webapp-structure
[ERROR] ---
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project
skyboxview-system-web: Execution default-war of goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args
constructor : Cannot construct org.apache.maven.plugin.war.util.WebappStructure
as it does not have a no-args constructor
Debugging information
message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args
constructor
cause-exception :
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args
constructor
class : org.apache.maven.plugin.war.util.WebappStructure
required-type : org.apache.maven.plugin.war.util.WebappStructure
path: /webapp-structure
---
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed:
Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does
not have a no-args constructor : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args
constructor
Debugging information
message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args
constructor
cause-exception :
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a no-args
constructor
class : org.apache.maven.plugin.war.util.WebappStructure
required-type : org.apache.maven.plugin.war.util.WebappStructure
path: /webapp-structure
---
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 13 more
Caused
[jira] (MWAR-279) WAR plugin fails during incremental build with JDK7
[
https://jira.codehaus.org/browse/MWAR-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MWAR-279:
Fix Version/s: 2.4
WAR plugin fails during incremental build with JDK7
---
Key: MWAR-279
URL: https://jira.codehaus.org/browse/MWAR-279
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Affects Versions: 2.1.1, 2.2
Environment: Windows7 64bit
maven 3.0.3
jdk-1.7.0_03
Reporter: Liya Katz
Priority: Blocker
Fix For: 2.4
Same error for war-plugin 2.2 and 2.1.1
Appears when running incremental build with jdk 7.
Build from clean works fine.
From the log:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project
xxx-web: Execution default-war of goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
[ERROR] Debugging information
[ERROR] message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
[ERROR] cause-exception :
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
[ERROR] cause-message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
[ERROR] class : org.apache.maven.plugin.war.util.WebappStructure
[ERROR] required-type : org.apache.maven.plugin.war.util.WebappStructure
[ERROR] path: /webapp-structure
[ERROR] ---
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on
project skyboxview-system-web: Execution default-war of goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
Debugging information
message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
cause-exception :
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
class : org.apache.maven.plugin.war.util.WebappStructure
required-type : org.apache.maven.plugin.war.util.WebappStructure
path: /webapp-structure
---
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war
failed: Cannot construct org.apache.maven.plugin.war.util.WebappStructure as
it does not have a no-args constructor : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
Debugging information
message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
cause-exception :
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message : Cannot construct
[jira] (MWAR-279) WAR plugin fails during incremental build with JDK7
[
https://jira.codehaus.org/browse/MWAR-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327753#comment-327753
]
Robert Scholte commented on MWAR-279:
-
maven-archiver has been updated to 2.5. Could someone verify if this is fixed
with the latest SNAPSHOT?
WAR plugin fails during incremental build with JDK7
---
Key: MWAR-279
URL: https://jira.codehaus.org/browse/MWAR-279
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Affects Versions: 2.1.1, 2.2
Environment: Windows7 64bit
maven 3.0.3
jdk-1.7.0_03
Reporter: Liya Katz
Priority: Blocker
Same error for war-plugin 2.2 and 2.1.1
Appears when running incremental build with jdk 7.
Build from clean works fine.
From the log:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project
xxx-web: Execution default-war of goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
[ERROR] Debugging information
[ERROR] message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
[ERROR] cause-exception :
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
[ERROR] cause-message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
[ERROR] class : org.apache.maven.plugin.war.util.WebappStructure
[ERROR] required-type : org.apache.maven.plugin.war.util.WebappStructure
[ERROR] path: /webapp-structure
[ERROR] ---
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on
project skyboxview-system-web: Execution default-war of goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
Debugging information
message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
cause-exception :
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
class : org.apache.maven.plugin.war.util.WebappStructure
required-type : org.apache.maven.plugin.war.util.WebappStructure
path: /webapp-structure
---
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war
failed: Cannot construct org.apache.maven.plugin.war.util.WebappStructure as
it does not have a no-args constructor : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
Debugging information
message : Cannot construct
org.apache.maven.plugin.war.util.WebappStructure as it does not have a
no-args constructor
cause-exception :
[jira] (MNG-5490) Add support for lifecycle activation for profiles
Gregory Baumgardner created MNG-5490:
Summary: Add support for lifecycle activation for profiles
Key: MNG-5490
URL: https://jira.codehaus.org/browse/MNG-5490
Project: Maven 2 3
Issue Type: Improvement
Components: Profiles
Affects Versions: 2.2.1
Environment: Windows 7
Reporter: Gregory Baumgardner
Priority: Minor
I have the following scenario: Initialization step is done in the default
lifecycle initialize phase which sets properties that are used in later build
phases. Unfortunately, the same properties need set in the clean lifecycle
in order to use them in the clean phase. There is no way to easily run the
same execution of plugins without duplication. However, it turns out very easy
to manipulate the phase attribute in the following way:
profile
iddefault-phase/id
activation
property
name!clean-all/name
/property
/activation
properties
init-phaseinitialize/init-phase
/properties
/profile
profile
idclean-phase/id
activation
property
nameclean-all/name
/property
/activation
properties
init-phasepre-clean/init-phase
/properties
/profile
profile
idplugin-config/id
activation
property
namejava.version/name !-- Always on --
/property
/activation
build
plugins
plugin
... !-- Whatever plugin --
executions
execution
idinitialize properties/id
goalsgoal!--The goal --/goal/goals
phase${init-phase}/phase
configuration
!-- The plugin config to use --
/configuration
/execution
/executions
/plugin
...
/plugins
/build
/profile
This will run the initialize step under initialize phase for default lifecycle
and under pre-clean phase for clean lifecycle provided that the config
information falls after the property set in a profile. However, the one issue
I have with this is that it requires you to run Maven with -Dclean-all property
on the command line. It would be even better if there was an activation for
lifecycle that could be set to default, clean, site, etc. Then, the
activation can occur when that specific lifecycle is invoked during the build.
As far as I can tell, there is no other way to determine this information.
--
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] (SUREFIRE-1007) Inconsisten encoding with large standard output
[ https://jira.codehaus.org/browse/SUREFIRE-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327757#comment-327757 ] Yves Langisch commented on SUREFIRE-1007: - How do you interpret the logs? Anything else I can provide to help you to track down the bug? Inconsisten encoding with large standard output --- Key: SUREFIRE-1007 URL: https://jira.codehaus.org/browse/SUREFIRE-1007 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Report Plugin, xml generation Affects Versions: 2.14.1, 2.15 Reporter: Yves Langisch Attachments: ibm-jdk7.log, ora-jdk7.log, surefire-encoding-test.zip, TEST-net.test.surefireencodingtest.EncodingTest.xml When having a lot of standard output in a failing test, the encoding of the resulting surefire-report XML is not consistent. The attached project shows that the encoding in 'TEST-net.test.surefireencodingtest.EncodingTest.xml' in the element system-out suddenly switches from UTF-8 to ISO-8859-1. Any workaround is highly appreciated... -- 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-280) Big performance hit in overlay
[
https://jira.codehaus.org/browse/MWAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MWAR-280.
-
Resolution: Fixed
Assignee: Olivier Lamy
Big performance hit in overlay
--
Key: MWAR-280
URL: https://jira.codehaus.org/browse/MWAR-280
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Components: overlay
Affects Versions: 2.2
Reporter: Simone Bordet
Assignee: Olivier Lamy
Fix For: 2.4
Here is the output of version 2.1.1 of the maven war plugin when overlaying
org.cometd.javascript:cometd-javascript-dojo:
{code}
[INFO] --- maven-war-plugin:2.1.1:war (default-war) @ tutorials-skeleton ---
[INFO] Packaging webapp
[INFO] Assembling webapp [tutorials-skeleton] in
[/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
[INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [7026 msecs]
{code}
Note how it took 7026 ms.
This is the output for the same project, but using version 2.2 of the maven
war plugin:
{code}
[INFO] --- maven-war-plugin:2.2:war (default-war) @ tutorials-skeleton ---
[INFO] Packaging webapp
[INFO] Assembling webapp [tutorials-skeleton] in
[/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
[INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [24151 msecs]
{code}
Note how it took 24151 ms, i.e. a 3-4 times performance hit.
--
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-tabpanelfocusedCommentId=327769#comment-327769
]
Herve Boutemy commented on MSITE-669:
-
I'm ok with the fact that we need better explanations
and these explanations can be triggered when we detect a calculated value
starting with ..
but please don't reopen the issue, prefer open a new issue (with a link to this
one if you want to show how they are related)
this will help track what has gone in each plugin version
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_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}
modules
module../../validation/validation-api/module
module../../validation/validation-aspect/module
module../parent/module
/modules
{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
