[jira] Updated: (MNG-2454) add @since to mojo at class level
[ http://jira.codehaus.org/browse/MNG-2454?page=all ] Brett Porter updated MNG-2454: -- Fix Version/s: 2.1 > add @since to mojo at class level > - > > Key: MNG-2454 > URL: http://jira.codehaus.org/browse/MNG-2454 > Project: Maven 2 > Issue Type: New Feature > Components: Plugin Creation Tools >Reporter: Brett Porter > Fix For: 2.1 > > -- 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: (MRESOURCES-24) Force overwrite resources defined in profiles
Force overwrite resources defined in profiles - Key: MRESOURCES-24 URL: http://jira.codehaus.org/browse/MRESOURCES-24 Project: Maven 2.x Resources Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Kees de Kooter I am using profiles to package for different environments. The profile typically defines a couple of properties files with db and log settings. The resource plugin only overwrites files that are changed, so the profile specific resources with the same name are ignored and the wrong resources are packaged. I could do a clean first, but that seems a bit of a crude approach. I would prefer to have a property like "overwrite=true" on a resource. -- 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-221) scm:update has no effect
scm:update has no effect Key: SCM-221 URL: http://jira.codehaus.org/browse/SCM-221 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-perforce Affects Versions: 1.0 Environment: http://svn.apache.org/maven-snapshot-repository/org/apache/maven/scm/maven-scm-provider-perforce/1.0-SNAPSHOT/maven-scm-provider-perforce-1.0-20060616.160825-6.jar Reporter: Yuri Schimke Priority: Critical We are trying to use scm:update in a cruisecontrol build to update the project before building. However it doesn't seem to actually write any changes to disk. The command completes successfully, but the files are not synced to head. The directory for the update is a working perforce directory. i.e. after the command below fails to update the files, "p4 sync" works immediately. [INFO] [scm:update] [INFO] Checkout working directory: C:\PerforceViews\dms_1.2_dev\dms [INFO] Executing: p4 client -i [INFO] Executing: p4 client -d nbk7xsp-B001279A7BC2E-MavenSCM-C:\PerforceViews\dms_1.2_dev\dms Is the generated clientspec just using for determining changesets? There is a valid clientspec already associated with the current project directory. -- 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: (MRESOURCES-23) Review Plugin Documentation
[ http://jira.codehaus.org/browse/MRESOURCES-23?page=all ] Franz Allan Valencia See updated MRESOURCES-23: --- Attachment: MRESOURCES-23-maven-resources-plugin-2.patch In index.html changed "This, thus, allows the separation ..." to "Thus, this allows the separation... " (reported by Edwin Punzalan) In encoding.html changed "UTF-8" to "UTF-8" (reported by Edwin Punzalan) In FAQ.html changed "The Maven Resource Plugin only allwos encoding values..." to "The Maven Resource Plugin only allows encoding values..." > Review Plugin Documentation > --- > > Key: MRESOURCES-23 > URL: http://jira.codehaus.org/browse/MRESOURCES-23 > Project: Maven 2.x Resources Plugin > Issue Type: Task >Reporter: Allan Ramirez > Assigned To: Allan Ramirez > Attachments: MRESOURCES-23-maven-resources-plugin-2.patch, > MRESOURCES-23-maven-resources-plugin.patch > > Original Estimate: 13 hours > Time Spent: 2 hours > Remaining Estimate: 11 hours > -- 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: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_70051 ] Richard van der Hoff commented on MJAR-28: -- Baerrach, have you been able to make any progress on this? Did you get an answer to your questions regarding the best way to fix this? We're suffering the same problem and would like to find a fix :/ http://jira.codehaus.org/browse/MNG-775 might make fixing this the "right" way rather difficult :( > Using the jar plugin with addClasspath and snapshots can create manifest > classpath with incorrect jar versions > -- > > Key: MJAR-28 > URL: http://jira.codehaus.org/browse/MJAR-28 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark J. Titorenko > > When the POM contains dependencies to snapshot versions of jars, and snapshot > versions of those jars are downloaded from a remote repository, the name of > the jar contained in the classpath added to the manifest, of the form > artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar > downloaded, which contains version information of the form > artifactID-X.X-MMDD.HHmmss-V.jar. > This does not affect snapshot versions which have been directly installed > into a local repository and have no uploaded version within the remote > repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar > form. -- 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-2408) Improve handling of "no plugin version found" error after intermittent errors
[ http://jira.codehaus.org/browse/MNG-2408?page=comments#action_70060 ] Brad Cozine commented on MNG-2408: -- Was having the issue also. Emptied local repo and removed that "Australlian" (example) mirror from my settings.xml. Did the trick. > Improve handling of "no plugin version found" error after intermittent errors > - > > Key: MNG-2408 > URL: http://jira.codehaus.org/browse/MNG-2408 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Documentation: Guides, > Artifacts >Affects Versions: 2.0.4 >Reporter: Graham Leggett >Priority: Blocker > Fix For: 2.0.5 > > > If you follow the instructions at > http://maven.apache.org/guides/getting-started/index.html#How%20do%20I%20make%20my%20first%20Maven%20project? > to use the archetype plugin to create a new project skeleton, the suggested > command line fails as below. > It seems there is a typo of some kind in the suggested command line, I am not > familiar enough with maven 2 to know for sure. > Graham-Leggetts-Computer:~/src/standard/alchemy/maven minfrin$ mvn > archetype:create -DgroupId=za.co.standardbank.alchemy > -DartifactId=alchemy-trader > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'archetype'. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] The plugin 'org.apache.maven.plugins:maven-archetype-plugin' does not > exist or no valid version could be found > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Tue Jun 27 09:43:14 SAST 2006 > [INFO] Final Memory: 1M/2M > [INFO] > -- 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-993) Upload remainder of JSTL 1.1.2
Upload remainder of JSTL 1.1.2 -- Key: MAVENUPLOAD-993 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-993 Project: maven-upload-requests Issue Type: Improvement Reporter: Bob Allison Attachments: jstl-standard-1.1.2.jar, jstl-standard-1.1.2.pom The Java library is present as javax.servlet:jstl:1.1.2 but the tag library is missing. It used to be located at javax.servlet:jstl-standard:1.1.2. The attached files are ones previously downloaded by Maven 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] Commented: (MNG-1493) Support in multiproject environment modules with different named POMs
[ http://jira.codehaus.org/browse/MNG-1493?page=comments#action_70063 ] John Casey commented on MNG-1493: - I was thinking I'd just allow a full specification of the relative pom-file path for modules, just like we allow the parent/relativePath to refer to a specific pom file location. It would actually improve the consistency of these path-based elements of the core POM (ie. not plugin configuration elements). > Support in multiproject environment modules with different named POMs > - > > Key: MNG-1493 > URL: http://jira.codehaus.org/browse/MNG-1493 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0 >Reporter: Joerg Schaible >Priority: Minor > Fix For: 2.1 > > > Command line version of Maven 2 supports POMs with a different name using the > -f option. Unfortunately such POMs cannot be used as modules, since the value > of the module tag is defined as a directory to another pom.xml instead of a > pathname to another POM. Only if the value is not already an existing file > the value should be treated as directory with a present pom.xml file. Similar > situation applies to the relativePath element of the parent tag. > This makes the generation of different artifacts from the same sources (with > some modifications) much more easy. Currently you will have to put the POMs > in separate directories and modify the sourec location into another module. -- 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-2214) ITs fail when bootstrapping M2 SVN trunk with java.lang.StringIndexOutOfBoundsException: String index out of range: 1
[ http://jira.codehaus.org/browse/MNG-2214?page=all ] John Casey closed MNG-2214. --- Assignee: John Casey Resolution: Cannot Reproduce I'm not seeing it either. > ITs fail when bootstrapping M2 SVN trunk with > java.lang.StringIndexOutOfBoundsException: String index out of range: 1 > - > > Key: MNG-2214 > URL: http://jira.codehaus.org/browse/MNG-2214 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build > Environment: Windows XP, M2 SVN trunk >Reporter: Rahul Thakur > Assigned To: John Casey > Fix For: 2.0.5 > > Attachments: StringReplacementTest.java > > > Here is an exception stacktrace for one of the failed tests... > it0002... FAILED > >> Error Stacktrace: > org.apache.maven.it.VerificationException: > java.lang.StringIndexOutOfBoundsException: String index out of range: 1 > at org.apache.maven.it.Verifier.executeHook(Verifier.java:366) > at org.apache.maven.it.Verifier.main(Verifier.java:862) > Caused by: java.lang.StringIndexOutOfBoundsException: String index out of > range: 1 > at java.lang.String.charAt(String.java:566) > at java.util.regex.Matcher.appendReplacement(Matcher.java:696) > at java.util.regex.Matcher.replaceAll(Matcher.java:806) > at java.lang.String.replaceAll(String.java:2028) > at > org.apache.maven.it.Verifier.resolveCommandLineArg(Verifier.java:698) > at org.apache.maven.it.Verifier.executeHook(Verifier.java:355) > ... 1 more > << Error Stacktrace -- 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: (MNG-2440) NPE during bootstrap
[ http://jira.codehaus.org/browse/MNG-2440?page=all ] John Casey reopened MNG-2440: - *sigh* As it turns out, things got a little confused on this end when I was trying to apply a patch from Marvin to fix the trunk bootstrap. I was trying to apply the patch to MNG-2447, but apparently this commit failed (most likely due to electricity problems at my house on that evening)...and I closed the wrong issue. So, is this still a problem? > NPE during bootstrap > > > Key: MNG-2440 > URL: http://jira.codehaus.org/browse/MNG-2440 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.1 >Reporter: Marvin King > Assigned To: John Casey > Fix For: 2.1 > > Attachments: MNG-2440-maven-repository-metadata.patch > > > bootstrapping maven2 creates results in NPE. -- 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: (MIDEA-60) Keep attached sources when replacing libraries in module
[ http://jira.codehaus.org/browse/MIDEA-60?page=all ] David Hay updated MIDEA-60: --- Attachment: ideatest-with-source.jar > Keep attached sources when replacing libraries in module > > > Key: MIDEA-60 > URL: http://jira.codehaus.org/browse/MIDEA-60 > Project: Maven 2.x Idea Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: David Hay > Attachments: ideatest-with-source.jar > > > Many times, the dependencies downloaded by Maven do not have corresponding > source jars. So I download the source separately and attach it to the > dependencies in my module. However, if I regenerate the module, those source > attachments are lost. > I'd like to see the Idea plugin (perhaps optionally) keep any source or > javadoc attachments that have been made. -- 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: (MIDEA-60) Keep attached sources when replacing libraries in module
[ http://jira.codehaus.org/browse/MIDEA-60?page=all ] David Hay updated MIDEA-60: --- Attachment: ideatest-after-module-rebuild.jar I'm attaching two project directories. The first, ideatest-with-source.jar, it my initial directory setup. I did the following to create this project: 1. mvn archetype:create -DgroupId=com.ideatest -DartifactId=ideatest 2. cd ideatest 3. Edit pom and add dependency to spring 2.0-rc2 4. mvn idea:idea 5. Open the project in Intellij and attach source to the spring jar file The second attachment, ideatest-after-module-rebuild.jar shows the state of the project after running 'mvn idea:module' in the project. Note that the sources are no longer attached to the spring jar file. > Keep attached sources when replacing libraries in module > > > Key: MIDEA-60 > URL: http://jira.codehaus.org/browse/MIDEA-60 > Project: Maven 2.x Idea Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: David Hay > Attachments: ideatest-after-module-rebuild.jar, > ideatest-with-source.jar > > > Many times, the dependencies downloaded by Maven do not have corresponding > source jars. So I download the source separately and attach it to the > dependencies in my module. However, if I regenerate the module, those source > attachments are lost. > I'd like to see the Idea plugin (perhaps optionally) keep any source or > javadoc attachments that have been made. -- 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: (MIDEA-60) Keep attached sources when replacing libraries in module
[ http://jira.codehaus.org/browse/MIDEA-60?page=all ] David Hay updated MIDEA-60: --- Attachment: ideatest-log.txt Attaching the result of running idea:module goal with the -X flag enabled. > Keep attached sources when replacing libraries in module > > > Key: MIDEA-60 > URL: http://jira.codehaus.org/browse/MIDEA-60 > Project: Maven 2.x Idea Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: David Hay > Attachments: ideatest-after-module-rebuild.jar, ideatest-log.txt, > ideatest-with-source.jar > > > Many times, the dependencies downloaded by Maven do not have corresponding > source jars. So I download the source separately and attach it to the > dependencies in my module. However, if I regenerate the module, those source > attachments are lost. > I'd like to see the Idea plugin (perhaps optionally) keep any source or > javadoc attachments that have been made. -- 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-92) Allow .classpath generation for plugin-development support
[ http://jira.codehaus.org/browse/MECLIPSE-92?page=comments#action_70071 ] stephane bouchet commented on MECLIPSE-92: -- Hi, I am testing the snapshot and ran into a problem with PDE. When the plugin generates the .classpath file, all the dependencies are added as external jars ( with full path ) not as jars in the project. I can ran the plugin without probleme but i got errors in my Manifest.mf file because eclipse cannot find some exported packages. Anyway, the rest is working great ! Stéphane > Allow .classpath generation for plugin-development support > -- > > Key: MECLIPSE-92 > URL: http://jira.codehaus.org/browse/MECLIPSE-92 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.1 >Reporter: Sachin Patel > Assigned To: fabrizio giustina > Attachments: pde_patch_1.diff > > > In order to improve eclipse plugin development with maven, the configuration > of the eclipse:eclipse goal should allow a flag to be set that that given pom > is an eclipse plugin and the .classpath generated should not add .classpath > entries for dependencies declared in the POM, since plugins really just > reference other plugins in the workspace and or use the "requiredPlugins" > classpath container. At runtime plugins cannot reference external > classes/jars so having all the "var" entries isn't necessary and adds clutter. -- 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-994) Upload 1.2 "cayenne", "cayenne-nodeps" and "cayenne-client-nodeps
Upload 1.2 "cayenne", "cayenne-nodeps" and "cayenne-client-nodeps -- Key: MAVENUPLOAD-994 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-994 Project: maven-upload-requests Issue Type: Task Reporter: Andrus Adamchik Cayenne is already on ibiblio. Please upload these three new bundles for the final release: http://objectstyle.org/downloads/cayenne/maven-bundles/cayenne-1.2-bundle.jar http://objectstyle.org/downloads/cayenne/maven-bundles/cayenne-client-nodeps-1.2-bundle.jar http://objectstyle.org/downloads/cayenne/maven-bundles/cayenne-nodeps-1.2-bundle.jar Thanks! Andrus P.S. BTW, is there any way to delete the intermediary versions at ibiblio (1.2M* and 1.2B*)? -- 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: (SCM-221) scm:update has no effect
[ http://jira.codehaus.org/browse/SCM-221?page=comments#action_70079 ] Mike Perham commented on SCM-221: - In Perforce the checkout and update commands are the same (sync). We use a generated clientspec because we need to check out a project to a specific directory. You cannot check out code to a particular location without using a custom clientspec. > scm:update has no effect > > > Key: SCM-221 > URL: http://jira.codehaus.org/browse/SCM-221 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.0 > Environment: > http://svn.apache.org/maven-snapshot-repository/org/apache/maven/scm/maven-scm-provider-perforce/1.0-SNAPSHOT/maven-scm-provider-perforce-1.0-20060616.160825-6.jar > >Reporter: Yuri Schimke > Assigned To: Mike Perham >Priority: Critical > > We are trying to use scm:update in a cruisecontrol build to update the > project before building. However it doesn't seem to actually write any > changes to disk. > The command completes successfully, but the files are not synced to head. > The directory for the update is a working perforce directory. i.e. after the > command below fails to update the files, "p4 sync" works immediately. > [INFO] [scm:update] > > [INFO] Checkout working directory: C:\PerforceViews\dms_1.2_dev\dms > > [INFO] Executing: p4 client -i > > [INFO] Executing: p4 client -d > nbk7xsp-B001279A7BC2E-MavenSCM-C:\PerforceViews\dms_1.2_dev\dms > > > Is the generated clientspec just using for determining changesets? There is > a valid clientspec already associated with the current project directory. -- 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: (CONTINUUM-782) Add a feature to allow cleaning the m2 local repo once every N days
[ http://jira.codehaus.org/browse/CONTINUUM-782?page=comments#action_70081 ] Jesse McConnell commented on CONTINUUM-782: --- short term solution would be to use -Dmaven.repo.local=/path/ in a custom scheduled build, could be that if you set it to something relative to the executing project that the repo could be cleaned up with clean... perhaps a weekly build schedule with goals clean and install with the added commandline option -Dmaven.repo.local="./target/localRepository" would work... > Add a feature to allow cleaning the m2 local repo once every N days > --- > > Key: CONTINUUM-782 > URL: http://jira.codehaus.org/browse/CONTINUUM-782 > Project: Continuum > Issue Type: New Feature > Components: Core system >Affects Versions: 1.0.3 >Reporter: Vincent Massol > > It's really hard with maven to know if your build is working or not. I've > been hit several times already by buillds working fine locally and on the CIs > but failing for a newcomer trying to build that project. The reason is that > remote repos are not immutable and artifacts can disappear or be modified in > there. > It would be nice if continnuum could help notice when this happen. A way to > implement this would to be to configure Continuum to clean its local repo > every N days. -- 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-995) Upload SAAJ Jars
Upload SAAJ Jars Key: MAVENUPLOAD-995 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-995 Project: maven-upload-requests Issue Type: Task Reporter: Dan Diephouse Assigned To: Carlos Sanchez Attachments: saaj-api-1.3-bundle.jar, saaj-impl-1.3-bundle.jar SAAJ is CDDL licensed and from sun -- 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-996) Upload JAX WS API jar
Upload JAX WS API jar - Key: MAVENUPLOAD-996 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-996 Project: maven-upload-requests Issue Type: Task Reporter: Dan Diephouse Attachments: jaxws-api-2.0-bundle.jar The JAX-WS api is CDDL'd and is attached -- 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-997) Upload PJL Compression Servlet Filter
Upload PJL Compression Servlet Filter - Key: MAVENUPLOAD-997 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-997 Project: maven-upload-requests Issue Type: Task Reporter: Dan Diephouse Attachments: pjl-comp-filter-1.6-bundle.jar This is an ASL licensed servlet compression filter -- 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-998) Upload custom jelly for maven
Upload custom jelly for maven - Key: MAVENUPLOAD-998 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-998 Project: maven-upload-requests Issue Type: Task Reporter: Lukas Theussl This is a custom version of jelly-core needed by m1 to fix MAVEN-1691. It is identified by commons-jelly maven commons-jelly 1.0.1-20060717 and was built from svn trunk (r 422982) by reverting the commits that caused http://issues.apache.org/jira/browse/JELLY-230. -- 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: (MSUREFIREREP-3) XML "time" field parse problem
[ http://jira.codehaus.org/browse/MSUREFIREREP-3?page=comments#action_70095 ] Carlos Sanchez commented on MSUREFIREREP-3: --- Try also with the latest maven-surefire-plugin (2.1.3 or 2.2) > XML "time" field parse problem > -- > > Key: MSUREFIREREP-3 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-3 > Project: Maven 2.x Surefire report Plugin > Issue Type: Bug >Reporter: Eduardo Rocha > Assigned To: Johnny R. Ruiz III > Attachments: TEST-br.com.mclaren.prototype.NumberTest.xml > > > There is a parse error with the "time" field when reading values from XML, > when the current locale outputs a time value like "1,078" (which is my case > with locale pt_BR). > [INFO] Generate "Maven Surefire Report" report. > java.lang.NumberFormatException: For input string: "1,078" > at > sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1224) > at java.lang.Float.parseFloat(Float.java:394) > at > org.codehaus.mojo.surefire.ReportTestSuite.startElement(ReportTestSuite.java:78) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:533) > at > com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:798) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFrag > mentScannerImpl.java:878) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(XM > LDocumentScannerImpl.java:1157) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispat > ch(XMLDocumentFragmentScannerImpl.java:1794) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragment > ScannerImpl.java:368) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:375) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:311) > at > org.codehaus.mojo.surefire.ReportTestSuite.(ReportTestSuite.java:59) > at > org.codehaus.mojo.surefire.SurefireReportParser.parseXMLReportFiles(SurefireReportParser.java:44) > at > org.codehaus.mojo.surefire.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:44) > at > org.codehaus.mojo.surefire.SurefireReportMojo.executeReport(SurefireReportMojo.java:77) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) > at > org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.java:842) > ... > I don't know if this bug where supposed to be open in the original > maven-surefire-plugin, since MOJO just reads the XML and produces the HTML. > With maven 1, the XML is written like "1.078", independently of locale. -- 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-2258) Wrong execution order of plugins in same phase
[ http://jira.codehaus.org/browse/MNG-2258?page=comments#action_70086 ] David Hay commented on MNG-2258: I'd actually rate this much higher priority. I've already run into this limitation several times during the development of my project. In particular, I want to run the dependency-maven-plugin:copy followed by the assembly plugin. But maven wants to run them in the opposite order, which doesn't work very well. I've also wanted to run the hibernate3-plugin to generate my DDL followed by an antrun plugin to load some sample data, but I can't be assured that the plugins will run in that order. > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: http://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen > Fix For: 2.1 > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- 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: (SCM-221) scm:update has no effect
[ http://jira.codehaus.org/browse/SCM-221?page=comments#action_70087 ] Yuri Schimke commented on SCM-221: -- We are trying to use the perforce support for three things. 1) scm:update in cruisecontrol - must use existing clientspec 2) maven-changelog-plugin - can use either existing or generated clientspec 3) release - must use generated clienspec 1&2 are run in cruise control, 2&3 are run locally. I guess we should set it just for the cruisecontrol box. Is that the idea? > scm:update has no effect > > > Key: SCM-221 > URL: http://jira.codehaus.org/browse/SCM-221 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.0 > Environment: > http://svn.apache.org/maven-snapshot-repository/org/apache/maven/scm/maven-scm-provider-perforce/1.0-SNAPSHOT/maven-scm-provider-perforce-1.0-20060616.160825-6.jar > >Reporter: Yuri Schimke > Assigned To: Mike Perham >Priority: Critical > > We are trying to use scm:update in a cruisecontrol build to update the > project before building. However it doesn't seem to actually write any > changes to disk. > The command completes successfully, but the files are not synced to head. > The directory for the update is a working perforce directory. i.e. after the > command below fails to update the files, "p4 sync" works immediately. > [INFO] [scm:update] > > [INFO] Checkout working directory: C:\PerforceViews\dms_1.2_dev\dms > > [INFO] Executing: p4 client -i > > [INFO] Executing: p4 client -d > nbk7xsp-B001279A7BC2E-MavenSCM-C:\PerforceViews\dms_1.2_dev\dms > > > Is the generated clientspec just using for determining changesets? There is > a valid clientspec already associated with the current project directory. -- 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: (MRM-121) wrong (incomplete) models returned from search
wrong (incomplete) models returned from search -- Key: MRM-121 URL: http://jira.codehaus.org/browse/MRM-121 Project: Maven Repository Manager Issue Type: Bug Components: indexing Affects Versions: 1.0-beta-1 Reporter: Milos Kleint Priority: Critical Attachments: maven-repository.patch I've started using the trunk of maven repository indexer in the maven support for netbeans. my usecases involve querying what groupIds/artifactId are available for a given prefix (for code completion in pom.xml) consider this usecase: 1. need to get the list of plugin groupIds. artifact repository is not enough as it's not able to query for packaging correctly. -> use pom repository index. 2. feed the repository index with pom models. Need to load the models with MavenProjectBuilder because otherwise the groupId is not declared for most poms unfortunately (as it's declared in the parent pom usually) 3. ERROR. when retrieving the hits based on a query that checks the groupIds, the actual result hit's model is created using only Model reader. thus mostly returning null in groupId field. patch involves creating a super class for defaultindexsearcher and providing 2 implementations based on what approach was chosen when populating the repository index. -- 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: (SCM-221) scm:update has no effect
[ http://jira.codehaus.org/browse/SCM-221?page=comments#action_70088 ] Yuri Schimke commented on SCM-221: -- is maven.scm.persistcheckout the system property to use the existing p4 clientspec > scm:update has no effect > > > Key: SCM-221 > URL: http://jira.codehaus.org/browse/SCM-221 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.0 > Environment: > http://svn.apache.org/maven-snapshot-repository/org/apache/maven/scm/maven-scm-provider-perforce/1.0-SNAPSHOT/maven-scm-provider-perforce-1.0-20060616.160825-6.jar > >Reporter: Yuri Schimke > Assigned To: Mike Perham >Priority: Critical > > We are trying to use scm:update in a cruisecontrol build to update the > project before building. However it doesn't seem to actually write any > changes to disk. > The command completes successfully, but the files are not synced to head. > The directory for the update is a working perforce directory. i.e. after the > command below fails to update the files, "p4 sync" works immediately. > [INFO] [scm:update] > > [INFO] Checkout working directory: C:\PerforceViews\dms_1.2_dev\dms > > [INFO] Executing: p4 client -i > > [INFO] Executing: p4 client -d > nbk7xsp-B001279A7BC2E-MavenSCM-C:\PerforceViews\dms_1.2_dev\dms > > > Is the generated clientspec just using for determining changesets? There is > a valid clientspec already associated with the current project directory. -- 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: (MAVEN-1741) maven 1.1 fails to run commons-attributes in mutliproject mode on a war project
[ http://jira.codehaus.org/browse/MAVEN-1741?page=comments#action_70089 ] Lukas Theussl commented on MAVEN-1741: -- This is _not_ the same as MAVEN-1638. However, I am a bit confused by the attached test case, running war:install in the war project does not generate the attributes, just like in the multiproject case. Maybe something has changed, can someone confirm that with the latest versions of the plugins? > maven 1.1 fails to run commons-attributes in mutliproject mode on a war > project > --- > > Key: MAVEN-1741 > URL: http://jira.codehaus.org/browse/MAVEN-1741 > Project: Maven > Issue Type: Bug >Affects Versions: 1.1-beta-2 >Reporter: nicolas de loof > Assigned To: Lukas Theussl >Priority: Minor > Fix For: 1.1-beta-3 > > Attachments: test_maven11_commons-attributes.zip > > > Attached zip contains a minimalist multiproject using commons-attributes that > demonstrates the bug. > - head (top level project) > - jar (minimalist jar project) : Sample.java has a "java.util.Date" attribute > - war (minimalist war project) : Sample.java has a "java.util.Date" attribute > When runing "maven war:install" on war project, attributes are generated as > expected. > When running from "head" project using "maven multiproject:install", > commons-attributes are > - generated as expected for the jar > - NOT generated in the war (no log from plugin) > I don't know if this is a maven, multiproject-plugin, war-plugin or > commons-attributes-plugin bug. > Please notice commons-attributes plugin uses a preGoal to automatically > register itself. -- 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: (MAVEN-1638) Post goals in plugins only seem to run once
[ http://jira.codehaus.org/browse/MAVEN-1638?page=comments#action_70090 ] Lukas Theussl commented on MAVEN-1638: -- This will be fixed with MAVEN-1691. > Post goals in plugins only seem to run once > --- > > Key: MAVEN-1638 > URL: http://jira.codehaus.org/browse/MAVEN-1638 > Project: Maven > Issue Type: Bug > Components: plugin manager >Affects Versions: 1.1-beta-1 > Environment: Win2k, Maven 1.1-beta 1 installed >Reporter: dion gillard > Fix For: 1.1-beta-3 > > > I have a reactored build which creates many EJB jars via ejb:install-snapshot > The was5 plugin from sourceforge is installed and it has a postGoal defined > on ejb:ejb. > Out of several EJB projects that are built during the reactored build, only > the first EJB project has the postGoal executed, it is skipped for the other > EJB projects -- 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: (MSUREFIREREP-3) XML "time" field parse problem
[ http://jira.codehaus.org/browse/MSUREFIREREP-3?page=comments#action_70093 ] Hugo Palma commented on MSUREFIREREP-3: --- Was the fix released ? I'm still seeing this with version 2.0 of the maven-surefire-report-plugin. > XML "time" field parse problem > -- > > Key: MSUREFIREREP-3 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-3 > Project: Maven 2.x Surefire report Plugin > Issue Type: Bug >Reporter: Eduardo Rocha > Assigned To: Johnny R. Ruiz III > Attachments: TEST-br.com.mclaren.prototype.NumberTest.xml > > > There is a parse error with the "time" field when reading values from XML, > when the current locale outputs a time value like "1,078" (which is my case > with locale pt_BR). > [INFO] Generate "Maven Surefire Report" report. > java.lang.NumberFormatException: For input string: "1,078" > at > sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1224) > at java.lang.Float.parseFloat(Float.java:394) > at > org.codehaus.mojo.surefire.ReportTestSuite.startElement(ReportTestSuite.java:78) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:533) > at > com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:798) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFrag > mentScannerImpl.java:878) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(XM > LDocumentScannerImpl.java:1157) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispat > ch(XMLDocumentFragmentScannerImpl.java:1794) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragment > ScannerImpl.java:368) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:375) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:311) > at > org.codehaus.mojo.surefire.ReportTestSuite.(ReportTestSuite.java:59) > at > org.codehaus.mojo.surefire.SurefireReportParser.parseXMLReportFiles(SurefireReportParser.java:44) > at > org.codehaus.mojo.surefire.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:44) > at > org.codehaus.mojo.surefire.SurefireReportMojo.executeReport(SurefireReportMojo.java:77) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) > at > org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.java:842) > ... > I don't know if this bug where supposed to be open in the original > maven-surefire-plugin, since MOJO just reads the XML and produces the HTML. > With maven 1, the XML is written like "1.078", independently of locale. -- 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: (MSOURCES-6) Sources plugin ignores resource includes/excludes
[ http://jira.codehaus.org/browse/MSOURCES-6?page=comments#action_70094 ] Carlos Sanchez commented on MSOURCES-6: --- A comment about the patch, to keep backwards comaptibility you can't remove non private methods, so you need to refactor your patch to keep old methods while adding the new ones you need, avoiding code duplication > Sources plugin ignores resource includes/excludes > - > > Key: MSOURCES-6 > URL: http://jira.codehaus.org/browse/MSOURCES-6 > Project: Maven 2.x Sources Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Matthew Beermann >Priority: Critical > Fix For: 2.0.2 > > Attachments: maven-sources-plugin-patches.zip, patch.txt > > > The sources plugin appears to ignore the and filters on > items. I discovered this because I have a project that needs to > package certain files that appear in the project root; e.g. > ., and then I certain files. > Trouble is, when the source plugin runs, it packages up EVERYTHING - > including the stuff in the "target" (output) directory! This leads to a > source attachment that's much too large. Worse, if you forget to clean > between builds, the size of the source jar will increase exponentially with > each build. > Checking out the source code at > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractJarSourceMojo.java?view=markup, > I think the problem is in the addDirectories() method, which is simply > adding resource.getDirectory() and dropping the other information on the > floor. -- 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-222) Exception while executing CMS command while anonymous
Exception while executing CMS command while anonymous - Key: SCM-222 URL: http://jira.codehaus.org/browse/SCM-222 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Affects Versions: 1.0-beta-2 Environment: Solaris 10, SunFire V100 Reporter: Charles Richard Priority: Minor I'm new to the following technologies so i imagine this is more of a user problem (ie me) but i can't seem to get around it: I've got Maven 1.0.2 and got the maven-scm-plugin version 1.6. When i execute the following command line to checkout a project as anonymous: maven scm:checkout -Dmaven.scm.url=scm:svn:http://my_ip/svn/portal_name/trunk I get an error "Exception while executing SCM command". I noticed under CVS that somebody said that the path to CVS should be set but i'd like to think that having the scm plugin under Maven would be enough and that Subversion (SVN) would not need to be installed. Charles -- 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-2434) Local snapshots should be preferred over remote ones
[ http://jira.codehaus.org/browse/MNG-2434?page=comments#action_70099 ] Carsten Ziegeler commented on MNG-2434: --- I don't think that this is a dupe: It really downloads the artifacts sometimes not just the poms. We are using the plain SNAPSHOT version. Now perhaps the interesting part is that this happens during a build where these artifacts have just been created and put in the local repository. So a simplified example is, you have two modules A and B, both have the version as SNAPSHOT and B depends on A. Now you build both modules at once, first A gets build and is installed in the local repo, then B gets build, downloads a snapshot of A from the remote server, builds and then uses the local version of B. I'm not exactly sure of this last part, but upto now, everytime changes locally done to A where available in B although B downloaded a SNAPSHOT of A which could not have these local changes. This does not happen always, but from time to time. > Local snapshots should be preferred over remote ones > > > Key: MNG-2434 > URL: http://jira.codehaus.org/browse/MNG-2434 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Carsten Ziegeler > > If you're build a project with snapshots, m2 tries to download the newest > versions of the snapshots even if the local ones are newer. Interestingly > later on, the local versions are used. So the download is useless. > A complex test case for this is the Cocoon project where nearly all modules > are snapshot and locally build. -- 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-92) Allow .classpath generation for plugin-development support
[ http://jira.codehaus.org/browse/MECLIPSE-92?page=comments#action_70100 ] fabrizio giustina commented on MECLIPSE-92: --- Paths in .classpath are now always relative, thanks for reporting this. There is a new snapshot deployed, if anybody wants to give it a try. > Allow .classpath generation for plugin-development support > -- > > Key: MECLIPSE-92 > URL: http://jira.codehaus.org/browse/MECLIPSE-92 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.1 >Reporter: Sachin Patel > Assigned To: fabrizio giustina > Attachments: pde_patch_1.diff > > > In order to improve eclipse plugin development with maven, the configuration > of the eclipse:eclipse goal should allow a flag to be set that that given pom > is an eclipse plugin and the .classpath generated should not add .classpath > entries for dependencies declared in the POM, since plugins really just > reference other plugins in the workspace and or use the "requiredPlugins" > classpath container. At runtime plugins cannot reference external > classes/jars so having all the "var" entries isn't necessary and adds clutter. -- 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-2455) goals should be able to run without using pom.xml even if its available
goals should be able to run without using pom.xml even if its available --- Key: MNG-2455 URL: http://jira.codehaus.org/browse/MNG-2455 Project: Maven 2 Issue Type: New Feature Environment: software platform Reporter: Jagan Priority: Blocker Maven goals should be able to run ignoring a pom.xml even if its present. In my custom made plugin, I want to ignore the pom file. Tried to use @requiresProject false, this ran fine if there is no pom, but if a pom file is available it uses it. Can someone please add a feature to ignore the pom even if its there. maybe like @ignoreProject or something like that. This change looks pretty simple and this issue is blocking our development. Thanks -Jagan -- 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: (MAVENUPLOAD-953) Custom dom4j for Maven 1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-953?page=all ] Arnaud Heritier reopened MAVENUPLOAD-953: - There's cetainly a problem with rewritting rules. I can't access to http://www.ibiblio.org/maven/maven/jars/dom4j-1.7-20060614.jar I receive : Not Found" > Custom dom4j for Maven 1 > > > Key: MAVENUPLOAD-953 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-953 > Project: maven-upload-requests > Issue Type: Task >Reporter: Lukas Theussl > Assigned To: Carlos Sanchez > > This is a custom version of dom4j needed by m1, see MAVEN-1345. It is > identified by > dom4j > maven > dom4j > 1.7-20060614 > and was built from dom4j cvs trunk as of 2006-06-08 with the branch > DOM4J_1_X_BRANCH merged in. -- 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: (CONTINUUM-778) show internal error page on unhandled exceptions
[ http://jira.codehaus.org/browse/CONTINUUM-778?page=comments#action_70109 ] Emmanuel Venisse commented on CONTINUUM-778: ContinuumException can't be a RuntimeException. Perhaps we can split it in two classes, a normal exception and a runtime For exception handling: http://forums.opensymphony.com/thread.jspa;jsessionid=apk1X_F1tR998Gv1cY?messageID=34547蛳 http://wiki.opensymphony.com/display/WW/Exception+Interceptor http://wiki.opensymphony.com/display/WW/Exception+Handling > show internal error page on unhandled exceptions > > > Key: CONTINUUM-778 > URL: http://jira.codehaus.org/browse/CONTINUUM-778 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Affects Versions: 1.0.3 >Reporter: Carlos Sanchez > Fix For: 1.1 > > > It's possible to setup a servlet filter or something similar that maybe > webwork already has (Struts has it) to catch all unhandled exceptions, log > them to the log file and redirect the user to a "internal error" page. > Related to this we should make ContinuumException a RuntimeException, don't > catch it in the web layer and let the previous mechanism do it. We'll save a > lot of exception handling code not needed. > Note that this is only for system exceptions, eg. if database is down, and > not model exceptions, eg. when looking up by id it the record doesn't exist. -- 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: (SCM-221) scm:update has no effect
[ http://jira.codehaus.org/browse/SCM-221?page=comments#action_70111 ] Mike Perham commented on SCM-221: - There is a parameter where you can override the clientspec for SCM to use. I don't have the source in front of me but if you found the persist parameter, you can find this one too. :-p persistcheckout would be used with continuum/cruisecontrol so it does not try to force sync a new copy of the code everytime. By persisting the clientspec, it will use the same clientspec the next time also and Perforce will only update changed files. Otherwise, it creates a temp clientspec, checks it out and deletes it afterwards - which can lead to really long checkout times for large projects. Which sucks if you are building every hour! > scm:update has no effect > > > Key: SCM-221 > URL: http://jira.codehaus.org/browse/SCM-221 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.0 > Environment: > http://svn.apache.org/maven-snapshot-repository/org/apache/maven/scm/maven-scm-provider-perforce/1.0-SNAPSHOT/maven-scm-provider-perforce-1.0-20060616.160825-6.jar > >Reporter: Yuri Schimke > Assigned To: Mike Perham >Priority: Critical > > We are trying to use scm:update in a cruisecontrol build to update the > project before building. However it doesn't seem to actually write any > changes to disk. > The command completes successfully, but the files are not synced to head. > The directory for the update is a working perforce directory. i.e. after the > command below fails to update the files, "p4 sync" works immediately. > [INFO] [scm:update] > > [INFO] Checkout working directory: C:\PerforceViews\dms_1.2_dev\dms > > [INFO] Executing: p4 client -i > > [INFO] Executing: p4 client -d > nbk7xsp-B001279A7BC2E-MavenSCM-C:\PerforceViews\dms_1.2_dev\dms > > > Is the generated clientspec just using for determining changesets? There is > a valid clientspec already associated with the current project directory. -- 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: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_70120 ] Baerrach bonDierne commented on MJAR-28: Most of the comments I have made have been against MASSEMBLY-67 but the bug I believe is definitely in Maven Archiver (no bug has yet been raised for it) MNG-775 doesn't affect this because: - if the artifact is released this bug does not occur - if the artifact is not deployed (only installed) then the correct value is -SNAPSHOT so the only time this problem occurrs is when the artifact is deployed but not yet released. If the artifact is deployed it has been placed in a repository with a timestamped snapshot version (complete with build number) and hence MNG-775 does not apply. My current work around is to manually rename the assembled artifacts to -SNAPSHOT. The notes in MASSEMBLY-67 list the cause of the problem, the use of Project.getRuntimeClasspathElements() instead of using the runtime artifacts. I'm looking into test cases now and should know more by the end of the week. > Using the jar plugin with addClasspath and snapshots can create manifest > classpath with incorrect jar versions > -- > > Key: MJAR-28 > URL: http://jira.codehaus.org/browse/MJAR-28 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark J. Titorenko > > When the POM contains dependencies to snapshot versions of jars, and snapshot > versions of those jars are downloaded from a remote repository, the name of > the jar contained in the classpath added to the manifest, of the form > artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar > downloaded, which contains version information of the form > artifactID-X.X-MMDD.HHmmss-V.jar. > This does not affect snapshot versions which have been directly installed > into a local repository and have no uploaded version within the remote > repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar > form. -- 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-1754) Default goal defined in the POM not used with maven -u
[ http://jira.codehaus.org/browse/MAVEN-1754?page=all ]
Lukas Theussl closed MAVEN-1754.
Assignee: Lukas Theussl (was: Arnaud Heritier)
Resolution: Fixed
Maven 1.0.2 did not show the default goal either with 'maven -u'. I've added
the info, but only when it's specified in the pom (if it's in maven.xml, a
deprecation warning is given anyway).
> Default goal defined in the POM not used with maven -u
> --
>
> Key: MAVEN-1754
> URL: http://jira.codehaus.org/browse/MAVEN-1754
> Project: Maven
> Issue Type: Bug
> Components: cli
>Affects Versions: 1.1-beta-2
>Reporter: Arnaud Heritier
> Assigned To: Lukas Theussl
>Priority: Trivial
> Fix For: 1.1-beta-3
>
>
> When the default goal is defined in the POM and not in the maven.xml, the
> command line 'maven -u' don't print it :
> {noformat}
> D:\OSS\Maven\1.X\SCM\core\trunk>maven -u
> __ __
> | \/ |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
> |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-3-SNAPSHOT
> Project Goals
> =
> [maven] ( NO DEFAULT GOAL )
> jar-install Compile Maven and put a new jar in ${
> maven.home}/lib.
> scripts-install Put scripts in ${maven.home}/bin.
> Undocumented goals :
> maven:build-install
> maven:build-plugin-profile
> maven:build-seed-repo
> maven:generate-install-scripts
> maven:installer
> maven:run-touchstone
> Maven is a project management and project comprehension tool. Maven is
> based on
> the concept of a project object model: builds, documentation creation, site
> publication, and distribution publication are all controlled from the project
> object model. Maven also provides tools to create source metrics, change logs
> based directly on source repository, and source cross-references. You can
> build
> a Maven installation from this source tree by running ant -f
> build-bootstrap.xml
> {noformat}
--
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: (MAVEN-1690) maven 1.1 beta 2 confuses class loaders while compiling plugin-genererated code
[ http://jira.codehaus.org/browse/MAVEN-1690?page=comments#action_70125 ] Lukas Theussl commented on MAVEN-1690: -- I cannot reproduce this with current 1.1-beta-3-SNAPSHOT. > maven 1.1 beta 2 confuses class loaders while compiling plugin-genererated > code > --- > > Key: MAVEN-1690 > URL: http://jira.codehaus.org/browse/MAVEN-1690 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 1.1-beta-2 > Environment: java version "1.4.2_09" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-b05) > Java HotSpot(TM) Client VM (build 1.4.2_09-b05, mixed mode) > Fedora Core 3 Linux on x86 >Reporter: Henning Schmiedehausen >Priority: Critical > Fix For: 1.1-beta-3 > > Attachments: maventest.tar.gz > > > This is a bit complicated to describe, so I've prepared an example to provoke > this bug. > - Unpack the attached maventest.tar.gz > - install the Torque Plugin into your maven by running > maven -DartifactId=maven-torque-plugin -DgroupId=torque -Dversion=3.1.1 > plugin:download > % cd maventest ; maven -q java:compile > build:start: > java:prepare-filesystem: > [mkdir] Created dir: /home/henning/scratch/test/maventest/target/classes > java:compile: > build-om: > torque:init: > BUILD FAILED > File.. /home/henning/.maven/cache/maven-torque-plugin-3.1.1/plugin.jelly > Element... taskdef > Line.. 87 > Column -1 > taskdef A class needed by class > org.apache.torque.task.TorqueJDBCTransformTask cannot be found: > org/apache/xerces/dom/CoreDocumentImpl > The missing class is inside the xerces jar, which is put on the classpath by > the torque plugin (see > http://svn.apache.org/viewcvs.cgi/db/torque/maven-plugin/trunk/plugin.jelly?rev=239621&view=markup, > the torque:init task defines the classpath exactly as described on > http://maven.apache.org/faq.html#classloader-property) > Funnily enough, the "jar:jar" task, which runs java:compile as a prerequisite > works: > % cd maventest ; rm -rf target ; maven -q jar:jar > build:start: > java:prepare-filesystem: > [mkdir] Created dir: /home/henning/scratch/test/maventest/target/classes > java:compile: > build-om: > torque:init: > torque:om-check: > torque:om: > torque:init: > Overriding previous definition of reference to torque-classpath > torque:om-generate: > Using contextProperties file: > /home/henning/scratch/test/maventest/project.properties > [torque-data-model] Using classpath > [torque-data-model] Generating to file > /home/henning/scratch/test/maventest/target/src/report.test.om.generation > Overriding previous definition of reference to maven.compile.src.set > [echo] Compiling to /home/henning/scratch/test/maventest/target/classes > [echo] > == > NOTE: Targetting JVM 1.4, classes > will not run on earlier JVMs > == > [javac] Compiling 5 source files to > /home/henning/scratch/test/maventest/target/classes > [javac] Note: > /home/henning/scratch/test/maventest/target/src/org/test/BaseJobEntryPeer.java > uses or overrides a deprecated API. > [javac] Note: Recompile with -deprecation for details. > java:jar-resources: > test:prepare-filesystem: > [mkdir] Created dir: > /home/henning/scratch/test/maventest/target/test-classes > [mkdir] Created dir: > /home/henning/scratch/test/maventest/target/test-reports > test:test-resources: > test:compile: > [echo] No test source files to compile. > test:test: > [echo] No tests to run. > jar:jar: > [jar] Building jar: > /home/henning/scratch/test/maventest/target/test-1.0.jar > % jar tvf target/test-1.0.jar > 0 Tue Sep 13 22:28:48 CEST 2005 META-INF/ >280 Tue Sep 13 22:28:46 CEST 2005 META-INF/MANIFEST.MF > 0 Tue Sep 13 22:28:48 CEST 2005 org/ > 0 Tue Sep 13 22:28:48 CEST 2005 org/test/ > 0 Tue Sep 13 22:28:48 CEST 2005 org/test/map/ > 7625 Tue Sep 13 22:28:48 CEST 2005 org/test/BaseJobEntry.class > 12288 Tue Sep 13 22:28:48 CEST 2005 org/test/BaseJobEntryPeer.class >311 Tue Sep 13 22:28:48 CEST 2005 org/test/JobEntry.class >288 Tue Sep 13 22:28:48 CEST 2005 org/test/JobEntryPeer.class > 2043 Tue Sep 13 22:28:48 CEST 2005 org/test/map/JobEntryMapBuilder.class > Both tasks, java:compile and jar:jar work fine and as expected using > maven-1.0.2 > This is a test case for a real world example, trying to compile and build the > site for the turbine 2.3.2-rc1 release. The classpath error > occurs when the site build process tries to run jdepend to build the metrics. > So the problem doesn't seem to be part of the plugins or > tasks but of the core. -- This message is automatically generated by JIRA. - If you think it wa
[jira] Created: (MECLIPSE-128) Eclipse goal breaks manually-configured external builder
Eclipse goal breaks manually-configured external builder
Key: MECLIPSE-128
URL: http://jira.codehaus.org/browse/MECLIPSE-128
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Windows, Eclipse 3.1.2
Reporter: Matt Tucker
I'm attempting to specify an external build tool for a project in Eclipse that
does Maven dependency resolution. I do this by:
1. in Eclipse going to Project->Properties->Builders
2. click New
3. select Program, click Ok
4. Specify
Location: ${env_var:MAVEN_HOME}/bin/mvn.bat
Working directory: ${project_loc}
Arguments: eclipse:eclipse
5. Switch to Refresh tab, specify:
[x] Refresh resources upon completion
[*] The project containing ...
6. Click Ok
Specifying this build does two things within Eclipse. It alters the .project
file and adds:
...
org.eclipse.ui.externaltools.ExternalToolBuilder
auto,clean,incremental,
LaunchConfigHandle
/.externalToolBuilders/Maven Builder.launch
...
...
And it creates a file .externalToolBuilders/.launch, which
creates the bulk of the settings for the custom build task.
However, when the eclipse goal is run, the Maven Eclipse plugin alters the
build command specification in .project to be:
org.eclipse.ui.externaltools.ExternalToolBuilder
It's completely throwing away the specified arguments to the buildCommand,
which causes Eclipse to not be able to find the custom build task details,
which causes any subsequent builds to fail. The Maven Eclipse plugin needs to
preserve this information when it writes the .project file for, as far as I can
tell, any auto-building to be useful or even possible.
--
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-2440) NPE during bootstrap
[ http://jira.codehaus.org/browse/MNG-2440?page=all ] Brett Porter closed MNG-2440. - Assignee: Brett Porter (was: John Casey) Resolution: Won't Fix Fix Version/s: (was: 2.1) the bootstrap works since applying the fix to make the modello version inherit in MNG-2447 > NPE during bootstrap > > > Key: MNG-2440 > URL: http://jira.codehaus.org/browse/MNG-2440 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.1 >Reporter: Marvin King > Assigned To: Brett Porter > Attachments: MNG-2440-maven-repository-metadata.patch > > > bootstrapping maven2 creates results in NPE. -- 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: (DOXIA-65) Version of parent pom in doxia doc renderer is not updated in svn
Version of parent pom in doxia doc renderer is not updated in svn - Key: DOXIA-65 URL: http://jira.codehaus.org/browse/DOXIA-65 Project: doxia Issue Type: Bug Environment: maven 2.1-snapshot Reporter: Maria Odea Ching Version should be 1.0-alpha-9-SNAPSHOT instead of 1.0-alpha-8-SNAPSHOT. -- 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: (DOXIA-65) Version of parent pom in doxia doc renderer is not updated in svn
[ http://jira.codehaus.org/browse/DOXIA-65?page=all ] Maria Odea Ching updated DOXIA-65: -- Attachment: doxia-65.patch Attached patch for this issue. > Version of parent pom in doxia doc renderer is not updated in svn > - > > Key: DOXIA-65 > URL: http://jira.codehaus.org/browse/DOXIA-65 > Project: doxia > Issue Type: Bug > Environment: maven 2.1-snapshot >Reporter: Maria Odea Ching > Attachments: doxia-65.patch > > > Version should be 1.0-alpha-9-SNAPSHOT instead of 1.0-alpha-8-SNAPSHOT. -- 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: (DOXIA-66) Version of parent pom in doxia editor is not updated in svn. Also the doxia core dependency.
Version of parent pom in doxia editor is not updated in svn. Also the doxia core dependency. Key: DOXIA-66 URL: http://jira.codehaus.org/browse/DOXIA-66 Project: doxia Issue Type: Bug Environment: maven 2.1-snapshot Reporter: Maria Odea Ching Attachments: DOXIA-66.patch Parent pom version should be 1.0-alpha-9-SNAPSHOT instead of 1.0-alpha-8-SNAPSHOT. doxia core dependency version should be 1.0-alpha-8 instead of 1.0-alpha-8-SNAPSHOT. -- 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: (DOXIA-66) Version of parent pom in doxia editor is not updated in svn. Also the doxia core dependency.
[ http://jira.codehaus.org/browse/DOXIA-66?page=all ] Maria Odea Ching updated DOXIA-66: -- Attachment: DOXIA-66.patch Attached patch file for this issue. > Version of parent pom in doxia editor is not updated in svn. Also the doxia > core dependency. > > > Key: DOXIA-66 > URL: http://jira.codehaus.org/browse/DOXIA-66 > Project: doxia > Issue Type: Bug > Environment: maven 2.1-snapshot >Reporter: Maria Odea Ching > Attachments: DOXIA-66.patch > > > Parent pom version should be 1.0-alpha-9-SNAPSHOT instead of > 1.0-alpha-8-SNAPSHOT. > doxia core dependency version should be 1.0-alpha-8 instead of > 1.0-alpha-8-SNAPSHOT. -- 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: (WAGON-55) Provide support for HTTP compression (request and response)
[ http://jira.codehaus.org/browse/WAGON-55?page=comments#action_70130 ] Nathan Beyer (Apache) commented on WAGON-55: Is there anyway to remove 'wagon-webdav' and the related patch from this issue? I'd like to try and get the lightweight-http and http patches to move forward without being held up by WebDAV. Thanks. > Provide support for HTTP compression (request and response) > --- > > Key: WAGON-55 > URL: http://jira.codehaus.org/browse/WAGON-55 > Project: wagon > Issue Type: New Feature > Components: wagon-http, wagon-http-lightweight, wagon-webdav >Reporter: Nathan Beyer (Cerner) > Attachments: gzip_patch.diff, HttpWagonGzipTest.java, > lightweight_gzip_patch.diff, LightweightHttpWagonGzipTest.java, > webdav_gzip_patch.diff > > > Implement support for HTTP-based wagon providers to utilize HTTP compression > (gzip?). For downloads, this would entail sending Accept-Encoding headers to > indicate that a server can compress the response. For uploads, as with > WebDAV, this would entail compressing the content and setting the appropriate > Content-Type values. -- 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: (MEV-425) plexus-container-default, junit scope compile is bad
plexus-container-default, junit scope compile is bad Key: MEV-425 URL: http://jira.codehaus.org/browse/MEV-425 Project: Maven Evangelism Issue Type: Bug Components: Dependencies Reporter: David Smiley Has junit as a compile-time dependency, instead of test or even optional, which is causing it to end up in my war file, I believe. -- 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-1493) Support in multiproject environment modules with different named POMs
[ http://jira.codehaus.org/browse/MNG-1493?page=comments#action_70132 ] Brett Porter commented on MNG-1493: --- sure, but that means we need to support an entry as either a directory or a pom file - won't that be too inconsistent? > Support in multiproject environment modules with different named POMs > - > > Key: MNG-1493 > URL: http://jira.codehaus.org/browse/MNG-1493 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0 >Reporter: Joerg Schaible >Priority: Minor > Fix For: 2.1 > > > Command line version of Maven 2 supports POMs with a different name using the > -f option. Unfortunately such POMs cannot be used as modules, since the value > of the module tag is defined as a directory to another pom.xml instead of a > pathname to another POM. Only if the value is not already an existing file > the value should be treated as directory with a present pom.xml file. Similar > situation applies to the relativePath element of the parent tag. > This makes the generation of different artifacts from the same sources (with > some modifications) much more easy. Currently you will have to put the POMs > in separate directories and modify the sourec location into another module. -- 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: (MRESOURCES-23) Review Plugin Documentation
[ http://jira.codehaus.org/browse/MRESOURCES-23?page=all ]
Franz Allan Valencia See updated MRESOURCES-23:
---
Attachment: MRESOURCES-23-maven-resources-plugin-2.2.patch
In the whole documentation
changed "main code" to "main source code"
changed all similar occurence of "copy or transfer" to "copy"
In index.html
changed "This, thus, allows the separation ..." to "Thus, this allows the
separation... "
(reported by Edwin Punzalan)
changed "Resources are categorized into two" to "Resources come in two"
changed all occurences of "resources of" to "resources for"
changed "Javadoc Plugin" to "Resources Plugin"
(reported by Dennis Lundberg)
In encoding.html
changed "UTF-8" to "UTF-8"
(reported by Edwin Punzalan)
In FAQ.html
changed "The Maven Resource Plugin only allwos encoding values..." to "The
Maven Resource Plugin only allows encoding values..."
(reported by Dennis Lundberg)
In filter.html
changed "we can sdo so" to "we can do so"
(reported by Dennis Lundberg)
changed "$... delimeters" to "${...} delimiters"
In include-exclude.html
changed "And to excludes a resource" to "And to exclude a resource"
changed "need to add an exclude tag" to "need to add an excludes tag"
changed "non-resource file #1" to "non-resource file #2", "non-resource file
#3", and "non-resource file #n"
(reported by Dennis Lundberg)
changed "To include a file" to "To include a resource"
In ResourcesMojo.java
changed "Copy application resources" to "Copy resources for the main source
code to the main output directory"
In site.xml
changed all occurences of "Maven Resource Report" to "Maven Resource Plugin"
(reported by Dennis Lundberg)
In TestResourcesMojo.java
changed "Copy test resources" to "Copy resources for the test source code to
the test output directory."
> Review Plugin Documentation
> ---
>
> Key: MRESOURCES-23
> URL: http://jira.codehaus.org/browse/MRESOURCES-23
> Project: Maven 2.x Resources Plugin
> Issue Type: Task
>Reporter: Allan Ramirez
> Assigned To: Allan Ramirez
> Attachments: MRESOURCES-23-maven-resources-plugin-2.2.patch,
> MRESOURCES-23-maven-resources-plugin-2.patch,
> MRESOURCES-23-maven-resources-plugin.patch
>
> Original Estimate: 13 hours
> Time Spent: 2 hours
> Remaining Estimate: 11 hours
>
--
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: (CONTINUUM-419) Can't click to see the latest build results from the main page
[ http://jira.codehaus.org/browse/CONTINUUM-419?page=all ] Brett Porter updated CONTINUUM-419: --- Fix Version/s: (was: 1.0.3) 1.1 > Can't click to see the latest build results from the main page > -- > > Key: CONTINUUM-419 > URL: http://jira.codehaus.org/browse/CONTINUUM-419 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.0 >Reporter: David Blevins > Assigned To: Emmanuel Venisse >Priority: Trivial > Fix For: 1.1 > > > When you are at the projects page (Summary.vm/fid/continuumProject) it's > really annoying you can't just click somewhere and see the latest build > results. You have to click "Build History" then the top "results" item, > which is a big of traveling. -- 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-1493) Support in multiproject environment modules with different named POMs
[ http://jira.codehaus.org/browse/MNG-1493?page=comments#action_70135 ] Joerg Schaible commented on MNG-1493: - Why? If you specify a path only, "pom.xml" is simply the default. The relativePath element of the parent should behave in exactly the same way (docs seem to imply that you have to specify the pom.xml, the path alone will not do - despite the tag name). > Support in multiproject environment modules with different named POMs > - > > Key: MNG-1493 > URL: http://jira.codehaus.org/browse/MNG-1493 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0 >Reporter: Joerg Schaible >Priority: Minor > Fix For: 2.1 > > > Command line version of Maven 2 supports POMs with a different name using the > -f option. Unfortunately such POMs cannot be used as modules, since the value > of the module tag is defined as a directory to another pom.xml instead of a > pathname to another POM. Only if the value is not already an existing file > the value should be treated as directory with a present pom.xml file. Similar > situation applies to the relativePath element of the parent tag. > This makes the generation of different artifacts from the same sources (with > some modifications) much more easy. Currently you will have to put the POMs > in separate directories and modify the sourec location into another module. -- 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-2258) Wrong execution order of plugins in same phase
[ http://jira.codehaus.org/browse/MNG-2258?page=comments#action_70136 ] Martin Zeltner commented on MNG-2258: - I'd rate this issue much higher too. I've already solved the order problem with dependencies (see MNG-1412) and this issue can be solved equivalently. > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: http://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen > Fix For: 2.1 > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- 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
