[jira] Commented: (MASSEMBLY-64) jar-with-dependencies has a last-one-copies-wins policy which can fail signed jars
[ http://jira.codehaus.org/browse/MASSEMBLY-64?page=comments#action_61464 ] Napoleon Esmundo C. Ramirez commented on MASSEMBLY-64: -- Oh wait, I take that back. According to http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html the classpath points to somewhere outside the uberjar. Therefore, the jars inside the uberjar can only be seen if located programmatically (not good). When exploded to another directory other than /, however, the packaging of the dependencies would mess up. Thus making both my suggestions void. In this case, exploding everything in the uberjar's / in order to make the uberjar executable will work--only that the security files will prevent the uberjar to execute if signed jars were used. Will removing the security files raise any license issues? > jar-with-dependencies has a last-one-copies-wins policy which can fail signed > jars > -- > > Key: MASSEMBLY-64 > URL: http://jira.codehaus.org/browse/MASSEMBLY-64 > Project: Maven 2.x Assembly Plugin > Type: Bug > Versions: 2.0.1 > Reporter: Geoffrey De Smet > Fix For: 2.1 > > > I've configured the plugins like this: > > org.apache.maven.plugins > maven-jar-plugin > > > > ggg.GGGStandaloneApp > true > > > > > > maven-assembly-plugin > > jar-with-dependencies > > > ggg.GGGStandaloneApp > > > > > BTW: Please document the archive option in the assembly plugin on the > assembly site, it took me a while of trial and error to find it. > However the application doesn't work yet, because: > Exception in thread "main" java.lang.SecurityException: no manifiest section > for signature file entry javax/activation/D > ataContentHandlerFactory.class > at sun.security.util.SignatureFileVerifier.verifySection(Unknown > Source) > at sun.security.util.SignatureFileVerifier.processImpl(Unknown Source) > at sun.security.util.SignatureFileVerifier.process(Unknown Source) > at java.util.jar.JarVerifier.processEntry(Unknown Source) > ... > It looks like it's because the everything in the META-INF directory have a > last-one-copied-wins policy. > Jar-jar would also solve this of course. > PS: I am also using acegisecurity, so I belive you can replicate this issue > by making an assembly of a HelloWorld dependend on acegi & activation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (ARCHETYPE-27) create simpler site archetype
[ http://jira.codehaus.org/browse/ARCHETYPE-27?page=all ] Brett Porter closed ARCHETYPE-27: - Resolution: Fixed > create simpler site archetype > - > > Key: ARCHETYPE-27 > URL: http://jira.codehaus.org/browse/ARCHETYPE-27 > Project: Maven Archetype > Type: New Feature > Components: maven-archetype-plugin > Reporter: Brett Porter > Assignee: Brett Porter > > > the current archetpye sets up dummy content for each type, and a pair of > locales. This is more like an example than an archetype. I'd like a simple > one that just establishes the structure, a default APT document and site.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (ARCHETYPE-28) when creating a new module inside a directory with a pom that has , update
[ http://jira.codehaus.org/browse/ARCHETYPE-28?page=all ] Brett Porter closed ARCHETYPE-28: - Resolution: Fixed Fix Version: 0.7 > when creating a new module inside a directory with a pom that has , > update > - > > Key: ARCHETYPE-28 > URL: http://jira.codehaus.org/browse/ARCHETYPE-28 > Project: Maven Archetype > Type: New Feature > Components: maven-archetype-plugin > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 0.7 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-15) Support includes/excludes
Support includes/excludes - Key: MPLUGIN-15 URL: http://jira.codehaus.org/browse/MPLUGIN-15 Project: Maven 2.x Plugin Plugin Type: Improvement Reporter: Jochen Kuhnle Support advanced scanner configuration (e.g. includes/excludes), just like the compiler plugin does. This allows to restrict the sources the plugin scans, rationale see compiler plugin. This also would help working around QDOX not supporting JDK 1.5 (see [1] and [2]). If this is wanted and somebody tells me the best way, I'll gladly implement it. I looked at the code and noticed a "brute force" approach would mean adding the scanner configuration to the plugin MOJO and propagating it through MojoScanner.populatePluginDescriptor and MojoDescriptorExtractor.execute (changing the intefaces). Does not sound like the best option... The next thing would be to add the configuration to PluginDescriptor (maybe other plugins might want to use this feature, too..). The third option would be to add it to some component manager that is available, but escaped me while looking at the code. Any suggestions? [1] http://jira.codehaus.org/browse/MPLUGIN-1 [2] http://jira.codehaus.org/browse/QDOX-94 -- 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: (MSUREFIRE-79) Docs for systemProperties on website are wrong
[ http://jira.codehaus.org/browse/MSUREFIRE-79?page=comments#action_61475 ]
Jorg Heymans commented on MSUREFIRE-79:
---
wouldn't it be more appropriate to just release a new snapshot instead of
forcing users to build from source ?
> Docs for systemProperties on website are wrong
> --
>
> Key: MSUREFIRE-79
> URL: http://jira.codehaus.org/browse/MSUREFIRE-79
> Project: Maven 2.x Surefire Plugin
> Type: Bug
> Reporter: Jason Dillon
> Priority: Critical
> Fix For: 2.2
>
>
> Site says:
> {code}
>
> ...
>
> ...
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
>
>
> propertyName
> propertyValue
>
>
>
>
> ...
>
> ...
>
> {code}
> Should be:
> {code}
>
> ...
>
> ...
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
>
> propertyValue
>
>
>
> ...
>
> ...
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-79) Docs for systemProperties on website are wrong
[ http://jira.codehaus.org/browse/MSUREFIRE-79?page=comments#action_61478 ]
Dan Tran commented on MSUREFIRE-79:
---
maven core plugins now has new snapshot repo, please check MSUREFIRE-80
> Docs for systemProperties on website are wrong
> --
>
> Key: MSUREFIRE-79
> URL: http://jira.codehaus.org/browse/MSUREFIRE-79
> Project: Maven 2.x Surefire Plugin
> Type: Bug
> Reporter: Jason Dillon
> Priority: Critical
> Fix For: 2.2
>
>
> Site says:
> {code}
>
> ...
>
> ...
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
>
>
> propertyName
> propertyValue
>
>
>
>
> ...
>
> ...
>
> {code}
> Should be:
> {code}
>
> ...
>
> ...
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
>
> propertyValue
>
>
>
> ...
>
> ...
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (SCM-174) Bugfix changelog cmd (take 1) and some general refinements
Bugfix changelog cmd (take 1) and some general refinements -- Key: SCM-174 URL: http://jira.codehaus.org/browse/SCM-174 Project: Maven SCM Type: Bug Components: maven-scm-provider-bazaar Environment: Tested: Tck tests on WinXP and Linux (Gentoo) with Bazaar 0.7 and Continuum with changelog report. Reporter: Torbjørn EIkli Smørgrav BazaarUtils: - refactored execute cmd, added more debugging onfo (bazaar version) ChangLogCmd: - Avoid null and empty filesets in the ChangeSets General: - More precise javadoc TODO: The changelog report is now generating empty reports (but is not failing as before). I plan to fix that in next my next patch (take 2). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-174) Bugfix changelog cmd (take 1) and some general refinements
[ http://jira.codehaus.org/browse/SCM-174?page=all ] Torbjørn EIkli Smørgrav updated SCM-174: Attachment: SCM-174-maven-scm-provider-bazaar.patch > Bugfix changelog cmd (take 1) and some general refinements > -- > > Key: SCM-174 > URL: http://jira.codehaus.org/browse/SCM-174 > Project: Maven SCM > Type: Bug > Components: maven-scm-provider-bazaar > Environment: Tested: Tck tests on WinXP and Linux (Gentoo) with Bazaar 0.7 > and Continuum with changelog report. > Reporter: Torbjørn EIkli Smørgrav > Attachments: SCM-174-maven-scm-provider-bazaar.patch > > > BazaarUtils: > - refactored execute cmd, added more debugging onfo (bazaar version) > ChangLogCmd: > - Avoid null and empty filesets in the ChangeSets > General: > - More precise javadoc > TODO: The changelog report is now generating empty reports (but is not > failing as before). I plan to fix that in next my next patch (take 2). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-175) ChangLogConsumer is not handling log entries from merged branches
ChangLogConsumer is not handling log entries from merged branches - Key: SCM-175 URL: http://jira.codehaus.org/browse/SCM-175 Project: Maven SCM Type: Bug Components: maven-scm-provider-bazaar Reporter: Torbjørn EIkli Smørgrav Priority: Minor The log entries from yourBranch after a "bzr merge yourBranch myBranch" is not handeled, just ignored. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-56) Refactor DirectoryMojo so it can be run either stand-alone or attached
[ http://jira.codehaus.org/browse/MASSEMBLY-56?page=all ] Allan Ramirez updated MASSEMBLY-56: --- Remaining Estimate: 1 hour Original Estimate: 1 hour > Refactor DirectoryMojo so it can be run either stand-alone or attached > -- > > Key: MASSEMBLY-56 > URL: http://jira.codehaus.org/browse/MASSEMBLY-56 > Project: Maven 2.x Assembly Plugin > Type: Improvement > Versions: 2.1 > Reporter: John Didion > Assignee: Allan Ramirez > Fix For: 2.1 > Attachments: MASSEMBLY-56.patch > > Original Estimate: 1 hour > Remaining: 1 hour > > Pretty straight-forward. Just make the directory goal into two goals (like > assembly and attached), one that can be run stand-alone and one that can be > run attached to a lifecycle phase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-56) Refactor DirectoryMojo so it can be run either stand-alone or attached
[ http://jira.codehaus.org/browse/MASSEMBLY-56?page=all ] Allan Ramirez closed MASSEMBLY-56: -- Resolution: Fixed Applied patch with small changes (renamed to directory-inline goal). Thanks > Refactor DirectoryMojo so it can be run either stand-alone or attached > -- > > Key: MASSEMBLY-56 > URL: http://jira.codehaus.org/browse/MASSEMBLY-56 > Project: Maven 2.x Assembly Plugin > Type: Improvement > Versions: 2.1 > Reporter: John Didion > Assignee: Allan Ramirez > Fix For: 2.1 > Attachments: MASSEMBLY-56.patch > > Original Estimate: 1 hour > Remaining: 1 hour > > Pretty straight-forward. Just make the directory goal into two goals (like > assembly and attached), one that can be run stand-alone and one that can be > run attached to a lifecycle phase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2158) Powered by: Spring rich client
[ http://jira.codehaus.org/browse/MNG-2158?page=all ] Carlos Sanchez closed MNG-2158: --- Assign To: Carlos Sanchez Resolution: Fixed Will be available next time the site is regenerated > Powered by: Spring rich client > -- > > Key: MNG-2158 > URL: http://jira.codehaus.org/browse/MNG-2158 > Project: Maven 2 > Type: Wish > Components: Documentation: General > Versions: 2.0.2 > Reporter: Geoffrey De Smet > Assignee: Carlos Sanchez > Priority: Trivial > > > Spring rich client is now powered by Maven 2: > http://spring-rich-c.sourceforge.net/ > The project itself is pretty alpha, but the build process is a nice example. > Especially the petclinic sample shows how to configure a fat client > application in maven 2. > Soon we 'll integrate the webstart plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-20) tag doesn't work during aggregated build.
[ http://jira.codehaus.org/browse/MWAR-20?page=all ] Maria Odea Ching updated MWAR-20: - Attachment: MWAR-20-maven-war-plugin.patch > tag doesn't work during aggregated build. > --- > > Key: MWAR-20 > URL: http://jira.codehaus.org/browse/MWAR-20 > Project: Maven 2.x War Plugin > Type: Bug > Reporter: David Boden > Assignee: Maria Odea Ching > Fix For: 2.0 > Attachments: MWAR-20-maven-war-plugin.patch > > > When building parent aggregator, subprojects tag uses the wrong > base directory (perhaps the base directory of the parent?) to search for the > specified web.xml. > > SalesStation > SSBuild > SNAPSHOT > ../SSBuild/pom.xml > > 4.0.0 > SalesStation > SS > war > SNAPSHOT > SalesStation SS webapp > > > WEB-INF/src > SS > > > org.apache.maven.plugins > maven-war-plugin > > . > target/** > > ../SS/WEB-INF/maven-web.xml > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-20) tag doesn't work during aggregated build.
[ http://jira.codehaus.org/browse/MWAR-20?page=all ] Maria Odea Ching updated MWAR-20: - Attachment: (was: MWAR-20-maven-war-plugin.patch) > tag doesn't work during aggregated build. > --- > > Key: MWAR-20 > URL: http://jira.codehaus.org/browse/MWAR-20 > Project: Maven 2.x War Plugin > Type: Bug > Reporter: David Boden > Assignee: Maria Odea Ching > Fix For: 2.0 > > Time Spent: 3 hours >Remaining: 0 minutes > > When building parent aggregator, subprojects tag uses the wrong > base directory (perhaps the base directory of the parent?) to search for the > specified web.xml. > > SalesStation > SSBuild > SNAPSHOT > ../SSBuild/pom.xml > > 4.0.0 > SalesStation > SS > war > SNAPSHOT > SalesStation SS webapp > > > WEB-INF/src > SS > > > org.apache.maven.plugins > maven-war-plugin > > . > target/** > > ../SS/WEB-INF/maven-web.xml > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-20) tag doesn't work during aggregated build.
[ http://jira.codehaus.org/browse/MWAR-20?page=all ] Maria Odea Ching updated MWAR-20: - Attachment: MWAR-20-maven-war-plugin.patch > tag doesn't work during aggregated build. > --- > > Key: MWAR-20 > URL: http://jira.codehaus.org/browse/MWAR-20 > Project: Maven 2.x War Plugin > Type: Bug > Reporter: David Boden > Assignee: Maria Odea Ching > Fix For: 2.0 > Attachments: MWAR-20-maven-war-plugin.patch > > Time Spent: 3 hours >Remaining: 0 minutes > > When building parent aggregator, subprojects tag uses the wrong > base directory (perhaps the base directory of the parent?) to search for the > specified web.xml. > > SalesStation > SSBuild > SNAPSHOT > ../SSBuild/pom.xml > > 4.0.0 > SalesStation > SS > war > SNAPSHOT > SalesStation SS webapp > > > WEB-INF/src > SS > > > org.apache.maven.plugins > maven-war-plugin > > . > target/** > > ../SS/WEB-INF/maven-web.xml > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-64) jar-with-dependencies has a last-one-copies-wins policy which can fail signed jars
[ http://jira.codehaus.org/browse/MASSEMBLY-64?page=all ] Allan Ramirez updated MASSEMBLY-64: --- Remaining Estimate: 5 hours Original Estimate: 5 hours > jar-with-dependencies has a last-one-copies-wins policy which can fail signed > jars > -- > > Key: MASSEMBLY-64 > URL: http://jira.codehaus.org/browse/MASSEMBLY-64 > Project: Maven 2.x Assembly Plugin > Type: Bug > Versions: 2.0.1 > Reporter: Geoffrey De Smet > Assignee: Allan Ramirez > Fix For: 2.1 > > Original Estimate: 5 hours > Remaining: 5 hours > > I've configured the plugins like this: > > org.apache.maven.plugins > maven-jar-plugin > > > > ggg.GGGStandaloneApp > true > > > > > > maven-assembly-plugin > > jar-with-dependencies > > > ggg.GGGStandaloneApp > > > > > BTW: Please document the archive option in the assembly plugin on the > assembly site, it took me a while of trial and error to find it. > However the application doesn't work yet, because: > Exception in thread "main" java.lang.SecurityException: no manifiest section > for signature file entry javax/activation/D > ataContentHandlerFactory.class > at sun.security.util.SignatureFileVerifier.verifySection(Unknown > Source) > at sun.security.util.SignatureFileVerifier.processImpl(Unknown Source) > at sun.security.util.SignatureFileVerifier.process(Unknown Source) > at java.util.jar.JarVerifier.processEntry(Unknown Source) > ... > It looks like it's because the everything in the META-INF directory have a > last-one-copied-wins policy. > Jar-jar would also solve this of course. > PS: I am also using acegisecurity, so I belive you can replicate this issue > by making an assembly of a HelloWorld dependend on acegi & activation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-29) Possibility to aggrates sources from other modules
[ http://jira.codehaus.org/browse/MASSEMBLY-29?page=all ] Edwin Punzalan updated MASSEMBLY-29: Assign To: Edwin Punzalan Remaining Estimate: 5 hours Original Estimate: 5 hours > Possibility to aggrates sources from other modules > -- > > Key: MASSEMBLY-29 > URL: http://jira.codehaus.org/browse/MASSEMBLY-29 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Alexandre Poitras > Assignee: Edwin Punzalan > Fix For: 2.1 > > Original Estimate: 5 hours > Remaining: 5 hours > > It would be nice if it was possible to aggregate the sources of the other > sibling modules instead of having to archive different jar files containing > the sources. I would like also to be able to do that with Javadoc but I think > it's already in the scope of the javadoc plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MWAR-20) tag doesn't work during aggregated build.
[ http://jira.codehaus.org/browse/MWAR-20?page=all ] Edwin Punzalan closed MWAR-20: -- Resolution: Fixed Patch applied. Thanks. > tag doesn't work during aggregated build. > --- > > Key: MWAR-20 > URL: http://jira.codehaus.org/browse/MWAR-20 > Project: Maven 2.x War Plugin > Type: Bug > Reporter: David Boden > Assignee: Maria Odea Ching > Fix For: 2.0 > Attachments: MWAR-20-maven-war-plugin.patch > > Time Spent: 3 hours >Remaining: 0 minutes > > When building parent aggregator, subprojects tag uses the wrong > base directory (perhaps the base directory of the parent?) to search for the > specified web.xml. > > SalesStation > SSBuild > SNAPSHOT > ../SSBuild/pom.xml > > 4.0.0 > SalesStation > SS > war > SNAPSHOT > SalesStation SS webapp > > > WEB-INF/src > SS > > > org.apache.maven.plugins > maven-war-plugin > > . > target/** > > ../SS/WEB-INF/maven-web.xml > > -- 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: (MASSEMBLY-29) Possibility to aggrates sources from other modules
[ http://jira.codehaus.org/browse/MASSEMBLY-29?page=comments#action_61500 ] Alexandre Poitras commented on MASSEMBLY-29: Yes exactly. > Possibility to aggrates sources from other modules > -- > > Key: MASSEMBLY-29 > URL: http://jira.codehaus.org/browse/MASSEMBLY-29 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Alexandre Poitras > Assignee: Edwin Punzalan > Fix For: 2.1 > > Original Estimate: 5 hours > Remaining: 5 hours > > It would be nice if it was possible to aggregate the sources of the other > sibling modules instead of having to archive different jar files containing > the sources. I would like also to be able to do that with Javadoc but I think > it's already in the scope of the javadoc plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MWAR-26) Do not overwrite target unless source is modified
[ http://jira.codehaus.org/browse/MWAR-26?page=all ] John Tolentino reopened MWAR-26: Maven 2.0.3 uses plexus-utils-1.1.jar in its lib. This overrides the version used in maven-war-plugin (which is version 1.2-SNAPSHOT) for this patch. Please revert until Maven 2 moves to version 1.2 of plexus-utils. > Do not overwrite target unless source is modified > - > > Key: MWAR-26 > URL: http://jira.codehaus.org/browse/MWAR-26 > Project: Maven 2.x War Plugin > Type: Bug > Reporter: Andres March > Assignee: John Tolentino > Fix For: 2.0 > Attachments: MWAR-26-maven-war-plugin-2.diff, MWAR-26-maven-war-plugin.diff > > Time Spent: 3 hours, 40 minutes >Remaining: 0 minutes > > I thought MWAR-8 had fixed my issue but it seems to still exist. Correct me > if I'm wrong but doing incremental builds with this war plugin is not > possible. All the web app sources get overwritten regardless if they have > been modified or not. Incremental build were possible in Maven 1 because it > was ANT based. This version uses plexus FileUtils which overwrites without > regard to if the target file exists or older than the source. Besides the > time issue, overwriting the web.xml each time makes my context reload since > the context runs on tomcat from the target location. I think this is a > reasonable configuration but if there is a better way, let me know. Building > inplace wars is not an option as it dirties the source. > If we are in agreement, I may be able to provide a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-786) Wicket 1.2 beta2 upload request
Wicket 1.2 beta2 upload request --- Key: MAVENUPLOAD-786 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-786 Project: maven-upload-requests Type: Task Reporter: Nathan Hamblen Please upload, with sources. -- 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: (MWAR-26) Do not overwrite target unless source is modified
[ http://jira.codehaus.org/browse/MWAR-26?page=comments#action_61508 ] Edwin Punzalan commented on MWAR-26: This patch has been reverted in SVN. > Do not overwrite target unless source is modified > - > > Key: MWAR-26 > URL: http://jira.codehaus.org/browse/MWAR-26 > Project: Maven 2.x War Plugin > Type: Bug > Reporter: Andres March > Assignee: John Tolentino > Fix For: 2.0 > Attachments: MWAR-26-maven-war-plugin-2.diff, MWAR-26-maven-war-plugin.diff > > Time Spent: 3 hours, 40 minutes >Remaining: 0 minutes > > I thought MWAR-8 had fixed my issue but it seems to still exist. Correct me > if I'm wrong but doing incremental builds with this war plugin is not > possible. All the web app sources get overwritten regardless if they have > been modified or not. Incremental build were possible in Maven 1 because it > was ANT based. This version uses plexus FileUtils which overwrites without > regard to if the target file exists or older than the source. Besides the > time issue, overwriting the web.xml each time makes my context reload since > the context runs on tomcat from the target location. I think this is a > reasonable configuration but if there is a better way, let me know. Building > inplace wars is not an option as it dirties the source. > If we are in agreement, I may be able to provide a patch. -- 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
