[jira] (MWAR-279) WAR plugin fails during incremental build with JDK7
Liya Katz created MWAR-279: -- Summary: 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: [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 -
[jira] (MRESOURCES-155) Add an option to NOT copy resources if the source haven't changed, even though the filtering is ON
Liya Katz created MRESOURCES-155: Summary: Add an option to NOT copy resources if the source haven't changed, even though the filtering is ON Key: MRESOURCES-155 URL: https://jira.codehaus.org/browse/MRESOURCES-155 Project: Maven 2.x Resources Plugin Issue Type: Improvement Components: copy, filtering Reporter: Liya Katz Coping resources during incremental build on big projects affects performance dramatically. It should be an option to stop coping filtered resources when the source is not newer than the target, just like in case of resources that were not filtered. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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:comment-tabpanel&focusedCommentId=282419#comment-282419
]
Liya Katz commented on MWAR-256:
It's quite odd that the jar inside the war does not have any classifier, but if
the same jar is chosen to be attached as an artifact to the project, it has to
have a classifier. There must be some disabling option for this annoying
"feature".
> 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
>
> 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}
> {{}}
> {{}}
> {{}}
> {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
> {{false}}, or magic value like
> {{NONE}} need to be introduced.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-240) archiveClasses and attachClasses in 2.1
[
https://jira.codehaus.org/browse/MWAR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282418#comment-282418
]
Liya Katz commented on MWAR-240:
same problem with maven 3.0.3 and war-plugin 2.1.1
had to downgrade to 2.1-beta-1
> archiveClasses and attachClasses in 2.1
> ---
>
> Key: MWAR-240
> URL: https://jira.codehaus.org/browse/MWAR-240
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_18
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Sergiy Shyrkov
> Attachments: effective-pom.out, mwar-240-test-case.zip
>
>
> There seems to be a regression between 2.1-beta-1 and 2.1 with regard to
> archiveClasses and attachClasses options.
> My use case:
> I have a WAR project with Java classes and I am setting both archiveClasses
> and attachClasses to true.
> With 2.1-beta-1 it was working correctly (mvn clean install) --> I got
> classes packaged into a JAR and placed into WEB-INF/lib and I got that JAR
> artifact deployed to my Maven repository.
> Just upgraded to 2.1 and I got the following with the same use case: I got
> classes packaged into a JAR and placed into WEB-INF/lib (correct) and I got
> an empty JAR artifact (only META-INF/ present) deployed to my Maven
> repository (incorrect).
> Looking at the code in 2.1 of WarMojo (line 230) I am seeing that the classes
> folder (for classes to be included into attached artifact) is empty, because
> it was cleared before due to archiveClasses=true
> Trying to debug both code branches I am seeing a difference between
> 2.1-beta-1 and 2.1 in that the
> getJarArchiver().getDirs() before the call to packager.packageClasses()
> method (line 233/234)
> is empty in the 2.1:
>(java.util.HashMap) {}
> whereas it is not in 2.1-beta-1. It contains a list of all my classes,
> perhaps because the same archiver instance was used to package them into JAR
> for WEB-INF/lib.
> That is why I am getting all my classes in the attached artifact with
> 2.1-beta-1
> I would really need your help in understanding the "correct" behaviour.
> Is this a regression bug for 2.1 or I am completely wrong in my expectations
> about archiveClasses and attachClasses used together?
> Kind regards
> Sergiy Shyrkov
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTRUN-163) Folder antrun with build-main.xml is left under ${project.build.directory} of the module
Folder antrun with build-main.xml is left under ${project.build.directory} of
the module
-
Key: MANTRUN-163
URL: http://jira.codehaus.org/browse/MANTRUN-163
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.6, 1.5
Reporter: Liya Katz
Since 1.5 the folder antrun with build-main.xml is left under
${project.build.directory} of the module, which sometimes cause this folder to
appear inside module's artifact (zip, tar and etc.) and forces to change
configuration to explicitly exclude this folder during archiving - very
annoying!
--
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-3538) Properties inside are not replaced in resulting POM
[
http://jira.codehaus.org/browse/MNG-3538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179139#action_179139
]
Liya Katz commented on MNG-3538:
Same problem with properties inside
> Properties inside are not replaced in resulting POM
>
>
> Key: MNG-3538
> URL: http://jira.codehaus.org/browse/MNG-3538
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9
>Reporter: Ondrej Par
> Fix For: 3.x
>
>
> When I use the following dependency definition, the correct classifier is
> used during build; however, when the project POM file is deployed to the
> repository, it still contains the property name, not the replaced value:
>
> someGroup
> someArtifact
> 3.3.0
> ${myproperty.arch}
>
--
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
