[jira] Created: (MNG-3064) "Building For Different Environments with Maven 2" in APT-format
"Building For Different Environments with Maven 2" in APT-format Key: MNG-3064 URL: http://jira.codehaus.org/browse/MNG-3064 Project: Maven 2 Issue Type: New Feature Components: Documentation: Guides Affects Versions: Documentation Reporter: Erik Drolshammer Priority: Trivial Attachments: building-for-different-environments.patch http://blogs.codehaus.org/people/trygvis/archives/001296_building_for_different_environments_with_maven_2.html in APT format. This guide is often referenced and should be included in the official docs. It is a pure encoding of the guide. I have only correct "lt" to "-" and commented out a dead link to TrackBack. -- 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: (MECLIPSE-284) Transitive dependencies with scope provided should not be part of .classpath file
Transitive dependencies with scope provided should not be part of .classpath file - Key: MECLIPSE-284 URL: http://jira.codehaus.org/browse/MECLIPSE-284 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: dependency resolution Affects Versions: 2.3 Environment: Windows XP Reporter: Jan Dieckmann Attachments: AbstractIdeSupportMojo.java We are using the maven eclipse plugin and it does a very good job for us. Úsing the plugin we now have the pom's as the sole source for all .classpath and .project files in our multi module project. We really appreciate this solution. The maven eclipse plugin does a lot for us .. actually it does too much. Some of our dependencies have a scope of "provided". The default maven behaviour is to ignore those items when transitive dependencies are resolved. The plugin's behaviour is different and there is no configuration to switch to the default behaviour. At least we did not find one. As a result our .classpath files have a lot of unnecessary references to jar files. We changed the class AbstractIdeSupportMojo.java to get rid of dispensable jars. The inner class IVUScopeFilter does the job. This class is used in the method call artifactCollector.collect(). Is there something we missed or should the plugin be changed in a way we did? best regards Jan Dieckmann -- 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: (MECLIPSE-283) Can't set ProjectNatures and BuildCommands for a Multi Module Build
[ http://jira.codehaus.org/browse/MECLIPSE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuri Schimke closed MECLIPSE-283. - Resolution: Fixed Fix Version/s: 2.3 OK I worked it out, while I need to define the defaults in the parent , I still need to include the plugin for each individual module. > Can't set ProjectNatures and BuildCommands for a Multi Module Build > --- > > Key: MECLIPSE-283 > URL: http://jira.codehaus.org/browse/MECLIPSE-283 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: multiproject >Affects Versions: 2.3 >Reporter: Yuri Schimke > Fix For: 2.3 > > > When running eclipse:eclipse the ProjectNatures and BuildCommands that I set > in the parent POM do not get applied to the modules below. > I'd like to include the checkstyle and Spring IDE features once at the top > level and not have to specify in each individual POM.xml > > > > > org.apache.maven.plugins > maven-eclipse-plugin > > > > org.springframework.ide.eclipse.core.springnature > > com.atlassw.tools.eclipse.checkstyle.CheckstyleNature > > > > org.springframework.ide.eclipse.core.springbuilder > > com.atlassw.tools.eclipse.checkstyle.CheckstyleBuilder > > > > > > -- 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-254) tests failed on windows
[
http://jira.codehaus.org/browse/MRELEASE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MRELEASE-254:
--
Attachment:
org.apache.maven.shared.release.phase.RewritePomsForDevelopmentPhaseTest.txt
I attach the surefire report.
Just to know when you installed cygwin Text File Type have you setup (Unix /
binary or DOS / text).
Perso, I use Unix / binary.
But anyway, IMHO using xmlunit (or rewrite xml with jdom Format) for reasons.
First, prevent this problems
Second : following xml will be equals
{code:xml}
bar
bar
bar
{code}
> tests failed on windows
> ---
>
> Key: MRELEASE-254
> URL: http://jira.codehaus.org/browse/MRELEASE-254
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Environment: windows + cygwin
>Reporter: Olivier Lamy
> Attachments: MRELEASE-254,
> org.apache.maven.shared.release.phase.RewritePomsForDevelopmentPhaseTest.txt
>
>
> Tests failed on windows due to Comparing files with String equals method.
> This patch compares xml content with using xmlunit.
--
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-383) Unable to add new file types for Repository Scanning
[ http://jira.codehaus.org/browse/MRM-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100310 ] Mathias Arens commented on MRM-383: --- I have the same problem. > Unable to add new file types for Repository Scanning > > > Key: MRM-383 > URL: http://jira.codehaus.org/browse/MRM-383 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Reporter: Dawn Angelito > Fix For: 1.0-alpha-2 > > > In the Repository Scanning page, unable to add new file types in auto-remove, > ignored and indexable-content sections. Always displays the message: Unable > to process blank pattern. -- 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-420) Editing a network proxy creates a new net work proxy when saving modifications
Editing a network proxy creates a new net work proxy when saving modifications -- Key: MRM-420 URL: http://jira.codehaus.org/browse/MRM-420 Project: Archiva Issue Type: Bug Components: remote proxy, web application Affects Versions: 1.0-alpha-1 Reporter: Fabrice BELLINGARD 1- Create a network proxy 2- Go and edit that proxy : after clicking on "Save Network Proxy", you'll see that a new network proxy has been created, with an empty identifier (which makes it impossible to delete afterwards) -- 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-420) Editing a network proxy creates a new network proxy when saving modifications
[ http://jira.codehaus.org/browse/MRM-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrice BELLINGARD updated MRM-420: --- Summary: Editing a network proxy creates a new network proxy when saving modifications (was: Editing a network proxy creates a new net work proxy when saving modifications) > Editing a network proxy creates a new network proxy when saving modifications > - > > Key: MRM-420 > URL: http://jira.codehaus.org/browse/MRM-420 > Project: Archiva > Issue Type: Bug > Components: remote proxy, web application >Affects Versions: 1.0-alpha-1 >Reporter: Fabrice BELLINGARD >Assignee: Fabrice BELLINGARD > > 1- Create a network proxy > 2- Go and edit that proxy : after clicking on "Save Network Proxy", you'll > see that a new network proxy has been created, with an empty identifier > (which makes it impossible to delete afterwards) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-320) svn: error: cannot set LC_ALL locale
[
http://jira.codehaus.org/browse/SCM-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100314
]
Morten Kristiansen commented on SCM-320:
I also experience this problem, and it happened going from 1.0-beta-3 to 1.0
for the maven-scm-plugin. I can set LC_ALL=en_US, and then it works fine. But
this again effects some XML writing we perform during build, so we don't really
want that.
What I have done is to set explicit version of the maven-scm-plugin in my pom,
using 1.0-beta-3. The problem occurs again using Continuum. It also uses the
scm plugin, but I can't control which version it is using. Or, can I?
> svn: error: cannot set LC_ALL locale
>
>
> Key: SCM-320
> URL: http://jira.codehaus.org/browse/SCM-320
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
> Environment: Linux 2.6.17.13-rev2-AM.RS #7 SMP Tue Nov 14 12:55:12
> PST 2006 x86_64 x86_64 x86_64 GNU/Linux
> Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode)
> Maven 2.0.5
>Reporter: Tim Morrow
>
> I'm using Maven 2.0.5. After the recent update to scm plugin version 1.0, my
> updates from a subversion repository fail. I get this:
> {noformat}
> $ mvn scm:update
> [INFO] [scm:update]
> [INFO] Executing: svn --non-interactive update
> [INFO] Working directory: /the/right/path
> [ERROR] Provider message:
> [ERROR] The svn command failed.
> [ERROR] Command output:
> [ERROR] svn: error: cannot set LC_ALL locale
> svn: error: environment variable LANG is not set
> svn: error: please check that your locale name is correct
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Command failed.The svn command failed.
> [INFO]
>
> {noformat}
> * Note that running "svn update" from the command line works just fine.
> * I did try setting the LANG environment variable to "en" then "en_US"
> locale, but that didn't work either.
> * If I set the maven-scm-plugin version to 1.0-rc1 or 1.0-beta-4, 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] Work started: (MRM-420) Editing a network proxy creates a new network proxy when saving modifications
[ http://jira.codehaus.org/browse/MRM-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-420 started by Fabrice BELLINGARD. > Editing a network proxy creates a new network proxy when saving modifications > - > > Key: MRM-420 > URL: http://jira.codehaus.org/browse/MRM-420 > Project: Archiva > Issue Type: Bug > Components: remote proxy, web application >Affects Versions: 1.0-alpha-1 >Reporter: Fabrice BELLINGARD >Assignee: Fabrice BELLINGARD > > 1- Create a network proxy > 2- Go and edit that proxy : after clicking on "Save Network Proxy", you'll > see that a new network proxy has been created, with an empty identifier > (which makes it impossible to delete afterwards) -- 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-420) Editing a network proxy creates a new network proxy when saving modifications
[ http://jira.codehaus.org/browse/MRM-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100320 ] Fabrice BELLINGARD commented on MRM-420: The attribute "disabled" of the proxy.id input field is set to true when editing, which causes the value of this field not to be sent back to the server when submitting the form. > Editing a network proxy creates a new network proxy when saving modifications > - > > Key: MRM-420 > URL: http://jira.codehaus.org/browse/MRM-420 > Project: Archiva > Issue Type: Bug > Components: remote proxy, web application >Affects Versions: 1.0-alpha-1 >Reporter: Fabrice BELLINGARD >Assignee: Fabrice BELLINGARD > > 1- Create a network proxy > 2- Go and edit that proxy : after clicking on "Save Network Proxy", you'll > see that a new network proxy has been created, with an empty identifier > (which makes it impossible to delete afterwards) -- 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-255) during a release several elements are removed from the pom.xml (which should be left there)
[ http://jira.codehaus.org/browse/MRELEASE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100319 ] Emmanuel Venisse commented on MRELEASE-255: --- Can you test with beta-5 or beta-6? I'm sure it's fixed since beta-5 > during a release several elements are removed from the pom.xml (which should > be left there) > --- > > Key: MRELEASE-255 > URL: http://jira.codehaus.org/browse/MRELEASE-255 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 >Reporter: Roman Cerny > > the following elements are removed from the pom.xml, during a release... > > > > > > > ]> -- 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-255) during a release several elements are removed from the pom.xml (which should be left there)
during a release several elements are removed from the pom.xml (which should be left there) --- Key: MRELEASE-255 URL: http://jira.codehaus.org/browse/MRELEASE-255 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Reporter: Roman Cerny the following elements are removed from the pom.xml, during a release... ]> -- 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-254) tests failed on windows
[ http://jira.codehaus.org/browse/MRELEASE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100321 ] Mark Hobson commented on MRELEASE-254: -- Looking at the Surefire report it appears to be losing the licence comment and inserting blank newlines into the rewritten POMs, which is wrong. This doesn't appear to be a line-ending problem - have you got any local modifications? What version of Maven are you using to run the tests? I'm not keen on using XML comparision since the indentation would not be tested, as you described above. > tests failed on windows > --- > > Key: MRELEASE-254 > URL: http://jira.codehaus.org/browse/MRELEASE-254 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: windows + cygwin >Reporter: Olivier Lamy > Attachments: MRELEASE-254, > org.apache.maven.shared.release.phase.RewritePomsForDevelopmentPhaseTest.txt > > > Tests failed on windows due to Comparing files with String equals method. > This patch compares xml content with using xmlunit. -- 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-2339) ${project.*} are interpreted in the wrong place
[
http://jira.codehaus.org/browse/MNG-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100325
]
Kenney Westerhof commented on MNG-2339:
---
Comitted fix in r549786 on trunk (2.1).
It produces lots of warnings - i'm not sure we want exactly that behaviour in
2.0.
See http://docs.codehaus.org/display/MAVEN/Refactoring+Interpolation
> ${project.*} are interpreted in the wrong place
> ---
>
> Key: MNG-2339
> URL: http://jira.codehaus.org/browse/MNG-2339
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.4
>Reporter: Emmanuel Venisse
>Assignee: Kenney Westerhof
>Priority: Critical
> Fix For: 2.0.8
>
>
> If a plugin use ${project.version}, this parameter is interpreted with the
> version of the current project and not the plugin version. I think we have
> the same pb with dependencies and other ${project.*}
> For a plugin in version 2.0 used in a project in version 1.0-SNAPSHOT,
> ${project.version} used in the plugin will be interpreted as 1.0-SNAPSHOT
> instead of 2.0
--
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: (MRELEASE-255) during a release several elements are removed from the pom.xml (which should be left there)
[ http://jira.codehaus.org/browse/MRELEASE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100327 ] Roman Cerny edited comment on MRELEASE-255 at 6/22/07 7:02 AM: --- just tested with 2.0-beta-6 the plugin still removes all three entries (xml, svn keywords and doctype) the plugin also changed a containing an umlaut from "ö" to "ö" (which leads to an error in the team list (of the generated project site)) was: just tested with 2.0-beta-6 the plugin still removes all three entries (xml, svn keywords and doctype) the plugin also changed a containing an umlaut from "ö" to "ö" (which leads to an error in the team list (of the generated project site)) > during a release several elements are removed from the pom.xml (which should > be left there) > --- > > Key: MRELEASE-255 > URL: http://jira.codehaus.org/browse/MRELEASE-255 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 >Reporter: Roman Cerny > > the following elements are removed from the pom.xml, during a release... > > > > > > > ]> -- 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-254) tests failed on windows
[ http://jira.codehaus.org/browse/MRELEASE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100329 ] Olivier Lamy commented on MRELEASE-254: --- No local modification. mvn -v says : Maven version: 2.0.5 (JAVA_HOME -> 1.4) Ok I understand more the need of String comparaison due to indetantion. But it looks to be a very STRANGE trouble. > tests failed on windows > --- > > Key: MRELEASE-254 > URL: http://jira.codehaus.org/browse/MRELEASE-254 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: windows + cygwin >Reporter: Olivier Lamy > Attachments: MRELEASE-254, > org.apache.maven.shared.release.phase.RewritePomsForDevelopmentPhaseTest.txt > > > Tests failed on windows due to Comparing files with String equals method. > This patch compares xml content with using xmlunit. -- 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: (MRELEASE-255) during a release several elements are removed from the pom.xml (which should be left there)
[ http://jira.codehaus.org/browse/MRELEASE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100327 ] Roman Cerny edited comment on MRELEASE-255 at 6/22/07 7:05 AM: --- just tested with 2.0-beta-6 the plugin still removes all three entries (xml, svn keywords and doctype) the plugin also changed a containing an umlaut from "ö" to "ö" (which leads to an error in the team list (of the generated project site)) error takes place when executing the "mvn release:prepare" goal was: just tested with 2.0-beta-6 the plugin still removes all three entries (xml, svn keywords and doctype) the plugin also changed a containing an umlaut from "ö" to "ö" (which leads to an error in the team list (of the generated project site)) error takes place during the "mvn release:prepare" goal > during a release several elements are removed from the pom.xml (which should > be left there) > --- > > Key: MRELEASE-255 > URL: http://jira.codehaus.org/browse/MRELEASE-255 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 >Reporter: Roman Cerny > > the following elements are removed from the pom.xml, during a release... > > > > > > > ]> -- 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: (MRELEASE-255) during a release several elements are removed from the pom.xml (which should be left there)
[ http://jira.codehaus.org/browse/MRELEASE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100327 ] Roman Cerny edited comment on MRELEASE-255 at 6/22/07 7:05 AM: --- just tested with 2.0-beta-6 the plugin still removes all three entries (xml, svn keywords and doctype) the plugin also changed a containing an umlaut from "ö" to "ö" (which leads to an error in the team list (of the generated project site)) error takes place during the "mvn release:prepare" goal was: just tested with 2.0-beta-6 the plugin still removes all three entries (xml, svn keywords and doctype) the plugin also changed a containing an umlaut from "ö" to "ö" (which leads to an error in the team list (of the generated project site)) > during a release several elements are removed from the pom.xml (which should > be left there) > --- > > Key: MRELEASE-255 > URL: http://jira.codehaus.org/browse/MRELEASE-255 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 >Reporter: Roman Cerny > > the following elements are removed from the pom.xml, during a release... > > > > > > > ]> -- 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: (MRM-416) Find artifact does not work.
[ http://jira.codehaus.org/browse/MRM-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100328 ] Maria Odea Ching edited comment on MRM-416 at 6/22/07 7:12 AM: --- Fixed in -r549792 Fix was: - Added DatabaseSearch class for querying from the database (This could be used for future database queries so there is only one entry point for all db queries) - Added ArtifactsByChecksumConstraint to be used for querying artifacts by checksum (either sha1, md5 or both) - Updated "artifact" result of findArtifact action in xwork.xml - Updated SearchAction to find an artifact (using checksums) in the database instead of in the indices - Updated results.jsp to accomodate when the results came from the database instead of the SearchResults that is for index searching - Deleted ArtifactsBySha1Constraint and its test, replaced by ArtifactsByChecksumConstraint - Created tests for the new classes added Please verify.. thanks :) was: Fixed in -r549792 Fix was: - Added DatabaseSearch class for querying from the database (This could be used for future database queries so there is only one entry point for all db queries) - Added ArtifactsByChecksumConstraint to be used for querying artifacts by checksum (either sha1, md5 or both) - Updated "artifact" result of findArtifact action in xwork.xml - Updated SearchAction to find an artifact (using checksums) in the database instead of in the indices - Updated results.jsp to accomodate when the results came from the database instead of the SearchResults that is for index searching - Deleted ArtifactsBySha1Constraint and its test, replaced by ArtifactsByChecksumConstraint - Created tests for the new classes added > Find artifact does not work. > > > Key: MRM-416 > URL: http://jira.codehaus.org/browse/MRM-416 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Henry S. Isidro >Assignee: Maria Odea Ching > Fix For: 1.0-alpha-2 > > > Finding an artifact always shows the 'No results found' message even though > the artifact that is being looked for is in the repository. -- 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-416) Find artifact does not work.
[ http://jira.codehaus.org/browse/MRM-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100328 ] Maria Odea Ching commented on MRM-416: -- Fixed in -r549792 Fix was: - Added DatabaseSearch class for querying from the database (This could be used for future database queries so there is only one entry point for all db queries) - Added ArtifactsByChecksumConstraint to be used for querying artifacts by checksum (either sha1, md5 or both) - Updated "artifact" result of findArtifact action in xwork.xml - Updated SearchAction to find an artifact (using checksums) in the database instead of in the indices - Updated results.jsp to accomodate when the results came from the database instead of the SearchResults that is for index searching - Deleted ArtifactsBySha1Constraint and its test, replaced by ArtifactsByChecksumConstraint - Created tests for the new classes added > Find artifact does not work. > > > Key: MRM-416 > URL: http://jira.codehaus.org/browse/MRM-416 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Henry S. Isidro >Assignee: Maria Odea Ching > Fix For: 1.0-alpha-2 > > > Finding an artifact always shows the 'No results found' message even though > the artifact that is being looked for is in the repository. -- 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-255) during a release several elements are removed from the pom.xml (which should be left there)
[ http://jira.codehaus.org/browse/MRELEASE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100327 ] Roman Cerny commented on MRELEASE-255: -- just tested with 2.0-beta-6 the plugin still removes all three entries (xml, svn keywords and doctype) the plugin also changed a containing an umlaut from "ö" to "ö" (which leads to an error in the team list (of the generated project site)) > during a release several elements are removed from the pom.xml (which should > be left there) > --- > > Key: MRELEASE-255 > URL: http://jira.codehaus.org/browse/MRELEASE-255 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 >Reporter: Roman Cerny > > the following elements are removed from the pom.xml, during a release... > > > > > > > ]> -- 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-420) Editing a network proxy creates a new network proxy when saving modifications
[ http://jira.codehaus.org/browse/MRM-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrice BELLINGARD closed MRM-420. -- Resolution: Fixed Fix Version/s: 1.0-alpha-2 Fixed on trunk. > Editing a network proxy creates a new network proxy when saving modifications > - > > Key: MRM-420 > URL: http://jira.codehaus.org/browse/MRM-420 > Project: Archiva > Issue Type: Bug > Components: remote proxy, web application >Affects Versions: 1.0-alpha-1 >Reporter: Fabrice BELLINGARD >Assignee: Fabrice BELLINGARD > Fix For: 1.0-alpha-2 > > > 1- Create a network proxy > 2- Go and edit that proxy : after clicking on "Save Network Proxy", you'll > see that a new network proxy has been created, with an empty identifier > (which makes it impossible to delete afterwards) -- 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-416) Find artifact does not work.
[ http://jira.codehaus.org/browse/MRM-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-416 stopped by Maria Odea Ching. > Find artifact does not work. > > > Key: MRM-416 > URL: http://jira.codehaus.org/browse/MRM-416 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Henry S. Isidro >Assignee: Maria Odea Ching > Fix For: 1.0-alpha-2 > > > Finding an artifact always shows the 'No results found' message even though > the artifact that is being looked for is in the repository. -- 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-254) tests failed on windows
[ http://jira.codehaus.org/browse/MRELEASE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson updated MRELEASE-254: - Attachment: build.log I've just built successfully under JDK1.4.2_14 with Maven 2.0.5 on Windows XP & Cygwin - see attached build log. I can't seem to be able to reproduce your problem, any further clues welcome. > tests failed on windows > --- > > Key: MRELEASE-254 > URL: http://jira.codehaus.org/browse/MRELEASE-254 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: windows + cygwin >Reporter: Olivier Lamy > Attachments: build.log, MRELEASE-254, > org.apache.maven.shared.release.phase.RewritePomsForDevelopmentPhaseTest.txt > > > Tests failed on windows due to Comparing files with String equals method. > This patch compares xml content with using xmlunit. -- 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: (MPMD-56) targetJdk support for jdk 1.6
[ http://jira.codehaus.org/browse/MPMD-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Gilday updated MPMD-56: -- Attachment: martingilday-pmd-patch.txt > targetJdk support for jdk 1.6 > - > > Key: MPMD-56 > URL: http://jira.codehaus.org/browse/MPMD-56 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 2.2 > Environment: Any >Reporter: Jeff Campbell > Attachments: martingilday-pmd-patch.txt > > > Currently you can only set a targetJdk to 1.3, 1.4, and 1.5 what about > 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] Updated: (MPMD-56) targetJdk support for jdk 1.6
[ http://jira.codehaus.org/browse/MPMD-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Gilday updated MPMD-56: -- Attachment: martingilday-pmd-patch2.txt > targetJdk support for jdk 1.6 > - > > Key: MPMD-56 > URL: http://jira.codehaus.org/browse/MPMD-56 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 2.2 > Environment: Any >Reporter: Jeff Campbell > Attachments: martingilday-pmd-patch.txt, martingilday-pmd-patch2.txt > > > Currently you can only set a targetJdk to 1.3, 1.4, and 1.5 what about > 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] Created: (MRM-421) Default configuration does not proxy the central repo - Failed pre-download policies
Default configuration does not proxy the central repo - Failed pre-download
policies
Key: MRM-421
URL: http://jira.codehaus.org/browse/MRM-421
Project: Archiva
Issue Type: Bug
Affects Versions: 1.0-alpha-2
Reporter: Wendy Smoak
Testing the fix for MRM-370...
rm -rf $M2_REPO/org/apache/maven/plugins/maven-clean-plugin
cd /path/to/project
mvn clean
I get the usual ...could not be found or no valid version... message. In the
Archiva logs:
jvm 1| 2007-06-22 06:25:29,796 [SocketListener0-1] INFO
org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Failed
pre-download policies
-C:\${appserver.home}\repositories\internal\org\apache\maven\plugins\maven-clean-plugin\maven-metadata.xml
There are no whitelist patterns for the internal -> central proxy connector.
We should ship with configuration that actually makes it proxy. Adding a
whitelist pattern of "*" seems to work.
Should an absence of whitelist patterns mean 'proxy everything'?
--
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-422) Default configuration for snapshots repository uses directory name of internal
Default configuration for snapshots repository uses directory name of internal
--
Key: MRM-422
URL: http://jira.codehaus.org/browse/MRM-422
Project: Archiva
Issue Type: Bug
Components: web application
Affects Versions: 1.0-alpha-2
Reporter: Wendy Smoak
Priority: Minor
The default configuration includes two repositories: 'internal' and
'snapshots'.
Both are configured to use a single directory named 'internal.'
Archiva Managed Snapshot Repository
Identifier snapshots
NameArchiva Managed Snapshot Repository
--> Directory /C:/${appserver.home}/repositories/internal/
<-
WebDAV URL http://localhost:8080/archiva/repository/snapshots/
TypeMaven 2.x Repository
Instead, the snapshots repo should use a directory called 'snapshots'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPMD-56) targetJdk support for jdk 1.6
[ http://jira.codehaus.org/browse/MPMD-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100339 ] Martin Gilday commented on MPMD-56: --- I have attached two patches. The first simply adds in 1.6 into the selection statement. The second I think is a slight improvement as it uses SourceType.getSourceTypeForId from PMD to select based upon an id. This should protect from having to change the plugin to eventually support 1.7 (Of course a new release would still be needed to use the new version of PMD). > targetJdk support for jdk 1.6 > - > > Key: MPMD-56 > URL: http://jira.codehaus.org/browse/MPMD-56 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 2.2 > Environment: Any >Reporter: Jeff Campbell > Attachments: martingilday-pmd-patch.txt, martingilday-pmd-patch2.txt > > > Currently you can only set a targetJdk to 1.3, 1.4, and 1.5 what about > 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] Updated: (MRM-422) Wrong directory name for snapshots repo in default config
[
http://jira.codehaus.org/browse/MRM-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak updated MRM-422:
Summary: Wrong directory name for snapshots repo in default config (was:
Default configuration for snapshots repository uses directory name of internal)
> Wrong directory name for snapshots repo in default config
> -
>
> Key: MRM-422
> URL: http://jira.codehaus.org/browse/MRM-422
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-alpha-2
>Reporter: Wendy Smoak
>Priority: Minor
>
> The default configuration includes two repositories: 'internal' and
> 'snapshots'.
> Both are configured to use a single directory named 'internal.'
> Archiva Managed Snapshot Repository
> Identifiersnapshots
> Name Archiva Managed Snapshot Repository
> --> Directory/C:/${appserver.home}/repositories/internal/
> <-
> WebDAV URLhttp://localhost:8080/archiva/repository/snapshots/
> Type Maven 2.x Repository
> Instead, the snapshots repo should use a directory called 'snapshots'.
--
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-3065) Add a element to the schema for dependencies a la M1
Add a element to the schema for dependencies a la M1 - Key: MNG-3065 URL: http://jira.codehaus.org/browse/MNG-3065 Project: Maven 2 Issue Type: Improvement Components: Dependencies Affects Versions: 2.0.x Reporter: Jason Melnick Priority: Minor Adding the optional element to the dependency element graph will allow more control for plug-in developers, as well as making things like WAR packaging much more straightforward. Why would I want to have to mess around with declaring dependencies of a WAR project that uses it's EARs deps so that they aren't included in WEB-INF/lib? These deps are NOT optional - it's just a workaround to get it to work because a clear facility isn't provided. Specifying true is much more clear for all parties. -- 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-179) Assembled jar includes artifact names in path
[
http://jira.codehaus.org/browse/MASSEMBLY-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100350
]
Patrick Kimber commented on MASSEMBLY-179:
--
I have a sample project which reproduces this issue. Let me know if you want
me to attach a copy.
> Assembled jar includes artifact names in path
> -
>
> Key: MASSEMBLY-179
> URL: http://jira.codehaus.org/browse/MASSEMBLY-179
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Jonathan Komorek
>Priority: Blocker
> Fix For: 2.2-beta-2
>
>
> This issue does not occur in 2.1 and began occurring in 2.2-SNAPSHOT
> (roughly) a couple months ago.
> After assembling a jar, the path for each of the included files begins with
> what seems to be ${artifactId}-${version}.${packaging}
> This includes files from dependent jars and files from sub-modules - all
> files.
> The plugin is configured in the POM as follows:
>
>
>
> maven-assembly-plugin
>
>
> 1
> package
>
> attached
>
>
>
> 2.2-SNAPSHOT
>
> assembly.xml
>
>
>
>
> The entire assembly.xml is as follows:
>
> dependencies
>
> jar
>
> false
>
>
> /
> true
> runtime
>
>
>
--
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-3067) Getting arbitrary depth=2 dependencies when using optional=true
Getting arbitrary depth=2 dependencies when using optional=true --- Key: MNG-3067 URL: http://jira.codehaus.org/browse/MNG-3067 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Reporter: Jason Melnick When using a dependency section like this in a WAR (just an excerpt - these are not the culprit to my knowledge): xmlbeans xbean true xmlbeans xbean_xpath true xml-apis xml-apis true xml-resolver xml-resolver true I am getting artifacts with a depth of 2 - when nothing should resolve. Only depth 1 (non-optional deps, plus their deps, etc) should be resolving. i.e. [INFO] mq: 2 [INFO] mqjms: 2 [INFO] spring-orm: 2 [INFO] struts: 1 [INFO] child: commons-beanutils:commons-beanutils:jar:1.6.1:compile (2; disabled) [INFO] child: commons-collections:commons-collections:jar:3.1:compile (2; disabled) [INFO] child: struts:struts-legacy:jar:1.1:compile (2; enabled) [INFO] child: commons-digester:commons-digester:jar:1.6:compile (2; disabled) [INFO] child: commons-fileupload:commons-fileupload:jar:1.0:compile (2; enabled) [INFO] child: commons-lang:commons-lang:jar:2.1:compile (2; disabled) [INFO] child: commons-logging:commons-logging:jar:1.0:compile (2; disabled) [INFO] child: commons-validator:commons-validator:jar:1.1.4:compile (2; disabled) [INFO] child: oro:oro:jar:2.0.7:compile (2; disabled) [INFO] child: javax.sql:jdbc-stdext:jar:2.0:compile (2; enabled) [INFO] commons-logging: 1 [INFO] child: log4j:log4j:jar:1.2.6:compile (2; enabled) [INFO] child: logkit:logkit:jar:1.0.1:compile (2; enabled) [INFO] child: avalon-framework:avalon-framework:jar:4.1.3:compile (2; enabled) [INFO] distribution-service-client-jar: 2 [INFO] jdbc-stdext: 2 [INFO] struts-bean: 1 [INFO] cmf-nol-submit-jar: 2 [INFO] mqiiop: 2 [INFO] distribution-service-ejb: 2 [INFO] jaxen: 2 [INFO] spring-dao: 2 [INFO] struts-tiles: 1 [INFO] cmf-final-jar: 2 [INFO] struts-legacy: 2 [INFO] standard: 1 [INFO] saxpath: 2 [INFO] jstl: 1 [INFO] nw-exception: 1 [INFO] relaxngDatatype: 2 [INFO] mqbind: 2 [INFO] struts-logic: 1 [INFO] commons-fileupload: 2 [INFO] isorelax: 2 [INFO] spring-core: 2 [INFO] log4j: 1 [INFO] msv: 2 [INFO] struts-nested: 1 [INFO] nw-struts: 1 [INFO] child: struts:struts:jar:1.1:compile (2; disabled) [INFO] struts-html: 1 [INFO] authorization-tag-jar: 1 [INFO] child: commons-logging:commons-logging:jar:1.0.4:compile (2; disabled) [INFO] child: log4j:log4j:jar:1.2.7:compile (2; disabled) [INFO] child: com.nationwide.common:nw-exception:jar:1.2.0:compile (2; disabled) [INFO] child: com.nationwide.pc.claims.horizon:simple-security-client-jar:jar:2.0.0:compile (2; 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-424) Source distribution should have version in the name and unpack to versioned -src directory
Source distribution should have version in the name and unpack to versioned -src directory -- Key: MRM-424 URL: http://jira.codehaus.org/browse/MRM-424 Project: Archiva Issue Type: Improvement Affects Versions: 1.0-alpha-2 Reporter: Wendy Smoak The source distribution should be named archiva-1.0-alpha-2-src.zip and unpack to archiva-1.0-alpha-2-src. Based on other discussions both the binary and source distributions should be renamed (and unpack to) apache-archiva-*. -- 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-423) Source distribution is missing license and notice files
Source distribution is missing license and notice files --- Key: MRM-423 URL: http://jira.codehaus.org/browse/MRM-423 Project: Archiva Issue Type: Bug Affects Versions: 1.0-alpha-2 Reporter: Wendy Smoak The Archiva source distribution is missing license and notice files. They must be included. -- 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-3067) Getting arbitrary depth=2 dependencies when using optional=true
[
http://jira.codehaus.org/browse/MNG-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100354
]
Jason Melnick commented on MNG-3067:
Note that the output towards the end was generated by using the following code:
ArtifactFilter filter = new ScopeArtifactFilter(DefaultArtifact.SCOPE_RUNTIME);
result =
resolver.resolveTransitively(dependencyArtifacts,
mavenProject.getArtifact(),local,remoteRepos, source, filter);
Set nodes = result.getArtifactResolutionNodes();
for (Iterator iter = nodes.iterator(); iter.hasNext();)
{
ResolutionNode node = (ResolutionNode)
iter.next();
if (!node.getArtifact().isOptional()) {
logger.info(node.getArtifact().getArtifactId() + ": " + node.getDepth());
if (node.getDepth() == 1) {
for (Iterator iter2 =
node.getChildrenIterator(); iter2.hasNext();) {
logger.info("\t child:
" + iter2.next().toString());
}
}
}
}
Also, none of the non-child depth 2 dependencies are declared in this POM and
are transitive dependencies of declared deps marked as optional.
> Getting arbitrary depth=2 dependencies when using optional=true
> ---
>
> Key: MNG-3067
> URL: http://jira.codehaus.org/browse/MNG-3067
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.6
>Reporter: Jason Melnick
>
> When using a dependency section like this in a WAR (just an excerpt - these
> are not the culprit to my knowledge):
>
> xmlbeans
> xbean
> true
>
>
> xmlbeans
> xbean_xpath
> true
>
>
> xml-apis
> xml-apis
> true
>
>
> xml-resolver
> xml-resolver
> true
>
> I am getting artifacts with a depth of 2 - when nothing should resolve. Only
> depth 1 (non-optional deps, plus their deps, etc) should be resolving. i.e.
> [INFO] mq: 2
> [INFO] mqjms: 2
> [INFO] spring-orm: 2
> [INFO] struts: 1
> [INFO] child: commons-beanutils:commons-beanutils:jar:1.6.1:compile
> (2; disabled)
> [INFO] child: commons-collections:commons-collections:jar:3.1:compile
> (2; disabled)
> [INFO] child: struts:struts-legacy:jar:1.1:compile (2; enabled)
> [INFO] child: commons-digester:commons-digester:jar:1.6:compile (2;
> disabled)
> [INFO] child: commons-fileupload:commons-fileupload:jar:1.0:compile
> (2; enabled)
> [INFO] child: commons-lang:commons-lang:jar:2.1:compile (2; disabled)
> [INFO] child: commons-logging:commons-logging:jar:1.0:compile (2;
> disabled)
> [INFO] child: commons-validator:commons-validator:jar:1.1.4:compile
> (2; disabled)
> [INFO] child: oro:oro:jar:2.0.7:compile (2; disabled)
> [INFO] child: javax.sql:jdbc-stdext:jar:2.0:compile (2; enabled)
> [INFO] commons-logging: 1
> [INFO] child: log4j:log4j:jar:1.2.6:compile (2; enabled)
> [INFO] child: logkit:logkit:jar:1.0.1:compile (2; enabled)
> [INFO] child: avalon-framework:avalon-framework:jar:4.1.3:compile (2;
> enabled)
> [INFO] distribution-service-client-jar: 2
> [INFO] jdbc-stdext: 2
> [INFO] struts-bean: 1
> [INFO] cmf-nol-submit-jar: 2
> [INFO] mqiiop: 2
> [INFO] distribution-service-ejb: 2
> [INFO] jaxen: 2
> [INFO] spring-dao: 2
> [INFO] struts-tiles: 1
> [INFO] cmf-final-jar: 2
> [INFO] struts-legacy: 2
> [INFO] standard: 1
> [INFO] saxpath: 2
> [INFO] jstl: 1
> [INFO] nw-exception: 1
> [INFO] relaxngDatatype: 2
> [INFO] mqbind: 2
> [INFO] struts-logic: 1
> [INFO] commons-fileupload: 2
> [INFO] isorelax: 2
> [INFO] spring-core: 2
> [INFO] log4j: 1
> [INFO] msv: 2
> [INFO] struts-nested: 1
> [INFO] nw-struts: 1
> [INFO] child: struts:struts:jar:1.1:compile (2; disabled)
> [INFO] struts-html: 1
> [INFO] authorization-tag-jar: 1
> [INFO] child: commons-logging:commons-logging:jar:1.0.4:compile (2;
> disabled)
> [INFO] child: log4j:log4j:jar:1.2.7:compile (2; disabled)
> [INFO] child: com.nationwide.common:nw-exception:jar:1.2.0:compile
> (2; disabled)
> [INFO] child:
> com.nationwide.
[jira] Created: (MNG-3066) Allow the specification of modules with project coordinates
Allow the specification of modules with project coordinates --- Key: MNG-3066 URL: http://jira.codehaus.org/browse/MNG-3066 Project: Maven 2 Issue Type: New Feature Affects Versions: 2.0.6 Reporter: Steven Cummings Currently, modules can only be specified by the parent POM as "simple paths", i.e., relative to the current project, like "module-a" and "../module-a". This explicit filesystem relation between parent project and modules can cause issues like CONTINUUM-1163. It makes sense to allow modules to be specified with project coordinates, like: module-a com.mygroup This way no explicit filesystem or SCM relation has to exist. The only requirement would be that the parent project is able to locate the specified artifact in one of its defined repositories (or repositories from settings.xml), and the artifact's POM contain an SCM section so that it can check out the code. >From there, maven can decide what temporary space to check out and build the >"child" project in, perhaps .m2-workspace or .m2-modules-temp in the >user-home. Perhaps this also could be configured in settings.xml just like the >local repository location. The value of this would be: * Parent projects no longer have to exist "one level above" or relative to all of its modules in SCM and the checkout filesystem. * When SCM is organized such that not all of the module projects are in the same folder, project coordinates could be simpler than relative paths. * When not all of the projects are in the same SCM repos, then the current module scheme won't even work. * It would be nice to have the ability to create ad-hoc parent POMs just for the purpose of executing arbitrary group builds. The modules can't specify more than one parent, but there may be more than one grouping from the top-down perspective. ** A good example is where a team has several groupIds that all of their projects are grouped into. Perhaps they don't want use parent POMs, or each group has unique configuration and so each has a different parent POM for its projects to inherit. Then, the group wants to run a global dashboard (dashboard-maven-plugin) report on all projects in all groups but not really use this new parent POM for inheritance or settings, only for the aggregation. They'd like this so that there is one place to go to observe the health of the team's projects. * Finally, some operating systems (to remained un-named because this is their defect...) have path limits of around 255 characters. Sometimes forcing modules to exist under or relative to their parent causes the checkouts for the group to surpass this limit. If there are projects already close to this limit, the path of the parent project can push paths of package directories and long class-names on over that limit. -- 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: (MECLIPSE-285) Add support for additional src/test dirs (like src/main/groovy)
Add support for additional src/test dirs (like src/main/groovy) --- Key: MECLIPSE-285 URL: http://jira.codehaus.org/browse/MECLIPSE-285 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Reporter: Andres Almiray It would be great if the eclipse:eclipse target would detect other plugins that add src/tests dirs configuration automatically and add those dirs to the generate .classpath, for example the org.codehaus.mojo.groovy plugin which adds src/main/groovy and src/test/groovy -- 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-75) [PATCH] NPE if loaded settings.xml does not contain
[ http://jira.codehaus.org/browse/MANTTASKS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-75: --- Attachment: MANTTASKS-75.diff > [PATCH] NPE if loaded settings.xml does not contain > - > > Key: MANTTASKS-75 > URL: http://jira.codehaus.org/browse/MANTTASKS-75 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 > Environment: Ant 1.6.5 >Reporter: Herve Boutemy >Priority: Trivial > Fix For: 2.0.7 > > Attachments: MANTTASKS-75.diff > > > see > http://www.nabble.com/Re%3A-NullPointer-with-maven-ant-tasks-2.0.6-%28linux%29-p11220688s177.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] Updated: (MANTTASKS-75) [PATCH] NPE if loaded settings.xml does not contain
[ http://jira.codehaus.org/browse/MANTTASKS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-75: --- Attachment: (was: MANTTASKS-75.diff) > [PATCH] NPE if loaded settings.xml does not contain > - > > Key: MANTTASKS-75 > URL: http://jira.codehaus.org/browse/MANTTASKS-75 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 > Environment: Ant 1.6.5 >Reporter: Herve Boutemy >Priority: Trivial > Fix For: 2.0.7 > > Attachments: MANTTASKS-75.diff > > > see > http://www.nabble.com/Re%3A-NullPointer-with-maven-ant-tasks-2.0.6-%28linux%29-p11220688s177.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] Commented: (MECLIPSE-248) Eclipse plugin looks for pom version "test"
[ http://jira.codehaus.org/browse/MECLIPSE-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100361 ] Carlos Sanchez commented on MECLIPSE-248: - the only way to get it work so far is delete the org/apache/maven/plugins/maven-eclipse-plugin folder from the local repo and install the plugin locally if you install without removing the folder doesn't work if you remove the folder and let it get downloaded doesn't work > Eclipse plugin looks for pom version "test" > --- > > Key: MECLIPSE-248 > URL: http://jira.codehaus.org/browse/MECLIPSE-248 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.3, 2.4 > Environment: Linux (Ubuntu Edgy), Maven 2.0.5, JDK5update11, totally > empty local repository, no remote repositories other than central >Reporter: Max Bowsher >Priority: Blocker > Fix For: 2.4 > > Attachments: log.txt, > org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest_testModule1Project.build.log > > > A clean build of the maven-eclipse-plugin-2.3 tag fails, because of a test > failure: > Tests in error: > > testModule1Project(org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest) > (build log for this test is attached) > Presumably this is not the fault of the eclipse plugin code, since it must > have built at one time in order to be released, but I'm not sure where else > to report it. > The test failure poses a problem for people trying to make modified versions > of the plugin based on the last released 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: (MECLIPSE-165) Ability to exclude filtered resources from eclipse's source directories
[ http://jira.codehaus.org/browse/MECLIPSE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100364 ] Paul Spencer commented on MECLIPSE-165: --- I have mentioned this issue in a post on Maven's users mailing list. The post is titled "I use resource filtering with the Eclipse plugin but, need filtered directories excluded." Basically I am asking for the ability to exclude filtered resources from the eclipse classpath. Paul Spencer > Ability to exclude filtered resources from eclipse's source directories > --- > > Key: MECLIPSE-165 > URL: http://jira.codehaus.org/browse/MECLIPSE-165 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: PDE support >Affects Versions: 2.3 >Reporter: Cédric Vidal > Attachments: MECLIPSE-165.patch > > > Resources should be in the classpath from Eclipse's point of view because > they end up being in the classpath from Maven 2's point of view, but whenever > resources are marked as being filtered by M2, Eclipse puts them unfiltered in > the classpath thus introducing an inconsistency between Maven 2 and Eclipse. > Whether or not to include filtered resource directories in eclipse's sources > directories is therefore a real dilemna. While I'm sure a consistent solution > to this dilemna will eventually be found, it would be great to let the user > choose what to do in the meantime. > The attached patch adresses this issue by adding a parameter, > 'excludeFilteredResourcesFromSourceDirs', which when set to true prevents > filtered resource directories from being added to eclipse's source > directories. The parameter defaults to false to avoid changing current > projects' behavior. > Regards, > Cédric Vidal > http://www.B-Process.com > PS: This parameter could be overriden on a per resource directory basis as > mentionned in MECLIPSE-162. This is not adressed by the attached patch though -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-21) Need a way to include limited set of webapp's dependencies
[ http://jira.codehaus.org/browse/MWAR-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100365 ] Jason Melnick commented on MWAR-21: --- No, this isn't fixed. Although the war plug-in's documentation has examples of how to do this it doesn't work properly due to a problem with M2's resolution of optional dependencies: see http://jira.codehaus.org/browse/MNG-3067 I have a fix for it (the war plugin, not the dependency mechanism) of which I'll post the patch ASAP... The problem is that somehow optional dependencies are being resolved for optional dependencies arbitrarily. The fix involves removing ResolutionNodes at the parent-level w/ a depth > 1 from the ArtifactResolutionResult as well as removing artifacts that are optional. > Need a way to include limited set of webapp's dependencies > -- > > Key: MWAR-21 > URL: http://jira.codehaus.org/browse/MWAR-21 > Project: Maven 2.x War Plugin > Issue Type: Improvement > Environment: M2.0.1 >Reporter: Dirk Olmes >Assignee: John Tolentino >Priority: Blocker > Fix For: 2.0 > > Attachments: AbstractWarMojo.diff, MWAR-21-workaround.patch > > Time Spent: 6 hours > Remaining Estimate: 0 minutes > > I need a way to pack a war that includes only a limited set of the webapp's > dependencies. We're deploying in mainly two different environments: for > testing, the webapp runs standalone and thus needs to include all its > dependencies in the war. For production we deploy the webapp into a JBoss > server that has all the dependencies already installed. > I've modified AbstractWarMojo in the following way: 1) allow to specify > dependencyIncludes an dependencyExcludes (as lists) 2) upon building the war, > each dependency is checked against the excludes and the includes and will be > added to the war accordingly. > While this patch may not be the best way to to it, it clearly shows my > requirements. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-9) WAR plugin should support minimal WARs for inclusion within an EAR
[ http://jira.codehaus.org/browse/MWAR-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100366 ] Jason Melnick commented on MWAR-9: -- I have a fix for this and will supply a patch ASAP. See http://jira.codehaus.org/browse/MWAR-21 and http://jira.codehaus.org/browse/MNG-3067 > WAR plugin should support minimal WARs for inclusion within an EAR > -- > > Key: MWAR-9 > URL: http://jira.codehaus.org/browse/MWAR-9 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Reporter: Mike Perham >Assignee: Stephane Nicoll > > I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my > deps. This is fine for a default but maven should also support "skeleton" > WARs which will be packaged within an EAR. We have EARs which package 3-4 > WARs each and to have the deps duplicated within each WAR means we cannot > have shared data (since the classes are loaded within each WAR's classloader, > rather than by the parent EAR's classloader). It also means 80MB EARs! :-) > It seems like two things need to happen: > 1) Add a "skeleton" flag which prevents copying any dependencies to > WEB-INF/lib. > 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which > lists the relative locations of the dependencies within the parent EAR. > Fabrice has basically the same idea written down here. Starting with "- for > a War..." : > http://marc.theaimsgroup.com/?l=turbine-maven-user&m=112737860024530&w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1603) Upload JIDE Common Layer to maven repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100369 ] Wim Deblauwe commented on MAVENUPLOAD-1603: --- When I use the depency, I get the following warning by Maven: [WARNING] POM for 'com.jidesoft:jide-oss:pom:2.0.4:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM Maybe there is something wrong in the pom? > Upload JIDE Common Layer to maven repository > > > Key: MAVENUPLOAD-1603 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1603 > Project: maven-upload-requests > Issue Type: Task >Reporter: David Qiao >Assignee: Carlos Sanchez > > JIDE Common Layer is Swing component library built on top of Java/Swing. It > is also the foundation of other component products from JIDE. This project > has over 30 Swing components and over 100k lines of code. It greatly enhanced > the default component set provided by Swing and allow developers to focus on > business logic layer instead of making components. > JIDE Common Layer was originally developed by JIDE Software developers as a > foundation in order to build other more advanced components. In April of > 2007, JIDE Software decided to open source this common layer so that more and > more developers can leverage them instead of wasting time building them > again. > For more information, please visit project home page on JIDE Software website > at http://www.jidesoft.com/products/oss.htm or on java.net at > https://jide-oss.dev.java.net. -- 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-1609) Synchronize opensymphony:xwork:jar:2.0.3 to central repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100370 ] Carlos Sanchez commented on MAVENUPLOAD-1609: - I'd keep using the old group until the next major release and then switch but you need to remove those snapshots > Synchronize opensymphony:xwork:jar:2.0.3 to central repo > > > Key: MAVENUPLOAD-1609 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1609 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Olivier Lamy > > Hi, > The artifact opensymphony:xwork:jar:2.0.3 is in the opensymphony repository > http://maven2.opensymphony.com/opensymphony/xwork/2.0.3/ . > Is it possible to have in http://repo1.maven.org/maven2/opensymphony/xwork/ ? > Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1608) FontBox/JempBox/PDFBox updates
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100371 ] Carlos Sanchez commented on MAVENUPLOAD-1608: - http://maven.apache.org/guides/mini/guide-central-repository-upload.html > FontBox/JempBox/PDFBox updates > -- > > Key: MAVENUPLOAD-1608 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1608 > Project: maven-upload-requests > Issue Type: Task >Reporter: Ben Litchfield > > Please let me know if this is right, this is the first time I have submitted > a request for a maven bundle. > Additional bundles > http://www.pdfbox.org/dist/FontBox-0.1.0-maven.jar > http://www.pdfbox.org/dist/JempBox-0.2.0-maven.jar > Other Project URLs > http://www.jempbox.org/ > http://www.fontbox.org/ > PDFBox SF Project site http://sourceforge.net/projects/pdfbox shows > benlitchfield as project admin > Thanks, > Ben -- 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-1603) Upload JIDE Common Layer to maven repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100374 ] Carlos Sanchez commented on MAVENUPLOAD-1603: - sounds like that, mvn -e or -X will give you the reason > Upload JIDE Common Layer to maven repository > > > Key: MAVENUPLOAD-1603 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1603 > Project: maven-upload-requests > Issue Type: Task >Reporter: David Qiao >Assignee: Carlos Sanchez > > JIDE Common Layer is Swing component library built on top of Java/Swing. It > is also the foundation of other component products from JIDE. This project > has over 30 Swing components and over 100k lines of code. It greatly enhanced > the default component set provided by Swing and allow developers to focus on > business logic layer instead of making components. > JIDE Common Layer was originally developed by JIDE Software developers as a > foundation in order to build other more advanced components. In April of > 2007, JIDE Software decided to open source this common layer so that more and > more developers can leverage them instead of wasting time building them > again. > For more information, please visit project home page on JIDE Software website > at http://www.jidesoft.com/products/oss.htm or on java.net at > https://jide-oss.dev.java.net. -- 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-1603) Upload JIDE Common Layer to maven repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100375 ] Wim Deblauwe commented on MAVENUPLOAD-1603: --- Does not seem to print anything extra: [EMAIL PROTECTED]:~/projects/jidetest$ mvn -e idea:idea + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'idea'. [INFO] [INFO] Building Test on JIDE [INFO]task-segment: [idea:idea] [INFO] [INFO] Preparing idea:idea [INFO] No goals needed for project - skipping [INFO] [idea:idea] [WARNING] POM for 'com.jidesoft:jide-oss:pom:2.0.4:compile' is invalid. It will be ignored for artifact resolution. Reason: Failed to validate POM [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Fri Jun 22 21:51:43 CEST 2007 [INFO] Final Memory: 6M/14M [INFO] [EMAIL PROTECTED]:~/projects/jidetest$ > Upload JIDE Common Layer to maven repository > > > Key: MAVENUPLOAD-1603 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1603 > Project: maven-upload-requests > Issue Type: Task >Reporter: David Qiao >Assignee: Carlos Sanchez > > JIDE Common Layer is Swing component library built on top of Java/Swing. It > is also the foundation of other component products from JIDE. This project > has over 30 Swing components and over 100k lines of code. It greatly enhanced > the default component set provided by Swing and allow developers to focus on > business logic layer instead of making components. > JIDE Common Layer was originally developed by JIDE Software developers as a > foundation in order to build other more advanced components. In April of > 2007, JIDE Software decided to open source this common layer so that more and > more developers can leverage them instead of wasting time building them > again. > For more information, please visit project home page on JIDE Software website > at http://www.jidesoft.com/products/oss.htm or on java.net at > https://jide-oss.dev.java.net. -- 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-530) Broken checksum for org/apache/maven/maven/2.0.6/maven-2.0.6.pom
[ http://jira.codehaus.org/browse/MEV-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100376 ] Carlos Sanchez commented on MEV-530: the PGP signature is also bad $ gpg --verify maven-2.0.6.pom.asc gpg: Signature made 03/26/07 19:05:00 using DSA key ID BB617866 gpg: BAD signature from "Sarel Jason van Zyl <[EMAIL PROTECTED]>" the pom is the same at repo1 and apache > Broken checksum for org/apache/maven/maven/2.0.6/maven-2.0.6.pom > > > Key: MEV-530 > URL: http://jira.codehaus.org/browse/MEV-530 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Max Bowsher > > org/apache/maven/maven/2.0.6/maven-2.0.6.pom has bad md5 and sha1 -- 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-1603) Upload JIDE Common Layer to maven repository
[
http://jira.codehaus.org/browse/MAVENUPLOAD-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100377
]
Carlos Sanchez commented on MAVENUPLOAD-1603:
-
it does for me
Validation Errors:
[DEBUG] For dependency Dependency {groupId=aqua, artifactId=aqua, version=5.0,
type=jar}: system-scoped dependency must specify an absolute path systemPath.
[DEBUG]
it' s fixed now
> Upload JIDE Common Layer to maven repository
>
>
> Key: MAVENUPLOAD-1603
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1603
> Project: maven-upload-requests
> Issue Type: Task
>Reporter: David Qiao
>Assignee: Carlos Sanchez
>
> JIDE Common Layer is Swing component library built on top of Java/Swing. It
> is also the foundation of other component products from JIDE. This project
> has over 30 Swing components and over 100k lines of code. It greatly enhanced
> the default component set provided by Swing and allow developers to focus on
> business logic layer instead of making components.
> JIDE Common Layer was originally developed by JIDE Software developers as a
> foundation in order to build other more advanced components. In April of
> 2007, JIDE Software decided to open source this common layer so that more and
> more developers can leverage them instead of wasting time building them
> again.
> For more information, please visit project home page on JIDE Software website
> at http://www.jidesoft.com/products/oss.htm or on java.net at
> https://jide-oss.dev.java.net.
--
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-52) Ability to add jboss dataosources (*ds.xml) files as a jarModule
[
http://jira.codehaus.org/browse/MEAR-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100378
]
Stephane Nicoll commented on MEAR-52:
-
According to Adrian Brock, the supported solution is as follows:
{quote}
So for future compatibility, the correct mechanism for non-spec
deployments is to add a META-INF/jboss-app.xml
mydatasource-ds.xml
{quote}
> Ability to add jboss dataosources (*ds.xml) files as a jarModule
>
>
> Key: MEAR-52
> URL: http://jira.codehaus.org/browse/MEAR-52
> Project: Maven 2.x Ear Plugin
> Issue Type: Wish
>Reporter: Cesar Izurieta
>Assignee: Stephane Nicoll
>
> It would be nice to be able to add a jarModule as:
>
>
> mysql-ds.xml
> true
>
>
> So the resulting application.xml looks like:
>
> ...
>
> mysql-ds.xml
>
>
> This would help to deploy jboss datasources with the ear.
--
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-121) Custom manifest attributres are ignored.
[
http://jira.codehaus.org/browse/MASSEMBLY-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-121:
-
Description:
Configure custom manifest entry in pom.xml
maven-assembly-plugin
2.1
false
package
attached
${basedir}/src/main/assembly/install.xml
${project.build.directory}
${project.build.directory}/assembly/work
com.company.Install
development
Custom manifest entry "mode" does not appear in jar manifest (although main
class entry does).
was:
Configure custom manifest entry in pom.xml
maven-assembly-plugin
2.1
false
package
attached
${basedir}/src/main/assembly/install.xml
${project.build.directory}
${project.build.directory}/assembly/work
com.company.Install
development
Custom manifest entry "mode" does not appear in jar manifest (although main
class entry does).
brian: What's the test you added? Is it an IT, or a unit test, or...? I'll
check this out, in addition to looking at the new patch.
> Custom manifest attributres are ignored.
>
>
> Key: MASSEMBLY-121
> URL: http://jira.codehaus.org/browse/MASSEMBLY-121
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP SP2
> Java JDK 1.5.0_07
> Maven 2.0.4
>Reporter: Mark Reynolds
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
> Attachments: assembly-plugin.patch, massembly121.zip
>
>
> Configure custom manifest entry in pom.xml
>
> maven-assembly-plugin
> 2.1
> false
>
>
> package
>
> attached
>
>
>
> ${basedir}/src/main/assembly/install.xml
>
> ${project.build.directory}
> ${project.build.directory}/assembly/work
>
>
> com.company.Install
>
>
> development
>
>
>
>
>
>
> Custom manifest entry "mode" does not appear in jar manifest (although main
> class entry does).
--
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-254) tests failed on windows
[ http://jira.codehaus.org/browse/MRELEASE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MRELEASE-254: -- Attachment: output.txt Lucky guy :-) Here my output. (really can't understand :-( ) > tests failed on windows > --- > > Key: MRELEASE-254 > URL: http://jira.codehaus.org/browse/MRELEASE-254 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: windows + cygwin >Reporter: Olivier Lamy > Attachments: build.log, MRELEASE-254, > org.apache.maven.shared.release.phase.RewritePomsForDevelopmentPhaseTest.txt, > output.txt > > > Tests failed on windows due to Comparing files with String equals method. > This patch compares xml content with using xmlunit. -- 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-256) ArrayIndexOutOfBoundsException using custom tagBase.
ArrayIndexOutOfBoundsException using custom tagBase. Key: MRELEASE-256 URL: http://jira.codehaus.org/browse/MRELEASE-256 Project: Maven 2.x Release Plugin Issue Type: Bug Environment: Ubuntu 7.04 Java 1.6.0_02-ea Maven 2.0.6 Reporter: Mark Soderquist My project SVN connection is: http://svn.novaworx.org/software/utility/trunk I would like to put the release tag at http://svn.novaworx.org/software/utility/1.0. I specified the following on the command line: mvn release:prepare -DdryRun=true -DtagBase="http://svn.novaworx.org/software/utility"; What is the release version for "Novaworx Utility Library"? (org.novaworx:utility) 1.0: : [Enter] What is SCM release tag or label for "Novaworx Utility Library"? (org.novaworx:utility) utility-1.0: : 1.0[Enter] What is the new development version for "Novaworx Utility Library"? (org.novaworx:utility) 1.1-SNAPSHOT: : [Enter] and received the following exception: java.lang.ArrayIndexOutOfBoundsException: 48 at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateUrlPath(RewritePomsForReleasePhase.java:249) at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateScm(RewritePomsForReleasePhase.java:124) at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.transformScm(RewritePomsForReleasePhase.java:61) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:271) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:180) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:116) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.simulate(AbstractRewritePomsPhase.java:691) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:190) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 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:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) 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:597) 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) -- 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-121) Custom manifest attributres are ignored.
[
http://jira.codehaus.org/browse/MASSEMBLY-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MASSEMBLY-121.
Resolution: Fixed
Applied. Thanks!
> Custom manifest attributres are ignored.
>
>
> Key: MASSEMBLY-121
> URL: http://jira.codehaus.org/browse/MASSEMBLY-121
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP SP2
> Java JDK 1.5.0_07
> Maven 2.0.4
>Reporter: Mark Reynolds
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
> Attachments: assembly-plugin.patch, massembly121.zip
>
>
> Configure custom manifest entry in pom.xml
>
> maven-assembly-plugin
> 2.1
> false
>
>
> package
>
> attached
>
>
>
> ${basedir}/src/main/assembly/install.xml
>
> ${project.build.directory}
> ${project.build.directory}/assembly/work
>
>
> com.company.Install
>
>
> development
>
>
>
>
>
>
> Custom manifest entry "mode" does not appear in jar manifest (although main
> class entry does).
--
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: (MRM-419) WebDAV functionality not working for Internet Explorer / Windows Network Places
[ http://jira.codehaus.org/browse/MRM-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Didion reopened MRM-419: - This bug is only fixed for IE. I am still unable to create a Windows Network Place for the repository. Repro step/error message same as above. > WebDAV functionality not working for Internet Explorer / Windows Network > Places > --- > > Key: MRM-419 > URL: http://jira.codehaus.org/browse/MRM-419 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0-alpha-2 >Reporter: John Didion >Assignee: Joakim Erdfelt > Fix For: 1.0-alpha-2 > > > I am using archiva built from source (r548493). I set up a managed repository > and several proxied repositories. > Browsing the WebDAV url from Firefox works just fine, but it appears the IE > doesn't recognize the url - it asks me if I want to "save this file", and its > type is unknown. > When I try to set up a Network Place using the url, it shows me the top level > of the repository, but if I try to browse to any folder, I get the error: > "Documents in this folder are not available. The folder may have been moved > or deleted, or network problems may be preventing a connection to the server. > There is a problem with the web server. Please try again later or contact the > server administrator." > I notice that the url it's trying to browse to is incorrect. The root URL of > the repository is: > http://[host]/archiva/repository/internal/ > but when I double-click on, say, commons-collections, it tries to browse to: > http://repository.muze.com/archiva/repository/commons-collections -- 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-3068) Build extensions fail to load if no available locally and remote repo is defined in the POM where the extension is defined
Build extensions fail to load if no available locally and remote repo is defined in the POM where the extension is defined -- Key: MNG-3068 URL: http://jira.codehaus.org/browse/MNG-3068 Project: Maven 2 Issue Type: Bug Components: General Affects Versions: 2.1 Reporter: Vincent Massol * If you define the remote repo in settings.xml it works * If you define it in the pom.xml file it doesn't 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-3068) Build extensions fail to load if no available locally and remote repo is defined in the POM where the extension is defined
[
http://jira.codehaus.org/browse/MNG-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Massol updated MNG-3068:
Description:
* If you define the remote repo in settings.xml it works
* If you define it in the pom.xml file it doesn't work
For example, this fails if xwiki-build-xar-handlers isn't available in the
local repo:
{noformat}
com.xpn.xwiki.platform
xwiki-build-xar-handlers
1.0-SNAPSHOT
xwiki
XWiki Maven2 Remote Repository
http://maven.xwiki.org
true
true
{noformat}
was:
* If you define the remote repo in settings.xml it works
* If you define it in the pom.xml file it doesn't work
> Build extensions fail to load if no available locally and remote repo is
> defined in the POM where the extension is defined
> --
>
> Key: MNG-3068
> URL: http://jira.codehaus.org/browse/MNG-3068
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.1
>Reporter: Vincent Massol
>
> * If you define the remote repo in settings.xml it works
> * If you define it in the pom.xml file it doesn't work
> For example, this fails if xwiki-build-xar-handlers isn't available in the
> local repo:
> {noformat}
>
>
>
> com.xpn.xwiki.platform
> xwiki-build-xar-handlers
> 1.0-SNAPSHOT
>
>
>
>
>
> xwiki
> XWiki Maven2 Remote Repository
> http://maven.xwiki.org
>
> true
>
>
> true
>
>
>
>
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3068) Build extensions fail to load if not available locally and remote repo is defined in the same POM where the extension is defined
[
http://jira.codehaus.org/browse/MNG-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Massol updated MNG-3068:
Summary: Build extensions fail to load if not available locally and remote
repo is defined in the same POM where the extension is defined (was: Build
extensions fail to load if no available locally and remote repo is defined in
the POM where the extension is defined)
> Build extensions fail to load if not available locally and remote repo is
> defined in the same POM where the extension is defined
>
>
> Key: MNG-3068
> URL: http://jira.codehaus.org/browse/MNG-3068
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.1
>Reporter: Vincent Massol
>
> * If you define the remote repo in settings.xml it works
> * If you define it in the pom.xml file it doesn't work
> For example, this fails if xwiki-build-xar-handlers isn't available in the
> local repo:
> {noformat}
>
>
>
> com.xpn.xwiki.platform
> xwiki-build-xar-handlers
> 1.0-SNAPSHOT
>
>
>
>
>
> xwiki
> XWiki Maven2 Remote Repository
> http://maven.xwiki.org
>
> true
>
>
> true
>
>
>
>
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3068) Build extensions fail to load if not available locally and remote repo is defined in the same POM where the extension is defined
[
http://jira.codehaus.org/browse/MNG-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-3068:
Assignee: John Casey
Description:
* If you define the remote repo in settings.xml it works
* If you define it in the pom.xml file it doesn't work
For example, this fails if xwiki-build-xar-handlers isn't available in the
local repo:
{noformat}
com.xpn.xwiki.platform
xwiki-build-xar-handlers
1.0-SNAPSHOT
xwiki
XWiki Maven2 Remote Repository
http://maven.xwiki.org
true
true
{noformat}
was:
* If you define the remote repo in settings.xml it works
* If you define it in the pom.xml file it doesn't work
For example, this fails if xwiki-build-xar-handlers isn't available in the
local repo:
{noformat}
com.xpn.xwiki.platform
xwiki-build-xar-handlers
1.0-SNAPSHOT
xwiki
XWiki Maven2 Remote Repository
http://maven.xwiki.org
true
true
{noformat}
I think I have this fixed in revId 549968, but without a test case I cannot be
sure. The change I made was to accumulate remote repository definitions,
starting with those passed in from settings and other initial locations, and
proceeding down the parent-child POM hierarchy as each model is scanned for
extensions. I'll take another look to be sure those remote repositories are
actually being used, right now.
> Build extensions fail to load if not available locally and remote repo is
> defined in the same POM where the extension is defined
>
>
> Key: MNG-3068
> URL: http://jira.codehaus.org/browse/MNG-3068
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.1
>Reporter: Vincent Massol
>Assignee: John Casey
>
> * If you define the remote repo in settings.xml it works
> * If you define it in the pom.xml file it doesn't work
> For example, this fails if xwiki-build-xar-handlers isn't available in the
> local repo:
> {noformat}
>
>
>
> com.xpn.xwiki.platform
> xwiki-build-xar-handlers
> 1.0-SNAPSHOT
>
>
>
>
>
> xwiki
> XWiki Maven2 Remote Repository
> http://maven.xwiki.org
>
> true
>
>
> true
>
>
>
>
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1916) Making it possible for plug-in to add modules to the reactor programatically
[
http://jira.codehaus.org/browse/MNG-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100390
]
Kenney Westerhof commented on MNG-1916:
---
Are you talking about just adding modules (maven 2 projects) to the reactor, or
are you talking about maven2 plugins?
For now I'll assume that 'plug-ins included in the reactor' means 'modules
included in the reactor'.
So, what's the problem with adding module sections for your modules manually?
Can't profile's be used, activating on the existence of a file, and adding a
module there? You'd have to specify 1 profile per module though.
solution 3: write a replacement component for the core and put it in
$M2_HOME/extensions, that'll do a workspace scan for your files and add the
modules
to the proper pom, or just add them to the reactor.
solution 4: write a plugin, and create a pom that uses that plugin. The plugin
will fork a new maven build with whatever set of projects you like.
Take a look at the maven-it-plugin in the sandbox, it basically does the same
thing: it runs src/it/*/pom.xml.
I think having */ will cause too much problems. Right now,
m2 will quit if you specify a module dir that doesn't have a pom.xml,
so that behaviour must change. Further, i think you only want to add
directories as modules that contain a certain file. That would require an
extensive
change to the pom. Even extensions won't work here, since you cannot alter the
reactor once it's running.
> Making it possible for plug-in to add modules to the reactor programatically
>
>
> Key: MNG-1916
> URL: http://jira.codehaus.org/browse/MNG-1916
> Project: Maven 2
> Issue Type: Improvement
> Components: Plugin API, Reactor and workspace
>Reporter: Nils Fredrik Gjerull
> Fix For: 2.1.x
>
>
> I would like to be able to specify a number of directories as plug-in
> directories, automatically discover every plug-in in those directories and
> include them in the reactor. As I understands it the reactor with it's
> modules ({{org.apache.maven.execution.ReactorManager}}) is created in
> {{org.apache.maven.DefaultMaven}}. If I understands this correctly maven
> plug-ins can't add projects to the reactor programatically.
> My proposition to solve this is to add a phase which will be executed after
> the pom.xml is parsed, but before the information stored in
> Model/MavenProject is used, and most importantly before the {{ReactorManager
> is created}}. Then you can add information to the MavenProject
> programatically, increasing the flexibility for plug-ins.
> I am not fluent in the maven2 code base, but it seems to me that this require
> quite a lot of changes to the code. As I understands it the life cycle starts
> after the {{ReactorManager}} is made, and therefore after the information in
> Model have started to be used.
--
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-197) 2.2-beta-1 regression, project artifact no longer included in
[ http://jira.codehaus.org/browse/MASSEMBLY-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-197: - Assignee: John Casey Description: In 2.1, included the project artifact itself - i.e., all the jars actually needed to execute the project. In 2.2-beta-1, is omitting the project artifact, so that assemblies that functioned correctly when built with 2.1, fail to execute when built with 2.2-beta-1. was: In 2.1, included the project artifact itself - i.e., all the jars actually needed to execute the project. In 2.2-beta-1, is omitting the project artifact, so that assemblies that functioned correctly when built with 2.1, fail to execute when built with 2.2-beta-1. Summary: 2.2-beta-1 regression, project artifact no longer included in (was: 2.2-beta-1 regression, project artifact no longer included in ) > 2.2-beta-1 regression, project artifact no longer included in > - > > Key: MASSEMBLY-197 > URL: http://jira.codehaus.org/browse/MASSEMBLY-197 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Max Bowsher >Assignee: John Casey >Priority: Blocker > Fix For: 2.2-beta-2 > > > In 2.1, included the project artifact itself - i.e., all the > jars actually needed to execute the project. > In 2.2-beta-1, is omitting the project artifact, so that > assemblies that functioned correctly when built with 2.1, fail to execute > when built with 2.2-beta-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] Closed: (MASSEMBLY-197) 2.2-beta-1 regression, project artifact no longer included in
[ http://jira.codehaus.org/browse/MASSEMBLY-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-197. Resolution: Fixed I've added two new flags to the dependencySet: useProjectArtifact and useProjectAttachments. By default, they are true and false, respectively. Enabling these flags makes them subject to filtering on includes/excludes, with the default action to include them (again, only when they are enabled...). I'm running a deploy build with integration tests, then I'll commit these changes. Shouldn't take longer than 10 mins. > 2.2-beta-1 regression, project artifact no longer included in > - > > Key: MASSEMBLY-197 > URL: http://jira.codehaus.org/browse/MASSEMBLY-197 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Max Bowsher >Assignee: John Casey >Priority: Blocker > Fix For: 2.2-beta-2 > > > In 2.1, included the project artifact itself - i.e., all the > jars actually needed to execute the project. > In 2.2-beta-1, is omitting the project artifact, so that > assemblies that functioned correctly when built with 2.1, fail to execute > when built with 2.2-beta-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] Closed: (MRM-423) Source distribution is missing license and notice files
[ http://jira.codehaus.org/browse/MRM-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MRM-423. --- Assignee: Wendy Smoak Resolution: Fixed Fix Version/s: 1.0-alpha-2 Fixed in r549981 > Source distribution is missing license and notice files > --- > > Key: MRM-423 > URL: http://jira.codehaus.org/browse/MRM-423 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Wendy Smoak >Assignee: Wendy Smoak > Fix For: 1.0-alpha-2 > > > The Archiva source distribution is missing license and notice files. They > must be included. -- 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-424) Distributions should have apache in the name and unpack to versioned directories
[ http://jira.codehaus.org/browse/MRM-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MRM-424: Summary: Distributions should have apache in the name and unpack to versioned directories (was: Source distribution should have version in the name and unpack to versioned -src directory) > Distributions should have apache in the name and unpack to versioned > directories > > > Key: MRM-424 > URL: http://jira.codehaus.org/browse/MRM-424 > Project: Archiva > Issue Type: Improvement >Affects Versions: 1.0-alpha-2 >Reporter: Wendy Smoak > > The source distribution should be named archiva-1.0-alpha-2-src.zip and > unpack to archiva-1.0-alpha-2-src. > Based on other discussions both the binary and source distributions should be > renamed (and unpack to) apache-archiva-*. -- 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-424) Distributions should have apache in the name and unpack to versioned directories
[ http://jira.codehaus.org/browse/MRM-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MRM-424: Assignee: Wendy Smoak > Distributions should have apache in the name and unpack to versioned > directories > > > Key: MRM-424 > URL: http://jira.codehaus.org/browse/MRM-424 > Project: Archiva > Issue Type: Improvement >Affects Versions: 1.0-alpha-2 >Reporter: Wendy Smoak >Assignee: Wendy Smoak > Fix For: 1.0-alpha-2 > > > The source distribution should be named archiva-1.0-alpha-2-src.zip and > unpack to archiva-1.0-alpha-2-src. > Based on other discussions both the binary and source distributions should be > renamed (and unpack to) apache-archiva-*. -- 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-424) Distributions should have apache in the name and unpack to versioned directories
[ http://jira.codehaus.org/browse/MRM-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MRM-424. --- Resolution: Fixed Fix Version/s: 1.0-alpha-2 Changed to apache-archiva-$version for the filename, but was unable to get -src into the directory name inside the source distro. > Distributions should have apache in the name and unpack to versioned > directories > > > Key: MRM-424 > URL: http://jira.codehaus.org/browse/MRM-424 > Project: Archiva > Issue Type: Improvement >Affects Versions: 1.0-alpha-2 >Reporter: Wendy Smoak > Fix For: 1.0-alpha-2 > > > The source distribution should be named archiva-1.0-alpha-2-src.zip and > unpack to archiva-1.0-alpha-2-src. > Based on other discussions both the binary and source distributions should be > renamed (and unpack to) apache-archiva-*. -- 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-179) Assembled jar includes artifact names in path
[
http://jira.codehaus.org/browse/MASSEMBLY-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-179:
-
Assignee: John Casey
> Assembled jar includes artifact names in path
> -
>
> Key: MASSEMBLY-179
> URL: http://jira.codehaus.org/browse/MASSEMBLY-179
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Jonathan Komorek
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.2-beta-2
>
>
> This issue does not occur in 2.1 and began occurring in 2.2-SNAPSHOT
> (roughly) a couple months ago.
> After assembling a jar, the path for each of the included files begins with
> what seems to be ${artifactId}-${version}.${packaging}
> This includes files from dependent jars and files from sub-modules - all
> files.
> The plugin is configured in the POM as follows:
>
>
>
> maven-assembly-plugin
>
>
> 1
> package
>
> attached
>
>
>
> 2.2-SNAPSHOT
>
> assembly.xml
>
>
>
>
> The entire assembly.xml is as follows:
>
> dependencies
>
> jar
>
> false
>
>
> /
> true
> runtime
>
>
>
--
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-194) unnecessary dependency expansion regression
[ http://jira.codehaus.org/browse/MASSEMBLY-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-194: - stephane, do you happen to have a test project that displays this behavior, so we can get it fixed? I'm not 100% certain I understand the issue here. In the meantime, I'll go back through the history on this issue and see what I can make of it... > unnecessary dependency expansion regression > --- > > Key: MASSEMBLY-194 > URL: http://jira.codehaus.org/browse/MASSEMBLY-194 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Brett Porter >Assignee: John Casey >Priority: Blocker > Fix For: 2.2-beta-2 > > Attachments: assembly-test.tar.gz > > > See the attached test project. It requires that you've run mvn clean install > for continuum previously so there is a sizable dependency in the repo to play > with. > If you build with assembly 2.1, only the tarball is expanded and included in > the final distribution (about 27mb) > With 2.2-beta-1, all the transitive dependencies are also expanded and > included (about 65mb). > This is a functionality change, but also consumes a very large amount of > memory and CPU. -- 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-422) Wrong directory name for snapshots repo in default config
[
http://jira.codehaus.org/browse/MRM-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak closed MRM-422.
---
Assignee: Wendy Smoak
Resolution: Fixed
Fix Version/s: 1.0-alpha-2
fixed in r550007
> Wrong directory name for snapshots repo in default config
> -
>
> Key: MRM-422
> URL: http://jira.codehaus.org/browse/MRM-422
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-alpha-2
>Reporter: Wendy Smoak
>Assignee: Wendy Smoak
>Priority: Minor
> Fix For: 1.0-alpha-2
>
>
> The default configuration includes two repositories: 'internal' and
> 'snapshots'.
> Both are configured to use a single directory named 'internal.'
> Archiva Managed Snapshot Repository
> Identifiersnapshots
> Name Archiva Managed Snapshot Repository
> --> Directory/C:/${appserver.home}/repositories/internal/
> <-
> WebDAV URLhttp://localhost:8080/archiva/repository/snapshots/
> Type Maven 2.x Repository
> Instead, the snapshots repo should use a directory called 'snapshots'.
--
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-421) Default configuration does not proxy the central repo - Failed pre-download policies
[
http://jira.codehaus.org/browse/MRM-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak closed MRM-421.
---
Assignee: Wendy Smoak
Resolution: Fixed
Fix Version/s: 1.0-alpha-2
fixed in r550008
> Default configuration does not proxy the central repo - Failed pre-download
> policies
>
>
> Key: MRM-421
> URL: http://jira.codehaus.org/browse/MRM-421
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0-alpha-2
>Reporter: Wendy Smoak
>Assignee: Wendy Smoak
> Fix For: 1.0-alpha-2
>
>
> Testing the fix for MRM-370...
> rm -rf $M2_REPO/org/apache/maven/plugins/maven-clean-plugin
> cd /path/to/project
> mvn clean
> I get the usual ...could not be found or no valid version... message. In the
> Archiva logs:
> jvm 1| 2007-06-22 06:25:29,796 [SocketListener0-1] INFO
> org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Failed
> pre-download policies
> -C:\${appserver.home}\repositories\internal\org\apache\maven\plugins\maven-clean-plugin\maven-metadata.xml
> There are no whitelist patterns for the internal -> central proxy connector.
> We should ship with configuration that actually makes it proxy. Adding a
> whitelist pattern of "*" seems to work.
> Should an absence of whitelist patterns mean 'proxy everything'?
--
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
