[jira] Updated: (MNG-2406) Add @since javadoc tags to plugin parameters
[ http://jira.codehaus.org/browse/MNG-2406?page=all ] Edwin Punzalan updated MNG-2406: Attachment: MNG-2406-maven-plugin-tools-java.patch MNG-2406-maven-plugin-tools-api.patch MNG-2406-maven-plugin-descriptor.patch > Add @since javadoc tags to plugin parameters > > > Key: MNG-2406 > URL: http://jira.codehaus.org/browse/MNG-2406 > Project: Maven 2 > Type: Improvement > Components: Documentation: General > Versions: 2.0.4 > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > Attachments: MNG-2406-maven-plugin-descriptor.patch, > MNG-2406-maven-plugin-tools-api.patch, MNG-2406-maven-plugin-tools-java.patch > > Original Estimate: 4 hours > Remaining: 4 hours > > also, update the plugin report and add a separate column for this tag -- 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: (MWAR-52) WAR plugin does not honor the webXml configuration setting [patch included!]
WAR plugin does not honor the webXml configuration setting [patch included!]
Key: MWAR-52
URL: http://jira.codehaus.org/browse/MWAR-52
Project: Maven 2.x War Plugin
Type: Bug
Versions: 2.0
Reporter: Andreas Schildbach
The WAR plugin does not honor the webXml configuration setting. I think this
comes from web.xml being hardcoded into WarMojo, rather than using the
default-value mechanism for the MOJO attribute.
Here is a patch:
Index:
C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
===
---
C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
(revision 416739)
+++
C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
(working copy)
@@ -102,7 +102,7 @@
/**
* The path to the web.xml file to use.
*
- * @parameter expression="${maven.war.webxml}"
+ * @parameter expression="${maven.war.webxml}"
default-value="WEB-INF/web.xml"
*/
private File webXml;
Index:
C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/WarMojo.java
===
---
C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/WarMojo.java
(revision 416739)
+++
C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/WarMojo.java
(working copy)
@@ -177,7 +177,7 @@
warArchiver.addDirectory( getWebappDirectory() );
-warArchiver.setWebxml( new File( getWebappDirectory(),
"WEB-INF/web.xml" ) );
+warArchiver.setWebxml( getWebXml() );
// create archive
archiver.createArchive( getProject(), archive );
--
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-52) WAR plugin does not honor the webXml configuration setting [patch included!]
[ http://jira.codehaus.org/browse/MWAR-52?page=all ]
Andreas Schildbach updated MWAR-52:
---
Attachment: patch.txt
> WAR plugin does not honor the webXml configuration setting [patch included!]
>
>
> Key: MWAR-52
> URL: http://jira.codehaus.org/browse/MWAR-52
> Project: Maven 2.x War Plugin
> Type: Bug
> Versions: 2.0
> Reporter: Andreas Schildbach
> Attachments: patch.txt
>
>
> The WAR plugin does not honor the webXml configuration setting. I think this
> comes from web.xml being hardcoded into WarMojo, rather than using the
> default-value mechanism for the MOJO attribute.
> Here is a patch:
> Index:
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
> ===
> ---
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
> (revision 416739)
> +++
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
> (working copy)
> @@ -102,7 +102,7 @@
> /**
> * The path to the web.xml file to use.
> *
> - * @parameter expression="${maven.war.webxml}"
> + * @parameter expression="${maven.war.webxml}"
> default-value="WEB-INF/web.xml"
> */
> private File webXml;
>
> Index:
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/WarMojo.java
> ===
> ---
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/WarMojo.java
> (revision 416739)
> +++
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/WarMojo.java
> (working copy)
> @@ -177,7 +177,7 @@
>
> warArchiver.addDirectory( getWebappDirectory() );
>
> -warArchiver.setWebxml( new File( getWebappDirectory(),
> "WEB-INF/web.xml" ) );
> +warArchiver.setWebxml( getWebXml() );
>
> // create archive
> archiver.createArchive( getProject(), archive );
--
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: (MPLUGIN-7) Reformat the autogenerated goal parameters page to improve readibility.
[ http://jira.codehaus.org/browse/MPLUGIN-7?page=comments#action_68222 ] Edwin Punzalan commented on MPLUGIN-7: -- Hervé, How was your work here? any progress? Anyway, the suggestion is to make the page more like the page in maven's project descriptor... where the items are listed on a section and the their details are tabled somewhere below it. And I don't think that you'll need to use the Multipage report for that as they're in one page. I would like to work on this right now, but when I imagine a page with plugin parameters listed and their detail table below, I feel like I only made it uglier. Is that really what we want this page to look like ? > Reformat the autogenerated goal parameters page to improve readibility. > --- > > Key: MPLUGIN-7 > URL: http://jira.codehaus.org/browse/MPLUGIN-7 > Project: Maven 2.x Plugin Plugin > Type: Improvement > Environment: any, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Priority: Minor > > Original Estimate: 8 hours > Remaining: 8 hours > > The goal plugin:xdoc creates a table describing the parameters for a plugin. > An example may be found here: > http://mojo.codehaus.org/xmlbeans-maven-plugin/xmlbeans-mojo.html > In the example, notice that the nowrap on the type, expression and > default-value columns causes the descriptions to be crammed into the right > side of the page. > So rather than having these values in their own columns, position them in > rows below the parameter as is done in the maven-model documentation for the > project descriptor. This way the fields don't compete for space across the > page: > http://maven.apache.org/maven2/maven-model/maven.html > What's more, the inclusion of hyperlinked xml at the top of the page > describing the configuration section of the plugin would benefit the end user > without manual effort of the plugin developer. -- 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: (MWAR-53) WAR plugin does not allow for ignoring the web.xml file
WAR plugin does not allow for ignoring the web.xml file --- Key: MWAR-53 URL: http://jira.codehaus.org/browse/MWAR-53 Project: Maven 2.x War Plugin Type: Bug Versions: 2.0 Reporter: Andreas Schildbach The WAR plugin does not allow for ignoring the web.xml file. I know that a WAR without web.xml does not make any sense in the normal use case, but if I'd like to overlay/join WARs with the WAR plugin (by defining dependencies to other WARs), there can be only one web.xml in the candidates (the WAR plugin does not join web.xml like cargo uberwar does). If I do not have a web.xml in my src/main/webapp folder, the WAR plugin complains. -- 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-48) review plugin documentation
[ http://jira.codehaus.org/browse/MWAR-48?page=all ] Marvin King updated MWAR-48: Attachment: (was: MWAR-48-maven-war-plugin[draft].patch) > review plugin documentation > --- > > Key: MWAR-48 > URL: http://jira.codehaus.org/browse/MWAR-48 > Project: Maven 2.x War Plugin > Type: Task > Versions: 2.0 > Reporter: Marvin King > Assignee: Marvin King > > Time Spent: 15 hours >Remaining: 0 minutes > -- 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-48) review plugin documentation
[ http://jira.codehaus.org/browse/MWAR-48?page=all ] Marvin King updated MWAR-48: Attachment: (was: MWAR-48-maven-war-plugin[draft2].patch) > review plugin documentation > --- > > Key: MWAR-48 > URL: http://jira.codehaus.org/browse/MWAR-48 > Project: Maven 2.x War Plugin > Type: Task > Versions: 2.0 > Reporter: Marvin King > Assignee: Marvin King > > Time Spent: 15 hours >Remaining: 0 minutes > -- 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-48) review plugin documentation
[ http://jira.codehaus.org/browse/MWAR-48?page=comments#action_68223 ] Marvin King commented on MWAR-48: - rewriting... > review plugin documentation > --- > > Key: MWAR-48 > URL: http://jira.codehaus.org/browse/MWAR-48 > Project: Maven 2.x War Plugin > Type: Task > Versions: 2.0 > Reporter: Marvin King > Assignee: Marvin King > > Time Spent: 15 hours >Remaining: 0 minutes > -- 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: (MDEP-25) Option to copy artifact also, along with its deps on (copy/unpack)-dependencies goals
Option to copy artifact also, along with its deps on (copy/unpack)-dependencies goals - Key: MDEP-25 URL: http://jira.codehaus.org/browse/MDEP-25 Project: Maven 2.x Dependency Plugin Type: New Feature Versions: 1.1 Reporter: Anagnostopoulos Kostis Priority: Minor Hi, This worthy plugin can be extended to provide the ability to copy the artifact along with its dependencies by default. That way, when it is used to build a dir with all required jars to run an application, it won't be necessary to use both goals, copy (for the artifact) and copy-dependencies (for its libs). I also want to ask the developers if they would preffer me to contribute a patch for this new boolean param, named "copyArtifact"? anKostis a gmail.com -- 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: (MDEP-26) New goal to write classpath string with all dependencies from local repo
New goal to write classpath string with all dependencies from local repo
Key: MDEP-26
URL: http://jira.codehaus.org/browse/MDEP-26
Project: Maven 2.x Dependency Plugin
Type: New Feature
Versions: 1.1
Reporter: Anagnostopoulos Kostis
Priority: Minor
Hi to all,
'm wondering whether it would be usefull to make a new mojo that when executed
it will output a text file containing the required classpath string to run a
project directly from the local repository.
For instance, the file would contain a classpath string like that :
{noformat}
/home/foo/.m2/repository/org/java/utils/util/util-1.0.jar:/home/foo/.m2/
{noformat}
The result file could then be used like that:
{noformat}
java -cp `cat resultFile` MyClass
{noformat}
The new goal should maybe a sub-class of AbstractFromDependenciesMojo.
In that case, the "useSubDirectoryPerType" and "useSubDirectoryPerArtifact"
params should move to (copy/unpack)-dependencies mojo classes. Anyway, these
params are only used by sub-classes, so, their definition should be propably
inside of those.
Next are the parameters of the mojo i propose:
goal name: dependency:printClasspath
params:
|| Param Name || Type || Description
| outputFile| File | The file to write the classpath string into. |
| overwrite | boolean| If true, re-write file even when nothing has
changed. |
| includeTypes | String | Comma Separated list of Types to include. |
| excludeTypes | String | Comma Separated list of Types to exclude |
| includeProjectArtifact| boolean | see [this
issue|http://jira.codehaus.org/browse/MDEP-25]. |
--
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: (MDEP-25) Option to copy artifact also, along with its deps on (copy/unpack)-dependencies goals
[ http://jira.codehaus.org/browse/MDEP-25?page=comments#action_68224 ]
Anagnostopoulos Kostis commented on MDEP-25:
I would suggest the name for that parameter to be:
{quote}
includeProjectArtifact
{quote}
so that it may be used also by [that
mojo|http://jira.codehaus.org/browse/MDEP-26].
> Option to copy artifact also, along with its deps on
> (copy/unpack)-dependencies goals
> -
>
> Key: MDEP-25
> URL: http://jira.codehaus.org/browse/MDEP-25
> Project: Maven 2.x Dependency Plugin
> Type: New Feature
> Versions: 1.1
> Reporter: Anagnostopoulos Kostis
> Priority: Minor
>
>
> Hi,
> This worthy plugin can be extended to provide the ability to copy the
> artifact along with its dependencies by default. That way, when it is used
> to build a dir with all required jars to run an application, it won't be
> necessary to use both goals, copy (for the artifact) and copy-dependencies
> (for its libs).
> I also want to ask the developers if they would preffer me to contribute a
> patch for this new boolean param, named "copyArtifact"?
> anKostis a gmail.com
--
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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_68227 ] Marek Bieganski commented on MNGECLIPSE-59: --- in patched Maven2Plugin class: Why method: getModel(IFile file) uses: getMavenEmbedder().readProjectWithDependencies( file.getLocation().toFile() ).getModel(); instead of quicker: getMavenEmbedder().readModel(file.getLocation().toFile()); ? > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_68229 ] Marek Bieganski commented on MNGECLIPSE-59: --- Caching artifact key in Maven2Nature instead of parsing model/project every time seems to be good idea too > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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] Erstellt: (CONTINUUM-736) "Edit User" page resets password to the empty password - admin user no longer useable
"Edit User" page resets password to the empty password - admin user no longer useable - Key: CONTINUUM-736 URL: http://jira.codehaus.org/browse/CONTINUUM-736 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.3 Reporter: Bernhard Wellhöfer Priority: Blocker Hello, I changed in the user management section the real name for the continuum admin user. The form where I added the real name also presented the password field. Here the password field was empty - nevertheless the admin user had a password. After entering the new real name for admin and after hitting "submit" the real named changed - but the password also changed. I did not enter anything in the password text field ... It seems that the new password is now blank. This is a serious issue, since the login page does not allow an empty password. So how do I reset the admin password to a known value? Moreover I need a solution how to repair my continuum system. Cheers, Bernd -- 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: (MECLIPSE-32) Allow for forcing the creation of direct project references for dependencies
[ http://jira.codehaus.org/browse/MECLIPSE-32?page=comments#action_68231 ] Barry Kaplan commented on MECLIPSE-32: -- Excellent! Thanks for the heads up Baerrach. > Allow for forcing the creation of direct project references for dependencies > > > Key: MECLIPSE-32 > URL: http://jira.codehaus.org/browse/MECLIPSE-32 > Project: Maven 2.x Eclipse Plugin > Type: Improvement > Versions: 2.0 > Reporter: Barry Kaplan > > > For some thirdparty dependencies, it is common (for me at least) that an > eclipse project for that dependency does/will exist in the workspace. It > would be nice if dependencies in eclipse projects can be forced to use a > direct project reference. eg: > > backport-util-concurrent > backport-util-concurrent > 2.0_01_pd > runtime > > > > > Where can be: > - 'project' -- always create a project reference > - 'jar' -- always create a jar reference as in MNG-955 > - 'auto' -- the behavior prior to MNG-955 -- 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-116) scm:update doesn't iterate through multi-projects
[ http://jira.codehaus.org/browse/SCM-116?page=all ] David Boden updated SCM-116: Attachment: UpdateSubprojectsMojo.java > scm:update doesn't iterate through multi-projects > - > > Key: SCM-116 > URL: http://jira.codehaus.org/browse/SCM-116 > Project: Maven SCM > Type: Bug > Versions: 1.0-beta-2 > Reporter: David Boden > Attachments: UpdateSubprojectsMojo.java > > > scm:update doesn't iterate through projects > > C:\dev\CDSSS>mvn scm:update > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] SalesStation ss_base_shared > [INFO] SalesStation cds_ss_shared > [INFO] SalesStation ss_offering_shared > [INFO] SalesStation ss_base_applet > [INFO] SalesStation sales_station_lib > [INFO] SalesStation ss_offering_lib > [INFO] SalesStation sales_station_applet > [INFO] SalesStation cds_ss_applet > [INFO] SalesStation cds_ss_lib > [INFO] SalesStation SS webapp > [INFO] SalesStation FET_S webapp (contains images) > [INFO] SalesStation CDSSS webapp > [INFO] Searching repository for plugin with prefix: 'scm'. > [INFO] > > [INFO] Building SalesStation CDSSS webapp > [INFO]task-segment: [scm:update] (aggregator-style) > [INFO] > > [INFO] [scm:update] > [INFO] Executing: cvs -f -q update -d > [INFO] Working directory: C:\dev\CDSSS > [WARNING] Unknown status: '? '. > [WARNING] Unknown status: 'M '. > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 5 seconds > [INFO] Finished at: Thu Dec 15 10:38:24 GMT 2005 > [INFO] Final Memory: 3M/7M > [INFO] > > C:\dev\CDSSS> > > Any reason why it doesn't iterate? I'm using Maven 2.0.1 and SCM version > 1.0-beta-2. Thanks. -- 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-1797) Dependency excludes apply to every subsequent dependency, not just the one it is declared under.
[ http://jira.codehaus.org/browse/MNG-1797?page=comments#action_68235 ] Andreas Schildbach commented on MNG-1797: - This issue is very annoying. There are several POMs on ibiblio that are missing provided from their javax.servlet, servlet-api dependency. I tried to fix this by excluding the dependency from the affected dependency path, and including the dependency in my POM (using the correct scope) again. Due to the behaviour of the exclude-mechanism, this approach does not work (and there does not seem to be any alternative, does it?) > Dependency excludes apply to every subsequent dependency, not just the one it > is declared under. > > > Key: MNG-1797 > URL: http://jira.codehaus.org/browse/MNG-1797 > Project: Maven 2 > Type: Bug > Versions: 2.0.1 > Reporter: David Hawkins > Fix For: 2.1 > Attachments: MNG-1797-maven-project.patch, MNG-1797-unit-test.patch, > it1019.tgz, it1020.tgz > > > If you specify ANY dependency excludes, all dependencies after that one in > the pom will also exclude what you specified. They appear to be cumulative > on every dependency in that they bleed over into sibling dependencies. > It's easy to test if you add an exclusion to a random dependency. This > exclusion should exclude a required transitive dependency that is included by > a dependency lower in the list. You will find that the dependency lower in > the list no longer includes the required dependency because it is using the > filter you declared in the other dependency. -- 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: (MPMD-33) do not fail build on PMD failures, include them in pmd report
[ http://jira.codehaus.org/browse/MPMD-33?page=comments#action_68236 ] Doug Douglass commented on MPMD-33: --- pmd-3.7 is now available on central. Please consider this patch for inclusion in the pmd plugin. In thinking about this issue some more, it may be worth providiing a configuration option to fail-on-error (the current behavior, should probably be the default) or include errors in the report. If this is desired, I may be able to provide a new patch in a few days. > do not fail build on PMD failures, include them in pmd report > - > > Key: MPMD-33 > URL: http://jira.codehaus.org/browse/MPMD-33 > Project: Maven 2.x Pmd Plugin > Type: Improvement > Versions: 2.1 > Reporter: Doug Douglass > Priority: Minor > Attachments: include-failures.patch > > > When PMD fails to find or successfuly process a file (e.g., throws NPE during > processFile method) maven-pmd-plugin fails, which fails the site generation > and the build. Instead of trying/having to configure the PMD plugin to either > exclude specific files, or to skip execution altogether (in the case of a > multi-module build), I think it may be better to include the error in the PMD > report, but continue processing files. > Attached is a patch against trunk that modifies the exception handling > behavior to include PMD processing failures in the PMD report. The exceptions > are also logged as WARNINGs. > This patch also updates maven-pmd-plugin to use PMD 3.7. > See http://www.nabble.com/-m2--NPE-with-maven-pmd-plugin-t1718122.html for > some more background on the original problem related to PMD and Jva 5 > Generics. -- 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-1797) Dependency excludes apply to every subsequent dependency, not just the one it is declared under.
[ http://jira.codehaus.org/browse/MNG-1797?page=comments#action_68237 ] Carlos Sanchez commented on MNG-1797: - you don't need to exclude them to chenge the scope, just add it with the right one > Dependency excludes apply to every subsequent dependency, not just the one it > is declared under. > > > Key: MNG-1797 > URL: http://jira.codehaus.org/browse/MNG-1797 > Project: Maven 2 > Type: Bug > Versions: 2.0.1 > Reporter: David Hawkins > Fix For: 2.1 > Attachments: MNG-1797-maven-project.patch, MNG-1797-unit-test.patch, > it1019.tgz, it1020.tgz > > > If you specify ANY dependency excludes, all dependencies after that one in > the pom will also exclude what you specified. They appear to be cumulative > on every dependency in that they bleed over into sibling dependencies. > It's easy to test if you add an exclusion to a random dependency. This > exclusion should exclude a required transitive dependency that is included by > a dependency lower in the list. You will find that the dependency lower in > the list no longer includes the required dependency because it is using the > filter you declared in the other dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2407) New user docs: proxy configuration is not clear to new users
New user docs: proxy configuration is not clear to new users Key: MNG-2407 URL: http://jira.codehaus.org/browse/MNG-2407 Project: Maven 2 Type: Bug Components: Documentation: Guides Versions: 2.0.4 Reporter: Graham Leggett When setting up maven v2.0.4 from the perspective of a new user, I have the need to use a proxy. Looking for proxy in the docs finds this first: http://maven.apache.org/guides/mini/guide-proxies.html This explains how to add proxy information to a "settings file", but does not clearly describe what a "settings file" is. The page does give a clue though, by linking the user here: http://maven.apache.org/maven-settings/settings.html This document contains the full definition of what goes into a settings file, but gives no clue as to where this settings file should live, or what it should be called. At this point I have hit a dead end, as a new maven v2 user, there are no more clues on how to set up a proxy. The docs need to be updated to link to information on where the settings file lives, and what the settings file is called. -- 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: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_68240 ] Brill Pappin commented on SUREFIRE-31: -- I'm needing this ASAP... I've got about 4000 junit 4 tests to automate. Is there anything I can do to speed this along or is there beta code out there someplace that I can use in the interim? > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Type: Improvement > Reporter: John Didion > Attachments: surefire-junit4.zip > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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: (MSITE-152) NPE in plugin site when a mojo has no configuration injection
NPE in plugin site when a mojo has no configuration injection - Key: MSITE-152 URL: http://jira.codehaus.org/browse/MSITE-152 Project: Maven 2.x Site Plugin Type: Bug Versions: 2.0-beta-5 Environment: xp Reporter: Dan Tran Fix For: 2.0 Attachments: site.log When a plugin has a mojo with no configuration injection like the one at https://svn.codehaus.org/mojo/tags/maven-native-1.0-alpha-1/native-maven-plugin/src/main/java/org/codehaus/mojo/natives/plugin/NativeInitializeMojo.java mvn site throws NPE. See attached log -- 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: (MDEP-25) Option to copy artifact also, along with its deps on (copy/unpack)-dependencies goals
[ http://jira.codehaus.org/browse/MDEP-25?page=comments#action_68254 ] Dan Tran commented on MDEP-25: -- you should use assembly:directory instead > Option to copy artifact also, along with its deps on > (copy/unpack)-dependencies goals > - > > Key: MDEP-25 > URL: http://jira.codehaus.org/browse/MDEP-25 > Project: Maven 2.x Dependency Plugin > Type: New Feature > Versions: 1.1 > Reporter: Anagnostopoulos Kostis > Priority: Minor > > > Hi, > This worthy plugin can be extended to provide the ability to copy the > artifact along with its dependencies by default. That way, when it is used > to build a dir with all required jars to run an application, it won't be > necessary to use both goals, copy (for the artifact) and copy-dependencies > (for its libs). > I also want to ask the developers if they would preffer me to contribute a > patch for this new boolean param, named "copyArtifact"? > anKostis a gmail.com -- 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: (MPLUGIN-7) Reformat the autogenerated goal parameters page to improve readibility.
[ http://jira.codehaus.org/browse/MPLUGIN-7?page=all ] Hervé BOUTEMY updated MPLUGIN-7: Attachment: xmlbeans-mojo2.html xmlbeans-mojo1.html > Reformat the autogenerated goal parameters page to improve readibility. > --- > > Key: MPLUGIN-7 > URL: http://jira.codehaus.org/browse/MPLUGIN-7 > Project: Maven 2.x Plugin Plugin > Type: Improvement > Environment: any, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Priority: Minor > Attachments: xmlbeans-mojo1.html, xmlbeans-mojo2.html > > Original Estimate: 8 hours > Remaining: 8 hours > > The goal plugin:xdoc creates a table describing the parameters for a plugin. > An example may be found here: > http://mojo.codehaus.org/xmlbeans-maven-plugin/xmlbeans-mojo.html > In the example, notice that the nowrap on the type, expression and > default-value columns causes the descriptions to be crammed into the right > side of the page. > So rather than having these values in their own columns, position them in > rows below the parameter as is done in the maven-model documentation for the > project descriptor. This way the fields don't compete for space across the > page: > http://maven.apache.org/maven2/maven-model/maven.html > What's more, the inclusion of hyperlinked xml at the top of the page > describing the configuration section of the plugin would benefit the end user > without manual effort of the plugin developer. -- 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: (MNGECLIPSE-146) Less aggressive source attatchment resolution
Less aggressive source attatchment resolution - Key: MNGECLIPSE-146 URL: http://jira.codehaus.org/browse/MNGECLIPSE-146 Project: Maven 2.x Extension for Eclipse Type: Improvement Components: Dependency Resolver Versions: 0.0.9 Reporter: Adam Lewis Assigned to: Eugene Kuleshov Priority: Minor It would be nice if the plugin was less aggresive when trying to resolve source artifacts. Typically if an artifact doesn't have a source jar in the repo at one instant it will still not have one a few minutes later. It would be nice if there were a configurable retry delay so that my IDE would only go out once a day to look for source attatchments that had previously failed to be found. -- 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-2301) Maven Archiver deleteing already existing pom.properties file.
[ http://jira.codehaus.org/browse/MNG-2301?page=comments#action_68282 ] Sharmarke Aden commented on MNG-2301: - The rational behind not deleting the pom.properties files are: 1) Implicitly deleting a file explicitly created by the user is bad policy. 2) The idea behind not deleting the pom.properties is to facilitate external systems such as build systems to interact with maven. For example, communicating build number and date. The build system would place the build number in the pom.properties file and the maven can pickup this build information from the pom.properties file. Basically, this fix is necessary to support maven built-in properties enhancement request (see http://jira.codehaus.org/browse/MNG-1832). > Maven Archiver deleteing already existing pom.properties file. > -- > > Key: MNG-2301 > URL: http://jira.codehaus.org/browse/MNG-2301 > Project: Maven 2 > Type: Bug > Components: maven-archiver > Versions: 2.0.4 > Reporter: Sharmarke Aden > Fix For: 2.0.5 > Attachments: maven-archiver_pomDelete.patch > > > My project has it's own pom.properties file and it seems that maven archiver > is deleting it right after packaging the application. Any particular reason > why it's doing this? It seems to me the archiver shouldn't be deleting the > file if it already exists. It should delete the file if it doesn't exists > otherwise it should add the necessary information (version, groupId, etc) to > the file and leave it be. I have attached a patch that fixes the issue. > Also note that this patch adds the "builtOn" property to the pom.properties > which is satisfy the following enhancement request: > http://jira.codehaus.org/browse/MNG-1830 -- 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-134) Surefire finds test classes but ignores test methods and configuration methods with TestNG and includes tag
[ http://jira.codehaus.org/browse/MSUREFIRE-134?page=comments#action_68285 ] Paul Russell commented on MSUREFIRE-134: Chaps, to clarify, my comment above is incorrect. The workaround 'works' for me because I happen to be following JUnit style naming conventions despite my use of NG. This is a pretty critical bug imho, and would benefit from your full attention. Don't want you to be labouring under the misapprehension that my workaround above is solving the problem. The inevitable question: and ETA for a patch for this? > Surefire finds test classes but ignores test methods and configuration > methods with TestNG and includes tag > --- > > Key: MSUREFIRE-134 > URL: http://jira.codehaus.org/browse/MSUREFIRE-134 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Environment: Maven 2.0.4 > Surefire Plugin 2.2 > TestNG 4.7 jdk15 (using annotations) > Sun JDK 1.5_06 > Windows XP SP 2 > Reporter: Mark Reynolds > Attachments: maven2-testng.zip > > > Attachment contains 2 projects which are identical except for how the test > cases are referenced. In one project they are referenced via a suite xml > file. In the second they are referenced using the includes tag. I believe > they should produce identical results. > Both projects find all 6 test classes, but only the one using a suite xml > file actually executes the configuration methods and test methods. The > project using an includes tag completely ignores the configuratiion methods > and test methods. -- 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: (MNGECLIPSE-142) Support for Callisto release version of Eclipse and WTP
[ http://jira.codehaus.org/browse/MNGECLIPSE-142?page=comments#action_68286 ] Mauritz Lovgren commented on MNGECLIPSE-142: I hope so. Isn't this the http://m2eclipse.codehaus.org Maven2 Eclipse Plugin developed by Mergere? Last time I checked, the m2eclipse plugin needs WTP 1.0 to work properly? Maybe I am wrong? > Support for Callisto release version of Eclipse and WTP > --- > > Key: MNGECLIPSE-142 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-142 > Project: Maven 2.x Extension for Eclipse > Type: Improvement > Versions: 0.0.10 > Environment: Any environment Eclipse 3.2 Callisto can run in. > Reporter: Mauritz Lovgren > Assignee: Eugene Kuleshov > Priority: Minor > > > As developers in the Eclipse domain are moving towards the Callisto release, > the m2 plugin should adapt to this move as well. -- 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: (MAVEN-1750) Can't use two times a multiprojects in 2 differents goals
[ http://jira.codehaus.org/browse/MAVEN-1750?page=all ]
Arnaud Heritier closed MAVEN-1750:
--
Assign To: Arnaud Heritier
Resolution: Cannot Reproduce
Neither do I. I can't reproduce it.
> Can't use two times a multiprojects in 2 differents goals
> -
>
> Key: MAVEN-1750
> URL: http://jira.codehaus.org/browse/MAVEN-1750
> Project: Maven
> Type: Bug
> Versions: 1.1-beta-3
> Environment: 1.1-beta-3 from trunk
> Reporter: Arnaud Heritier
> Assignee: Arnaud Heritier
> Fix For: 1.1-beta-3
>
>
> in the plugins-site project (in plugins and in the sandbox) we have two goals:
> plugins:build-all-sites which calls multiproject:site (to create the main
> site) and the goal "site" through a multiproject:goal (to create each plugin
> site)
> plugins:deploy-all-sites which calls site:${maven.site.deploy.method}deploy
> (to deploy the main site) and the goal site:${maven.site.deploy.method}deploy
> through multiproject:goal (to deploy each plugin site)
> In the plugins root project we have the same goals which call the ones in the
> plugins-site (with maven:maven)
> I tried to create a goal to call these two goals successively.
> {code:xml}
>name="plugins:build-and-deploy-all-sites"
> description="Build and deploy the web site for all plugins and for the root
> site"
> prereqs="plugins:build-all-sites,plugins:deploy-all-sites"/>
>name="plugins:build-and-deploy-all-sites2"
> description="Build and deploy the web site for all plugins and for the root
> site">
>
>
>
> {code}
> If I call these goals from the project plugins-site or if I call the 2 goals
> from the command line (maven plugins:build-all-sites
> plugins:deploy-all-sites) I receive this error :
> {code}
> BUILD FAILED
> File..
> file:/d:/Data/maven-1/cache/maven-multiproject-plugin-1.5-SNAPSHOT/plugin.jelly
> Element... maven:param-check
> Line.. 215
> Column -1
> A goal to run must be specified, e.g.
> maven -Dgoal=clean multiproject:goal
> {code}
> This error happens when the multiproject is called in
> plugins:deploy-all-sites to deploy all plugins sites.
> I displayed the value of the variable goal just before the attainGoal and the
> value is correct
> If we run the goals build-and-deploy-all-sites and
> build-and-deploy-all-sites2 from the plugins root we have the same error
> But if we call "maven plugins:build-all-sites plugins:deploy-all-sites" it
> works.
--
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: (MPLUGIN-7) Reformat the autogenerated goal parameters page to improve readibility.
[ http://jira.codehaus.org/browse/MPLUGIN-7?page=comments#action_68295 ] Edwin Punzalan commented on MPLUGIN-7: -- Those pages are alright... but I was thinking of something similar to javadoc's Field Summary/Field Details section. But if the plugin have the javadoc report included, they might become too similar. > Reformat the autogenerated goal parameters page to improve readibility. > --- > > Key: MPLUGIN-7 > URL: http://jira.codehaus.org/browse/MPLUGIN-7 > Project: Maven 2.x Plugin Plugin > Type: Improvement > Environment: any, jdk 1.4.2_06 > Reporter: Corridor Software Developer > Priority: Minor > Attachments: xmlbeans-mojo1.html, xmlbeans-mojo2.html > > Original Estimate: 8 hours > Remaining: 8 hours > > The goal plugin:xdoc creates a table describing the parameters for a plugin. > An example may be found here: > http://mojo.codehaus.org/xmlbeans-maven-plugin/xmlbeans-mojo.html > In the example, notice that the nowrap on the type, expression and > default-value columns causes the descriptions to be crammed into the right > side of the page. > So rather than having these values in their own columns, position them in > rows below the parameter as is done in the maven-model documentation for the > project descriptor. This way the fields don't compete for space across the > page: > http://maven.apache.org/maven2/maven-model/maven.html > What's more, the inclusion of hyperlinked xml at the top of the page > describing the configuration section of the plugin would benefit the end user > without manual effort of the plugin developer. -- 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: (MJAVADOC-79) Review plugin documentation
[ http://jira.codehaus.org/browse/MJAVADOC-79?page=comments#action_68296 ] Maria Odea Ching commented on MJAVADOC-79: -- Thanks :) Will apply the comments above.. > Review plugin documentation > --- > > Key: MJAVADOC-79 > URL: http://jira.codehaus.org/browse/MJAVADOC-79 > Project: Maven 2.x Javadoc Plugin > Type: Task > Reporter: Maria Odea Ching > Assignee: Maria Odea Ching > > -- 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: (MSITE-138) site:stage does not create xref
[ http://jira.codehaus.org/browse/MSITE-138?page=comments#action_68297 ] Wouter Zoons commented on MSITE-138: this happens with all reports I've used so far: javadoc, jxr, cobertura etc.. at first glance the output directory URL property is properly set on the reactor projects in the site mojo, the problem could be related to the relative path resolution; I'll post the solution/patch if I find it > site:stage does not create xref > --- > > Key: MSITE-138 > URL: http://jira.codehaus.org/browse/MSITE-138 > Project: Maven 2.x Site Plugin > Type: Bug > Versions: 2.0-beta-5 > Reporter: Jorg Heymans > > > as reported here : > http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.user/40178 > the xref and test-xref dirs both have an empty index.html after the site is > staged. -- 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-54) Unable to filter files while creating assembly
[ http://jira.codehaus.org/browse/MASSEMBLY-54?page=comments#action_68299 ] Corridor Software Developer commented on MASSEMBLY-54: -- Fabulous. Thanks for the clarification. > Unable to filter files while creating assembly > -- > > Key: MASSEMBLY-54 > URL: http://jira.codehaus.org/browse/MASSEMBLY-54 > Project: Maven 2.x Assembly Plugin > Type: Improvement > Versions: 2.0 > Reporter: Chris Hagmann > Assignee: Allan Ramirez > Fix For: 2.1 > > Original Estimate: 6 hours >Time Spent: 12 hours > Remaining: 0 minutes > > It doesn't seem to be possible to use filtering when creating assemblies. I > have a couple of plain-text files which need to be updated when creating the > assembly (e.g. README.TXT, .version). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGECLIPSE-142) Support for Callisto release version of Eclipse and WTP
[ http://jira.codehaus.org/browse/MNGECLIPSE-142?page=all ] Eugene Kuleshov closed MNGECLIPSE-142: -- Resolution: Won't Fix Never been the case and never require WTP and have no explicit support for it. Though there are couple jiras opened for better integeration with WTP enabled projects. > Support for Callisto release version of Eclipse and WTP > --- > > Key: MNGECLIPSE-142 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-142 > Project: Maven 2.x Extension for Eclipse > Type: Improvement > Versions: 0.0.10 > Environment: Any environment Eclipse 3.2 Callisto can run in. > Reporter: Mauritz Lovgren > Assignee: Eugene Kuleshov > Priority: Minor > > > As developers in the Eclipse domain are moving towards the Callisto release, > the m2 plugin should adapt to this move as well. -- 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-52) WAR plugin does not honor the webXml configuration setting [patch included!]
[ http://jira.codehaus.org/browse/MWAR-52?page=all ]
Brett Porter updated MWAR-52:
-
Remaining Estimate: 15 minutes
Original Estimate: 15 minutes
> WAR plugin does not honor the webXml configuration setting [patch included!]
>
>
> Key: MWAR-52
> URL: http://jira.codehaus.org/browse/MWAR-52
> Project: Maven 2.x War Plugin
> Type: Bug
> Versions: 2.0
> Reporter: Andreas Schildbach
> Attachments: patch.txt
>
> Original Estimate: 15 minutes
> Remaining: 15 minutes
>
> The WAR plugin does not honor the webXml configuration setting. I think this
> comes from web.xml being hardcoded into WarMojo, rather than using the
> default-value mechanism for the MOJO attribute.
> Here is a patch:
> Index:
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
> ===
> ---
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
> (revision 416739)
> +++
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
> (working copy)
> @@ -102,7 +102,7 @@
> /**
> * The path to the web.xml file to use.
> *
> - * @parameter expression="${maven.war.webxml}"
> + * @parameter expression="${maven.war.webxml}"
> default-value="WEB-INF/web.xml"
> */
> private File webXml;
>
> Index:
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/WarMojo.java
> ===
> ---
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/WarMojo.java
> (revision 416739)
> +++
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/WarMojo.java
> (working copy)
> @@ -177,7 +177,7 @@
>
> warArchiver.addDirectory( getWebappDirectory() );
>
> -warArchiver.setWebxml( new File( getWebappDirectory(),
> "WEB-INF/web.xml" ) );
> +warArchiver.setWebxml( getWebXml() );
>
> // create archive
> archiver.createArchive( getProject(), archive );
--
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-52) WAR plugin does not honor the webXml configuration setting [patch included!]
[ http://jira.codehaus.org/browse/MWAR-52?page=all ]
Brett Porter closed MWAR-52:
Assign To: Brett Porter
Resolution: Cannot Reproduce
the code is correct. the custom web.xml is copied to WEB-INF/web.xml in the
exploded webapp, which is what the code you intended to change is referring to.
I have enhanced the test to ensure the bundled web.xml is correct. If you have
a test case for something that fails, please reopen the issue.
> WAR plugin does not honor the webXml configuration setting [patch included!]
>
>
> Key: MWAR-52
> URL: http://jira.codehaus.org/browse/MWAR-52
> Project: Maven 2.x War Plugin
> Type: Bug
> Versions: 2.0
> Reporter: Andreas Schildbach
> Assignee: Brett Porter
> Attachments: patch.txt
>
> Original Estimate: 15 minutes
> Remaining: 15 minutes
>
> The WAR plugin does not honor the webXml configuration setting. I think this
> comes from web.xml being hardcoded into WarMojo, rather than using the
> default-value mechanism for the MOJO attribute.
> Here is a patch:
> Index:
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
> ===
> ---
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
> (revision 416739)
> +++
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
> (working copy)
> @@ -102,7 +102,7 @@
> /**
> * The path to the web.xml file to use.
> *
> - * @parameter expression="${maven.war.webxml}"
> + * @parameter expression="${maven.war.webxml}"
> default-value="WEB-INF/web.xml"
> */
> private File webXml;
>
> Index:
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/WarMojo.java
> ===
> ---
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/WarMojo.java
> (revision 416739)
> +++
> C:/cc/sd_area51_3/OcToPuS/tools/maven/plugins/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/WarMojo.java
> (working copy)
> @@ -177,7 +177,7 @@
>
> warArchiver.addDirectory( getWebappDirectory() );
>
> -warArchiver.setWebxml( new File( getWebappDirectory(),
> "WEB-INF/web.xml" ) );
> +warArchiver.setWebxml( getWebXml() );
>
> // create archive
> archiver.createArchive( getProject(), archive );
--
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-47) Regression : Files not copied when overlaying wars
[ http://jira.codehaus.org/browse/MWAR-47?page=all ]
Brett Porter updated MWAR-47:
-
Assign To: Brett Porter
Remaining Estimate: 30 minutes
Original Estimate: 30 minutes
> Regression : Files not copied when overlaying wars
> --
>
> Key: MWAR-47
> URL: http://jira.codehaus.org/browse/MWAR-47
> Project: Maven 2.x War Plugin
> Type: Bug
> Versions: 2.0
> Reporter: Eric Bottard
> Assignee: Brett Porter
> Fix For: 2.0.1
>
> Original Estimate: 30 minutes
> Remaining: 30 minutes
>
> The handy "overlay wars" functionnality seems to have changed with release
> 2.0 : files that are already in place (no matter last modification date) are
> never overwritten from overlaid wars.
> This is problematic since after a first packaging of the war file, any file
> coming from a dependent war will already sit there and will never be updated.
> The faulty line is here (AbstractWarMojo.java):
> for ( int j = 0; j < files.length; j++ )
> {
> File targetFile = new File( targetDir, files[j] );
> // Do not overwrite existing files.
> if ( !targetFile.exists() ) // <== WILL
> ALWAYS FAIL
> {
> try
> {
> targetFile.getParentFile().mkdirs();
> copyFileIfModified( new File( srcDir, files[j] ),
> targetFile );
> }
> catch ( IOException e )
> {
> throw new MojoExecutionException( "Error copying file '"
> + files[j] + "' to '" + targetFile + "'",
> e );
> }
> }
> }
> My use case is, I guess, pretty common : I have a "framework" project
> (packaging = war) that must benefit may "real, final" projects that produce
> the final artifact (packaging = war as well). The "framework" part is a
> 'dependent war' of the real project and is 'overlaid' by the war plugin. The
> trouble is, if I update any file of the framework part, changes are not taken
> into account since files already exist in the target directory.
> Please consider removing the " if ( !targetFile.exists() )" part (last
> modification date alone is fine).
> regards,
> eb.
--
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-47) Regression : Files not copied when overlaying wars
[ http://jira.codehaus.org/browse/MWAR-47?page=all ]
Brett Porter closed MWAR-47:
Resolution: Fixed
> Regression : Files not copied when overlaying wars
> --
>
> Key: MWAR-47
> URL: http://jira.codehaus.org/browse/MWAR-47
> Project: Maven 2.x War Plugin
> Type: Bug
> Versions: 2.0
> Reporter: Eric Bottard
> Assignee: Brett Porter
> Fix For: 2.0.1
>
> Original Estimate: 30 minutes
>Time Spent: 45 minutes
> Remaining: 0 minutes
>
> The handy "overlay wars" functionnality seems to have changed with release
> 2.0 : files that are already in place (no matter last modification date) are
> never overwritten from overlaid wars.
> This is problematic since after a first packaging of the war file, any file
> coming from a dependent war will already sit there and will never be updated.
> The faulty line is here (AbstractWarMojo.java):
> for ( int j = 0; j < files.length; j++ )
> {
> File targetFile = new File( targetDir, files[j] );
> // Do not overwrite existing files.
> if ( !targetFile.exists() ) // <== WILL
> ALWAYS FAIL
> {
> try
> {
> targetFile.getParentFile().mkdirs();
> copyFileIfModified( new File( srcDir, files[j] ),
> targetFile );
> }
> catch ( IOException e )
> {
> throw new MojoExecutionException( "Error copying file '"
> + files[j] + "' to '" + targetFile + "'",
> e );
> }
> }
> }
> My use case is, I guess, pretty common : I have a "framework" project
> (packaging = war) that must benefit may "real, final" projects that produce
> the final artifact (packaging = war as well). The "framework" part is a
> 'dependent war' of the real project and is 'overlaid' by the war plugin. The
> trouble is, if I update any file of the framework part, changes are not taken
> into account since files already exist in the target directory.
> Please consider removing the " if ( !targetFile.exists() )" part (last
> modification date alone is fine).
> regards,
> eb.
--
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-35) War packaging fails with long file names
[ http://jira.codehaus.org/browse/MWAR-35?page=all ] Brett Porter closed MWAR-35: Assign To: Brett Porter Resolution: Fixed I've canonicalised the source file, which is about all I can do for the situation. It should be noted that the reporter was not using 2.0 despite the report according to the trace, more likely 2.0-beta-3. I don't have a test case to confirm whether this really works or not. > War packaging fails with long file names > > > Key: MWAR-35 > URL: http://jira.codehaus.org/browse/MWAR-35 > Project: Maven 2.x War Plugin > Type: Bug > Versions: 2.0 > Environment: Windows, Maven 2.0.4 > Reporter: Laurent Dauvilaire > Assignee: Brett Porter > Fix For: 2.0.1 > > > The package action fails when file name are too long. > Note: the file creating the error can be created by hand. > (echo yes > > d:\Home\LDauvilaire\src\Repository\SVN\JHub\modules\display-webapp\modules\hub-internal\..\..\..\..\target\dev\3.0.20\hub-webapp-internal\hub-webapp-internal-3.0.20\fceditor\editor\dialog\fck_spellerpages\spellerpages\server-scripts\spellchecker.cfm) > See stack trace below: > [INFO] [war:war] > [INFO] Exploding webapp... > [INFO] Copy webapp resources to > d:\Home\LDauvilaire\src\Repository\SVN\JHub\modules\display-webapp\modules\hub-internal\..\..\..\..\target\dev\3.0.20\hub-webapp-internal\hub-webapp-internal-3.0.20 > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error assembling WAR > Embedded error: Could not explode webapp... > d:\Home\LDauvilaire\src\Repository\SVN\JHub\modules\display-webapp\modules\hub-internal\..\..\..\..\target\dev\3.0.20\hub-webapp-internal\hub-webapp-internal-3.0.20\fceditor\editor\dialog\fck_spellerpages\spellerpages\server-scripts\spellchecker.cfm > (The filename, directory name, or volume label syntax is incorrect) > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling WAR > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error assembling > WAR > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:91) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 16 more > Caused by: org.apache.maven.plugin.MojoExecutionException: Could not explode > webapp... > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:202) > at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:108) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:86) > ... 18 more > Caused by: java.io.FileNotFoundException: > d:\Home\LDauvilaire\src\Repository\SVN\JHub\modules\display-webapp\modules\hub-internal\..\..\..\..\target\dev\3.0.20\hub-webapp-internal\hub-webapp-internal-3.0.20\fceditor\editor\dialog\fck_spellerpages\spellerpages\server-scripts\spellchecker.cfm > (The filename, directory name, or volume label syntax is incorrect) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:179) > at java.io.FileOutputStream.(FileOutputStream.java:131) > at org.codehaus.plexus.util.FileUtils.copyFil
