[jira] Created: (MRM-312) ConcurrentModificationException
ConcurrentModificationException --- Key: MRM-312 URL: http://jira.codehaus.org/browse/MRM-312 Project: Archiva Issue Type: Bug Components: WebDAV interface Affects Versions: 1.0 Environment: tomcat 5.5 windows 2000 jdk SUN 1.5 archiva SNAPSHOT Reporter: nicolas de loof Archiva is deployed as maven repository proxy for my company I get ConcurrentModificationExceptions in logs, that looks from maven-side as HTTP 500. This is related to WAGON-79. Solving this issue requires to upgrade dependency to Wagon-2.0-SNAPSHOT. The 2.0 branch introduces some new methods on Wagon interface that requires some simple changes in archiva code, like adding delegates methods in org.apache.maven.archiva.proxy.WagonDelegate -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-312) ConcurrentModificationException
[ http://jira.codehaus.org/browse/MRM-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92130 ] nicolas de loof commented on MRM-312: - Also upgrading to 2.0 makes some testcase fail due to the connect() method beeing deprecated and throwing "IllegalStateException: Cannot open a connection to a null wagon repository." > ConcurrentModificationException > --- > > Key: MRM-312 > URL: http://jira.codehaus.org/browse/MRM-312 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0 > Environment: tomcat 5.5 windows 2000 jdk SUN 1.5 archiva SNAPSHOT >Reporter: nicolas de loof > > Archiva is deployed as maven repository proxy for my company > I get ConcurrentModificationExceptions in logs, that looks from maven-side as > HTTP 500. > This is related to WAGON-79. > Solving this issue requires to upgrade dependency to Wagon-2.0-SNAPSHOT. The > 2.0 branch introduces some new methods on Wagon interface that requires some > simple changes in archiva code, like adding delegates methods in > org.apache.maven.archiva.proxy.WagonDelegate -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (WAGON-81) connect( x , y ) deprecation cause IllegalStateExceptions
connect( x , y ) deprecation cause IllegalStateExceptions - Key: WAGON-81 URL: http://jira.codehaus.org/browse/WAGON-81 Project: wagon Issue Type: Improvement Components: wagon-provider-api Affects Versions: 1.0 Reporter: nicolas de loof Priority: Trivial Attachments: abstractWagon.patch Wagon-provider-api 2.0 SNAPSHOT deprecates the connect methods with arguments (repository, proxyInfo...) Deprecation breaks existing code, as the parameters are not used to set the internal repository/proxyInfo/authenticationInfo and connect() throws an IllegalStateException Having those deprecated connect( x ) call the required setters solves the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-292) Replace DEFAULT_CLIENTSPEC_PROPERTY system property by a map to store in memory clientspec names
[
http://jira.codehaus.org/browse/SCM-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92132
]
Emmanuel Venisse commented on SCM-292:
--
Possible solution without modification in continuum:
instead of system property, we can store the clientspec in
${user.home}/.scm/perforce.xml (other providers use a xml file to configure the
provider too)
In this file we store a mapping between the scmurl and the clientspec
{noformat}
scm:perforce:[EMAIL
PROTECTED]:port:path_to_repository1
username-host-MavenSCM-path-to-repo1
scm:perforce:[EMAIL
PROTECTED]:port:path_to_repository2
username-host-MavenSCM-path-to-repo2
{noformat}
and in PerforceScmProvider.getClientspecName(...) we return the clientSpecName
from the xml file. If if doesn't exist, we generate a default name and we store
it in the xml file.
WDYT?
> Replace DEFAULT_CLIENTSPEC_PROPERTY system property by a map to store in
> memory clientspec names
>
>
> Key: SCM-292
> URL: http://jira.codehaus.org/browse/SCM-292
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-perforce
>Affects Versions: 1.0-beta-4
>Reporter: Emmanuel Venisse
> Assigned To: Patrick Schneider
>Priority: Critical
> Fix For: 1.0
>
>
> With a Map instead of a system property, we'll can support more that one
> clientspec in the jvm. It's necessary for Continuum because it access to more
> than one project in Perforce.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2917) Ant classpath issue in maven 2.0.6
[ http://jira.codehaus.org/browse/MNG-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92135 ] Yuri Schimke commented on MNG-2917: --- This seems like the most appropriate solution http://www.nabble.com/Re%3A-maven-2.0.6-and-xdoclet-maven-plugin-p9839377s177.html xdoclet-maven-plugin org.codehaus.mojo xdoclet generate-resources xdoclet ant ant 1.6.5 > Ant classpath issue in maven 2.0.6 > -- > > Key: MNG-2917 > URL: http://jira.codehaus.org/browse/MNG-2917 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Yuri Schimke >Priority: Critical > > This was working in 2.0.5. Unfortunately I'm guessing its related to the > woefully bad xdoclet-maven-plugin > The main error is that the xdoclet-maven-plugin can't find one of the ant > classes > Caused by: java.lang.NoClassDefFoundError: org/apache/tools/ant/PropertyHelper > - > this realm = app0.child-container[org.codehaus.mojo:xdoclet-maven-plugin] > urls[0] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/org/codehaus/mojo/xdoclet-maven-plugin/1.0-alpha-2/xdoclet-maven-plugin-1.0-alpha-2.jar > urls[1] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-wsee-module/1.2.3/xdoclet-wsee-module-1.2.3.jar > urls[2] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar > urls[3] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-jboss-module/1.2.3/xdoclet-jboss-module-1.2.3.jar > urls[4] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-xdoclet-module/1.2.3/xdoclet-xdoclet-module-1.2.3.jar > urls[5] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-orion-module/1.2.3/xdoclet-orion-module-1.2.3.jar > urls[6] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-jmx-module/1.2.3/xdoclet-jmx-module-1.2.3.jar > urls[7] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-ibm-module/1.2.3/xdoclet-ibm-module-1.2.3.jar > urls[8] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar > urls[9] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/commons-collections/commons-collections/2.1/commons-collections-2.1.jar > urls[10] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/ant/ant/1.5.2/ant-1.5.2.jar > urls[11] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-apache-module/1.2.3/xdoclet-apache-module-1.2.3.jar > urls[12] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/ant/ant-launcher/1.6.5/ant-l > auncher-1.6.5.jar > urls[13] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-fr_FR-locale/1.2.3/xdoclet-fr_FR-locale-1.2.3.jar > urls[14] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-objectweb-module/1.2.3/xdoclet-objectweb-module-1.2.3.jar > urls[15] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/org/apache/maven/plugins/maven-antrun-plugin/1.0/maven-antrun-plugin-1.0.jar > urls[16] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-java-module/1.2.3/xdoclet-java-module-1.2.3.jar > urls[17] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-exolab-module/1.2.3/xdoclet-exolab-module-1.2.3.jar > urls[18] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-bea-module/1.2.3/xdoclet-bea-module-1.2.3.jar > urls[19] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-mvcsoft-module/1.2.3/xdoclet-mvcsoft-module-1.2.3.jar > urls[20] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-sun-module/1.2.3/xdoclet-sun-module-1.2.3.jar > urls[21] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-spring-module/1.2.3/xdoclet-spring-module-1.2.3.jar > urls[22] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-de-locale/1.2.3/xdoclet-de-locale-1.2.3.jar > urls[23] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/jboss/jboss-j2ee/3.2.1/jboss-j2ee-3.2.1.jar > urls[24] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/javax/servlet/servlet-api/2.3/servlet-api-2.3.jar > urls[25] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-web-module/1.2.3/xdoclet-web-module-1.2.3.jar > urls[26] = > file:/C:/Docume~1/nbk7xsp/.m2/repository/xdoclet/xdoclet-caucho-module/1.2.3/xdoclet-caucho-module-1.2.3.jar > urls[27] = > file:/C:/Docu
[jira] Closed: (MRELEASE-190) scmTagPhase scm comment when creating the branch/tag directory uses the prefix [maven-scm]
[ http://jira.codehaus.org/browse/MRELEASE-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-190. - Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 2.0-beta-5 > scmTagPhase scm comment when creating the branch/tag directory uses the > prefix [maven-scm] > -- > > Key: MRELEASE-190 > URL: http://jira.codehaus.org/browse/MRELEASE-190 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Reporter: Edwin Punzalan > Assigned To: Emmanuel Venisse > Fix For: 2.0-beta-5 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MIDEA-85) [Patch] Allow organizing of modules into groups
[ http://jira.codehaus.org/browse/MIDEA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralf Quebbemann updated MIDEA-85: - Attachment: MIDEA-85-maven-idea-plugin.patch Patch allows organizing of modules into groups. The feature can be enabled setting the property "useGroups" to true. > [Patch] Allow organizing of modules into groups > --- > > Key: MIDEA-85 > URL: http://jira.codehaus.org/browse/MIDEA-85 > Project: Maven 2.x Idea Plugin > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Ralf Quebbemann > Attachments: MIDEA-85-maven-idea-plugin.patch > > > The Idea plugin currently does not support grouping of modules. Grouping of > modules is very useful in case you have a "deep" project structure with > several container (or parent) projects within projects. > This feature organizes project modules into groups and can be activated > setting the property "useGroups" to true. > Most of the code was provided by idus (Apache MyFaces, Tobago Committer). I > simply added the property to activate this option. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-133) Merge redundant repository classes
[ http://jira.codehaus.org/browse/SCM-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-133: - Fix Version/s: (was: future) 2.0 > Merge redundant repository classes > -- > > Key: SCM-133 > URL: http://jira.codehaus.org/browse/SCM-133 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Affects Versions: 1.0-beta-2 >Reporter: Mike Perham > Fix For: 2.0 > > > Currently there are: > com.apache.maven.scm.repository.ScmRepository > com.apache.maven.scm.provider.ScmProviderRepository > The comment at the top of the former says: > * @todo clarify need - should be able to merge with ScmProviderRepository? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MIDEA-85) [Patch] Allow organizing of modules into groups
[Patch] Allow organizing of modules into groups --- Key: MIDEA-85 URL: http://jira.codehaus.org/browse/MIDEA-85 Project: Maven 2.x Idea Plugin Issue Type: New Feature Affects Versions: 2.0 Reporter: Ralf Quebbemann The Idea plugin currently does not support grouping of modules. Grouping of modules is very useful in case you have a "deep" project structure with several container (or parent) projects within projects. This feature organizes project modules into groups and can be activated setting the property "useGroups" to true. Most of the code was provided by idus (Apache MyFaces, Tobago Committer). I simply added the property to activate this option. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-17) test structure needs further clean up
[ http://jira.codehaus.org/browse/SCM-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-17: Fix Version/s: (was: future) 1.0 > test structure needs further clean up > - > > Key: SCM-17 > URL: http://jira.codehaus.org/browse/SCM-17 > Project: Maven SCM > Issue Type: Test > Components: maven-scm-provider-clearcase, maven-scm-provider-cvs, > maven-scm-provider-local, maven-scm-provider-perforce, > maven-scm-provider-starteam, maven-scm-provider-svn >Reporter: Brett Porter > Fix For: 1.0 > > > The following is needed: > - all providers need to utilise the TCK where possible. > - any tests in providers that can be generalised should be moved to the TCK > - other tests in the providers should just test provider specific functions, > and probably not be integration tests like the TCK is > - need further tests for other commands, including those yet to be added > - review coverage for each provider -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-18) complete commands and expose through ScmManager
[ http://jira.codehaus.org/browse/SCM-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-18: Fix Version/s: (was: future) 1.0 > complete commands and expose through ScmManager > --- > > Key: SCM-18 > URL: http://jira.codehaus.org/browse/SCM-18 > Project: Maven SCM > Issue Type: Task > Components: maven-scm-api, maven-scm-provider-clearcase, > maven-scm-provider-cvs, maven-scm-provider-local, > maven-scm-provider-perforce, maven-scm-provider-starteam, > maven-scm-provider-svn >Reporter: Brett Porter > Fix For: 1.0 > > > many commands are not completely implemented, or not implemented at all, and > some that are have not been exposed through the ScmManager interface. > These all need to be rounded out and tested via the TCK for a final 1.0 > 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: (MAVENUPLOAD-1459) upload of svnkit 1.1.2
upload of svnkit 1.1.2 -- Key: MAVENUPLOAD-1459 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1459 Project: maven-upload-requests Issue Type: Task Reporter: Renaud Bruyeron This is release 1.1.2 for svnkit, a pure-java subversion client used by many other projects. Note that the svnkit developers have added the necessary hooks in their build to easily produce the bundle with each release, which should smooth out the publication to the repository from now on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-208) Support for ClearCase, and other SCMs that do checkout projects to subdirectories of the checkout directory
[ http://jira.codehaus.org/browse/MRELEASE-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated MRELEASE-208: -- Assignee: Emmanuel Venisse Fix Version/s: 2.0-beta-5 > Support for ClearCase, and other SCMs that do checkout projects to > subdirectories of the checkout directory > --- > > Key: MRELEASE-208 > URL: http://jira.codehaus.org/browse/MRELEASE-208 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.0-beta-5 >Reporter: Arne Degenring > Assigned To: Emmanuel Venisse > Fix For: 2.0-beta-5 > > Attachments: patch-match-release-manager.txt > > > The attached patch makes the maven-release-manager support SCMs that do NOT > checkout projects into the checkout directory itself but into subdirectories > of the checkout directory. The SCM provider implementation must provide a > relative path to the project directory within the CheckoutScmResult. This has > been implemented for ClearCase already. See SCM-288 for further details. > The patch also contains a ScmTranslator implementation for ClearCase, and > therefore makes it possible to use the Release plugin with ClearCase (only > when using auto-generated config specs as introduced by SCM-287). > PS: The maven-release-plugin's unit tests in trunk seem to fail at the > moment, even without this patch, at least in my environment. This patch only > makes changes to maven-release-manager, not maven-release-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-313) archiva fails to serve maven2 plugin from legacy repository
archiva fails to serve maven2 plugin from legacy repository --- Key: MRM-313 URL: http://jira.codehaus.org/browse/MRM-313 Project: Archiva Issue Type: Improvement Components: remote proxy Affects Versions: 1.0 Reporter: nicolas de loof Priority: Minor Archiva is configured to proxy http://dist.codehaus.org/ (legacy layout) the xdoclet2 maven2 plugin is deployed under /xdoclet/maven-plugins. This looks right as the type is set to "maven-plugin". trying to download http://archiva/repository/maven/xdoclet/maven2-xdoclet2-plugin/2.0.5/maven2-xdoclet2-plugin-2.0.5.jar fails archiva has no info from the specified URL about trying to get a maven-plugin ! http://archiva/repository/maven/xdoclet/maven2-xdoclet2-plugin/2.0.5/maven2-xdoclet2-plugin-2.0.5.maven-plugin works as expected. 2 options (suggestions are wecome) : - use a "-plugin" pattern that a plugin is required (just a hack, and requires all plugin to follow this convention) - read the requested artifact POM to get the artifact type. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MEJB-3) Add ejb bundle feature like in maven 1
[ http://jira.codehaus.org/browse/MEJB-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92148 ] johan Eltes commented on MEJB-3: I'm on Maven 2.0.5. Although I've added the ejb plugin configuration stated above... maven-ejb-plugin true ... my dependencies don't get listed in the ClassPath: entry of the generated MANIFEST.MF. Is there anything else I need to do? Any specific scope to be defined for the dependencies? > Add ejb bundle feature like in maven 1 > -- > > Key: MEJB-3 > URL: http://jira.codehaus.org/browse/MEJB-3 > Project: Maven 2.x Ejb Plugin > Issue Type: New Feature > Environment: windows >Reporter: Alexandre Vivien > > It could be nice if we could include dependencies in the ejb jar produce by > the ejb plugin. In fact, I think an ejb bundle feature like in Maven 1 will > be useful. We could use the dependencies scope or whatever. (Perhaps it can > be handy to add a new scope name "bundle" that could be use with ejb, war and > ear plugin ) > Thanks. > Alexandre Vivien -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2856) Maven Archetype Plugin Changes PNG images
[ http://jira.codehaus.org/browse/MNG-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92151 ] Franz Allan Valencia See commented on MNG-2856: --- You can do something like this ... ... ... To avoid filtering of your resources. > Maven Archetype Plugin Changes PNG images > - > > Key: MNG-2856 > URL: http://jira.codehaus.org/browse/MNG-2856 > Project: Maven 2 > Issue Type: Bug > Components: Plugin Creation Tools >Affects Versions: 2.0.4 > Environment: Fedora Core 6 >Reporter: Ole Ersoy >Priority: Minor > > When the maven archetype serializes 123.png, it changes the file, making it > unreadable. > Here's the log info: > [WARNING] > org.apache.velocity.runtime.exception.ReferenceException: > reference : template = > archetype-resources/src/main/resources/images/123.png > [line 9,column 50] : $I is not a valid reference. > [WARNING] > org.apache.velocity.runtime.exception.ReferenceException: > reference : template = > archetype-resources/src/main/resources/images/123.png > [line 11,column 115] : $I is not a valid reference. > Maybe there needs to be a binary resources tag in the archetype descriptor, > so that the maven archetype simply copies binary resources, without > attempting to evaluate template parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2933) Declaring the same resource dir in pom and overwriting it in a profile
Declaring the same resource dir in pom and overwriting it in a profile -- Key: MNG-2933 URL: http://jira.codehaus.org/browse/MNG-2933 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.6 Reporter: Dirk Olmes Priority: Minor I have a pom that declares a resource dir in the main section of the pom and a profile which re-declares the same resource dir in a profile, this time with excludes. Example: src/main/resources src/main/resources http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2923) Having any active profiles causes the build to fail
[ http://jira.codehaus.org/browse/MNG-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92161 ] Micah Whitacre commented on MNG-2923: - Ok so I tracked this down again and am now going to try and see if I can explain it. I have a project that transitively inherits a project from multiple locations. Here is an example of the setup: 1. projectA:[1,3):test depth of 4 2. projectA:[1,3):compile depth of 3 3. projectA:[1,2):test depth of 2 4. projectA:[1,2):compile depth of 3. The version that should be resolved is 1.2 which is valid for all of those ranges. When resolving the dependencies it resolves them in that order. By the time it is resolving the 3 instances the first instance has already been disabled. So when it is resolving the 3 instance it determines that based on the scopes it should enable 2 and disable 3. On line 193 of DefaultArtifactCollector it sets the version of the farthest (instance 2). Calling DefaultArtifact.setVersion(String) sets the versionRange of the artifact to null. When trying to find a match for the versionRange when trying to resolve instance 4, on line 164 of DefaultArtifactCollector it can't find a match for instance 2 now because its range is null. So then it throws the NPE on the toString() call. Why is calling setVersion clearing out the versionRange? Shouldn't it be acceptable to have both specified? > Having any active profiles causes the build to fail > --- > > Key: MNG-2923 > URL: http://jira.codehaus.org/browse/MNG-2923 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 >Reporter: Matthew Beermann >Priority: Blocker > Attachments: pom.xml > > > (This seems to be a regression in 2.0.6, and does not occur in 2.0.5.) If I > have any active profiles when building certain projects in Maven 2.0.6, the > build will fail. For example, adding something as simple as: > > > foo > > true > > > > ...to my ~/.m2/settings.xml file will cause the stack trace below, but the > build will succeed once I remove it. I'm attaching my POM for reference. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:75) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: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:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[jira] Created: (MECLIPSE-250) default Maven directory structure not used when generating .classpath file on new project imported to Eclipse
default Maven directory structure not used when generating .classpath file on new project imported to Eclipse - Key: MECLIPSE-250 URL: http://jira.codehaus.org/browse/MECLIPSE-250 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Reporter: Tom Baker The current m2eclipse plugin does not create .classpath files that honor the standard Maven directory structure when it is used. To reproduce this, start with a simple project that uses the default Maven directory structure. Import the project into Eclipse as a regular project (not as a Java, or a Maven project). At this point, the project does not have a .classpath file. Run 'Maven2 Enable'. The .classpath file that gets generated does not correctly identify the default source folders and output folders based on the standard Maven directory structure. Here are sample contents of .classpath after running Maven2 Enable: Here is what I would have expected to see there: I think that when generating this file, the plugin should dynamically determine which of the standard directories contain source, and should add these entries to the .classpath file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-195) unpackOptions ignored
unpackOptions ignored - Key: MASSEMBLY-195 URL: http://jira.codehaus.org/browse/MASSEMBLY-195 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Reporter: Todd Wolff excludes/includes defined within unpack options of dependency set are effectively ignored -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2931) DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version
[ http://jira.codehaus.org/browse/MNG-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92187 ] Carlos Sanchez commented on MNG-2931: - I can see a cycle the child can't be released until the parent is if the parent is released with a released version of the child in depMngmt the child wouldn't run again as its version is still snapshot > DefaultArtifactCollector changes the version of the originatingArtifact if > it's in the dependencyManagement with another version > > > Key: MNG-2931 > URL: http://jira.codehaus.org/browse/MNG-2931 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts >Affects Versions: 2.0.5, 2.0.6 >Reporter: Carlos Sanchez > Attachments: MNG-2931.patch > > > DefaultDependencyTreeBuilder > https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/shared/dependency/tree/DefaultDependencyTreeBuilder.java > calls collect like this > collector.collect( project.getDependencyArtifacts(), > project.getArtifact(), managedVersions, repository, >project.getRemoteArtifactRepositories(), > metadataSource, null, >Collections.singletonList( listener ) ); > Problem: > This pom > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-component-api/1.0-alpha-22/plexus-component-api-1.0-alpha-22.pom > extends > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-22/plexus-containers-1.0-alpha-22.pom > that in dependencyManagement has > org.codehaus.plexus:plexus-component-api:1.0-alpha-19 > so during collect project.getArtifact().getVersion() is changed to the > managedVersion instead of the original one > Either this is a bug or an exception should be thrown when > originatingArtifact is in managedVersions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2934) Cannot Deploy Using Webdav due to DependencyManagement
Cannot Deploy Using Webdav due to DependencyManagement -- Key: MNG-2934 URL: http://jira.codehaus.org/browse/MNG-2934 Project: Maven 2 Issue Type: Bug Components: Dependencies, Deployment Affects Versions: 2.0.6 Reporter: Stephen Duncan Jr Attachments: pom.xml The webdav wagon requires commons-httpclient-2.0.2.jar. If I have a dependencyManagement section that specifies commons-httpclient 3.0.1, then deployment fails. The resulting output is: [EMAIL PROTECTED] webdavtest]$ mvn deploy [INFO] Scanning for projects... [INFO] artifact org.apache.maven.wagon:wagon-webdav: checking for updates from ce-releases - this realm = app0.child-container[extensions] urls[0] = file:/home/duncans/.m2/repository/de/zeigermann/xml/xml-im-exporter/1.1/xml-im-exporter-1.1.jar urls[1] = file:/home/duncans/.m2/repository/jdom/jdom/1.0/jdom-1.0.jar urls[2] = file:/home/duncans/.m2/repository/org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.jar urls[3] = file:/home/duncans/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar urls[4] = file:/home/duncans/.m2/repository/slide/slide-webdavlib/2.1/slide-webdavlib-2.1.jar urls[5] = file:/home/duncans/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar urls[6] = file:/home/duncans/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar urls[7] = file:/home/duncans/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar urls[8] = file:/home/duncans/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar Number of imports: 0 this realm = plexus.core urls[0] = file:/home/duncans/apps/maven/lib/maven-core-2.0.6-uber.jar Number of imports: 0 - [INFO] [INFO] Building Unnamed - test:webdavtest:pom:1.0-SNAPSHOT [INFO]task-segment: [deploy] [INFO] [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing /home/duncans/tmp/webdavtest/pom.xml to /home/duncans/.m2/repository/test/webdavtest/1.0-SNAPSHOT/webdavtest-1.0-SNAPSHOT.pom [INFO] [deploy:deploy] altDeploymentRepository = null [INFO] Retrieving previous build number from snapshots [WARNING] repository metadata for: 'snapshot test:webdavtest:1.0-SNAPSHOT' could not be retrieved from repository: snapshots due to an error: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested protocol: dav [INFO] Repository 'snapshots' will be blacklisted [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested protocol: dav Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagondav. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Thu Apr 05 13:49:52 EDT 2007 [INFO] Final Memory: 6M/10M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2930) Update JavaMojoDescriptorExtractor to make it more re-use friendly
[
http://jira.codehaus.org/browse/MNG-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon updated MNG-2930:
--
Complexity: Novice (was: Intermediate)
Patch attached: Yes
> Update JavaMojoDescriptorExtractor to make it more re-use friendly
> --
>
> Key: MNG-2930
> URL: http://jira.codehaus.org/browse/MNG-2930
> Project: Maven 2
> Issue Type: Improvement
> Components: Plugin Creation Tools
>Reporter: Jason Dillon
>Priority: Minor
> Fix For: 2.0.7
>
> Attachments: MNG-2930.diff
>
>
> Update the {{JavaMojoDescriptorExtractor}} in the {{maven-plugin-tools-java}}
> module to make it more friendly for reusability.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-2930) Update JavaMojoDescriptorExtractor to make it more re-use friendly
[
http://jira.codehaus.org/browse/MNG-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon updated MNG-2930:
--
Fix Version/s: 2.0.7
> Update JavaMojoDescriptorExtractor to make it more re-use friendly
> --
>
> Key: MNG-2930
> URL: http://jira.codehaus.org/browse/MNG-2930
> Project: Maven 2
> Issue Type: Improvement
> Components: Plugin Creation Tools
>Reporter: Jason Dillon
>Priority: Minor
> Fix For: 2.0.7
>
> Attachments: MNG-2930.diff
>
>
> Update the {{JavaMojoDescriptorExtractor}} in the {{maven-plugin-tools-java}}
> module to make it more friendly for reusability.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (CONTINUUM-1182) Pass configured scm username and password to execution of maven goals
[
http://jira.codehaus.org/browse/CONTINUUM-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Edelbroek reopened CONTINUUM-1182:
--
Its not good to configure the scm username and password in the settings.xml,
because it then can be read by other users. For me and our organisation it is
very important that the scm username and password cannot be read by other users
because only our build manager has certain rights to our SCM (which is Starteam
in our case). Also in our organisation, the build environment is shared among
different users, so storing the password in the settings.xml is not an option.
Therefore i need i way to use the scm username and password from continuum so
that they can be used by a maven plugin.
I made a small change to continuum-core to get this to work. The idea behind
this change is that the scm username and password are stored as environment
variables in the shell where maven is executed. A maven plugin can then use
these environment variables to configure the scm username and password.
I hope that you adopt this change in the next release of continuum.
The diff file is shown below and made against the 1.1-SNAPSHOT version, date
2007-04-05.
Index:
H:/workspaces/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/ShellCommandHelper.java
===
---
H:/workspaces/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/ShellCommandHelper.java
(revision 525924)
+++
H:/workspaces/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/ShellCommandHelper.java
(working copy)
@@ -20,6 +20,7 @@
*/
import java.io.File;
+import org.apache.maven.continuum.model.project.Project;
/**
* @author mailto:[EMAIL PROTECTED]">Trygve Laugstøl
@@ -30,14 +31,14 @@
String ROLE = ShellCommandHelper.class.getName();
ExecutionResult executeShellCommand( File workingDirectory, String
executable, String arguments, File output,
- long idCommand )
+ Project project )
throws Exception;
ExecutionResult executeShellCommand( File workingDirectory, String
executable, String[] arguments, File output,
- long idCommand )
+ Project project )
throws Exception;
-boolean isRunning( long idCommand );
+boolean isRunning( Project project );
-void killProcess( long idCommand );
+void killProcess( Project project );
}
Index:
H:/workspaces/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java
===
---
H:/workspaces/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java
(revision 525924)
+++
H:/workspaces/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java
(working copy)
@@ -24,6 +24,7 @@
import org.codehaus.plexus.util.cli.Commandline;
import org.codehaus.plexus.util.cli.StreamConsumer;
import org.codehaus.plexus.util.cli.WriterStreamConsumer;
+import org.apache.maven.continuum.model.project.Project;
import java.io.File;
import java.io.FileWriter;
@@ -45,8 +46,12 @@
// ShellCommandHelper Implementation
// --
+public static final String SCM_USERNAME = "CONTINUUM.PROJECT.SCM.USERNAME";
+public static final String SCM_PASSWORD = "CONTINUUM.PROJECT.SCM.PASSWORD";
+
+
public ExecutionResult executeShellCommand( File workingDirectory, String
executable, String arguments, File output,
-long idCommand )
+Project project )
throws Exception
{
Commandline cl = new Commandline();
@@ -55,11 +60,11 @@
argument.setLine( arguments );
-return executeShellCommand( workingDirectory, executable,
argument.getParts(), output, idCommand );
+return executeShellCommand( workingDirectory, executable,
argument.getParts(), output, project );
}
public ExecutionResult executeShellCommand( File workingDirectory, String
executable, String[] arguments,
-File output, long idCommand )
+File output, Project project )
throws Exception
{
//
--
@@ -68,12 +73,17 @@
Commandline cl = new Commandline();
-cl.setPid( idCommand );
+cl.setPid( project.getId() );
cl.addSystemEnv
[jira] Commented: (WAGON-74) WebDav component references non-existant jetty pom and fails to install into maven when building.
[ http://jira.codehaus.org/browse/WAGON-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92194 ] Carlos Sanchez commented on WAGON-74: - this was not a problem for me before > WebDav component references non-existant jetty pom and fails to install into > maven when building. > - > > Key: WAGON-74 > URL: http://jira.codehaus.org/browse/WAGON-74 > Project: wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-2 > Environment: Maven 2.0.5 >Reporter: Derek Clarkson >Priority: Blocker > > When attempt to deploy using the webdav to a local Archiva repository I get > the message: > Protocol [dav] is unsupported by the current configuration. > Turning on debug I see at the top of the log: > [DEBUG] Artifact not found - using stub model: Unable to download the > artifact from any repository > org.mortbay.jetty:jetty:pom:4.2.12 > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > aegeon-proxy (http://192.168.0.91:/proxy/aegeon) > Looking inside the repo1.maven.org/maven2 repository I can see that the > directory exists for jetty 4.2.12 but there is no pom in it. My build pom > makes reference to the following extension: > > > org.apache.maven.wagon > wagon-webdav > 1.0-beta-2 > > > Please suggest a fix as this is blocking our development because we cannot > deploy to our local Archiva server. > ciao > Derek -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2935) settings.xml errors are ignored
settings.xml errors are ignored --- Key: MNG-2935 URL: http://jira.codehaus.org/browse/MNG-2935 Project: Maven 2 Issue Type: Bug Components: Settings Affects Versions: 2.1-alpha-1 Reporter: Carlos Sanchez Priority: Minor when there's a parsing error on settings.xml the build continues ignoring it $ mvn clean -X + Error stacktraces are turned on. Maven version: 2.1-SNAPSHOT [ERROR] Failed to read settings from: xxx\.m2\settings.xml. Throwing XmlPullParserException... [DEBUG] Registering at plexus.core: org.apache.maven.wagon.providers.ssh.jsch.interactive.PrompterUIKeyboardInteractive (object realm: [EMAIL PROTECTED]), lookuprealm=plexus.core [INFO] Scanning for projects... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1460) Jython 2.2-beta-1 upload request
Jython 2.2-beta-1 upload request Key: MAVENUPLOAD-1460 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1460 Project: maven-upload-requests Issue Type: Task Reporter: Kevin Menard The Jython project is submitting a bundle for its latest maven bundle. This one is a significant departure from the previous bundles in that it now uses the new style groupId. Rather than "jython" it now uses "org.python", making it more maven-friendly and reflecting the fact that Jython is a first-class PSF project. This can be seen on: http://www.python.org/psf/records/board/resolutions/ "RESOLVED, that the org.python.* Java package name be reserved for use by the Jython project. Approved by IRC vote 7-0-0, March 12, 2007." Please note that the jython.org domain is also under the jurisdiction of the PSF, as evidenced by the WHOIS records. Hopefully this is sufficient enough detail to prove that bundle is in good standing for upload. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2936) IllegalArgumentException forking during javadoc
[ http://jira.codehaus.org/browse/MNG-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MNG-2936: Attachment: log.txt Not also that you get build error and then build successful [INFO] [ERROR] BUILD ERROR [INFO] [INFO] null [INFO] ... [INFO] [INFO] Total time: 4 seconds [INFO] Finished at: Thu Apr 05 16:29:26 PDT 2007 [INFO] Final Memory: 8M/15M [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 4 seconds [INFO] Finished at: Thu Apr 05 16:29:26 PDT 2007 [INFO] Final Memory: 8M/15M [INFO] > IllegalArgumentException forking during javadoc > --- > > Key: MNG-2936 > URL: http://jira.codehaus.org/browse/MNG-2936 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 > Environment: XP, spaces in path to local repo >Reporter: Carlos Sanchez > Attachments: log.txt, logX.txt > > > it0051 fails > I think it's picking an older plexus-utils > Caused by: java.lang.IllegalArgumentException > at java.lang.ProcessImpl.(ProcessImpl.java:69) > at java.lang.ProcessImpl.start(ProcessImpl.java:30) > at java.lang.ProcessBuilder.start(ProcessBuilder.java:451) > at java.lang.Runtime.exec(Runtime.java:591) > at > org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:653) > at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:102) > at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) > at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1196) > at > org.apache.maven.plugin.javadoc.JavadocJar.execute(JavadocJar.java:108) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:618) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:359) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:260) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:146) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:304) > ... 11 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2936) IllegalArgumentException forking during javadoc
[ http://jira.codehaus.org/browse/MNG-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MNG-2936: Attachment: logX.txt > IllegalArgumentException forking during javadoc > --- > > Key: MNG-2936 > URL: http://jira.codehaus.org/browse/MNG-2936 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 > Environment: XP, spaces in path to local repo >Reporter: Carlos Sanchez > Attachments: log.txt, logX.txt > > > it0051 fails > I think it's picking an older plexus-utils > Caused by: java.lang.IllegalArgumentException > at java.lang.ProcessImpl.(ProcessImpl.java:69) > at java.lang.ProcessImpl.start(ProcessImpl.java:30) > at java.lang.ProcessBuilder.start(ProcessBuilder.java:451) > at java.lang.Runtime.exec(Runtime.java:591) > at > org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:653) > at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:102) > at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) > at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1196) > at > org.apache.maven.plugin.javadoc.JavadocJar.execute(JavadocJar.java:108) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:618) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:359) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:260) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:146) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:304) > ... 11 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2936) IllegalArgumentException forking during javadoc
IllegalArgumentException forking during javadoc --- Key: MNG-2936 URL: http://jira.codehaus.org/browse/MNG-2936 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.1-alpha-1 Environment: XP, spaces in path to local repo Reporter: Carlos Sanchez Attachments: log.txt, logX.txt I think it's picking an older plexus-utils -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2936) IllegalArgumentException forking during javadoc
[ http://jira.codehaus.org/browse/MNG-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MNG-2936: Description: it0051 fails I think it's picking an older plexus-utils Caused by: java.lang.IllegalArgumentException at java.lang.ProcessImpl.(ProcessImpl.java:69) at java.lang.ProcessImpl.start(ProcessImpl.java:30) at java.lang.ProcessBuilder.start(ProcessBuilder.java:451) at java.lang.Runtime.exec(Runtime.java:591) at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:653) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:102) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1196) at org.apache.maven.plugin.javadoc.JavadocJar.execute(JavadocJar.java:108) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:618) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:359) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:260) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:146) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:304) ... 11 more was:I think it's picking an older plexus-utils Testcase included: yes > IllegalArgumentException forking during javadoc > --- > > Key: MNG-2936 > URL: http://jira.codehaus.org/browse/MNG-2936 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 > Environment: XP, spaces in path to local repo >Reporter: Carlos Sanchez > Attachments: log.txt, logX.txt > > > it0051 fails > I think it's picking an older plexus-utils > Caused by: java.lang.IllegalArgumentException > at java.lang.ProcessImpl.(ProcessImpl.java:69) > at java.lang.ProcessImpl.start(ProcessImpl.java:30) > at java.lang.ProcessBuilder.start(ProcessBuilder.java:451) > at java.lang.Runtime.exec(Runtime.java:591) > at > org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:653) > at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:102) > at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) > at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1196) > at > org.apache.maven.plugin.javadoc.JavadocJar.execute(JavadocJar.java:108) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:618) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:359) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:260) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:146) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:304) > ... 11 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2937) it0013 and it0020 fail with missing plugins
it0013 and it0020 fail with missing plugins --- Key: MNG-2937 URL: http://jira.codehaus.org/browse/MNG-2937 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.1-alpha-1 Environment: XP Reporter: Carlos Sanchez Attachments: it0013-log.txt, it0020-log.txt -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2937) it0013 and it0020 fail with missing plugins
[ http://jira.codehaus.org/browse/MNG-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MNG-2937: Attachment: it0020-log.txt > it0013 and it0020 fail with missing plugins > --- > > Key: MNG-2937 > URL: http://jira.codehaus.org/browse/MNG-2937 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 > Environment: XP >Reporter: Carlos Sanchez > Attachments: it0013-log.txt, it0020-log.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2937) it0013 and it0020 fail with missing plugins
[ http://jira.codehaus.org/browse/MNG-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MNG-2937: Attachment: it0013-log.txt > it0013 and it0020 fail with missing plugins > --- > > Key: MNG-2937 > URL: http://jira.codehaus.org/browse/MNG-2937 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1-alpha-1 > Environment: XP >Reporter: Carlos Sanchez > Attachments: it0013-log.txt, it0020-log.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2938) Build error is ignored at the end of the build
Build error is ignored at the end of the build -- Key: MNG-2938 URL: http://jira.codehaus.org/browse/MNG-2938 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.1-alpha-1 Reporter: Carlos Sanchez On a build error you get "BUILD ERROR" and then "BUILD SUCCESSFUL" [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to construct build plan for: org.apache.maven.its.it0020:maven-it-it0020:maven-plugin:1.0-SNAPSHOT ( task-segment: [clean:clean, install, ... [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Apr 05 16:27:47 PDT 2007 [INFO] Final Memory: 6M/11M [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Apr 05 16:27:47 PDT 2007 [INFO] Final Memory: 6M/11M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MGROOVY-1) Support mojo plugin.xml generation for Groovy mojos
[
http://jira.codehaus.org/browse/MGROOVY-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon closed MGROOVY-1.
--
Resolution: Fixed
> Support mojo plugin.xml generation for Groovy mojos
> ---
>
> Key: MGROOVY-1
> URL: http://jira.codehaus.org/browse/MGROOVY-1
> Project: Maven 2.x Groovy Plugin
> Issue Type: New Feature
>Reporter: Jason Dillon
> Assigned To: Jason Dillon
> Fix For: 1.0-alpha-3
>
>
> Right now there isn't really a good way to generate a plugin.xml for a Mojo
> implemented in Groovy.
> There is the {{javalike-maven-plugin-tools}} module which kinda works, though
> requires some icky ";" tokens to get qDox to properly parse out javadocs for
> parameters. I'm not sure that this module handles annotations on
> super-classes either.
> I've hacked up an extractor.groovy a while ago (MNG-1664) which uses regex,
> but that doesn't handle super-classes either.
> Really need a nice way to parse regular groovy (w/o needing ";') to generate
> a plugin.xml.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MGROOVY-25) Groovy scripts compiled by the maven groovy plugin does not have the org.apache.maven.plugin package on its classpath
[
http://jira.codehaus.org/browse/MGROOVY-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon closed MGROOVY-25.
---
Resolution: Won't Fix
You need to include everything your code depends on in the modules dependencies.
> Groovy scripts compiled by the maven groovy plugin does not have the
> org.apache.maven.plugin package on its classpath
> -
>
> Key: MGROOVY-25
> URL: http://jira.codehaus.org/browse/MGROOVY-25
> Project: Maven 2.x Groovy Plugin
> Issue Type: Bug
>Affects Versions: 1.0-alpha-2
> Environment: all
>Reporter: Jesse Eichar
> Assigned To: Jason Dillon
>Priority: Minor
>
> consider the following script:
> class ScriptClass{
> def testRequirements(){
> def requiredFile=new File("/requiredFile")
> if( !requiredFile.exists ){
> throw new org.apache.maven.plugin.MojoFailureException( "RequiredFile
> does not exist" )
> }
> }
> }
> This script will not compile correctly using the compile plugin because the
> MojoFailureException is not on the classpath. As a work around you can throw
> an AssertionError or a RuntimeException but in both cases you get a big ugly
> stacktrace. If you can throw a MojoFailureException the maven build will
> fail cleaning reporting the error and the stack trace can be shown using the
> -e stack trace.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1992) CLI -D should override properties in settings.xml
[ http://jira.codehaus.org/browse/MNG-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-1992: --- Fix Version/s: (was: 2.1.x) 2.1-alpha-1 > CLI -D should override properties in settings.xml > - > > Key: MNG-1992 > URL: http://jira.codehaus.org/browse/MNG-1992 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.2 > Environment: xp >Reporter: Brian Fox > Assigned To: Jason van Zyl > Fix For: 2.1-alpha-1 > > > I have a mojo that takes a parameter as an expression, simple boolean. If I > set it to true in my settings.xml, setting it to false with -D doesn't have > any effect. The CLI should have the final say. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
