[jira] Work stopped: (MRM-358) Update Consumers button in Database - Artifact Scanning doesn't work
[ http://jira.codehaus.org/browse/MRM-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-358 stopped by Napoleon Esmundo C. Ramirez. > Update Consumers button in Database - Artifact Scanning doesn't work > > > Key: MRM-358 > URL: http://jira.codehaus.org/browse/MRM-358 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 >Reporter: Dawn Angelito >Assignee: Napoleon Esmundo C. Ramirez >Priority: Critical > Fix For: 1.0-alpha-2 > > > 1) Log in as admin. > 2) Click the Database button in the left menu under Administration. > 3) In Database - Unprocessed Artifacts Scanning, uncheck > "validate-repository-metadata" to disable it. > 4) Click the Update Consumers button. > Once the page is refreshed, notice that "validate-repository-metadata" is > still enabled. > Note: Try the same procedure in Database - Artifact Cleanup Scanning. The > changes made will not be saved. -- 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: (MRM-358) Update Consumers button in Database - Artifact Scanning doesn't work
[ http://jira.codehaus.org/browse/MRM-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Napoleon Esmundo C. Ramirez updated MRM-358: Attachment: MRM-358-archiva-webapp.patch The code in trunk doesn't do anything yet. The patch includes working stuff, updates the cron and consumers. Dunno what the Update Database button does. > Update Consumers button in Database - Artifact Scanning doesn't work > > > Key: MRM-358 > URL: http://jira.codehaus.org/browse/MRM-358 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 >Reporter: Dawn Angelito >Assignee: Napoleon Esmundo C. Ramirez >Priority: Critical > Fix For: 1.0-alpha-2 > > Attachments: MRM-358-archiva-webapp.patch > > > 1) Log in as admin. > 2) Click the Database button in the left menu under Administration. > 3) In Database - Unprocessed Artifacts Scanning, uncheck > "validate-repository-metadata" to disable it. > 4) Click the Update Consumers button. > Once the page is refreshed, notice that "validate-repository-metadata" is > still enabled. > Note: Try the same procedure in Database - Artifact Cleanup Scanning. The > changes made will not be saved. -- 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] Work started: (MRM-357) Update Consumers button in Repository Scanning doesn't work
[ http://jira.codehaus.org/browse/MRM-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-357 started by Napoleon Esmundo C. Ramirez. > Update Consumers button in Repository Scanning doesn't work > --- > > Key: MRM-357 > URL: http://jira.codehaus.org/browse/MRM-357 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 1.0-alpha-1 >Reporter: Dawn Angelito >Assignee: Napoleon Esmundo C. Ramirez >Priority: Critical > Fix For: 1.0-alpha-2 > > > 1) Log in as admin. > 2) Click the Repository Scanning button in the left menu under Administration. > 3) In Repository Scanning - Consumers of Known Content, check > "validate-checksums" to enable it. > 4) Click the Update Consumers button. > Once the page is refreshed, notice that "validate-checksums" is still > disabled. -- 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-407) "Scanned" is always set to true even if unchecked in the Edit Repository page
"Scanned" is always set to true even if unchecked in the Edit Repository page - Key: MRM-407 URL: http://jira.codehaus.org/browse/MRM-407 Project: Archiva Issue Type: Bug Components: repository interface Reporter: Dawn Angelito Steps: 1) Log in as admin. 2) In the left menu, under Administration, click Repositories. 3) Edit a repository. 4) Uncheck "Scanned". 5) Click Update Repository. Notice that "Scanned" is still set to "True" after saving. This is also true for "Releases Included" (see MRM-374). -- 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: (MRM-381) Find artifact always displays error message even with a valid file input.
[ http://jira.codehaus.org/browse/MRM-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Teodoro Cue Jr. updated MRM-381: Attachment: MRM-381-archiva-webapp.patch Patch attached. The patch addresses the issue that the checksum is not pass from the JSP to the action. The final fix on this is dependent on MRM-376. > Find artifact always displays error message even with a valid file input. > - > > Key: MRM-381 > URL: http://jira.codehaus.org/browse/MRM-381 > Project: Archiva > Issue Type: Bug > Components: browser >Affects Versions: 1.0-alpha-1 > Environment: JDK 1.5, Windows XP, Firefox 1.5.0.11 >Reporter: Maria Cristina Malonzo >Priority: Blocker > Fix For: 1.0-alpha-1 > > Attachments: MRM-381-archiva-webapp.patch > > > Steps: > 1. Click on the "Find Artifact" on the left menu. > 2. On the search field, click on browse and select a valid jar (for example, > ant-1.5.jar) > 3. Hit the "Go!" button. > Notice that even though you selected a valid jar, it always prompts the error > message saying " You must select a file, or enter the checksum. If the file > was given and you receive this message, there may have been an error > generating the checksum." -- 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: (MRM-357) Update Consumers button in Repository Scanning doesn't work
[ http://jira.codehaus.org/browse/MRM-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Napoleon Esmundo C. Ramirez updated MRM-357: Attachment: MRM-357-archiva-webapp.patch Patch contains the fix that updates the consumers in the Repository Scanning page. > Update Consumers button in Repository Scanning doesn't work > --- > > Key: MRM-357 > URL: http://jira.codehaus.org/browse/MRM-357 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 1.0-alpha-1 >Reporter: Dawn Angelito >Assignee: Napoleon Esmundo C. Ramirez >Priority: Critical > Fix For: 1.0-alpha-2 > > Attachments: MRM-357-archiva-webapp.patch > > > 1) Log in as admin. > 2) Click the Repository Scanning button in the left menu under Administration. > 3) In Repository Scanning - Consumers of Known Content, check > "validate-checksums" to enable it. > 4) Click the Update Consumers button. > Once the page is refreshed, notice that "validate-checksums" is still > disabled. -- 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] Work stopped: (MRM-357) Update Consumers button in Repository Scanning doesn't work
[ http://jira.codehaus.org/browse/MRM-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-357 stopped by Napoleon Esmundo C. Ramirez. > Update Consumers button in Repository Scanning doesn't work > --- > > Key: MRM-357 > URL: http://jira.codehaus.org/browse/MRM-357 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 1.0-alpha-1 >Reporter: Dawn Angelito >Assignee: Napoleon Esmundo C. Ramirez >Priority: Critical > Fix For: 1.0-alpha-2 > > Attachments: MRM-357-archiva-webapp.patch > > > 1) Log in as admin. > 2) Click the Repository Scanning button in the left menu under Administration. > 3) In Repository Scanning - Consumers of Known Content, check > "validate-checksums" to enable it. > 4) Click the Update Consumers button. > Once the page is refreshed, notice that "validate-checksums" is still > disabled. -- 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: (MRM-376) Clicking an artifact in the Search Results page results to HTTP ERROR: 500
[ http://jira.codehaus.org/browse/MRM-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97666 ] Maria Odea Ching commented on MRM-376: -- Re: MRM-402 I found out that the problem with the commons-dbcp-1.0 artifact was that its version in the pom is '1.0-dev', but when you browse that artifact from the results page.. the version that is queried is '1.0' thus the JDOObjectNotFoundException. Is this still an archiva problem? or is it with the pom. Also, I found out that some artifacts that have parent projects are getting the same error JDOObjectNotFoundException because it wasn't added to the database due to a 'null' origin field. I think the problem is during the merging of the parent poms. Will comment more on this issue later on. > Clicking an artifact in the Search Results page results to HTTP ERROR: 500 > -- > > Key: MRM-376 > URL: http://jira.codehaus.org/browse/MRM-376 > Project: Archiva > Issue Type: Bug > Components: browser >Reporter: Dawn Angelito >Assignee: Maria Odea Ching >Priority: Blocker > Fix For: 1.0-alpha-1 > > > Steps: > 1) On the left menu, under Find, click Search. > 2) Enter a keyword that you want to search. (e.g. ant) > 3) Click Submit. The search results will be displayed. > 4) Click an artifact from the list. (In my case, I clicked "ant".) > Resulted to: > HTTP ERROR: 500 > Unable to find Database Object [ant:ant:1.6::pom] of type > org.apache.maven.archiva.model.ArchivaArtifactModel using no fetch-group > RequestURI=/archiva/browse/ant/ant/1.6 -- 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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97667 ] Brett Porter commented on MASSEMBLY-54: --- Arnaud - did it work in 2.1? We should create a new issue rather than reopening something in an already released version. > Unable to filter files while creating assembly > -- > > Key: MASSEMBLY-54 > URL: http://jira.codehaus.org/browse/MASSEMBLY-54 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Chris Hagmann >Assignee: Allan Ramirez > Fix For: 2.1 > > Original Estimate: 6 hours > Time Spent: 12 hours > Remaining Estimate: 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: (MASSEMBLY-54) Unable to filter files while creating assembly
[ http://jira.codehaus.org/browse/MASSEMBLY-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MASSEMBLY-54. - Resolution: Fixed re-closing for the original fix. See MASSEMBLY-154 for the addition to filterSet (patch included). > Unable to filter files while creating assembly > -- > > Key: MASSEMBLY-54 > URL: http://jira.codehaus.org/browse/MASSEMBLY-54 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Chris Hagmann >Assignee: Allan Ramirez > Fix For: 2.1 > > Original Estimate: 6 hours > Time Spent: 12 hours > Remaining Estimate: 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] Commented: (MRM-376) Clicking an artifact in the Search Results page results to HTTP ERROR: 500
[ http://jira.codehaus.org/browse/MRM-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97670 ] Brett Porter commented on MRM-376: -- I think it's still an Archiva problem, as it should have detected and rejected the invalid POM rather than putting it into the database (and recorded it as an error so that it could be cleaned up/fixed later). > Clicking an artifact in the Search Results page results to HTTP ERROR: 500 > -- > > Key: MRM-376 > URL: http://jira.codehaus.org/browse/MRM-376 > Project: Archiva > Issue Type: Bug > Components: browser >Reporter: Dawn Angelito >Assignee: Maria Odea Ching >Priority: Blocker > Fix For: 1.0-alpha-1 > > > Steps: > 1) On the left menu, under Find, click Search. > 2) Enter a keyword that you want to search. (e.g. ant) > 3) Click Submit. The search results will be displayed. > 4) Click an artifact from the list. (In my case, I clicked "ant".) > Resulted to: > HTTP ERROR: 500 > Unable to find Database Object [ant:ant:1.6::pom] of type > org.apache.maven.archiva.model.ArchivaArtifactModel using no fetch-group > RequestURI=/archiva/browse/ant/ant/1.6 -- 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-206) Filtering does not work when using in fileSet inside moduleSet
[ http://jira.codehaus.org/browse/MASSEMBLY-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97672 ] serxio commented on MASSEMBLY-206: -- Also fails outside moduleSet. This is my descriptor: SNAPSHOT tar.gz true README* LICENSE* NOTICE* target lib *.jar src/main/bin bin * true unix 0744 src/main/config config * true unix 0644 > Filtering does not work when using in fileSet inside moduleSet > -- > > Key: MASSEMBLY-206 > URL: http://jira.codehaus.org/browse/MASSEMBLY-206 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 > Environment: win32 >Reporter: Liya Jan > > i have a descriptor : > > > com.cc:module1 > com.cc:module2 > com.cc:module3 > > > > > src/main > true > core > > conf/* > > > > false > > > and although there is "true", the copied sources are not > filtered. -- 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: (MCLOVER-70) Non-Clovered Jars used for Transitive Dependencies
[ http://jira.codehaus.org/browse/MCLOVER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97677 ] Thomas Leonard commented on MCLOVER-70: --- We have the same problem. Applying the patch fixes it, but I have to compile the plugin with tests disabled (revision 535629), otherwise I get: --- T E S T S --- Running org.apache.maven.plugin.clover.internal.CloverMojoTest [debug] Loading license from classpath [targetFile] [debug] Using license file [targetFile] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec Running org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.099 sec <<< FAILURE! Results : Failed tests: testSwizzleCloverDependenciesWhenCloveredVersionOfDependencyIsNewerThanOriginal(org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest) testSwizzleCloverDependenciesWhenOriginalVersionOfDependencyIsNewerThanCloveredOne(org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest) Tests run: 6, Failures: 2, Errors: 0, Skipped: 0 The actual error is: --- Test set: org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest --- Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.098 sec <<< FAILURE! testSwizzleCloverDependenciesWhenCloveredVersionOfDependencyIsNewerThanOriginal(org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest) Time elapsed: 0.031 sec <<< FAILURE! org.jmock.core.DynamicMockError: mockArtifact: no match found Invoked: org.apache.maven.artifact.Artifact.getVersionRange() Allowed: stub: getClassifier, returns stub: getGroupId, returns stub: getArtifactId, returns stub: getVersion, returns stub: getType, returns stub: getScope, returns stub: getFile, returns stub: getId, returns stub: setScope, is void at org.jmock.core.AbstractDynamicMock.mockInvocation(Unknown Source) at org.jmock.core.CoreMock.invoke(Unknown Source) at $Proxy2.getVersionRange(Unknown Source) at org.apache.maven.plugin.clover.CloverInstrumentInternalMojo.swizzleCloverDependencies(CloverInstrumentInternalMojo.java:254) at org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest.testSwizzleCloverDependenciesWhenCloveredVersionOfDependencyIsNewerThanOriginal(CloverInstrumentInternalMojoTest.java:112) at org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest.testSwizzleCloverDependenciesWhenCloveredVersionOfDependencyIsNewerThanOriginal(CloverInstrumentInternalMojoTest.java:112) > Non-Clovered Jars used for Transitive Dependencies > -- > > Key: MCLOVER-70 > URL: http://jira.codehaus.org/browse/MCLOVER-70 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: James Olsen > Attachments: mclover-70.patch > > > When executing tests or building ear/war archives, the plugin is not using > instrumented jars for transitive dependencies. The ordinary jar is used > instead. Hence no test coverage stats are obtained for those components. > Adding the transitive dependency as a direct dependency on the project > results in both the instrumented and plain jar appearing in the archive. I > presume the same also happens for the unit test classpath although I haven't > confirmed. > The plugin should use the instrumented version of the jar where available > regardless of whether the dependency is direct or transitive. -- 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: (MRM-381) Find artifact always displays error message even with a valid file input.
[ http://jira.codehaus.org/browse/MRM-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-381. Resolution: Fixed Applied submitted patch. Fixed in -r543109 > Find artifact always displays error message even with a valid file input. > - > > Key: MRM-381 > URL: http://jira.codehaus.org/browse/MRM-381 > Project: Archiva > Issue Type: Bug > Components: browser >Affects Versions: 1.0-alpha-1 > Environment: JDK 1.5, Windows XP, Firefox 1.5.0.11 >Reporter: Maria Cristina Malonzo >Assignee: Maria Odea Ching >Priority: Blocker > Fix For: 1.0-alpha-1 > > Attachments: MRM-381-archiva-webapp.patch > > > Steps: > 1. Click on the "Find Artifact" on the left menu. > 2. On the search field, click on browse and select a valid jar (for example, > ant-1.5.jar) > 3. Hit the "Go!" button. > Notice that even though you selected a valid jar, it always prompts the error > message saying " You must select a file, or enter the checksum. If the file > was given and you receive this message, there may have been an error > generating the checksum." -- 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: (MAVENUPLOAD-1574) Upload Hibernate Entity Manager 3.3.1.ga
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Valikov updated MAVENUPLOAD-1574: - Attachment: hibernate-entitymanager-3.3.1.ga-bundle.jar Sorry, my fault. Bundles are corrected. Should I create new issues or how do we proceed? > Upload Hibernate Entity Manager 3.3.1.ga > > > Key: MAVENUPLOAD-1574 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1574 > Project: maven-upload-requests > Issue Type: Task >Reporter: Aleksei Valikov > Attachments: hibernate-entitymanager-3.3.1.ga-bundle.jar, > hibernate-entitymanager-3.3.1.ga-bundle.jar > > > Emmanuel Bernard of Hibernate has asked me to overtake Ibiblio uploading for > Hibernate Entity Manager. > Please see http://opensource.atlassian.com/projects/hibernate/browse/EJB-287 > for details (I'm the assignee of the issue). -- 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: (MAVENUPLOAD-1575) Upload Hibernate Validator 3.0.0.ga
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Valikov updated MAVENUPLOAD-1575: - Attachment: hibernate-validator-3.0.0.ga-bundle.jar Sorry, my fault. Bundles are corrected. Should I create new issues or how do we proceed? > Upload Hibernate Validator 3.0.0.ga > --- > > Key: MAVENUPLOAD-1575 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1575 > Project: maven-upload-requests > Issue Type: Task >Reporter: Aleksei Valikov > Attachments: hibernate-validator-3.0.0.ga-bundle.jar, > hibernate-validator-3.0.0.ga-bundle.jar > > > Emmanuel Bernard of Hibernate has asked me to overtake Ibiblio uploading for > Hibernate Entity Manager. Hibernate Validator is one of dependencies. > Please see http://opensource.atlassian.com/projects/hibernate/browse/EJB-287 > for details (I'm the assignee of the issue). -- 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] Work stopped: (MRM-376) Clicking an artifact in the Search Results page results to HTTP ERROR: 500
[ http://jira.codehaus.org/browse/MRM-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-376 stopped by Maria Odea Ching. > Clicking an artifact in the Search Results page results to HTTP ERROR: 500 > -- > > Key: MRM-376 > URL: http://jira.codehaus.org/browse/MRM-376 > Project: Archiva > Issue Type: Bug > Components: browser >Reporter: Dawn Angelito >Assignee: Maria Odea Ching >Priority: Blocker > Fix For: 1.0-alpha-1 > > > Steps: > 1) On the left menu, under Find, click Search. > 2) Enter a keyword that you want to search. (e.g. ant) > 3) Click Submit. The search results will be displayed. > 4) Click an artifact from the list. (In my case, I clicked "ant".) > Resulted to: > HTTP ERROR: 500 > Unable to find Database Object [ant:ant:1.6::pom] of type > org.apache.maven.archiva.model.ArchivaArtifactModel using no fetch-group > RequestURI=/archiva/browse/ant/ant/1.6 -- 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: (MRM-376) Clicking an artifact in the Search Results page results to HTTP ERROR: 500
[ http://jira.codehaus.org/browse/MRM-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97692 ] Maria Odea Ching commented on MRM-376: -- Fixed the problem when the artifact has a parent project -r543115. The main cause of the problem was a 'null' origin in the parent pom, thereby causing the JDO exception of not being able to save to object thus the JDOObjectNotFoundException when searching/browsing the artifact. I'll look into the other problem again, and fix it up. Thanks! > Clicking an artifact in the Search Results page results to HTTP ERROR: 500 > -- > > Key: MRM-376 > URL: http://jira.codehaus.org/browse/MRM-376 > Project: Archiva > Issue Type: Bug > Components: browser >Reporter: Dawn Angelito >Assignee: Maria Odea Ching >Priority: Blocker > Fix For: 1.0-alpha-1 > > > Steps: > 1) On the left menu, under Find, click Search. > 2) Enter a keyword that you want to search. (e.g. ant) > 3) Click Submit. The search results will be displayed. > 4) Click an artifact from the list. (In my case, I clicked "ant".) > Resulted to: > HTTP ERROR: 500 > Unable to find Database Object [ant:ant:1.6::pom] of type > org.apache.maven.archiva.model.ArchivaArtifactModel using no fetch-group > RequestURI=/archiva/browse/ant/ant/1.6 -- 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] Work started: (MRM-376) Clicking an artifact in the Search Results page results to HTTP ERROR: 500
[ http://jira.codehaus.org/browse/MRM-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-376 started by Maria Odea Ching. > Clicking an artifact in the Search Results page results to HTTP ERROR: 500 > -- > > Key: MRM-376 > URL: http://jira.codehaus.org/browse/MRM-376 > Project: Archiva > Issue Type: Bug > Components: browser >Reporter: Dawn Angelito >Assignee: Maria Odea Ching >Priority: Blocker > Fix For: 1.0-alpha-1 > > > Steps: > 1) On the left menu, under Find, click Search. > 2) Enter a keyword that you want to search. (e.g. ant) > 3) Click Submit. The search results will be displayed. > 4) Click an artifact from the list. (In my case, I clicked "ant".) > Resulted to: > HTTP ERROR: 500 > Unable to find Database Object [ant:ant:1.6::pom] of type > org.apache.maven.archiva.model.ArchivaArtifactModel using no fetch-group > RequestURI=/archiva/browse/ant/ant/1.6 -- 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: (MRM-406) Replace the archiva.version propertry with project.version
[ http://jira.codehaus.org/browse/MRM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97696 ] Joakim Erdfelt commented on MRM-406: Try it yourself. # Change from archiva.version to project.version # When in trunk build the entire archiva - [trunk]$ mvn clean install # Make a change to archiva-database. #* This is key piece of showing this failure. #* The change should be obvious, to show that archiva-database functionality has been updated. # Now build just database - [trunk/archiva-database]$ mvn clean install # Now execute the webapp - [trunk/archiva-web/archiva-webapp]$ mvn clean jetty:run At this point you'll either get build failures, or when executing the webapp, you are *NOT* using the latest archiva-database. What happens. # The install process changes the SNAPSHOT in the pom to a TIMESTAMP(a). # The installing everything works, as the TIMESTAMP(a)s are all the same. # Installing the archiva-database project causes a new TIMESTAMP(b) to be created for it. # Running the archiva-webapp, uses the parent-pom reference as SNAPSHOT, which resolves to TIMESTAMP(a), and as such, the archiva-database it uses is the old TIMESTAMP(a) version, not the intended TIMESTAMP(b) version. This is a *well known* issue with maven. We've hit this with redback too. It uses the same technique. I can't speak for continuum. I contend that this is *not* and issue with archiva, but an issue with the maven-release-plugin, for not performing the updates to the versions correctly. Solution: # Fix the maven-release-plugin to do version updates correctly. > Replace the archiva.version propertry with project.version > -- > > Key: MRM-406 > URL: http://jira.codehaus.org/browse/MRM-406 > Project: Archiva > Issue Type: Improvement >Affects Versions: 1.0-alpha-1 >Reporter: Franz Allan Valencia See >Assignee: Joakim Erdfelt > Fix For: 1.0-alpha-1 > > Attachments: MRM-406-archiva-parent.patch > > > There is no need for the archiva.version property in the pom because this can > be represented by the project.version property. Furthermore this can cause > problems when doing a release with continuum. -- 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: (MRESOURCES-8) maven-resources-plugin ignores configuration/resources property
[
http://jira.codehaus.org/browse/MRESOURCES-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97698
]
Stian commented on MRESOURCES-8:
- over a year later -
Any answers to Andreas' questions yet?
> maven-resources-plugin ignores configuration/resources property
> ---
>
> Key: MRESOURCES-8
> URL: http://jira.codehaus.org/browse/MRESOURCES-8
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Reporter: Leszek Gawron
>Assignee: Brett Porter
> Attachments: example.zip, MRESOURCES-8-workaround.patch, pom.xml
>
>
> I am evaluating maven + eclipse combo. In a trivial POM filtered resources
> exist only in target/classes. If one executes Project -> Clean under eclipse
> this information is lost. If filtered resources would appear as source folder
> they would survive cleaning and not got overriden by unfiltered ones.
> I have been trying to implement a scenario which would allow filtered
> resources to appear as "static" source folder under eclipse.
> The POM explains it best:
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.mobilebox.squash.client
> squash-client
> jar
> 1.0-SNAPSHOT
> Maven Quick Start Archetype
> http://maven.apache.org
>
>
>
> maven-resources-plugin
>
>
> prefilter-resources
> generate-resources
>
> resources
>
>
>
> target/generated-resources
>
>
>
> src/main/resource-templates
> true
>
>
>
>
>
>
>
>
> ${ffile}
>
>
>
> src/main/resources
>
>
> target/generated-resources
>
>
>
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
> filter.properties
>
>
> thing is this part:
>
>
> src/main/properties
> true
>
>
> is completely ignored. Instead for both maven-resource-plugin executions (the
> one in generate-resources phase and the default one) this config is used:
>
>
> src/main/resources
>
>
> target/generated-resources
>
>
> which of course breaks the whole idea.
> Is this a bug or a design decision. In latter case is there any equivalent
> approach I might take?
--
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] Issue Comment Edited: (MCLOVER-70) Non-Clovered Jars used for Transitive Dependencies
[ http://jira.codehaus.org/browse/MCLOVER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97677 ] Thomas Leonard edited comment on MCLOVER-70 at 5/31/07 7:41 AM: We have the same problem (two jars in classpath: clover and normal). Applying the patch fixes that, although it still doesn't use the clover version for transitive dependencies not given in the pom.xml. Note: I have to compile the plugin with tests disabled (revision 535629), otherwise I get: --- T E S T S --- Running org.apache.maven.plugin.clover.internal.CloverMojoTest [debug] Loading license from classpath [targetFile] [debug] Using license file [targetFile] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec Running org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.099 sec <<< FAILURE! Results : Failed tests: testSwizzleCloverDependenciesWhenCloveredVersionOfDependencyIsNewerThanOriginal(org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest) testSwizzleCloverDependenciesWhenOriginalVersionOfDependencyIsNewerThanCloveredOne(org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest) Tests run: 6, Failures: 2, Errors: 0, Skipped: 0 The actual error is: --- Test set: org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest --- Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.098 sec <<< FAILURE! testSwizzleCloverDependenciesWhenCloveredVersionOfDependencyIsNewerThanOriginal(org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest) Time elapsed: 0.031 sec <<< FAILURE! org.jmock.core.DynamicMockError: mockArtifact: no match found Invoked: org.apache.maven.artifact.Artifact.getVersionRange() Allowed: stub: getClassifier, returns stub: getGroupId, returns stub: getArtifactId, returns stub: getVersion, returns stub: getType, returns stub: getScope, returns stub: getFile, returns stub: getId, returns stub: setScope, is void at org.jmock.core.AbstractDynamicMock.mockInvocation(Unknown Source) at org.jmock.core.CoreMock.invoke(Unknown Source) at $Proxy2.getVersionRange(Unknown Source) at org.apache.maven.plugin.clover.CloverInstrumentInternalMojo.swizzleCloverDependencies(CloverInstrumentInternalMojo.java:254) at org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest.testSwizzleCloverDependenciesWhenCloveredVersionOfDependencyIsNewerThanOriginal(CloverInstrumentInternalMojoTest.java:112) at org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest.testSwizzleCloverDependenciesWhenCloveredVersionOfDependencyIsNewerThanOriginal(CloverInstrumentInternalMojoTest.java:112) was: We have the same problem. Applying the patch fixes it, but I have to compile the plugin with tests disabled (revision 535629), otherwise I get: --- T E S T S --- Running org.apache.maven.plugin.clover.internal.CloverMojoTest [debug] Loading license from classpath [targetFile] [debug] Using license file [targetFile] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec Running org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.099 sec <<< FAILURE! Results : Failed tests: testSwizzleCloverDependenciesWhenCloveredVersionOfDependencyIsNewerThanOriginal(org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest) testSwizzleCloverDependenciesWhenOriginalVersionOfDependencyIsNewerThanCloveredOne(org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest) Tests run: 6, Failures: 2, Errors: 0, Skipped: 0 The actual error is: --- Test set: org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest --- Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.098 sec <<< FAILURE! testSwizzleCloverDependenciesWhenCloveredVersionOfDependencyIsNewerThanOriginal(org.apache.maven.plugin.clover.CloverInstrumentInternalMojoTest) Time elapsed: 0.031 sec <<< FAILURE! org.jmock.core.DynamicMockError: mockArtifact: no match found Invoked: org.apache.maven.artifact.Artifact.getVersionRange() Allowed: stub: getClassifier, returns stub: getGroupId, returns stub: getArtifactId, returns stub: getVersion, returns stub: getType, returns stub: getScope, returns stub: getFile, returns stub: getId, returns stub: setScope, i
[jira] Created: (MRM-408) The mvn deploy:deploy-file command gives "Parent doesn't exist" in a fresh install
The mvn deploy:deploy-file command gives "Parent doesn't exist" in a fresh install -- Key: MRM-408 URL: http://jira.codehaus.org/browse/MRM-408 Project: Archiva Issue Type: Bug Affects Versions: 0.9 Environment: Archiva 0.9-alpha-2 (bin) Reporter: Damon Rand I'm trying to follow the docs at this page. http://maven.apache.org/archiva/guides/getting-started/maven-configuration.html I'm setting security credentials and issuing this command with a pom.xml to include wagon-webdav mvn deploy:deploy-file -DgroupId=com.orbeon -DartifactId=blah -Dversion=3.5.1 -Dpackaging=jar -Dfile=lib/blah.jar -DrepositoryId=3rdp-releases -Durl=http://jerboa.intsec.amnesty.org:8081/archiva/repository/3rdp-releases/ I get this error message [INFO] Error deploying artifact: Failed to transfer file: http://jerboa.intsec.a mnesty.org:8081/archiva/repository/3rdp-releases//com/orbeon/blah/3.5.1/blah-3.5 .1.jar. Return code is: 409 An ethereal trace shows this request PUT /archiva/repository/3rdp-releases/com/orbeon/blah/3.5.1/blah-3.5.1.jar HTTP/1.1 And this response.. Error 409 Conflict Error 409 Conflict Resource in error: http://jerboa.intsec.amnesty.org:8081/archiva/repository/com/orbeon/blah/3.5.1/blah-3.5.1.jar/com/orbeon/blah/3.5.1/blah-3.5.1.jar";> http://jerboa.intsec.amnesty.org:8081/archiva/repository/com/orbeon/blah/3.5.1/blah-3.5.1.jar/com/orbeon/blah/3.5.1/blah-3.5.1.jar Exception details: it.could.webdav.DAVException: Parent doesn't exist at it.could.webdav.DAVResource.write(DAVResource.java:465) at it.could.webdav.methods.PUT.process(PUT.java:59) at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) at org.codehaus.plexus.webdav.simple.SimpleDavServerComponent.process(SimpleDavServerComponent.java:142) at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:156) at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:111) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Note that request and response are very different.. /archiva/repository/3rdp-releases/com/orbeon/blah/3.5.1/blah-3.5.1.jar /archiva/repository/com/orbeon/blah/3.5.1/blah-3.5.1.jar/com/orbeon/blah/3.5.1/blah-3.5.1.jar Has anyone got this working? I can't imagine how it could work, at least in the release I have. -- 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: (MEV-364) Fix dependencies of common-lang 1.0 (add test scope for junit)
[ http://jira.codehaus.org/browse/MEV-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97732 ] Henri Yandell commented on MEV-364: --- Lang is required by CLI - I think it's just the TypeHandler part. I'm not sure if this is the kind of fix that can be made to the repository though. Failing that, I'm working on getting CLI 1.1 out, all the bugs are resolved now (and lang/logging are no longer dependencies). > Fix dependencies of common-lang 1.0 (add test scope for junit) > -- > > Key: MEV-364 > URL: http://jira.codehaus.org/browse/MEV-364 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies, Invalid POM >Reporter: Guillaume Boissier > > consider changing > > > junit > junit > 3.7 > > > to > > > junit > junit > 3.7 > test > > -- 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-1957) clause in the activation section has to provide more complex expressions.
[ http://jira.codehaus.org/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97733 ] Eric Redmond commented on MNG-1957: --- To keep consistent, I think I'd rather prefer the version range syntax that dependency versions use. > clause in the activation section has to provide more complex > expressions. > - > > Key: MNG-1957 > URL: http://jira.codehaus.org/browse/MNG-1957 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0, 2.0.1 >Reporter: Trustin Lee > Fix For: 2.0.x > > > For now, provides only one operator '!' which means negation, but > it would be great if i can use '+' and ~ operator: > 1.5+ > 1.1 ~ 1.4 > ~ 1.3 > 1.4 ~ -- 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-2607) Cycle in plugins build
[
http://jira.codehaus.org/browse/MNG-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Redmond closed MNG-2607.
-
Resolution: Fixed
Fix Version/s: 2.0.x
has not arrisen in quite a while
> Cycle in plugins build
> --
>
> Key: MNG-2607
> URL: http://jira.codehaus.org/browse/MNG-2607
> Project: Maven 2
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 2.0.5
>Reporter: Eric Redmond
> Fix For: 2.0.x
>
>
> I just bootstrapped 2.0.5-SNAP and attempted to build plugins from scratch.
> The following cycle ensued:
> The projects in the reactor contain a cyclic reference: Edge between
> 'Vertex{label='org.apache.maven.plugins:maven-javadoc-plugin'}' and
> 'Vertex{label='org.apache.maven.plugins:maven-checkstyle-plugin'}' introduces
> to cycle in the graph org.apache.maven.plugins:maven-checkstyle-plugin -->
> org.apache.maven.plugins:maven-javadoc-plugin -->
> org.apache.maven.plugins:maven-checkstyle-plugin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3026) New maven-runtime shared component
New maven-runtime shared component -- Key: MNG-3026 URL: http://jira.codehaus.org/browse/MNG-3026 Project: Maven 2 Issue Type: New Feature Components: Shared Reporter: Mark Hobson Attachments: maven-runtime.zip The attached shared component allows introspection of the current Maven runtime environment. The MavenRuntime API provides access to all Maven project metadata available within a specified class path, which can be useful for diagnostic purposes. -- 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-234) Maven skin / version as plugin parameters
Maven skin / version as plugin parameters - Key: MSITE-234 URL: http://jira.codehaus.org/browse/MSITE-234 Project: Maven 2.x Site Plugin Issue Type: Improvement Affects Versions: 2.0-beta-5 Reporter: Stefano Bagnara I have an m2 reactor project where one of the modules is the skin used by one of the other modules (and every of its children). root |- maven-skin '- module1 (using maven-skin) The problem is that module1 declare the skin in its site.xml file and this way the version is not updated when I use the release:prepare to update my poms. So I checked the site plugin searching for a way to declare the skin in the plugin configuration instead of the site.xml descriptor but there is no such option. I think that a good solution would be to use something like the remote resource plugin (used for LICENSE/NOTICE) also for the skin declaration. -- 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-234) Maven skin / version as plugin parameters
[ http://jira.codehaus.org/browse/MSITE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97736 ] Stefano Bagnara commented on MSITE-234: --- Sorry.. the tree has been changed by the JIRA formater | root (1.0-SNAPSHOT) | - maven-skin (1.1-SNAPSHOT) | - module1 (using maven-skin - 1.1-SNAPSHOT) > Maven skin / version as plugin parameters > - > > Key: MSITE-234 > URL: http://jira.codehaus.org/browse/MSITE-234 > Project: Maven 2.x Site Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-5 >Reporter: Stefano Bagnara > > I have an m2 reactor project where one of the modules is the skin used > by one of the other modules (and every of its children). > root > |- maven-skin > '- module1 (using maven-skin) > The problem is that module1 declare the skin in its site.xml file and > this way the version is not updated when I use the release:prepare to > update my poms. > So I checked the site plugin searching for a way to declare the skin in > the plugin configuration instead of the site.xml descriptor but there is > no such option. > I think that a good solution would be to use something like the remote > resource plugin (used for LICENSE/NOTICE) also for the skin declaration. -- 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-2622) Reformatted Guides List
[ http://jira.codehaus.org/browse/MNG-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Redmond closed MNG-2622. - Resolution: Fixed Fix Version/s: 2.0.x applied a while ago > Reformatted Guides List > --- > > Key: MNG-2622 > URL: http://jira.codehaus.org/browse/MNG-2622 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: Guides >Reporter: Eric Redmond >Priority: Trivial > Fix For: 2.0.x > > Attachments: guides_list.patch > > > Reformatting the existing guides list to split the guides into a more > thematic hierachy, reducing large groupings of documents. > Example: > http://www.propellors.net/maven/site/guides/index.html -- 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-2641) Nabble Links to Docs and LHS menu
[ http://jira.codehaus.org/browse/MNG-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Redmond closed MNG-2641. - Resolution: Fixed Fix Version/s: 2.0.x link is in mailing list archives > Nabble Links to Docs and LHS menu > - > > Key: MNG-2641 > URL: http://jira.codehaus.org/browse/MNG-2641 > Project: Maven 2 > Issue Type: New Feature > Components: Documentation: Guides >Reporter: Eric Redmond >Priority: Trivial > Fix For: 2.0.x > > Attachments: nabble_links.patch > > > A patch to add nabble forum link to the site.xml file of the main maven site, > added link to community.apt, and squeezed in a minor fix to the site.css file. -- 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: (MNG-3012) ClassCastException due to plexus-utils NOT being filtered during plugin loading
[ http://jira.codehaus.org/browse/MNG-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3012: Description: The eclipse:eclipse mojo was a perfect example of this. It needs to read the plugin configurations from the POM to look for things like maven-compiler-plugin's source/target values, so it can setup the .classpath appropriately. When the IdeUtils (line 345) calls execution.getConfiguration(), it assumes the result will be an Xpp3Dom instance, and tries to cast it accordingly. Because Maven now has its own "shaded" or internal copy of plexus-utils that it doesn't share, the eclipse plugin loads the Xpp3Dom class from a different classloader, and the result is a ClassCastException. Admittedly, exposing plugin.getConfiguration() as a java.lang.Object doesn't help plugin developers very much, and that they need to "just know" that it's of type Xpp3Dom (and cast accordingly) has gotten us into some trouble here. It's important to note that all plugins that deal directly with plugin.getConfiguration() or execution.getConfiguration() will have a problem here, meaning older versions of the eclipse plugin (including all released versions) and many others will immediately suffer if we leave this as-is. Ideally, plugin.getConfiguration() should just return some object (okay, maybe it's a java.lang.Object, but that's *not* an elegant solution) that contains structured arbitrary data...so, perhaps a good solution would be to make the assumption that the object's toString() method will render it into XML. Working from an assumption like that, one could do the following: String str = String.valueOf( plugin.getConfiguration() ); Xpp3DomBuilder.build( new StringReader( str ) ); and proceed as if the plugin.getConfiguration() method had returned a type Xpp3Dom, even if we later change it to return something from javax.xml (thinking DOM). This is a more resilient approach than simply casting to Xpp3Dom, and it's the one I've implemented for the eclipse plugin in revId 541953. This is a problem in the current trunk, and any solution will likely take some design time to fix, so I don't want this plugin to become non-functional for developers working with trunk in the meantime (like anyone using m2eclipse). was: The eclipse:eclipse mojo was a perfect example of this. It needs to read the plugin configurations from the POM to look for things like maven-compiler-plugin's source/target values, so it can setup the .classpath appropriately. When the IdeUtils (line 345) calls execution.getConfiguration(), it assumes the result will be an Xpp3Dom instance, and tries to cast it accordingly. Because Maven now has its own "shaded" or internal copy of plexus-utils that it doesn't share, the eclipse plugin loads the Xpp3Dom class from a different classloader, and the result is a ClassCastException. Admittedly, exposing plugin.getConfiguration() as a java.lang.Object doesn't help plugin developers very much, and that they need to "just know" that it's of type Xpp3Dom (and cast accordingly) has gotten us into some trouble here. It's important to note that all plugins that deal directly with plugin.getConfiguration() or execution.getConfiguration() will have a problem here, meaning older versions of the eclipse plugin (including all released versions) and many others will immediately suffer if we leave this as-is. Ideally, plugin.getConfiguration() should just return some object (okay, maybe it's a java.lang.Object, but that's *not* an elegant solution) that contains structured arbitrary data...so, perhaps a good solution would be to make the assumption that the object's toString() method will render it into XML. Working from an assumption like that, one could do the following: String str = String.valueOf( plugin.getConfiguration() ); Xpp3DomBuilder.build( new StringReader( str ) ); and proceed as if the plugin.getConfiguration() method had returned a type Xpp3Dom, even if we later change it to return something from javax.xml (thinking DOM). This is a more resilient approach than simply casting to Xpp3Dom, and it's the one I've implemented for the eclipse plugin in revId 541953. This is a problem in the current trunk, and any solution will likely take some design time to fix, so I don't want this plugin to become non-functional for developers working with trunk in the meantime (like anyone using m2eclipse). > ClassCastException due to plexus-utils NOT being filtered during plugin > loading > --- > > Key: MNG-3012 > URL: http://jira.codehaus.org/browse/MNG-3012 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Priority: Blocker > > The eclipse:
[jira] Commented: (MRM-406) Replace the archiva.version propertry with project.version
[
http://jira.codehaus.org/browse/MRM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97740
]
Brett Porter commented on MRM-406:
--
I tried steps 1 - 5 and I got the correct archiva-database (I did a diff to
confirm).
The install process does not change the SNAPSHOT in the POM into a TIMESTAMP.
Only the deploy process does, and then only remotely. You'll only get that
locally when it is downloaded from the server again.
I believe you've seen it with redback because you regularly deployed and used
those depoyed snapshots. I didn't dispute that would be a problem. It's
something that should be fixed in Maven.
I believe the release plugin has work under way to dereference the expressions
so that it can fix the properties that hold versions too (though this is a
hairy issue and not one that should be considered a best practice).
I just believe that given all these circumstances, using ${project.version} was
the least harmful. The redback release process got bitten by the fact that it
wasn't updated more than once.
But I'm also not the one releasing it, so as long as it's documented either
way, I don't care what it's set to.
> Replace the archiva.version propertry with project.version
> --
>
> Key: MRM-406
> URL: http://jira.codehaus.org/browse/MRM-406
> Project: Archiva
> Issue Type: Improvement
>Affects Versions: 1.0-alpha-1
>Reporter: Franz Allan Valencia See
>Assignee: Joakim Erdfelt
> Fix For: 1.0-alpha-1
>
> Attachments: MRM-406-archiva-parent.patch
>
>
> There is no need for the archiva.version property in the pom because this can
> be represented by the project.version property. Furthermore this can cause
> problems when doing a release with continuum.
--
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-117) ability to add dependency to jvm's classpath rather in surefirebooter classloader
[ http://jira.codehaus.org/browse/SUREFIRE-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97741 ] Kenney Westerhof commented on SUREFIRE-117: --- It works perfectly here, but it may be a windows issue. Could you please provide a testcase I can run here? > ability to add dependency to jvm's classpath rather in surefirebooter > classloader > - > > Key: SUREFIRE-117 > URL: http://jira.codehaus.org/browse/SUREFIRE-117 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.0 (2.2 plugin) > Environment: xp >Reporter: Dan Tran >Assignee: Kenney Westerhof > Fix For: 2.4 > > Attachments: MSUREFIRE-121-booter.patch, MSUREFIRE-121.plugin.patch, > MSUREFIRE-121.plugin.patch2, MSUREFIRE-121.plugin.patch3 > > > I have a usecase where i have a jar file got loaded by -Xbootclasspath, that > jar file then loads classes from another jar ( my dependency) > expected in the classpath. > The problem is that surefire plugin does not add my dependencies at JVM > commanline thru -classpath option, but after the JVM starts -- 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] Deleted: (MNG-3025) This is a test bug to try and attach something as a patch
[ http://jira.codehaus.org/browse/MNG-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl deleted MNG-3025: --- > This is a test bug to try and attach something as a patch > - > > Key: MNG-3025 > URL: http://jira.codehaus.org/browse/MNG-3025 > Project: Maven 2 > Issue Type: Bug >Reporter: Jason van Zyl > -- 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-2628) (patch) If not necessary, don't extract the integration tests to $TEMP
[
http://jira.codehaus.org/browse/MNG-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2628.
--
Resolution: Fixed
Already applied.
> (patch) If not necessary, don't extract the integration tests to $TEMP
> --
>
> Key: MNG-2628
> URL: http://jira.codehaus.org/browse/MNG-2628
> Project: Maven 2
> Issue Type: Improvement
> Components: integration tests
>Reporter: Dan Fabulich
> Attachments: 467135simpleExtractResources.txt
>
>
> Whenever you run the integration tests, they currently extract resources into
> $TEMP, even if the resources are already just lying around as files on the
> file system. Under this patch, tests can use "simpleExtractResources" to
> force the ResourceExtractor to guess the proper location where the tests
> should be run, and hand back a File pointing to the resources to use.
> To use this, the tests will need to be changed as well. The tests should now
> go like this:
> public void testit() throws Exception {
> File testDir = ResourceExtractor.simpleExtractResources( getClass(),
> "/it");
> Verifier verifier = new Verifier( testDir.getAbsolutePath() );
> verifier.executeGoal( "package" );
> }
--
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-1578) Java Projection Library 1.0
Java Projection Library 1.0 --- Key: MAVENUPLOAD-1578 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1578 Project: maven-upload-requests Issue Type: Task Reporter: Paul Austin ftp://dav.revolsys.com/public/maven/javaproj-1.0-bundle.jar http://www.jhlabs.com/java/maps/proj/index.html http://www.jhlabs.com/contact.html [EMAIL PROTECTED] for the maven bundle Java Projection Library is a Java version of the PROJ4 GIS projection library -- 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: (MNG-2347) MavenExecutionRequest.getBaseDirectory() should be propagated to the ${basedir} expression
[
http://jira.codehaus.org/browse/MNG-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2347:
---
Fix Version/s: (was: 2.1.x)
2.1-alpha-1
Component/s: (was: General)
Embedding
> MavenExecutionRequest.getBaseDirectory() should be propagated to the
> ${basedir} expression
> --
>
> Key: MNG-2347
> URL: http://jira.codehaus.org/browse/MNG-2347
> Project: Maven 2
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 2.0-alpha-1
> Environment: Maven 2.1-SNAPSHOT
>Reporter: Ovidio Mallo
>Assignee: Jason van Zyl
> Fix For: 2.1-alpha-1
>
> Attachments: MNG-2347-maven-core.patch
>
>
> When executing a goal given by a MavenExecutionRequest (e.g. on the
> MavenEmbedder) which has no POM file set (e.g. archetype:create), the
> MavenExecutionRequest.getBaseDirectory() is not propagated to the expression
> ${basedir} for the plugins to be used.
> Currently, the ${basedir} is set to the directory where the POM file resides,
> if any is specified. Otherwise, it is simply set to the current working
> directory. I guess that when no POM file is given, ${basedir} should be set
> to the base directory set on the MavenExecutionRequest.
--
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: (MEAR-65) Support MAR archives
[ http://jira.codehaus.org/browse/MEAR-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97743 ] David J. M. Karlsen commented on MEAR-65: - Nice - thanks! We're not specifying anything special in application.xml today - so I suppose that should work OK. > Support MAR archives > > > Key: MEAR-65 > URL: http://jira.codehaus.org/browse/MEAR-65 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: Stephane Nicoll >Priority: Trivial > > Add support for adding MARs to the archive (mar), like the axis2 > addressing module @: > http://repo1.maven.org/maven2/org/apache/axis2/addressing/1.2/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-238) release:prepare hangs at cvs update
release:prepare hangs at cvs update --- Key: MRELEASE-238 URL: http://jira.codehaus.org/browse/MRELEASE-238 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: Lothar Hegebart Priority: Blocker release:prepare just hangs indefinitely, no more information given by -X and -e when i define version 2.0-beta-5 as plugin version it works just fine -- 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: (MAVENUPLOAD-1483) Please synchronize the jDTAUS repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1483. --- Resolution: Fixed > Please synchronize the jDTAUS repository > > > Key: MAVENUPLOAD-1483 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1483 > Project: maven-upload-requests > Issue Type: Task >Reporter: Christian Schulte >Assignee: Carlos Sanchez > Attachments: org.jdtaus.sh > > -- 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: (MAVENUPLOAD-1575) Upload Hibernate Validator 3.0.0.ga
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1575. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload Hibernate Validator 3.0.0.ga > --- > > Key: MAVENUPLOAD-1575 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1575 > Project: maven-upload-requests > Issue Type: Task >Reporter: Aleksei Valikov >Assignee: Carlos Sanchez > Attachments: hibernate-validator-3.0.0.ga-bundle.jar, > hibernate-validator-3.0.0.ga-bundle.jar > > > Emmanuel Bernard of Hibernate has asked me to overtake Ibiblio uploading for > Hibernate Entity Manager. Hibernate Validator is one of dependencies. > Please see http://opensource.atlassian.com/projects/hibernate/browse/EJB-287 > for details (I'm the assignee of the issue). -- 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: (MAVENUPLOAD-1574) Upload Hibernate Entity Manager 3.3.1.ga
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1574. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload Hibernate Entity Manager 3.3.1.ga > > > Key: MAVENUPLOAD-1574 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1574 > Project: maven-upload-requests > Issue Type: Task >Reporter: Aleksei Valikov >Assignee: Carlos Sanchez > Attachments: hibernate-entitymanager-3.3.1.ga-bundle.jar, > hibernate-entitymanager-3.3.1.ga-bundle.jar > > > Emmanuel Bernard of Hibernate has asked me to overtake Ibiblio uploading for > Hibernate Entity Manager. > Please see http://opensource.atlassian.com/projects/hibernate/browse/EJB-287 > for details (I'm the assignee of the issue). -- 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: (MAVENUPLOAD-1576) Xanot (XML to Object mapper). Central repository upload request.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1576. --- Assignee: Carlos Sanchez Resolution: Fixed > Xanot (XML to Object mapper). Central repository upload request. > > > Key: MAVENUPLOAD-1576 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1576 > Project: maven-upload-requests > Issue Type: Task >Reporter: Ferdinand Neman >Assignee: Carlos Sanchez > > http://xanot.sourceforge.net/xanot-1.0.6-bundle.jar > http://xanot.sourceforge.net > http://xanot.sourceforge.net/team-list.html > Hi, Im Ferdinand Neman. I have created a library to map XML to java object > and viseversa. It works very much like Apache's Commons Digester. But it uses > annotation on the object model. Its much easier than Digester. Thank you. > Please Upload. -- 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: (MAVENUPLOAD-1454) Upload of rmock 2.0.0. Group already exists.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1454. --- Resolution: Fixed > Upload of rmock 2.0.0. Group already exists. > > > Key: MAVENUPLOAD-1454 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1454 > Project: maven-upload-requests > Issue Type: Task >Reporter: Daniel Brolund >Assignee: Carlos Sanchez > > RMock 2.0.0 is a Java mock object framework to use with jUnit. RMock has > support for a setup-modify-run-verify workflow when writing jUnit tests. It > integrates better with IDE refactoring support and allows designing classes > and interfaces in a true test-first fashion. -- 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-3012) ClassCastException due to plexus-utils NOT being filtered during plugin loading
[ http://jira.codehaus.org/browse/MNG-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3012. --- Resolution: Fixed added importFrom(..) to new plugin realms, to bring in Xpp3Dom from the version of plexus-utils used by maven itself. This should prevent ClassCastExceptions in the plugins when they call plugin.getConfiguration(). I've verified this in the maven-eclipse-plugin by reverting mine and Kenney's changes to IdeUtils, and re-running. > ClassCastException due to plexus-utils NOT being filtered during plugin > loading > --- > > Key: MNG-3012 > URL: http://jira.codehaus.org/browse/MNG-3012 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > > The eclipse:eclipse mojo was a perfect example of this. It needs to read the > plugin configurations from the POM to look for things like > maven-compiler-plugin's source/target values, so it can setup the .classpath > appropriately. > When the IdeUtils (line 345) calls execution.getConfiguration(), it assumes > the result will be an Xpp3Dom instance, and tries to cast it accordingly. > Because Maven now has its own "shaded" or internal copy of plexus-utils that > it doesn't share, the eclipse plugin loads the Xpp3Dom class from a different > classloader, and the result is a ClassCastException. Admittedly, exposing > plugin.getConfiguration() as a java.lang.Object doesn't help plugin > developers very much, and that they need to "just know" that it's of type > Xpp3Dom (and cast accordingly) has gotten us into some trouble here. > It's important to note that all plugins that deal directly with > plugin.getConfiguration() or execution.getConfiguration() will have a problem > here, meaning older versions of the eclipse plugin (including all released > versions) and many others will immediately suffer if we leave this as-is. > Ideally, plugin.getConfiguration() should just return some object (okay, > maybe it's a java.lang.Object, but that's *not* an elegant solution) that > contains structured arbitrary data...so, perhaps a good solution would be to > make the assumption that the object's toString() method will render it into > XML. Working from an assumption like that, one could do the following: > String str = String.valueOf( plugin.getConfiguration() ); > Xpp3DomBuilder.build( new StringReader( str ) ); > and proceed as if the plugin.getConfiguration() method had returned a type > Xpp3Dom, even if we later change it to return something from javax.xml > (thinking DOM). This is a more resilient approach than simply casting to > Xpp3Dom, and it's the one I've implemented for the eclipse plugin in revId > 541953. This is a problem in the current trunk, and any solution will likely > take some design time to fix, so I don't want this plugin to become > non-functional for developers working with trunk in the meantime (like anyone > using m2eclipse). -- 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-3021) it0114 is failing in trunk
[ http://jira.codehaus.org/browse/MNG-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3021. --- Resolution: Cannot Reproduce The issue may have been specific to my environment, as it seems to be passing now. Will reopen if things start failing again... > it0114 is failing in trunk > -- > > Key: MNG-3021 > URL: http://jira.codehaus.org/browse/MNG-3021 > Project: Maven 2 > Issue Type: Bug >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > > it's not finding the plugin resource in the plugin classloader/realm. -- 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-3027) forked execution does not get configuration from the POM
forked execution does not get configuration from the POM Key: MNG-3027 URL: http://jira.codehaus.org/browse/MNG-3027 Project: Maven 2 Issue Type: Bug Reporter: John Casey steps to reproduce: 1. go into maven/components/trunk/maven-project 2. run `mvn -P reporting site:run` 3. notice that checkstyle first reports 216 errors, then when it forks and re-checks (for some reason), it reports 7513 errors. This is because it isn't configured with the settings in the POM. -- 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: (MNG-3027) forked execution does not get configuration from the POM
[ http://jira.codehaus.org/browse/MNG-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3027: Assignee: John Casey > forked execution does not get configuration from the POM > > > Key: MNG-3027 > URL: http://jira.codehaus.org/browse/MNG-3027 > Project: Maven 2 > Issue Type: Bug >Reporter: John Casey >Assignee: John Casey > > steps to reproduce: > 1. go into maven/components/trunk/maven-project > 2. run `mvn -P reporting site:run` > 3. notice that checkstyle first reports 216 errors, then when it forks and > re-checks (for some reason), it reports 7513 errors. This is because it isn't > configured with the settings in the POM. -- 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: (CONTINUUM-1298) Unable to release project with nested structure (more than one pom with modules)
Unable to release project with nested structure (more than one pom with modules) Key: CONTINUUM-1298 URL: http://jira.codehaus.org/browse/CONTINUUM-1298 Project: Continuum Issue Type: Bug Components: Release Affects Versions: 1.1-alpha-1 Reporter: Wendy Smoak If a project has a nested multi-module structure, you can't use the "Release" button in Continuum. The error is: Cannot release two or more parent projects in the same project group at the same time. Workaround: Find the top-level parent pom within the group, and click the release icon to the right of it While it would be an error to try to release two separate hierarchies at the same time, ontinuum Release needs to understand how to find the "top level" parent pom in a group containing projects within a single hierarchy. -- 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: (MANTTASKS-29) more powerful filesetId
[ http://jira.codehaus.org/browse/MANTTASKS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MANTTASKS-29. -- Resolution: Fixed Patch applied. > more powerful filesetId > --- > > Key: MANTTASKS-29 > URL: http://jira.codehaus.org/browse/MANTTASKS-29 > Project: Maven 2.x Ant Tasks > Issue Type: New Feature >Reporter: Dave Brondsema >Assignee: Jason van Zyl >Priority: Minor > Attachments: MANTTASKS-29.diff, MANTTASKS-29_site.diff, > maven-ant-tasks_mapper-2.patch, maven-ant-tasks_mapper.patch > > > I would like to copy all dependencies into a 'lib' directory without version > numbers in the filename. I don't think I can safely determine which part of > the filename is the artifact and which part is the version number. Only > maven knows that, so I think the m2 ant tasks need something more flexible > than the current filesetId. > Brett Porter suggests: > Basically, filesetId references the local repository directory, so it > will need to be something that: > 1) produces a reference to all the artifacts downloaded for use later > 2) can be used as a mapper in association with the filesetId produced -- 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: (MANTTASKS-29) more powerful filesetId
[ http://jira.codehaus.org/browse/MANTTASKS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-29: --- Attachment: MANTTASKS-29-bis.diff forgot "svn add src/main/java/org/apache/maven/artifact/ant/VersionMapper.java"... > more powerful filesetId > --- > > Key: MANTTASKS-29 > URL: http://jira.codehaus.org/browse/MANTTASKS-29 > Project: Maven 2.x Ant Tasks > Issue Type: New Feature >Reporter: Dave Brondsema >Assignee: Jason van Zyl >Priority: Minor > Attachments: MANTTASKS-29-bis.diff, MANTTASKS-29.diff, > MANTTASKS-29_site.diff, maven-ant-tasks_mapper-2.patch, > maven-ant-tasks_mapper.patch > > > I would like to copy all dependencies into a 'lib' directory without version > numbers in the filename. I don't think I can safely determine which part of > the filename is the artifact and which part is the version number. Only > maven knows that, so I think the m2 ant tasks need something more flexible > than the current filesetId. > Brett Porter suggests: > Basically, filesetId references the local repository directory, so it > will need to be something that: > 1) produces a reference to all the artifacts downloaded for use later > 2) can be used as a mapper in association with the filesetId produced -- 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-2347) MavenExecutionRequest.getBaseDirectory() should be propagated to the ${basedir} expression
[
http://jira.codehaus.org/browse/MNG-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2347.
--
Resolution: Fixed
Patch applied.
> MavenExecutionRequest.getBaseDirectory() should be propagated to the
> ${basedir} expression
> --
>
> Key: MNG-2347
> URL: http://jira.codehaus.org/browse/MNG-2347
> Project: Maven 2
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 2.0-alpha-1
> Environment: Maven 2.1-SNAPSHOT
>Reporter: Ovidio Mallo
>Assignee: Jason van Zyl
> Fix For: 2.1-alpha-1
>
> Attachments: MNG-2347-maven-core.patch
>
>
> When executing a goal given by a MavenExecutionRequest (e.g. on the
> MavenEmbedder) which has no POM file set (e.g. archetype:create), the
> MavenExecutionRequest.getBaseDirectory() is not propagated to the expression
> ${basedir} for the plugins to be used.
> Currently, the ${basedir} is set to the directory where the POM file resides,
> if any is specified. Otherwise, it is simply set to the current working
> directory. I guess that when no POM file is given, ${basedir} should be set
> to the base directory set on the MavenExecutionRequest.
--
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-2977) it0072 fails because of Xpp3Dom being in two classloaders, a resuilt of the plexus-utils hiding
[ http://jira.codehaus.org/browse/MNG-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2977. -- Resolution: Fixed John has fixed this. > it0072 fails because of Xpp3Dom being in two classloaders, a resuilt of the > plexus-utils hiding > --- > > Key: MNG-2977 > URL: http://jira.codehaus.org/browse/MNG-2977 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1.x >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.1-alpha-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] Commented: (MCLOVER-70) Non-Clovered Jars used for Transitive Dependencies
[ http://jira.codehaus.org/browse/MCLOVER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97775 ] Daniel Gredler commented on MCLOVER-70: --- Yeah, the patch breaks some unit tests... I think it has to do with some mock objects that are strict about what invocations they allow and when. Just install with -Dmaven.test.ignore :-) > Non-Clovered Jars used for Transitive Dependencies > -- > > Key: MCLOVER-70 > URL: http://jira.codehaus.org/browse/MCLOVER-70 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: James Olsen > Attachments: mclover-70.patch > > > When executing tests or building ear/war archives, the plugin is not using > instrumented jars for transitive dependencies. The ordinary jar is used > instead. Hence no test coverage stats are obtained for those components. > Adding the transitive dependency as a direct dependency on the project > results in both the instrumented and plain jar appearing in the archive. I > presume the same also happens for the unit test classpath although I haven't > confirmed. > The plugin should use the instrumented version of the jar where available > regardless of whether the dependency is direct or transitive. -- 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-2906) version ranges don't work after a day has passed
[ http://jira.codehaus.org/browse/MNG-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97774 ] Damon Jacobsen commented on MNG-2906: - I also have this issue now. I am using JasperReports with the same dependency of com.lowagie.itext [1.02b,) > version ranges don't work after a day has passed > > > Key: MNG-2906 > URL: http://jira.codehaus.org/browse/MNG-2906 > Project: Maven 2 > Issue Type: Bug >Reporter: Bill Dudney > > dependency A has a range dependency on B > my project has a dependency on A (not directly on B) > I build my project with a fresh clean repo (i.e. rm -rf ~/.m2/repository) > B's latest is downloaded as expected > the next morning I rebuild my project and I get error messages that no > suitable version can be found; > No versions are present in the repository for the artifact with a range > [1.02b,) com.lowagie:itext-null.jar > the particulars are jfreereports depending on [1.02b,) of lowagie. -- 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] Issue Comment Edited: (MSITE-211) Can't deploy site using site:deploy due to a ProxyHTTP error
[ http://jira.codehaus.org/browse/MSITE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97778 ] Thomas Champagne edited comment on MSITE-211 at 5/31/07 3:28 PM: - I think the issue 80 of project Wagon is the cause of problem : http://jira.codehaus.org/browse/WAGON-80 was: I think this issue is the cause. > Can't deploy site using site:deploy due to a ProxyHTTP error > > > Key: MSITE-211 > URL: http://jira.codehaus.org/browse/MSITE-211 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: linux ubuntu dapper drake >Reporter: Elid OR >Priority: Blocker > > When I execute the site deployment (with version that comes with maven 2.0.5) > "mvn site:deploy " I got an error see log en debug mode below. This used to > work correctly with maven version 2.04 (so maybe site plugin version > 2.0-beta-4 : > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy > error: Forbidden > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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:324) > 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 uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > ... 16 more > Caused by: org.apache.maven.wagon.authentication.AuthenticationException: > Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: > Forbidden > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149) > ... 18 more > Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: > proxy error: Forbidden > at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) > ... 20 more > [INFO] > > [INFO] Total time: 3 seconds > [INFO] Finished at: Wed Feb 21 12:00:41 CET 2007 > [INFO] Final Memory: 3M/7M > [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 info
[jira] Updated: (MASSEMBLY-210) repository does not include the parent pom
[
http://jira.codehaus.org/browse/MASSEMBLY-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-210:
-
Assignee: John Casey
Description:
I am running the assembly on a project with a parent pom. dist
zip
true
foo-${version}
. foo-base
true
**/target/**
repository
test
The parent pom is not included at all.
was:
I am running the assembly on a project with a parent pom.
{code:xml}
dist
zip
true
foo-${version}
.
foo-base
true
**/target/**
repository
test
{code}
The parent pom is not included at all.
Fix Version/s: 2.2-beta-2
> repository does not include the parent pom
> --
>
> Key: MASSEMBLY-210
> URL: http://jira.codehaus.org/browse/MASSEMBLY-210
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Stephane Nicoll
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
>
> I am running the assembly on a project with a parent pom. encoding="ISO-8859-15"?> dist
> zip
> true
> foo-${version}
> . foo-base
> true
> **/target/**
> repository
> test
> The parent pom is not included at all.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-210) repository does not include the parent pom
[
http://jira.codehaus.org/browse/MASSEMBLY-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-210:
-
Description:
I am running the assembly on a project with a parent pom. dist
zip
true
foo-${version}
. foo-base
true
*/target/*
repository test
The parent pom is not included at all.
was:
I am running the assembly on a project with a parent pom. dist
zip
true
foo-${version}
. foo-base
true
**/target/**
repository
test
The parent pom is not included at all.
I've modified maven-repository-builder in maven/shared/trunk
(DefaultRepositoryAssembler) to include the ancestor POMs of the current
project. Is this what you needed?
I'll also update the assembly plugin POM so it depends on the new version of
maven-repository-builder, and deploy snapshots of both.
> repository does not include the parent pom
> --
>
> Key: MASSEMBLY-210
> URL: http://jira.codehaus.org/browse/MASSEMBLY-210
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Stephane Nicoll
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
>
> I am running the assembly on a project with a parent pom. encoding="ISO-8859-15"?> dist
> zip
> true
> foo-${version}
> . foo-base
> true
> */target/*
> repository
> test
> The parent pom is not included at all.
--
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: (MRELEASE-205) release should allow you to answer "yes to all" or apply version to all
[ http://jira.codehaus.org/browse/MRELEASE-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MRELEASE-205. --- Assignee: Carlos Sanchez Resolution: Won't Fix there's already autoVersionSubmodules property http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html > release should allow you to answer "yes to all" or apply version to all > --- > > Key: MRELEASE-205 > URL: http://jira.codehaus.org/browse/MRELEASE-205 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3, 2.0-beta-4 >Reporter: Brian Fox >Assignee: Carlos Sanchez > > The plugin prompts for 2 things: the release version and next development > version for each pom in a multiproject build. In my case, this is 200 > questions per release. The plugin should make it easy to apply the same > version to all 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: (MAVENUPLOAD-1483) Please synchronize the jDTAUS repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97784 ] Christian Schulte commented on MAVENUPLOAD-1483: Thanks! Everything works. Sorry for the noise... > Please synchronize the jDTAUS repository > > > Key: MAVENUPLOAD-1483 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1483 > Project: maven-upload-requests > Issue Type: Task >Reporter: Christian Schulte >Assignee: Carlos Sanchez > Attachments: org.jdtaus.sh > > -- 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: (MCHANGELOG-59) Apply proper formating in the report for newlines in SCM comments.
[
http://jira.codehaus.org/browse/MCHANGELOG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHANGELOG-59.
-
Assignee: Dennis Lundberg
Resolution: Fixed
Fix Version/s: 2.1
> Apply proper formating in the report for newlines in SCM comments.
> --
>
> Key: MCHANGELOG-59
> URL: http://jira.codehaus.org/browse/MCHANGELOG-59
> Project: Maven 2.x Changelog Plugin
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
>Priority: Minor
> Fix For: 2.1
>
>
> Taken from the users list:
> {quote}
> Would it be possible to change the newlines in the comments to -tags in
> HTML? We sometimes use lists to summarize our changes in files and these
> lists become pretty much unreadable in HTML without the line-breaks.
> {quote}
--
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: (MCHANGELOG-63) Tag-based reports have new headers, SCM-comments with newlines get linebreaks in HTML, lay-out update on changelog-report
[ http://jira.codehaus.org/browse/MCHANGELOG-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MCHANGELOG-63: -- Affects Version/s: 2.0 Fix Version/s: (was: 2.0) > Tag-based reports have new headers, SCM-comments with newlines get linebreaks > in HTML, lay-out update on changelog-report > - > > Key: MCHANGELOG-63 > URL: http://jira.codehaus.org/browse/MCHANGELOG-63 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Roland Asmann >Priority: Minor > Attachments: maven-changelog-plugin-2.0-CFC-20070330.patch > > > Several updates that made the lay-out of the sites change: > - Reports based on tags don't show the message for ranges, but have own > headers and messages now. This change needs the updates I made to SCM > (http://jira.codehaus.org/browse/SCM-294)! > - Newlines in SCM-comments are printed with line-breaks now. > - Removed the paragraph-tags around every single file-entry (didn't like the > way it looked). -- 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: (MRELEASE-236) ArrayindexoutofBoundsException rewriting the Poms for release
[ http://jira.codehaus.org/browse/MRELEASE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MRELEASE-236. --- Assignee: Carlos Sanchez Resolution: Fixed Fix Version/s: 2.0 Fixed in release manager 1.0-alpha-4-SNAPSHOT > ArrayindexoutofBoundsException rewriting the Poms for release > - > > Key: MRELEASE-236 > URL: http://jira.codehaus.org/browse/MRELEASE-236 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: William Ferguson >Assignee: Carlos Sanchez >Priority: Blocker > Fix For: 2.0 > > Attachments: MRELEASE-236-patch.txt, pom.xml, Stacktrace.txt > > > Just testing out maven-release-plugin-2.0-beta-6 prior to release and noticed > that it always fails on release:prepare when it is rewriting the Poms. > Looking at the source code, the while loop at lines 249:252 of > RewritePomsForReleasePhase class will always iterate past the end of the char > arrays. > I'm not sure, but I suspect the appropriate soltuion is to check to ensure > that i < tagPathChars.length and i < trunkPathChars.length within the loop > and if so to break. -- 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: (MRELEASE-237) can't release a pom without it's modules
[
http://jira.codehaus.org/browse/MRELEASE-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97792
]
Carlos Sanchez commented on MRELEASE-237:
-
I use
{code}
mvn -N release:prepare -Dgoals=
{code}
> can't release a pom without it's modules
>
>
> Key: MRELEASE-237
> URL: http://jira.codehaus.org/browse/MRELEASE-237
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Brett Porter
>
> We have the common pattern of a parent POM which may have modules, but is
> released independently from them (plugins, archetypes being a classic
> example). This is currently not possible in the release plugin.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-128) SCM properties being replaced during release:perform
[
http://jira.codehaus.org/browse/MRELEASE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sanchez updated MRELEASE-128:
Fix Version/s: (was: 2.0-beta-5)
> SCM properties being replaced during release:perform
>
>
> Key: MRELEASE-128
> URL: http://jira.codehaus.org/browse/MRELEASE-128
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
>Reporter: Craig Dickson
>Assignee: Emmanuel Venisse
>Priority: Critical
> Attachments: after-release-perform-pom.xml,
> after-release-prepre-pom.xml, original-pom.xml
>
>
> The section of a pom in CVS for a pom archetype project looks like this
> prior to executing release:prepare :
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
>
> Then after executing release:prepare, the pom in CVS looks like this (new
> tag is only difference):
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
> R-1_7
>
> Then after executing release:perform, the pom looks like this in CVS:
>
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
>
> Notice that the properties that were there for the base URLs for CVS and
> ViewCVS have been replaced with literal values.
> No other properties in the POM are being replaced
--
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-2869) Make sure MNG-2831 works on trunk
[ http://jira.codehaus.org/browse/MNG-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2869. -- Resolution: Fixed This is IT0115 and John has fixed it. > Make sure MNG-2831 works on trunk > - > > Key: MNG-2869 > URL: http://jira.codehaus.org/browse/MNG-2869 > Project: Maven 2 > Issue Type: Task >Affects Versions: 2.1.x >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.1-alpha-1 > > > Look at IT0015 for a reference, but this should work on trunk and I believe > there is still a problem. -- 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: (MCHANGELOG-54) NPE during "Developer Activity" report generation
[ http://jira.codehaus.org/browse/MCHANGELOG-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97801 ] Dennis Lundberg commented on MCHANGELOG-54: --- The Synergy provider has been fixed, a new release of SCM has been made and the this plugin is using that latest release. I've deployed a new 2.1-SNAPSHOT of this plugin. Could you have a go and verify that this problem has been fixed? > NPE during "Developer Activity" report generation > - > > Key: MCHANGELOG-54 > URL: http://jira.codehaus.org/browse/MCHANGELOG-54 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 > Environment: windows 2000, maven 2.0.4, SCM Synergy > maven-changelog-plugin:2.0-SNAPSHOT >Reporter: David Vicente > Attachments: changelog-patch-2.txt, changelog-patch.txt > > > I'm using the maven-changelog-plugin:2.0-SNAPSHOT and i have a > NullPointerException during "Developer Activity" report generation. > java.lang.NullPointerException at > org.apache.maven.plugin.changelog.ChangeLogReport.countFilesChanged(ChangeLogReport.java:889) > > at > org.apache.maven.plugin.changelog.DeveloperActivityReport.doSummary(DeveloperActivityReport.java:221) > > at > org.apache.maven.plugin.changelog.DeveloperActivityReport.doChangedSets(DeveloperActivityReport.java:180) > > at > org.apache.maven.plugin.changelog.DeveloperActivityReport.doGenerateReport(DeveloperActivityReport.java:146) > > at > org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:296) > > I have the Synergy SCM. > it occurs when a Synergy task is completed without modified file, the > changelog.xml has an entry without file. > it occurs with the last released version. > I made the correction (see changelog-patch.txt) and it works fine -- 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: (MCHANGELOG-56) Date format not understood by CVS
[
http://jira.codehaus.org/browse/MCHANGELOG-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97804
]
Dennis Lundberg commented on MCHANGELOG-56:
---
The latest 2.1-SNAPSHOT of this plugin uses a fixed version of SCM.
Could you please verify that this problem has been fixed?
> Date format not understood by CVS
> -
>
> Key: MCHANGELOG-56
> URL: http://jira.codehaus.org/browse/MCHANGELOG-56
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
> Environment: CVS 1.12.13, Linux 2.6.18-4-xen-686 #1 SMP Thu Jan 25
> 02:34:40 UTC 2007 i686 GNU/Linux
>Reporter: Stefan Seidel
>
> In my pom.xml:
> {code}
>
>
>
> org.apache.maven.plugins
> maven-changelog-plugin
> 2.0-SNAPSHOT
>
> ...
> {code}
> mvn site output:
> {code}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building ReportingsPortlet
> [INFO]task-segment: [site]
> [INFO]
>
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] [site:site]
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [INFO] Generate "Change Log" report.
> [INFO] Generating changed sets xml to:
> /home/stefan/workspace/alles/xpm-portal/portlets/Reportings/target/changelog.xml
> [INFO] Executing: cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/home/cvs -q log
> -d 2007-01-29T15:46:22+0100<2007-03-01T15:46:22+0100
> [INFO] Working directory:
> /home/stefan/workspace/alles/xpm-portal/portlets/Reportings/src/main/java
> [ERROR] Provider message:
> [ERROR] The cvs command failed.
> [ERROR] Command output:
> [ERROR] cvs [log aborted]: Can't parse date/time: `2007-01-29T15:46:22+0100'
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: An error is occurred during
> changelog command :
> Command failed.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 7 seconds
> [INFO] Finished at: Wed Feb 28 15:46:22 GMT+01:00 2007
> [INFO] Final Memory: 20M/116M
> [INFO]
>
> {code}
> It is understandable, because this CVS version just does not support this
> strange date format.
> Running
> {code}
> cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/home/cvs -q log -d "2007-01-29
> 15:46:22 +0100<2007-03-01 15:46:22 +0100"
> {code}
> on the command line instead does work.
--
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: (MNG-2831) Cannot add custom artifact handler and custom lifecycle as a build extension
[
http://jira.codehaus.org/browse/MNG-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2831:
---
Fix Version/s: (was: 2.1-alpha-1)
2.0.7
This now works on trunk, so we'll have to look at this for 2.0.7.
> Cannot add custom artifact handler and custom lifecycle as a build extension
>
>
> Key: MNG-2831
> URL: http://jira.codehaus.org/browse/MNG-2831
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.5
>Reporter: Vincent Massol
>Assignee: Jason van Zyl
> Fix For: 2.0.7
>
>
> I have an extension registering a custom artifact handler and a custom
> lifecycle against plexus. The project that uses that extension get the
> following error:
> {noformat}
> [DEBUG] Error looking up lifecycle mapping to retrieve optional mojos.
> Lifecycle ID: clean. Error: Component descriptor cannot be found in the
> component repository: org.apache.maven.lifecycle.mapping.LifecycleMappingxar.
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> Component descriptor cannot be found in the component repository:
> org.apache.maven.lifecycle.mapping.LifecycleMappingxar.
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:323)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440)
> at
> org.apache.maven.execution.MavenSession.lookup(MavenSession.java:123)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.findOptionalMojosForLifecycle(DefaultLifecycleExecutor.java:)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:999)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:980)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> 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)
> [DEBUG] Skipping disabled repository codehaus.plugin.snapshots
> [DEBUG] Skipping disabled repository apache.snapshots
> [DEBUG] maven-clean-plugin: resolved to version 2.1 from repository central
> [DEBUG] Retrieving parent-POM:
> org.apache.maven.plugins:maven-plugin-parent::2.0 for project:
> null:maven-clean-plugin:maven-plugin:2.1 from the repository.
> [DEBUG] org.apache.maven.plugins:maven-clean-plugin:maven-plugin:2.1:runtime
> (selected for runtime)
> [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for
> runtime)
> [DEBUG] Retrieving parent-POM:
> org.apache.maven.shared:shared-components-parent::1 for project:
> null:file-management:jar:1.0 from the repository.
> [DEBUG] org.apache.maven.shared:file-management:jar:1.0:runtime (selected
> for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected for
> runtime)
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-clean-plugin:2.1:clean' -->
> [DEBUG] (f) directory =
> /Users/vmassol/dev/maven/trunks/core-integration-testing/core-integration-tests/src/test/resources/it0115-customArtifactHandlerAndCustomLifecycle/test-project/target
> [DEBUG] (f) outputDirectory =
> /Users/vmassol/dev/maven/trunks/core-integration-testing/core-integration-tests/src/test/resources/it0115-customArtifactHandlerAndCustomLifecycle/test-project/target/classes
> [DEBUG] (f) testOutputDirectory =
> /Users/vmassol/dev/maven/trunks/core-integration-testing/core-integration-tests/src/test/resources/it0115-customArtifactHandlerAnd
[jira] Updated: (MNG-2939) ${basedir isn't well interpolated in properties files
[
http://jira.codehaus.org/browse/MNG-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2939:
---
Description: If you have ${basedir} in a properties file, it is
interpolated to a directory path like C:\mypath\myproject instead of
C\:\\mypathmyproject (was: If you have ${basedir} in a properties file, it is
interpolated to a directory path like C:\mypath\myproject instead of
C\:\\mypath\\myproject)
So what windows code produces the right construct to create this path?
> ${basedir isn't well interpolated in properties files
> -
>
> Key: MNG-2939
> URL: http://jira.codehaus.org/browse/MNG-2939
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4, 2.0.5, 2.0.6
>Reporter: Emmanuel Venisse
> Fix For: 2.0.7
>
>
> If you have ${basedir} in a properties file, it is interpolated to a
> directory path like C:\mypath\myproject instead of C\:\\mypathmyproject
--
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-2921) ejb-client dependency no longer working
[ http://jira.codehaus.org/browse/MNG-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2921. -- Resolution: Fixed Patch applied. Works with trunk and the branch. > ejb-client dependency no longer working > --- > > Key: MNG-2921 > URL: http://jira.codehaus.org/browse/MNG-2921 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: Fedora Core 6 >Reporter: Frank Cornelis >Assignee: Jason van Zyl >Priority: Blocker > Fix For: 2.0.7 > > Attachments: MNG-2921.diff, test.zip > > > When running 'mvn clean install' on the test project (see attachment) under > Maven 2.0.5 every builds as expected. On Maven 2.0.6 it no longer compiles. > On Maven 2.0.5 I get in the log: > [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null) > [DEBUG] be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT:compile > (selected for compile) > Under Maven 2.0.6 I get: > [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null) > [DEBUG] be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT > (selected for null) > and an error message saying it cannot find the required interfaces defined in > Model. > When I remove type:ejb-client in the Client pom.xml it compiles again. -- 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-3027) forked execution does not get configuration from the POM
[ http://jira.codehaus.org/browse/MNG-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3027. --- Resolution: Fixed pulling configuration for mojos forked from reports using the section in addition to the build section. Also, improved the detection of reports when no report-set is defined (when we just iterate through all MojoDescriptors in a plugin). > forked execution does not get configuration from the POM > > > Key: MNG-3027 > URL: http://jira.codehaus.org/browse/MNG-3027 > Project: Maven 2 > Issue Type: Bug >Reporter: John Casey >Assignee: John Casey > > steps to reproduce: > 1. go into maven/components/trunk/maven-project > 2. run `mvn -P reporting site:run` > 3. notice that checkstyle first reports 216 errors, then when it forks and > re-checks (for some reason), it reports 7513 errors. This is because it isn't > configured with the settings in the POM. -- 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-3022) it0108 fails in trunk
[ http://jira.codehaus.org/browse/MNG-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3022. --- Resolution: Fixed apparently, this is only a sporadic problem in my (and others') environments. We should try to improve this test to be a little more stable, but I'm not interested in putting too much time into this test until the artifact resolution subsystem is refactored. Reopen if this becomes a more persistent problem. > it0108 fails in trunk > - > > Key: MNG-3022 > URL: http://jira.codehaus.org/browse/MNG-3022 > Project: Maven 2 > Issue Type: Bug >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > > testSnapshotUpdatedWithMetadata(org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest) > Time elapsed: 3.435 sec <<< FAILURE! > junit.framework.ComparisonFailure: expected: but was: > at junit.framework.Assert.assertEquals(Assert.java:81) > at junit.framework.Assert.assertEquals(Assert.java:87) > at org.apache.maven.it.Verifier.assertArtifactContents(Verifier.java:1499) > at > org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.assertArtifactContents(MavenIT0108SnapshotUpdateTest.java:255) > at > org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.testSnapshotUpdatedWithMetadata(MavenIT0108SnapshotUpdateTest.java:113) > at > org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.testSnapshotUpdatedWithMetadata(MavenIT0108SnapshotUpdateTest.java:113) > 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:324) > at junit.framework.TestCase.runTest(TestCase.java:154) > at > org.apache.maven.integrationtests.AbstractMavenIntegrationTestCase.runTest(AbstractMavenIntegrationTestCase.java:75) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > 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:324) > at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) > at org.apache.maven.surefire.Surefire.run(Surefire.java:132) > 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:324) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) > at > org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:198) > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:398) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:638) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:354) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:255) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:141) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:304) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:124) > at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:906) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:367) > 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:324) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.pl
[jira] Closed: (MNG-2913) neither site lifecycle phase nor site:run mojo triggers surefire tests to run when surefire-report is configured
[ http://jira.codehaus.org/browse/MNG-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-2913. --- Resolution: Fixed reports now trigger forking properly. > neither site lifecycle phase nor site:run mojo triggers surefire tests to run > when surefire-report is configured > - > > Key: MNG-2913 > URL: http://jira.codehaus.org/browse/MNG-2913 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > Fix For: 2.1-alpha-1 > > > it looks like the BuildPlanner is not taking into account forked > lifecycles/executions when it injects report mojos into the mix. -- 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: (MRM-406) Replace the archiva.version propertry with project.version
[ http://jira.codehaus.org/browse/MRM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97833 ] Joakim Erdfelt commented on MRM-406: Mulling about this for a while. I see a third solution. * Remove all entries for archiva related modules/projects. * Remove archiva.version property. * Set in all in all archiva modules/projects to project.version It's the dependencyManagement fault that we are working around with the archiva.version property. > Replace the archiva.version propertry with project.version > -- > > Key: MRM-406 > URL: http://jira.codehaus.org/browse/MRM-406 > Project: Archiva > Issue Type: Improvement >Affects Versions: 1.0-alpha-1 >Reporter: Franz Allan Valencia See >Assignee: Joakim Erdfelt > Fix For: 1.0-alpha-1 > > Attachments: MRM-406-archiva-parent.patch > > > There is no need for the archiva.version property in the pom because this can > be represented by the project.version property. Furthermore this can cause > problems when doing a release with continuum. -- 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] Work stopped: (MRM-143) improve error reporting on corrupt jars, poms, etc
[ http://jira.codehaus.org/browse/MRM-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-143 stopped by Maria Odea Ching. > improve error reporting on corrupt jars, poms, etc > -- > > Key: MRM-143 > URL: http://jira.codehaus.org/browse/MRM-143 > Project: Archiva > Issue Type: Improvement > Components: indexing >Reporter: Brett Porter >Assignee: Maria Odea Ching > Fix For: 1.0-alpha-2 > > > currently, many failures can be detected during indexing but none are > reported anywhere other than the logs. Either these need to be sent through > the regular reporting mechanism, or the regular reporting mechanism needs to > be able to come back later and pick up the same issues. -- 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: (MNG-2471) Add search box to the index page
[ http://jira.codehaus.org/browse/MNG-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2471: --- The search box is way to huge and this really needs to be integrated as an option in the site plugin. > Add search box to the index page > > > Key: MNG-2471 > URL: http://jira.codehaus.org/browse/MNG-2471 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: General >Reporter: Marvin King > Attachments: index-wfocus-woutlogo-wmojocodehausoption.html, > index-with-focus.html, index-without-logo-with-mojocodehausoption.html, > index.html, index[wlogo_wfocus_XHTML].html, > index[wlogo_wfocus_XHTML_CSS2].html, index[wlogo_wfocus_XHTML_CSS].html, > MNG-2471-site.patch, > MNG-2471-site[with_focus_smallsearchbox_withmojocodehausoption].patch, > MNG-2471-site[wlogo_wfocus_XHTML].patch, > site-without-logo-with-mojocodehausoption.css, site[wlogo_wfocus_XHTML].css > > > - google for now -- 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: (MNG-671) implement a license clickthrough
[ http://jira.codehaus.org/browse/MNG-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-671: -- Jesse, you still interested in this and have a need for it? > implement a license clickthrough > > > Key: MNG-671 > URL: http://jira.codehaus.org/browse/MNG-671 > Project: Maven 2 > Issue Type: New Feature >Reporter: Brett Porter > Fix For: 2.1.x > > Attachments: maven-artifact-manager-patch-2.txt, > maven-artifact-manager-patch.txt, maven-artifact-patch-2.txt, > maven-license-patches-3.zip, maven-settings-patch-2.txt, > maven-settings-patch.txt > > > we need some basic license acceptance policy for downloadable artifacts. For > now, this can just be a Y/N that is saved forever. -- 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: (MNG-2831) Cannot add custom artifact handler and custom lifecycle as a build extension
[
http://jira.codehaus.org/browse/MNG-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2831:
---
This does not work currently on the branch. I'm not sure anyone other then
Vincent is using this as it is a custom packaging along with an artifact
handler. I'm not sure this is critical for 2.0.7.
> Cannot add custom artifact handler and custom lifecycle as a build extension
>
>
> Key: MNG-2831
> URL: http://jira.codehaus.org/browse/MNG-2831
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.5
>Reporter: Vincent Massol
>Assignee: Jason van Zyl
> Fix For: 2.0.7
>
>
> I have an extension registering a custom artifact handler and a custom
> lifecycle against plexus. The project that uses that extension get the
> following error:
> {noformat}
> [DEBUG] Error looking up lifecycle mapping to retrieve optional mojos.
> Lifecycle ID: clean. Error: Component descriptor cannot be found in the
> component repository: org.apache.maven.lifecycle.mapping.LifecycleMappingxar.
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> Component descriptor cannot be found in the component repository:
> org.apache.maven.lifecycle.mapping.LifecycleMappingxar.
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:323)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440)
> at
> org.apache.maven.execution.MavenSession.lookup(MavenSession.java:123)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.findOptionalMojosForLifecycle(DefaultLifecycleExecutor.java:)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:999)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:980)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> 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)
> [DEBUG] Skipping disabled repository codehaus.plugin.snapshots
> [DEBUG] Skipping disabled repository apache.snapshots
> [DEBUG] maven-clean-plugin: resolved to version 2.1 from repository central
> [DEBUG] Retrieving parent-POM:
> org.apache.maven.plugins:maven-plugin-parent::2.0 for project:
> null:maven-clean-plugin:maven-plugin:2.1 from the repository.
> [DEBUG] org.apache.maven.plugins:maven-clean-plugin:maven-plugin:2.1:runtime
> (selected for runtime)
> [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for
> runtime)
> [DEBUG] Retrieving parent-POM:
> org.apache.maven.shared:shared-components-parent::1 for project:
> null:file-management:jar:1.0 from the repository.
> [DEBUG] org.apache.maven.shared:file-management:jar:1.0:runtime (selected
> for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected for
> runtime)
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-clean-plugin:2.1:clean' -->
> [DEBUG] (f) directory =
> /Users/vmassol/dev/maven/trunks/core-integration-testing/core-integration-tests/src/test/resources/it0115-customArtifactHandlerAndCustomLifecycle/test-project/target
> [DEBUG] (f) outputDirectory =
> /Users/vmassol/dev/maven/trunks/core-integration-testing/core-integration-tests/src/test/resources/it0115-customArtifactHandlerAndCustomLifecycle/test-project/target/classes
> [DEBUG] (f) testOutputDirectory =
> /Users/vmassol/dev/maven/trunks/core-integration-testing/core-i
[jira] Closed: (MNG-545) M2 / xdoc / attribute of xhtml tags are filtered => so can't use all xhtml features.
[ http://jira.codehaus.org/browse/MNG-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-545. - Resolution: Won't Fix This needs to be a general way to apply styles, not to selected item. Not general enough. > M2 / xdoc / attribute of xhtml tags are filtered => so can't use all xhtml > features. > > > Key: MNG-545 > URL: http://jira.codehaus.org/browse/MNG-545 > Project: Maven 2 > Issue Type: Bug > Environment: w2k >Reporter: Antoine >Priority: Minor > Fix For: 2.2.x > > Attachments: patch.txt > > > in xdocs > in a tag : the class and the id attributes are filtered. So can't use > special css styles. > in a tag : target and title attributes are filtered (but not the href > ). so can't use full features of (I did not try the img attribute, > etc) > => xhtml in xdocs should be rendered as much as it is written in the xdoc > file. > (other problem related : tag is transformed in "", so put a > double line in most browser... (a jira issue is yet open for M1). -- 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: (MNG-2010) Add new lifecycle phases for IT
[ http://jira.codehaus.org/browse/MNG-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2010: --- These look good at first blush but we need to decide whether we are going to work toward the pattern of having integration tests in separate modules before adding these. The lifecycle is getting pretty good and I would rather use the existing test phases and encourage separate modules to do integration testing. I think one module will get out of hand with the possibility of 35 phases. > Add new lifecycle phases for IT > --- > > Key: MNG-2010 > URL: http://jira.codehaus.org/browse/MNG-2010 > Project: Maven 2 > Issue Type: Task > Components: integration tests, Plugins and Lifecycle >Reporter: Vincent Massol > Fix For: 2.0.x > > Attachments: MNG-2010-maven-lifecycle.patch, MNG-2010-site.patch > > > Namely: > * generate-integration-test-sources > * process-integration-test-sources > * generate-integration-test-resources > * process-integration-test-resources > * integration-test-compile > and possibly a: > * integration-test-package -- 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-671) implement a license clickthrough
[ http://jira.codehaus.org/browse/MNG-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97844 ] Jesse Kuhnert commented on MNG-671: --- I'm almost afraid to say no but given that Howard has been doing some hibernate stuff somehow already I'm guessing that the licensing stuff wrt lgpl in apache might not be as strict as was previously thought. ...So no? (unless someone is in the process of doing work for this, in which case yes? ;) ) > implement a license clickthrough > > > Key: MNG-671 > URL: http://jira.codehaus.org/browse/MNG-671 > Project: Maven 2 > Issue Type: New Feature >Reporter: Brett Porter > Fix For: 2.1.x > > Attachments: maven-artifact-manager-patch-2.txt, > maven-artifact-manager-patch.txt, maven-artifact-patch-2.txt, > maven-license-patches-3.zip, maven-settings-patch-2.txt, > maven-settings-patch.txt > > > we need some basic license acceptance policy for downloadable artifacts. For > now, this can just be a Y/N that is saved forever. -- 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-1889) Plugins without descriptors
[ http://jira.codehaus.org/browse/MNG-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1889. -- Resolution: Fixed Patch applied. > Plugins without descriptors > --- > > Key: MNG-1889 > URL: http://jira.codehaus.org/browse/MNG-1889 > Project: Maven 2 > Issue Type: Bug > Components: Plugin Creation Tools >Affects Versions: 2.0.1 >Reporter: Jochen Wiedmann >Priority: Minor > Fix For: 2.0.x > > Attachments: maven-no-plugin-descriptors.patch, > numMojoDescriptors.patch > > > The attached patch throws an exception, if no Mojos are found in a plugin. > Background: If such a plugin is installed, then an NPE is caused in the > DefaultLifeCycleExecutor, which properly assumes, that a plugin contains Mojo > descriptors. Obviously, the actual error is in the plugin itself, where it > should be exposed. It took me some hours to find this actual reason. (I still > do not know, why the Mojos aren't found in my plugin, but that's another > story.) The patch should be able to save the same number of hours for other > plugin developers. > Note: The InvalidPluginDescriptorException, which is triggered by the patch, > is possibly not proper. I choosed it, because it allowed to leave the method > signature unchanged and keep the patch simple. It is up to the reviewer to > choose another exception. -- 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-2399) file size check on pom.xml (or thing specified by --file opt) should only apply to regular files (patch attached)
[
http://jira.codehaus.org/browse/MNG-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2399.
--
Resolution: Won't Fix
The pom.xml should be a file. Not sure why this would ever be useful like
having a POM be a named pipe. You would create a different builder if you
wanted to use a different source.
> file size check on pom.xml (or thing specified by --file opt) should only
> apply to regular files (patch attached)
> -
>
> Key: MNG-2399
> URL: http://jira.codehaus.org/browse/MNG-2399
> Project: Maven 2
> Issue Type: Bug
> Components: Command Line, General
>Affects Versions: 2.0.4
>Reporter: Alan D. Salewski
>Priority: Minor
> Fix For: 2.0.x
>
> Attachments: MNG-2399-maven-core-2.0.4.patch,
> MNG-2399-maven-core-trunk.patch, mvn-get-plugin
>
>
> The file size check in {{maven-core/.../org/apache/maven/DefaultMaven.java}}
> is applied too aggressively. In particular, it should only be applied to
> regular files; when reading from a unix named pipe (probably other
> platform-specific devices, too) we may not be able to determine the file size
> prior to reading the data.
> The real-world motiviation from this is the attached '{{mvn-get-plugin}}'
> {{bash}} script, which wants to pipe a dummy {{pom.xml}} file to {{mvn}} on
> {{stdin}} (by specifying {{/dev/stdin}} as the argument to the {{mvn}}
> {{\-\-file}} command line option).
> Once I submit this issue and have the issue number, I'll attach two patches,
> one against the maven svn trunk, and one against the {{maven-2.0.4}} 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] Closed: (MNG-2656) Revised the Introduction to the POM
[ http://jira.codehaus.org/browse/MNG-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2656. -- Resolution: Won't Fix Check to make sure this is still up to date, and reopen if you want to continue on this. > Revised the Introduction to the POM > --- > > Key: MNG-2656 > URL: http://jira.codehaus.org/browse/MNG-2656 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: Introductions >Reporter: Franz Allan Valencia See >Priority: Minor > Attachments: MNG-2656-maven-site-2.patch, MNG-2656-maven-site.patch > > > Revise the Minimal POM > Discuss Project Inheritance further > Add Discussion about Project Aggregation -- 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-2663) SAR packaging support needed in maven-artifact
[ http://jira.codehaus.org/browse/MNG-2663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2663. -- Resolution: Won't Fix We're not adding any more artifact handlers to the core. In 2.1 this works fine, and we'll fix the issue for adding them in 2.0.7. > SAR packaging support needed in maven-artifact > -- > > Key: MNG-2663 > URL: http://jira.codehaus.org/browse/MNG-2663 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Brian Topping >Priority: Critical > Attachments: sar.patch > > > PAR packaging is supported by Maven Artifact, but SAR is not. This patch is > a components.xml change that provides it, duplicating what is already there > for PAR. -- 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-2687) Module paths may be too long on Windows
[ http://jira.codehaus.org/browse/MNG-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2687. -- Resolution: Fixed Patch applied to trunk and branch. > Module paths may be too long on Windows > --- > > Key: MNG-2687 > URL: http://jira.codehaus.org/browse/MNG-2687 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0-alpha-1 >Reporter: Stepan Roh > Attachments: canonicalize_modules.patch > > > Consider this example: > multiproject X is in C:\some\folder and points to module Y with > ../../Y > module Y is multiproject and points to module Z with ../../Z > module Z is normal jar project > Now when it comes to location of pom.xml of module Z, it will be: > C:\some\folder\..\..\Y\..\..\Z\pom.xml. This may result in unnecessarily long > path - too long for Windows. I suggest to use canonicalization which would > make it much more shorter C:\Z\pom.xml (patch 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] Closed: (MNG-1489) test repository connection first time (get a file at / ?) for better error reporting
[ http://jira.codehaus.org/browse/MNG-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1489. -- Resolution: Won't Fix Too old, stale and not very good patches. > test repository connection first time (get a file at / ?) for better error > reporting > > > Key: MNG-1489 > URL: http://jira.codehaus.org/browse/MNG-1489 > Project: Maven 2 > Issue Type: Improvement >Reporter: Brett Porter > Fix For: 2.1.x > > Attachments: MNG-1489-maven-artifact-manager.patch, > MNG-1489-maven-artifact.patch > > > if a particular remote repository is being used to download from for the > first time, test the retrieval of a known file so that missing > proxies/unreachable repo can be better diagnosed > (this may be possible to do as part of the first request instead). > Currently, users receive the error that a particular plugin can't 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] Closed: (MNG-2621) IncludesArtifactFilter in maven-artifact should accept wildcards
[ http://jira.codehaus.org/browse/MNG-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2621. -- Resolution: Fixed Not allowing wildcard filters. Powerful but could potentially wreak havoc. > IncludesArtifactFilter in maven-artifact should accept wildcards > > > Key: MNG-2621 > URL: http://jira.codehaus.org/browse/MNG-2621 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Brian Topping > Attachments: IncludesArtifactFilter.patch > > > There is a todo in > http://svn.apache.org/viewvc/maven/components/trunk/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/filter/IncludesArtifactFilter.java?view=markup > to add regex. I checked all the sources and could only find usages of this > code by maven-assembly-plugin, webstart-maven-plugin and exec-maven-plugin. > The latter two are in mojo. > If you look at > http://svn.palle.net/projects/hauskeeper/hauskeeper-server/src/assemblies/debian.xml, > Trygvis is assuming that wildcards work, when in fact they do not. > Arguably, this is a documentation bug that it does not work. > The attached patch fixes this problem. -- 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: (MRM-406) Replace the archiva.version propertry with project.version
[
http://jira.codehaus.org/browse/MRM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97852
]
Brett Porter commented on MRM-406:
--
good idea. Let the release plugin take care of updating it.
actually, even if we just populate the versions in dependency management
instead of using ${project.version}, it should work - the release plugin does
deal correctly with depMgmt.
> Replace the archiva.version propertry with project.version
> --
>
> Key: MRM-406
> URL: http://jira.codehaus.org/browse/MRM-406
> Project: Archiva
> Issue Type: Improvement
>Affects Versions: 1.0-alpha-1
>Reporter: Franz Allan Valencia See
>Assignee: Joakim Erdfelt
> Fix For: 1.0-alpha-1
>
> Attachments: MRM-406-archiva-parent.patch
>
>
> There is no need for the archiva.version property in the pom because this can
> be represented by the project.version property. Furthermore this can cause
> problems when doing a release with continuum.
--
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: (MRM-376) Clicking an artifact in the Search Results page results to HTTP ERROR: 500
[ http://jira.codehaus.org/browse/MRM-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97853 ] Maria Odea Ching commented on MRM-376: -- I opened a separate jira for checking or detecting invalid poms, MRM-409. > Clicking an artifact in the Search Results page results to HTTP ERROR: 500 > -- > > Key: MRM-376 > URL: http://jira.codehaus.org/browse/MRM-376 > Project: Archiva > Issue Type: Bug > Components: browser >Reporter: Dawn Angelito >Assignee: Maria Odea Ching >Priority: Blocker > Fix For: 1.0-alpha-1 > > > Steps: > 1) On the left menu, under Find, click Search. > 2) Enter a keyword that you want to search. (e.g. ant) > 3) Click Submit. The search results will be displayed. > 4) Click an artifact from the list. (In my case, I clicked "ant".) > Resulted to: > HTTP ERROR: 500 > Unable to find Database Object [ant:ant:1.6::pom] of type > org.apache.maven.archiva.model.ArchivaArtifactModel using no fetch-group > RequestURI=/archiva/browse/ant/ant/1.6 -- 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-50) Coding standard descriptor
[ http://jira.codehaus.org/browse/MNG-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-50. Resolution: Won't Fix Added to the design documents for 2.1. > Coding standard descriptor > -- > > Key: MNG-50 > URL: http://jira.codehaus.org/browse/MNG-50 > Project: Maven 2 > Issue Type: New Feature >Reporter: Jason van Zyl >Priority: Minor > Fix For: 2.1.x > > > Add a field to the POM that describes the coding standard used by a project. > This value could then be used to create a link to a standard set of documents > describing the chose coding standard: sun, turbine, gnu or what have you. > This could possibly be combined with some other properties that might > generally control source formatting and verification type plugins like > checkstyle. -- 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: (MNG-2577) Allow interpolation of Properties in settings.xml
[ http://jira.codehaus.org/browse/MNG-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2577: --- This one requires some pondering to make sure we can achieve something deterministic. > Allow interpolation of Properties in settings.xml > - > > Key: MNG-2577 > URL: http://jira.codehaus.org/browse/MNG-2577 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.4, 2.0.5 >Reporter: Michael Locher >Priority: Critical > Attachments: DefaultMavenSettingsBuilder.java.diff > > > the attached patch (against 2.0.4) allows interpolation of system properties > into the .m2/settings.xml > and interpolation of system properties and the properties of profiles found > in .m2/settings.xml (if they are activeByDefault) into conf/settings.xml > these features are necessary in order to propagate user account settings > defined in user-specific .m2/settings.xml into server sections of the > institution-wide conf/settings.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-235) named references don't work, regression from beta-5
named references don't work, regression from beta-5
---
Key: MSITE-235
URL: http://jira.codehaus.org/browse/MSITE-235
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-6
Reporter: Brett Porter
src/site/apt/guides/introduction/introduction-to-the-pom.apt
May be because of spaces?
This works in beta-5:
* {{{introduction-to-the-pom.html#What is a POM}What is a POM}}?
...
* {What is a POM}?
But not in 2.0-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: (MNG-2831) Cannot add custom artifact handler and custom lifecycle as a build extension
[
http://jira.codehaus.org/browse/MNG-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97855
]
Brett Porter commented on MNG-2831:
---
I'd say it's a priority for 2.0.x only if it's a regression against an earlier
2.0.x, and there is no workaround.
I guess this could be closed for 2.1-alpha-1, and if we do fix it for 2.0.7
change the version?
> Cannot add custom artifact handler and custom lifecycle as a build extension
>
>
> Key: MNG-2831
> URL: http://jira.codehaus.org/browse/MNG-2831
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.5
>Reporter: Vincent Massol
>Assignee: Jason van Zyl
> Fix For: 2.0.7
>
>
> I have an extension registering a custom artifact handler and a custom
> lifecycle against plexus. The project that uses that extension get the
> following error:
> {noformat}
> [DEBUG] Error looking up lifecycle mapping to retrieve optional mojos.
> Lifecycle ID: clean. Error: Component descriptor cannot be found in the
> component repository: org.apache.maven.lifecycle.mapping.LifecycleMappingxar.
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> Component descriptor cannot be found in the component repository:
> org.apache.maven.lifecycle.mapping.LifecycleMappingxar.
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:323)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440)
> at
> org.apache.maven.execution.MavenSession.lookup(MavenSession.java:123)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.findOptionalMojosForLifecycle(DefaultLifecycleExecutor.java:)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:999)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:980)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> 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)
> [DEBUG] Skipping disabled repository codehaus.plugin.snapshots
> [DEBUG] Skipping disabled repository apache.snapshots
> [DEBUG] maven-clean-plugin: resolved to version 2.1 from repository central
> [DEBUG] Retrieving parent-POM:
> org.apache.maven.plugins:maven-plugin-parent::2.0 for project:
> null:maven-clean-plugin:maven-plugin:2.1 from the repository.
> [DEBUG] org.apache.maven.plugins:maven-clean-plugin:maven-plugin:2.1:runtime
> (selected for runtime)
> [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for
> runtime)
> [DEBUG] Retrieving parent-POM:
> org.apache.maven.shared:shared-components-parent::1 for project:
> null:file-management:jar:1.0 from the repository.
> [DEBUG] org.apache.maven.shared:file-management:jar:1.0:runtime (selected
> for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected for
> runtime)
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-clean-plugin:2.1:clean' -->
> [DEBUG] (f) directory =
> /Users/vmassol/dev/maven/trunks/core-integration-testing/core-integration-tests/src/test/resources/it0115-customArtifactHandlerAndCustomLifecycle/test-project/target
> [DEBUG] (f) outputDirectory =
> /Users/vmassol/dev/maven/trunks/core-integration-testing/core-integration-tests/src/test/resources/it0115-customArtifactHandlerAndCustomLifecycle/test-project/target/classes
> [DEBUG] (f) testOutputDirectory =
> /Users/vmassol/dev/maven/t
[jira] Created: (MRM-409) No checking of invalid poms or artifacts during repository scanning resulting to some objects not being found on the database
No checking of invalid poms or artifacts during repository scanning resulting to some objects not being found on the database - Key: MRM-409 URL: http://jira.codehaus.org/browse/MRM-409 Project: Archiva Issue Type: Bug Components: repository scanning Affects Versions: 1.0-alpha-1 Reporter: Maria Odea Ching See MRM-376 for more details -- 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: (MNG-2072) expression left out of plugin descriptor when you specify default-value before expression in @parameter mojo annotation
[
http://jira.codehaus.org/browse/MNG-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2072:
---
Patch Submitted: (was: [Yes])
> expression left out of plugin descriptor when you specify default-value
> before expression in @parameter mojo annotation
> ---
>
> Key: MNG-2072
> URL: http://jira.codehaus.org/browse/MNG-2072
> Project: Maven 2
> Issue Type: Bug
> Components: Plugin Creation Tools
>Affects Versions: 2.0.2
>Reporter: John Casey
> Fix For: 2.1.x
>
>
> Steps to reproduce:
> 1. open the maven-clean-mojo:CleanMojo
> 2. Reverse the order of the attributes to the @parameter expression in the
> verbose parameter
> 3. run 'mvn clean package'
> 4. copy target/classes/META-INF/maven/plugin.xml to basedir
> 5. Undo the change in the @parameter annotation
> 6. run 'mvn clean package'
> 7. run 'diff -u plugin.xml target/classes/META-INF/maven/plugin.xml
> You'll see something similar to:
> --- plugin.xml 2006-02-14 18:58:06.0 -0500
> +++ target/classes/META-INF/maven/plugin.xml2006-02-14 18:58:20.0
> -0500
> @@ -69,6 +69,7 @@
> default-value="${project.build.testOutputDirectory}"/>
> implementation="boolean">${clean.followSymLinks}
> default-value="${project.build.outputDirectory}"/>
> +${clean.verbose}
>
>
>
> The relevant line is in
> maven-plugin-tools-java:org/apache/maven/tools/plugin/extractor/java/JavaMojoDescriptorExtractor,
> line 417:
> pd.setExpression( parameter.getNamedParameter(
> PARAMETER_EXPRESSION ) );
> it appears to be a qdox problem.
--
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: (MNG-2813) OutOfMemoryError when using profiles and pom inheritance
[ http://jira.codehaus.org/browse/MNG-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2813: --- Assignee: (was: Jason van Zyl) Applying and trying on the trunk. > OutOfMemoryError when using profiles and pom inheritance > > > Key: MNG-2813 > URL: http://jira.codehaus.org/browse/MNG-2813 > Project: Maven 2 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.4 > Environment: maven-2.0.4 >Reporter: Jochen Kuhnle >Priority: Critical > Fix For: 2.1-alpha-1 > > Attachments: MNG-2813-maven-project.patch > > > When using profiles and POM inheritance, Maven grows out of heap space. This > especially happens when using Xpp3Dom's combine.children="append" on plugin > configurations in the POMs. > The cause of this is the DefaultProfileInjector in maven-project. It calls > Xpp3Dom.mergeXpp3Dom with the profile's configuration as dominant DOM, and > the models configuration as recessive DOM to merge the dominant DOM into the > recessive one. However, mergeXpp3Dom directly changes the dominant DOM, > instead of creating a merged copy. Therefor the profiles DOM is changed. If > this profile is injected a second time, e.g. because of a reactor build, the > original DOM is gone. Since the changed profile is also saved in the model, > this often results in the profile DOM (changed by earlier merge) being merged > into itself (saved in model from earlier merge). Boom -- we get an > OutOfMemoryError. > The attached patch changes DefaultProfileInjector by ensuring that dominant > DOMs are copied before they are passed to Xpp3Dom.mergeXpp3Dom. -- 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-2656) Revised the Introduction to the POM
[ http://jira.codehaus.org/browse/MNG-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-2656: --- Assignee: Brett Porter patch looks good to me, and still applies... making some adjustments and applying. > Revised the Introduction to the POM > --- > > Key: MNG-2656 > URL: http://jira.codehaus.org/browse/MNG-2656 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: Introductions >Reporter: Franz Allan Valencia See >Assignee: Brett Porter >Priority: Minor > Attachments: MNG-2656-maven-site-2.patch, MNG-2656-maven-site.patch > > > Revise the Minimal POM > Discuss Project Inheritance further > Add Discussion about Project Aggregation -- 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
