[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/27-Nov-2005_12.30.45/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ruby-Mojo support
Eric Redmond wrote: Maven developers: I have just completed a couple projects to add Ruby support for Maven 2, allowing one to write mojos in Ruby as well as generate mojo descriptors based upon RDoc markup. But I have run into a hurdle. I currently am making the plugin:descriptor run my RubyExtractor by adding the maven-plugin-tools-ruby project to the maven-plugin-plugin dependency list. I figured when running the descriptor goal on the plugin project, it populates the mojoDescriptorExtractors with those injected by Plexus, which naturally must exist in the classpath space (I believe I am correct here). So my question is: is there another way I am missing in which to add my RubyExtractor to the plugin "descriptor" which does not include modifying the maven-plugin-plugin project in any way? I'll definitely help you integrate your code into maven/plexus as I've been playing around with Ruby in the last month and I would really like to see this in Maven. We're generally in IRC if you want to chat about integration: irc.codehaus.org: #maven. Thanks! Eric -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1694) Build execution order control in fine grained projects.
[ http://jira.codehaus.org/browse/MNG-1694?page=comments#action_52114 ] Mark Proctor commented on MNG-1694: --- skipping is fine by me, as long as its fast. Thats what I did for M1, I implemented my own build goal that iterates the reactor and calls jar:jar if a jar doesn't exist. > Build execution order control in fine grained projects. > --- > > Key: MNG-1694 > URL: http://jira.codehaus.org/browse/MNG-1694 > Project: Maven 2 > Type: Wish > Components: Reactor and workspace > Reporter: Mark Proctor > > > Currently in multi module projects you can only work in 2 modes. > 1) Build everything > 2) Build a single module, IF you have built and installed all its dependency > modules > I would like to be able to work the following way: > 1) Build everything > 2) Build an individual module, will build all the modules prior to it in the > reactor list. > 3) Build a module module and all modules after it in the reactor list, will > build missing prior modules. > Use Case > 1) perform checkout and build > 2) module fails > 3) keep fixing module and running just its unit tests > 3) once all its unit tests pass build it and all modules after it in the > reactor list. I don't need to build ones prior as they are unnaffected by the > changes. > In large mutli module projects this will save a LOT of time especially when > you are gearing up for deployment and want to check that everything works - > currently this is time consuming and repetitive, with much of the repetition > uneeded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ruby-Mojo support
The project building the plugin can add this without modifying the original plugin plugin: maven-plugin-plugin ... maven-plugin-tools-ruby ... We'd be very interested in this support. Are you willing to contribute it back to the project? Cheers, Brett Eric Redmond wrote: > Maven developers: > > I have just completed a couple projects to add Ruby support for Maven 2, > allowing one to write mojos in Ruby as well as generate mojo descriptors > based upon RDoc markup. But I have run into a hurdle. I currently am making > the plugin:descriptor run my RubyExtractor by adding the > maven-plugin-tools-ruby project to the maven-plugin-plugin dependency list. > I figured when running the descriptor goal on the plugin project, it > populates the mojoDescriptorExtractors with those injected by Plexus, which > naturally must exist in the classpath space (I believe I am correct here). > > So my question is: is there another way I am missing in which to add my > RubyExtractor to the plugin "descriptor" which does not include modifying > the maven-plugin-plugin project in any way? > > Thanks! > Eric > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ruby-Mojo support
Maven developers: I have just completed a couple projects to add Ruby support for Maven 2, allowing one to write mojos in Ruby as well as generate mojo descriptors based upon RDoc markup. But I have run into a hurdle. I currently am making the plugin:descriptor run my RubyExtractor by adding the maven-plugin-tools-ruby project to the maven-plugin-plugin dependency list. I figured when running the descriptor goal on the plugin project, it populates the mojoDescriptorExtractors with those injected by Plexus, which naturally must exist in the classpath space (I believe I am correct here). So my question is: is there another way I am missing in which to add my RubyExtractor to the plugin "descriptor" which does not include modifying the maven-plugin-plugin project in any way? Thanks! Eric
[jira] Updated: (MNG-1694) Build execution order control in fine grained projects.
[ http://jira.codehaus.org/browse/MNG-1694?page=all ] Brett Porter updated MNG-1694: -- Component: (was: maven-compiler-plugin) Reactor and workspace > Build execution order control in fine grained projects. > --- > > Key: MNG-1694 > URL: http://jira.codehaus.org/browse/MNG-1694 > Project: Maven 2 > Type: Wish > Components: Reactor and workspace > Reporter: Mark Proctor > > > Currently in multi module projects you can only work in 2 modes. > 1) Build everything > 2) Build a single module, IF you have built and installed all its dependency > modules > I would like to be able to work the following way: > 1) Build everything > 2) Build an individual module, will build all the modules prior to it in the > reactor list. > 3) Build a module module and all modules after it in the reactor list, will > build missing prior modules. > Use Case > 1) perform checkout and build > 2) module fails > 3) keep fixing module and running just its unit tests > 3) once all its unit tests pass build it and all modules after it in the > reactor list. I don't need to build ones prior as they are unnaffected by the > changes. > In large mutli module projects this will save a LOT of time especially when > you are gearing up for deployment and want to check that everything works - > currently this is time consuming and repetitive, with much of the repetition > uneeded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1694) Build execution order control in fine grained projects.
[ http://jira.codehaus.org/browse/MNG-1694?page=comments#action_52112 ] Brett Porter commented on MNG-1694: --- I think what you really want here is - build this project and its *dependencies* inside this workspace - continue from last failed build Both reasonable ideas, but I also worry about introducing this kind of multi-mode operation too much. I would prefer to work on the ability to make some builds simply skip by as the files are unchanged. This makes the behaviour the same always and protects the user from their own error in not knowing what is updated. > Build execution order control in fine grained projects. > --- > > Key: MNG-1694 > URL: http://jira.codehaus.org/browse/MNG-1694 > Project: Maven 2 > Type: Wish > Components: maven-compiler-plugin > Reporter: Mark Proctor > > > Currently in multi module projects you can only work in 2 modes. > 1) Build everything > 2) Build a single module, IF you have built and installed all its dependency > modules > I would like to be able to work the following way: > 1) Build everything > 2) Build an individual module, will build all the modules prior to it in the > reactor list. > 3) Build a module module and all modules after it in the reactor list, will > build missing prior modules. > Use Case > 1) perform checkout and build > 2) module fails > 3) keep fixing module and running just its unit tests > 3) once all its unit tests pass build it and all modules after it in the > reactor list. I don't need to build ones prior as they are unnaffected by the > changes. > In large mutli module projects this will save a LOT of time especially when > you are gearing up for deployment and want to check that everything works - > currently this is time consuming and repetitive, with much of the repetition > uneeded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1692) Project scoped Repository
[ http://jira.codehaus.org/browse/MNG-1692?page=comments#action_52111 ] Brett Porter commented on MNG-1692: --- I don't know if this is the right solution to the problem. It could be useful, however if the workspace functionality is able to identify where the project output files are even without running the build mojos (which would be ideal), then the local repo becomes unnecessary as everything is sourced from the workspace. However, if that becomes a longer term feature, this could be a quicker fix, and would also assist with interim plugin development. > Project scoped Repository > - > > Key: MNG-1692 > URL: http://jira.codehaus.org/browse/MNG-1692 > Project: Maven 2 > Type: Wish > Components: Artifacts and Repositories > Reporter: Mark Proctor > Fix For: 2.1 > > > In multi module builds I would like jars to not instally locally until I > instruct it and still be able to build individual modules. At the moment if I > try and build an invidiual module it insists on looking in the local repo. In > Maven 1 we worked around this by using jar override. > The use case for this is for when you are messing around with multiple > checkouts of the same version and don't want them to interact with each > other. With current M2 I either have to create different versions in the pom > for each checkout, when all changes are likely to end up in the "master" > checkout for a specific verison. Or I can specify the repo to be in the > project, but that means I have to checkout everything each time I want to > build something. > This could be achieve by using root/target as a project level repo for the > produced jars which would use the local repo for anything that it can't find > it the project repo. Only when I tell it to install will it copy the jars > from the project repo to the local repo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1694) Build execution order control in fine grained projects.
Build execution order control in fine grained projects. --- Key: MNG-1694 URL: http://jira.codehaus.org/browse/MNG-1694 Project: Maven 2 Type: Wish Components: maven-compiler-plugin Reporter: Mark Proctor Currently in multi module projects you can only work in 2 modes. 1) Build everything 2) Build a single module, IF you have built and installed all its dependency modules I would like to be able to work the following way: 1) Build everything 2) Build an individual module, will build all the modules prior to it in the reactor list. 3) Build a module module and all modules after it in the reactor list, will build missing prior modules. Use Case 1) perform checkout and build 2) module fails 3) keep fixing module and running just its unit tests 3) once all its unit tests pass build it and all modules after it in the reactor list. I don't need to build ones prior as they are unnaffected by the changes. In large mutli module projects this will save a LOT of time especially when you are gearing up for deployment and want to check that everything works - currently this is time consuming and repetitive, with much of the repetition uneeded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1693) .wtpmodules does not use same output directory as compiler
.wtpmodules does not use same output directory as compiler -- Key: MNG-1693 URL: http://jira.codehaus.org/browse/MNG-1693 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0.1 Reporter: Barry Kaplan When the output path is overriden via the outputDirectory configuration property, the 'java-output-path' property in .wtpmodules does not use this value. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1693) .wtpmodules does not use same output directory as compiler
[ http://jira.codehaus.org/browse/MNG-1693?page=comments#action_52108 ] Barry Kaplan commented on MNG-1693: --- And I think this is causing some eclipse validators to scan surefire generated files (which I target to a different output directory than eclipse), which can get quite slow at times. > .wtpmodules does not use same output directory as compiler > -- > > Key: MNG-1693 > URL: http://jira.codehaus.org/browse/MNG-1693 > Project: Maven 2 > Type: Bug > Components: maven-eclipse-plugin > Versions: 2.0.1 > Reporter: Barry Kaplan > > > When the output path is overriden via the outputDirectory configuration > property, the 'java-output-path' property in .wtpmodules does not use this > value. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1692) Project scoped Repository
Project scoped Repository - Key: MNG-1692 URL: http://jira.codehaus.org/browse/MNG-1692 Project: Maven 2 Type: Wish Components: Artifacts and Repositories Reporter: Mark Proctor Fix For: 2.1 In multi module builds I would like jars to not instally locally until I instruct it and still be able to build individual modules. At the moment if I try and build an invidiual module it insists on looking in the local repo. In Maven 1 we worked around this by using jar override. The use case for this is for when you are messing around with multiple checkouts of the same version and don't want them to interact with each other. With current M2 I either have to create different versions in the pom for each checkout, when all changes are likely to end up in the "master" checkout for a specific verison. Or I can specify the repo to be in the project, but that means I have to checkout everything each time I want to build something. This could be achieve by using root/target as a project level repo for the produced jars which would use the local repo for anything that it can't find it the project repo. Only when I tell it to install will it copy the jars from the project repo to the local repo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=comments#action_52107 ] Barry Kaplan commented on MNG-1605: --- BTW, only with the double slashes do I get the warning. But the double slash was the only thing I could find that worked. I tried all kinds other combinations. > Allow eclipse source to be specified at the dependency level > > > Key: MNG-1605 > URL: http://jira.codehaus.org/browse/MNG-1605 > Project: Maven 2 > Type: New Feature > Components: maven-eclipse-plugin > Versions: 2.0 > Reporter: Barry Kaplan > Assignee: fabrizio giustina > > > Many (most?) projects do not have sources uploaded. And in any case, most > projects only need a small subset of the sources. Source downloading, even > (especially?) for sources that don't exist, is very time consuming. > Therefore, it would be nice to specify this eclipse plugin specific option as > the dependency level. Maybe something like: > > backport-util-concurrent > backport-util-concurrent > 2.0_01_pd > runtime > > > > > (For this to be general, it would of course require a much different model > than the simple plugin-level property injection. ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=comments#action_52106 ]
Barry Kaplan commented on MNG-1605:
---
Workaround: I changed the plugin config to:
//${project.artifactId}/target/eclipse-classes
This caused the following warnings:
[INFO] [eclipse:eclipse]
[WARNING] This plugin currently doesn't support include patterns for resources.
Adding the entire directory.
[WARNING] This plugin currently doesn't support include patterns for resources.
Adding the entire directory.
[WARNING] This plugin currently doesn't support include patterns for resources.
Adding the entire directory.
[WARNING] This plugin currently doesn't support include patterns for resources.
Adding the entire directory.
[WARNING] This plugin currently doesn't support include patterns for resources.
Adding the entire directory.
Which caused noticable delays for the directories with lots of files. But it
did create the correct output path.
> Allow eclipse source to be specified at the dependency level
>
>
> Key: MNG-1605
> URL: http://jira.codehaus.org/browse/MNG-1605
> Project: Maven 2
> Type: New Feature
> Components: maven-eclipse-plugin
> Versions: 2.0
> Reporter: Barry Kaplan
> Assignee: fabrizio giustina
>
>
> Many (most?) projects do not have sources uploaded. And in any case, most
> projects only need a small subset of the sources. Source downloading, even
> (especially?) for sources that don't exist, is very time consuming.
> Therefore, it would be nice to specify this eclipse plugin specific option as
> the dependency level. Maybe something like:
>
> backport-util-concurrent
> backport-util-concurrent
> 2.0_01_pd
> runtime
>
>
>
>
> (For this to be general, it would of course require a much different model
> than the simple plugin-level property injection. )
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=comments#action_52105 ] Barry Kaplan commented on MNG-1605: --- A correct output path would have the project prepended, eg: "iris-infra/target/eclipse-classes". This is indeed what is created when running from the leaf project, not what I showed above. It appears the only thing that could have broke with were the changes to EclipseClasspathWriter and EclipseUtils. > Allow eclipse source to be specified at the dependency level > > > Key: MNG-1605 > URL: http://jira.codehaus.org/browse/MNG-1605 > Project: Maven 2 > Type: New Feature > Components: maven-eclipse-plugin > Versions: 2.0 > Reporter: Barry Kaplan > Assignee: fabrizio giustina > > > Many (most?) projects do not have sources uploaded. And in any case, most > projects only need a small subset of the sources. Source downloading, even > (especially?) for sources that don't exist, is very time consuming. > Therefore, it would be nice to specify this eclipse plugin specific option as > the dependency level. Maybe something like: > > backport-util-concurrent > backport-util-concurrent > 2.0_01_pd > runtime > > > > > (For this to be general, it would of course require a much different model > than the simple plugin-level property injection. ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=comments#action_52104 ] Barry Kaplan commented on MNG-1605: --- Thanks Fabrizio. All works except the output path. I have the following defined: org.apache.maven.plugins maven-eclipse-plugin /target/eclipse-classes ... When the eclipse project is generated from the leaf project directory, the output path is created correctly as "target/eclipse-classes". However, when I generated eclipse projects via the root project using multi-project, the output path has a drive letter prepended, eg "R:target/eclipse-classes". (I haven't yet tried to see why this might be.) > Allow eclipse source to be specified at the dependency level > > > Key: MNG-1605 > URL: http://jira.codehaus.org/browse/MNG-1605 > Project: Maven 2 > Type: New Feature > Components: maven-eclipse-plugin > Versions: 2.0 > Reporter: Barry Kaplan > Assignee: fabrizio giustina > > > Many (most?) projects do not have sources uploaded. And in any case, most > projects only need a small subset of the sources. Source downloading, even > (especially?) for sources that don't exist, is very time consuming. > Therefore, it would be nice to specify this eclipse plugin specific option as > the dependency level. Maybe something like: > > backport-util-concurrent > backport-util-concurrent > 2.0_01_pd > runtime > > > > > (For this to be general, it would of course require a much different model > than the simple plugin-level property injection. ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-610) Upload XWork-Spring Integration to central Maven Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-610?page=comments#action_52103 ] Matt Raible commented on MAVENUPLOAD-610: - Sorry about that Carlos - I've fixed the bundle and re-uploaded it. > Upload XWork-Spring Integration to central Maven Repository > --- > > Key: MAVENUPLOAD-610 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-610 > Project: maven-upload-requests > Type: Task > Reporter: Matt Raible > > > Please upload xwork-spring integration bundle for integration WebWork and > Spring in WebWork 2.x. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-610) Upload XWork-Spring Integration to central Maven Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-610?page=comments#action_52102 ] Carlos Sanchez commented on MAVENUPLOAD-610: The pom has to be called pom.xml The groupId should be net.java.dev.xwork-optional > Upload XWork-Spring Integration to central Maven Repository > --- > > Key: MAVENUPLOAD-610 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-610 > Project: maven-upload-requests > Type: Task > Reporter: Matt Raible > > > Please upload xwork-spring integration bundle for integration WebWork and > Spring in WebWork 2.x. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-609) maven taglib plugin 1.4.2 for maven 1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-609?page=comments#action_52101 ] Carlos Sanchez commented on MAVENUPLOAD-609: id needs to be removed > maven taglib plugin 1.4.2 for maven 1 > - > > Key: MAVENUPLOAD-609 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-609 > Project: maven-upload-requests > Type: Task > Reporter: fabrizio giustina > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-227) struts 1.2.4 and 1.2.8 dependencies still broken
[ http://jira.codehaus.org/browse/MEV-227?page=comments#action_52100 ] Wendy Smoak commented on MEV-227: - The corrected m1 pom (with dependency scope hints added) for 1.2.8 is in the Struts repository: https://svn.apache.org/repos/asf/struts/action/branches/STRUTS_1_2_BRANCH/project.xml It has not yet been uploaded to the Apache repo; I'm hoping the release manager will do that tomorrow. > struts 1.2.4 and 1.2.8 dependencies still broken > > > Key: MEV-227 > URL: http://jira.codehaus.org/browse/MEV-227 > Project: Maven Evangelism > Type: Sub-task > Reporter: denis Cabasson > Assignee: Carlos Sanchez > > > Looks like the dependencies are still broken -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-231) OJB should list commons-dbcp as a dependency
[ http://jira.codehaus.org/browse/MEV-231?page=comments#action_52099 ] Carlos Sanchez commented on MEV-231: Let's add only the necessary or this will be a mess. > OJB should list commons-dbcp as a dependency > > > Key: MEV-231 > URL: http://jira.codehaus.org/browse/MEV-231 > Project: Maven Evangelism > Type: Bug > Components: Invalid POM > Reporter: Matt Raible > Assignee: Edwin Punzalan > > > This POM works much better than the one at: > http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.3/db-ojb-1.0.3.pom > > 4.0.0 > ojb > db-ojb > 1.0.3 > > > > commons-dbcp > commons-dbcp > 1.2 > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MEV-227) struts 1.2.4 and 1.2.8 dependencies still broken
[ http://jira.codehaus.org/browse/MEV-227?page=all ] Carlos Sanchez reopened MEV-227: Fixed 1.2.4 but not yet 1.2.8 > struts 1.2.4 and 1.2.8 dependencies still broken > > > Key: MEV-227 > URL: http://jira.codehaus.org/browse/MEV-227 > Project: Maven Evangelism > Type: Sub-task > Reporter: denis Cabasson > Assignee: Carlos Sanchez > > > Looks like the dependencies are still broken -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-230) Struts POM should have Cactus dependencies listed with test
[ http://jira.codehaus.org/browse/MEV-230?page=all ] Carlos Sanchez closed MEV-230: -- Assign To: Carlos Sanchez (was: Edwin Punzalan) Resolution: Duplicate Dupe of MEV-227 > Struts POM should have Cactus dependencies listed with test > -- > > Key: MEV-230 > URL: http://jira.codehaus.org/browse/MEV-230 > Project: Maven Evangelism > Type: Improvement > Components: Invalid POM > Reporter: Matt Raible > Assignee: Carlos Sanchez > > > [DEBUG] struts:struts:jar:1.2.4 (selected for compile) > [DEBUG] junit:junit:jar:3.8.1 (not setting scope to: compile; local scope > test wins) > [WARNING] > Artifact junit:junit:jar:3.8.1 retains local scope 'test' overriding > broader scope 'compile' > given by a dependency. If this is not intended, modify or remove the > local scope. > [DEBUG] junit:junit:jar:3.8.1 (selected for compile) > [DEBUG] oro:oro:jar:2.0.7 (selected for compile) > [DEBUG] commons-logging:commons-logging:jar:1.0.4 (selected for compile) > [DEBUG] commons-collections:commons-collections:jar:2.1 (removed - nearer > found: 2.1.1) > [DEBUG] commons-collections:commons-collections:jar:2.1 (selected for > compile) > [DEBUG] xalan:xalan:jar:2.5.1 (selected for compile) > [DEBUG] commons-digester:commons-digester:jar:1.5 (selected for compile) > [DEBUG] commons-beanutils:commons-beanutils:jar:1.6.1 (setting scope > to: compile) > [DEBUG] commons-beanutils:commons-beanutils:jar:1.6 (removed - nearer > found: 1.6.1) > [DEBUG] commons-beanutils:commons-beanutils:jar:1.6 (selected for > compile) > [DEBUG] commons-logging:commons-logging:jar:1.0 (removed - nearer > found: 1.0.4) > [DEBUG] commons-logging:commons-logging:jar:1.0 (selected for compile) > [DEBUG] commons-collections:commons-collections:jar:2.1 (removed - > nearer found: 2.1.1) > [DEBUG] commons-collections:commons-collections:jar:2.1 (selected for > compile) > [DEBUG] cactus:cactus:jar:12-1.4.1 (selected for compile) > [DEBUG] commons-lang:commons-lang:jar:2.0 (selected for compile) > [DEBUG] commons-validator:commons-validator:jar:1.1.3 (selected for > compile) > [DEBUG] cactus:cactus-ant:jar:1.4.1 (selected for compile) > [DEBUG] commons-fileupload:commons-fileupload:jar:1.0 (selected for > compile) > [DEBUG] commons-beanutils:commons-beanutils:jar:1.6.1 (selected for > compile) > [DEBUG] antlr:antlr:jar:2.7.2 (selected for compile) > [DEBUG] struts:struts-el:jar:1.2.4 (selected for compile) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-227) struts 1.2.4 and 1.2.8 dependencies still broken
[ http://jira.codehaus.org/browse/MEV-227?page=all ] Carlos Sanchez closed MEV-227: -- Assign To: Carlos Sanchez Resolution: Fixed Used the one provided by Wendy at matt's repo > struts 1.2.4 and 1.2.8 dependencies still broken > > > Key: MEV-227 > URL: http://jira.codehaus.org/browse/MEV-227 > Project: Maven Evangelism > Type: Sub-task > Reporter: denis Cabasson > Assignee: Carlos Sanchez > > > Looks like the dependencies are still broken -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r348621 - in /maven/site/trunk: pom.xml src/site/site.xml
Odd, it's fine when I generate it. Republished, will look into why it got there. (whoever last did it, it came out as " instead of " around UA-...) - Brett Vincent Siveton wrote: > Hi Brett, > >> Modified: maven/site/trunk/src/site/site.xml >> URL: >> http://svn.apache.org/viewcvs/maven/site/trunk/src/site/site.xml?rev=34862 >> 1&r1=348620&r2=348621&view=diff >> == >> >> --- maven/site/trunk/src/site/site.xml (original) >> +++ maven/site/trunk/src/site/site.xml Wed Nov 23 18:36:35 2005 >> @@ -17,7 +17,17 @@ >>http://maven.apache.org/scm"/> >>http://maven.apache.org/wagon"/> >>http://maven.apache.org/jxr"/> >> + http://maven.apache.org/doxia"/> >> >> + >> + >> + http://www.google-analytics.com/urchin.js"; >> type="text/javascript"> >> + >> + >> +_uacct = "UA-140879-1"; >> +urchinTracker(); >> + >> + >> >> >> > > According to this change, it seems that we have now a JS error on > http://maven.apache.org > > Cheers, > > Vincent > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] 2.0.1/2.1 dev process
Alan D. Cabrera wrote: > Brett Porter wrote, On 11/24/2005 4:23 PM: > >> My thoughts: >> - this is more risky that it will be missed if someone misses one >> >> > This is not as likely if the commits are made to both lines at the same > time. I don't understand this reasoning. If using this technique, if one is missed, you have to backtrack and find what was missed. If you use the weekly technique (or whatever interval), you are merging everything since last merge ensuring nothing is missed. > Also, there will be times when it will not make sense to apply > the branch change in the trunk. You want the original patch author to > make that investigation and decision at the time of the checkin not a > "third party" branch merger at the time of a branch merge. I don't exactly agree. The only case where I feel something should go onto the branch and not the trunk is if that functionality was removed on the trunk for some reason. In that case, the merge will conflict on that change and it can be easily thrown away. Do you have a specific use case? > >> - its more cumbersome on an individual commit >> >> > Not more cumbersome. Waiting to do the work at the uber merge merely > postpones the inevitable. I can't agree here. Assuming no review, per commit adds a command for every commit, per week adds a command per week. Getting into review stage - you've already said that the review is the same at either point. I'd prefer to do them sequentially myself. I understand that there might be some issues that require the original author to be involved. In this case I'd instead encourage authors to still be aware of the affect of their changes and if they think they will be problematic - to call for an early merge to raise a flag on it. That fits the community style better too :) > Blind merges that just dump whatever is in a > branch into the trunk are always dangerous without careful scrutiny; > performing this due diligence makes it the same, usually more, amount of > work as individual multi branch commits. I agree blind merges are bad. When I do it, I always review the resulting commit to ensure it still makes sense. And aside from that, you rely a lot on your automated testing to ensure everything is still sane. I see where you are going, and it probably becomes more the case as you get to a much larger project size than what we are dealing with (100's of developers instead of 10's). The fact is that the majority of commits in the project at present are comfortably isolated and merge nicely. > And you want to know of the clash and have that discussion asap, at the > time of the checkin, not later. Issues like this need to be resolved > before the trunk evolves further and while things are still fresh in > everyone's mind. That's true. I've thought about Maven tracking last merge points and allowing CI to automatically perform that merge on the trunk automatically and alert when it has a conflict and then let someone resolve that, and then test the build. > The paradigm I espouse applies to what ever product management style > that is in place. The issues that I raise are not as relevant for more > mature product lines that do not change that radically. But it has > always been my experience that a "blind" merge at the end of a branch > release is always more work and error prone than "multi branch" checkins. > > Just my 2 cents. :) That's fair enough, but I just don't see it here where we are doing very little (well, currently no) trunk work. And its super tedious and anything tedious is error prone. I'd grumble about doing it, and anything you have to grumble about is going to cause some sort of issues. Others are welcome to disagree with me :) Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/26-Nov-2005_08.30.48/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r348621 - in /maven/site/trunk: pom.xml src/site/site.xml
Hi Brett, > Modified: maven/site/trunk/src/site/site.xml > URL: > http://svn.apache.org/viewcvs/maven/site/trunk/src/site/site.xml?rev=34862 > 1&r1=348620&r2=348621&view=diff > == > > --- maven/site/trunk/src/site/site.xml (original) > +++ maven/site/trunk/src/site/site.xml Wed Nov 23 18:36:35 2005 > @@ -17,7 +17,17 @@ >http://maven.apache.org/scm"/> >http://maven.apache.org/wagon"/> >http://maven.apache.org/jxr"/> > + http://maven.apache.org/doxia"/> > > + > + > + http://www.google-analytics.com/urchin.js"; > type="text/javascript"> > + > + > +_uacct = "UA-140879-1"; > +urchinTracker(); > + > + > > > According to this change, it seems that we have now a JS error on http://maven.apache.org Cheers, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPECLIPSE-108) Scope system in dependencies not supported
[ http://jira.codehaus.org/browse/MPECLIPSE-108?page=all ]
Brett Porter closed MPECLIPSE-108:
--
Resolution: Duplicate
Fix Version: (was: 1.10)
> Scope system in dependencies not supported
> --
>
> Key: MPECLIPSE-108
> URL: http://jira.codehaus.org/browse/MPECLIPSE-108
> Project: maven-eclipse-plugin
> Type: Bug
> Environment: Maven2-maven-eclipse-plugin 2.0-beta-2 + Windows XP
> Reporter: J-C
> Assignee: fabrizio giustina
> Attachments: EclipseClasspathWriter.java
>
>
> In my pom.xml, I have a dependency:
>
> javax.persistence
> ejb
> system
> 3.0
>
>
> ${jboss.deploy}/ejb3.deployer/ejb3-persistence.jar
>
>
> With scope sytem, in .classpath file, a lib shoud be generated insted of a
> var.
> To fix that see EclipseClasspathWriter.addDependency in attachment.
> //
> //path = "M2_REPO/" //$NON-NLS-1$
> //+ EclipseUtils.toRelativeAndFixSeparator(
> // localRepositoryFile, fullPath, false);
> //MODIF///
> if
> (Artifact.SCOPE_SYSTEM.equalsIgnoreCase(artifact.getScope())) {
> path = EclipseUtils.toRelativeAndFixSeparator(
> localRepositoryFile, fullPath,
> false);
> kind = "lib"; //$NON-NLS-1$
> } else {
> path = "M2_REPO/" //$NON-NLS-1$
> +
> EclipseUtils.toRelativeAndFixSeparator(
>
> localRepositoryFile, fullPath, false);
> kind = "var"; //$NON-NLS-1$
> }
> //
> //END MODIF///
> .
> /// REMOVED
> /// kind = "var"; //$NON-NLS-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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MPECLIPSE-108) Scope system in dependencies not supported
[ http://jira.codehaus.org/browse/MPECLIPSE-108?page=all ]
Brett Porter reopened MPECLIPSE-108:
> Scope system in dependencies not supported
> --
>
> Key: MPECLIPSE-108
> URL: http://jira.codehaus.org/browse/MPECLIPSE-108
> Project: maven-eclipse-plugin
> Type: Bug
> Environment: Maven2-maven-eclipse-plugin 2.0-beta-2 + Windows XP
> Reporter: J-C
> Assignee: fabrizio giustina
> Attachments: EclipseClasspathWriter.java
>
>
> In my pom.xml, I have a dependency:
>
> javax.persistence
> ejb
> system
> 3.0
>
>
> ${jboss.deploy}/ejb3.deployer/ejb3-persistence.jar
>
>
> With scope sytem, in .classpath file, a lib shoud be generated insted of a
> var.
> To fix that see EclipseClasspathWriter.addDependency in attachment.
> //
> //path = "M2_REPO/" //$NON-NLS-1$
> //+ EclipseUtils.toRelativeAndFixSeparator(
> // localRepositoryFile, fullPath, false);
> //MODIF///
> if
> (Artifact.SCOPE_SYSTEM.equalsIgnoreCase(artifact.getScope())) {
> path = EclipseUtils.toRelativeAndFixSeparator(
> localRepositoryFile, fullPath,
> false);
> kind = "lib"; //$NON-NLS-1$
> } else {
> path = "M2_REPO/" //$NON-NLS-1$
> +
> EclipseUtils.toRelativeAndFixSeparator(
>
> localRepositoryFile, fullPath, false);
> kind = "var"; //$NON-NLS-1$
> }
> //
> //END MODIF///
> .
> /// REMOVED
> /// kind = "var"; //$NON-NLS-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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52095 ] Brett Porter commented on MNG-678: -- has anyone tried using IP addresses instead of host names to see if it helps? I didn't think that was related. > scp intermittently failing deploying artifact > - > > Key: MNG-678 > URL: http://jira.codehaus.org/browse/MNG-678 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0-alpha-3 > Environment: JDK 1.5, Red Hat 9 > Reporter: Joe Futrelle > Assignee: Brett Porter > Fix For: 2.0.1 > > > Some of the time, deploying artifacts fails during the scp transfer. The > bottom of the stack trace is reproduced below. If I run the m2 deploy enough > times, it succeeds; not sure why. > This is not an unknown issue with Jsch; apparently client code can cause > behavior like this if it doesn't dispose of connections properly. Possibly a > plugin that's runs before the deploy phase is messing up the connection state > somehow? > Caused by: org.apache.maven.wagon.TransferFailedException: Error occured > while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' > to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) > ... 17 more > Caused by: com.jcraft.jsch.JSchException: session is down > at com.jcraft.jsch.Channel.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) > ... 20 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-710) Add ability to fork the maven-compiler-plugin
[ http://jira.codehaus.org/browse/MNG-710?page=comments#action_52094 ] Brett Porter commented on MNG-710: -- Mark - yes. But what do you mean "will"? > Add ability to fork the maven-compiler-plugin > - > > Key: MNG-710 > URL: http://jira.codehaus.org/browse/MNG-710 > Project: Maven 2 > Type: Improvement > Reporter: Rod Coffin > Assignee: Trygve Laugstol > Fix For: 2.0-beta-1 > Attachments: maven-compiler-plugin.diff.txt, > maven-compiler-plugin.diff3.txt, plexus-compiler-api.diff.txt, > plexus-compiler-api.diff3.txt, plexus-compiler-javac.diff.txt, > plexus-compiler-javac.diff2.txt, plexus-compiler-javac.diff3.txt > > > Add the ability to fork the maven-compiler-plugin. This would allow projects > to be compiled with a JDK other than the one used to run Maven from. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
using votes
Hi, Just following a thread on the users list about whether we use votes for determining priorities. I've never used it as they were generally low, though that's possibly a chicken and egg problem. I've also never really focused on it because basically we schedule everything and do it in an appropriate release. Votes for scheduled issues are unlikely to change whether it gets done - though now we are starting to see a lot more issues unscheduled, so it may be a better way of gauging priorities. We would need to promote their use more, and that in turn could encourage less duplicates as filing a duplicate instead of voting dilutes its priority. Thoughts? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1471) Module paths for system scope are relative to parent pom instead of its own
[ http://jira.codehaus.org/browse/MNG-1471?page=comments#action_52092 ] Brett Porter commented on MNG-1471: --- systemPath was only intended for use in finding system libraries. This was for two specific purposes: - location of Java system libraries (tools.jar, for example). We hope to have this handled by specification dependencies - location of system libraries in a native build. This now can be handled by custom resolvers Aside from that, its use was originally going to be omitted so it will be discouraged going forward. > Module paths for system scope are relative to parent pom instead of its own > --- > > Key: MNG-1471 > URL: http://jira.codehaus.org/browse/MNG-1471 > Project: Maven 2 > Type: Bug > Components: maven-compiler-plugin > Versions: 2.0 > Environment: Win XP, Maven 2.0 > Reporter: Jeff Jensen > Assignee: John Casey > Priority: Critical > Fix For: 2.0.1 > Attachments: MNG-1471-maven-project.patch > > Original Estimate: 30 minutes > Remaining: 30 minutes > > When building from the parent POM dir, all paths are relative to it. A > problem occurs when its modules have dependencies of system - > the module's corresponding is relative to the parent POM dir, > instead of the module's POM dir. > With a module's set to compile correctly it on its own, > compiling from its parent POM dir gives this error: > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > GroupId: thegrp > ArtifactId: subsystem > Version: 2.1-SNAPSHOT > Reason: System artifact: thegrp:subsystem:jar:2.1-SNAPSHOT not found in > path: src\lib\subsystem.jar > thegrp:subsystem:2.1-SNAPSHOT:jar > (would be nice to have the fully qualified path name listed there, instead of > the relative one so users would know where it is really looking for it > from) > Expected behavior is that Maven treats system scope paths relative to the > module POM, not the parent's POM. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - checkout] Sun Nov 27 00:15:01 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051127.001501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051127.001501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-232) DWR POM should list dependencies as optional
[ http://jira.codehaus.org/browse/MEV-232?page=comments#action_52091 ] Julien Dubois commented on MEV-232: --- Matt, the Maven 2 pom is still under testing, so : 1- If you want to use the Maven 1 project.xml (for DWR 1.0), you can use my own list of exclusions from here : http://cvs.sourceforge.net/viewcvs.py/tudu/tudu/pom.xml?rev=1.7&view=markup 2- I'm going to speed up my testing, merge it into the HEAD (it's the 1.0 branch), so that you have a nice clean pom ASAP. 3- If you are ready for it, you can still participate in the making of DWR 1.1 by using our snapshot release I mentioned earlier. It's working fine for Tudu Lists, so it's useable. > DWR POM should list dependencies as optional > > > Key: MEV-232 > URL: http://jira.codehaus.org/browse/MEV-232 > Project: Maven Evangelism > Type: Bug > Components: Invalid POM > Reporter: Matt Raible > > > AFAIK, DWR doesn't require any dependencies at runtime, therefore all it's > dependencies should be marked optional (except servlet which should be > provided). > Current: http://www.ibiblio.org/maven2/uk/ltd/getahead/dwr/1.0/dwr-1.0.pom > Updated: > http://static.appfuse.org/repository/uk/ltd/getahead/dwr/1.0/dwr-1.0.pom -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems preventing the cargo m2 build from working perfectly
Brett Porter wrote: Vincent Massol wrote: Hi, Just a heads up on the progress on the cargo m2 build. Things are progressing but we still have the following annoying issues: * No forking of tests in the surefire plugin. This prevents building all the functional tests. MNG-441 Looking at this now. -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-610) Upload XWork-Spring Integration to central Maven Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-610?page=comments#action_52089 ] Patrick Lightbody commented on MAVENUPLOAD-610: --- My name is Patrick Lightbody and I approve this message. > Upload XWork-Spring Integration to central Maven Repository > --- > > Key: MAVENUPLOAD-610 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-610 > Project: maven-upload-requests > Type: Task > Reporter: Matt Raible > > > Please upload xwork-spring integration bundle for integration WebWork and > Spring in WebWork 2.x. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems preventing the cargo m2 build from working perfectly
Vincent Massol wrote: > Hi, > > Just a heads up on the progress on the cargo m2 build. Things are > progressing but we still have the following annoying issues: > > * No forking of tests in the surefire plugin. This prevents building all the > functional tests. MNG-441 Yes its annoying for all of us. Are you volunteering to help fix it? This is high on my todo list, but I have other things to do. > > * Deploy pluging failing because of scp command "hardcoded" even when using > custom scp and ssh executable. MNG-1587 Got a patch? > > * Deploy plugin failing with "session down" when using scp protocol to > deploy. MNG-678 I saw some discussion today, I'll have a look. I also intend to try the latest jsch release. Unless anyone intends to dig into jsch and fix it, the only alternative is a workaround I think that the original reporter suggested. I'll try it. > > * Custom checkstyle rule configuration not working. MNG-1113 I got no response to " Vincent, what do you think of this patch?". There's still some discussion and I'm afraid I don't understand the issue. > > * maven-one-plugin not on ibiblio nor in any snapshot repository. I'm pretty sure it is as that's how I gave it to Dain to use when I created it. > > * Error when running the assembly plugin as part of a multimodule build. > JIRA issue exists. MNG-1684 Given it is the weekend, not surprising nobody's looked at it. I've scheduled for 2.0.1. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1684) Problem with reactor when using attached goal
[ http://jira.codehaus.org/browse/MNG-1684?page=all ] Brett Porter updated MNG-1684: -- Fix Version: 2.0.1 > Problem with reactor when using attached goal > - > > Key: MNG-1684 > URL: http://jira.codehaus.org/browse/MNG-1684 > Project: Maven 2 > Type: Bug > Components: maven-assembly-plugin > Versions: 2.0 > Reporter: Vincent Massol > Fix For: 2.0.1 > > > Here's my project dir structure: > trunk/ > |_ core/ > |_ api/ > |_ (several projects here) > |_ uberjar/ (assembly project) > |_ samples > |_ testdata > |_ empty-jar > |_ (...) > If I build the trunk/core/ubjerjar project alone it works fine. Note: I have > attached the "attached" goal to the verify phase so the assembly can be > created when calling "mvn install". > If I build the project from the trunk by typing "mvn install", the uberjar/ > project fails saying that the empty-jar artifact cannot be found in the local > repository. That's normal it cannot be found because there are no > dependencies on it in the core/ branch and it hasn't been built yet when the > uberjar project executes. Of course there are no dependencies to it in the > uberjar project. > It seems there's something fishy happening in the assembly plugin > implementation... :-) > 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release maven-one-plugin?
It was on snapshots.maven.codehaus.org like the other snapshots at one point. I assume it still is. I literally put it together in 15 minutes, so I don't know if it is sufficiently tested for a release, but I'll try and take a look at this one. - Brett Vincent Massol wrote: > Hi there, > > Could we release an alpha of the maven-one-plugin plugin? I am using it in > the cargo's build but it's failing the build when people try to build as > it's not available on ibiblio. > > Is it available from an existing repo (I don't mind using a snapshot > version)? > > Also, what's the status about the continuum instance of maven zones running > all projects and making them available in a repo? That would be really the > best for everyone I think. > > Thanks > -Vincent > > > > > > > ___ > Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger > Téléchargez cette version sur http://fr.messenger.yahoo.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-610) Upload XWork-Spring Integration to central Maven Repository
Upload XWork-Spring Integration to central Maven Repository --- Key: MAVENUPLOAD-610 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-610 Project: maven-upload-requests Type: Task Reporter: Matt Raible Please upload xwork-spring integration bundle for integration WebWork and Spring in WebWork 2.x. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (MNG-1430) add j2ee project nature/builders to generated .project file
By the wat, wtp M9 doesn't use the .deployables directory anymore. Don't know if it has a effect on eclipse-plugin and now you can choose easily your project structure so it's quite easy to make it fit the maven way. On 11/26/05, Dan Allen (JIRA) <[EMAIL PROTECTED]> wrote: > [ http://jira.codehaus.org/browse/MNG-1430?page=comments#action_52070 ] > > Dan Allen commented on MNG-1430: > > > Awesome! Good work. I like your idea for the wtpversion. I am assuming to > override the output location, one would just use the > project.build.outputDirectory and set it to .deployables > > > add j2ee project nature/builders to generated .project file > > --- > > > > Key: MNG-1430 > > URL: http://jira.codehaus.org/browse/MNG-1430 > > Project: Maven 2 > > Type: Improvement > > Components: maven-eclipse-plugin > > Versions: 2.0 > > Environment: maven 2.0 on linux > > Reporter: Dan Allen > > Assignee: fabrizio giustina > > Attachments: MNG-1430.txt > > > > > > When the eclipse:eclipse target generates the .project file for a war > > project in maven, the .project file contains only the natures and builders > > for a regular java project. The additional information is as follows for > > WTP 0.71 > > > > > > org.eclipse.wst.common.modulecore.ComponentStructuralBuilder > > > > > > > > > > > > org.eclipse.wst.validation.validationbuilder > > > > > > > > > > > > org.eclipse.wst.common.modulecore.ComponentStructuralBuilderDependen > > > > > > > > > > > > org.eclipse.wst.common.modulecore.DependencyGraphBuilder > > > > > > > > org.eclipse.jem.workbench.JavaEMFNature > > org.eclipse.wst.common.modulecore.ModuleCoreNature > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: >http://jira.codehaus.org/secure/Administrators.jspa > - > For more information on JIRA, see: >http://www.atlassian.com/software/jira > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Alexandre Poitras Québec, Canada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-238) jWebunit 1.2 has invalid artifact/groupId for servletapi
[ http://jira.codehaus.org/browse/MEV-238?page=comments#action_52088 ] Matt Raible commented on MEV-238: - Disregard my last comment - my compilation fails because Struts 1.2.4 doesn't have provided on its servletapi dependency, and my 2.4 version gets overridden with Struts' 2.2 version. > jWebunit 1.2 has invalid artifact/groupId for servletapi > > > Key: MEV-238 > URL: http://jira.codehaus.org/browse/MEV-238 > Project: Maven Evangelism > Type: Bug > Components: Invalid POM > Reporter: Matt Raible > > > Currently is: > > servletapi > servletapi > 2.3 > > Should be: > > javax.servlet > servlet-api > 2.3 > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/26-Nov-2005_04.30.48/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-227) struts 1.2.4 and 1.2.8 dependencies still broken
[ http://jira.codehaus.org/browse/MEV-227?page=comments#action_52087 ] Matt Raible commented on MEV-227: - The one you've sent me looks good Wendy, I'm using it now in my custom repo: http://static.appfuse.org/repository/struts/struts/1.2.4/struts-1.2.4.pom > struts 1.2.4 and 1.2.8 dependencies still broken > > > Key: MEV-227 > URL: http://jira.codehaus.org/browse/MEV-227 > Project: Maven Evangelism > Type: Sub-task > Reporter: denis Cabasson > > > Looks like the dependencies are still broken -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52086 ] Vincent Massol commented on MNG-678: Thanks Bart for helping me on this :-) I have tried your nslookup command on beaver.codehaus.org and it seems to have worked fine (but then I'm no DNS expert): [EMAIL PROTECTED] vmassol]$ nslookup > www.apache.org Server: 127.0.0.1 Address:127.0.0.1#53 Non-authoritative answer: Name: www.apache.org Address: 209.237.227.195 > scp intermittently failing deploying artifact > - > > Key: MNG-678 > URL: http://jira.codehaus.org/browse/MNG-678 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0-alpha-3 > Environment: JDK 1.5, Red Hat 9 > Reporter: Joe Futrelle > Assignee: Brett Porter > Fix For: 2.0.1 > > > Some of the time, deploying artifacts fails during the scp transfer. The > bottom of the stack trace is reproduced below. If I run the m2 deploy enough > times, it succeeds; not sure why. > This is not an unknown issue with Jsch; apparently client code can cause > behavior like this if it doesn't dispose of connections properly. Possibly a > plugin that's runs before the deploy phase is messing up the connection state > somehow? > Caused by: org.apache.maven.wagon.TransferFailedException: Error occured > while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' > to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) > ... 17 more > Caused by: com.jcraft.jsch.JSchException: session is down > at com.jcraft.jsch.Channel.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) > ... 20 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52085 ] Bart Selders commented on MNG-678: -- Sorry, I did speak too quick with possibly the wrong conclusion: DNS on beaver.codehaus.org is likely configured to be not accessible from outside, so my test is not valid. > scp intermittently failing deploying artifact > - > > Key: MNG-678 > URL: http://jira.codehaus.org/browse/MNG-678 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0-alpha-3 > Environment: JDK 1.5, Red Hat 9 > Reporter: Joe Futrelle > Assignee: Brett Porter > Fix For: 2.0.1 > > > Some of the time, deploying artifacts fails during the scp transfer. The > bottom of the stack trace is reproduced below. If I run the m2 deploy enough > times, it succeeds; not sure why. > This is not an unknown issue with Jsch; apparently client code can cause > behavior like this if it doesn't dispose of connections properly. Possibly a > plugin that's runs before the deploy phase is messing up the connection state > somehow? > Caused by: org.apache.maven.wagon.TransferFailedException: Error occured > while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' > to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) > ... 17 more > Caused by: com.jcraft.jsch.JSchException: session is down > at com.jcraft.jsch.Channel.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) > ... 20 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52084 ] Bart Selders commented on MNG-678: -- Vincent, In our case the repository host was failing to execute proper lookups. I just looked at beaver.codehaus.org and it is also failing lookups on its primary DNS server. So that I think the reason for you current problem! Beaver.codehaus.org DNS is not working properly. its /etc/resolv.conf contains: nameserver 127.0.0.1 nameserver 199.212.134.1 nameserver 199.212.134.2 nameserver 64.7.153.49 nameserver 63.246.20.110 and when I try to use beaver to do lookups it won't anser. [EMAIL PROTECTED] ~]$ nslookup > server beaver.codehaus.org Default server: beaver.codehaus.org Address: 64.7.141.17#53 > www.apache.org ;; connection timed out; no servers could be reached > scp intermittently failing deploying artifact > - > > Key: MNG-678 > URL: http://jira.codehaus.org/browse/MNG-678 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0-alpha-3 > Environment: JDK 1.5, Red Hat 9 > Reporter: Joe Futrelle > Assignee: Brett Porter > Fix For: 2.0.1 > > > Some of the time, deploying artifacts fails during the scp transfer. The > bottom of the stack trace is reproduced below. If I run the m2 deploy enough > times, it succeeds; not sure why. > This is not an unknown issue with Jsch; apparently client code can cause > behavior like this if it doesn't dispose of connections properly. Possibly a > plugin that's runs before the deploy phase is messing up the connection state > somehow? > Caused by: org.apache.maven.wagon.TransferFailedException: Error occured > while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' > to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) > ... 17 more > Caused by: com.jcraft.jsch.JSchException: session is down > at com.jcraft.jsch.Channel.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) > ... 20 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems preventing the cargo m2 build from working perfectly
Hi, Just a heads up on the progress on the cargo m2 build. Things are progressing but we still have the following annoying issues: * No forking of tests in the surefire plugin. This prevents building all the functional tests. MNG-441 * Deploy pluging failing because of scp command "hardcoded" even when using custom scp and ssh executable. MNG-1587 * Deploy plugin failing with "session down" when using scp protocol to deploy. MNG-678 * Custom checkstyle rule configuration not working. MNG-1113 * maven-one-plugin not on ibiblio nor in any snapshot repository. * Error when running the assembly plugin as part of a multimodule build. JIRA issue exists. MNG-1684 I'm probably forgetting a few. There are also several other issues but they are minor. Thanks -Vincent ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-238) jWebunit 1.2 has invalid artifact/groupId for servletapi
[ http://jira.codehaus.org/browse/MEV-238?page=comments#action_52083 ] Matt Raible commented on MEV-238: - Here's a strange one - if I set the scope to "provided", even though I have the following in my pom.xml, the servlet-api isn't included and compilation fails. servlet-api javax.servlet 2.4 provided > jWebunit 1.2 has invalid artifact/groupId for servletapi > > > Key: MEV-238 > URL: http://jira.codehaus.org/browse/MEV-238 > Project: Maven Evangelism > Type: Bug > Components: Invalid POM > Reporter: Matt Raible > > > Currently is: > > servletapi > servletapi > 2.3 > > Should be: > > javax.servlet > servlet-api > 2.3 > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release maven-one-plugin?
Hi there, Could we release an alpha of the maven-one-plugin plugin? I am using it in the cargo's build but it's failing the build when people try to build as it's not available on ibiblio. Is it available from an existing repo (I don't mind using a snapshot version)? Also, what's the status about the continuum instance of maven zones running all projects and making them available in a repo? That would be really the best for everyone I think. Thanks -Vincent ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1324) "System" dependencies path non correctly added to eclipse buildpath
[ http://jira.codehaus.org/browse/MNG-1324?page=comments#action_52082 ]
Brill Pappin commented on MNG-1324:
---
What do you mean update the maven-eclipse-plugin?
What should end users do to get this fix in place?
> "System" dependencies path non correctly added to eclipse buildpath
> ---
>
> Key: MNG-1324
> URL: http://jira.codehaus.org/browse/MNG-1324
> Project: Maven 2
> Type: Bug
> Components: maven-eclipse-plugin
> Environment: SVN snapshot a few days old
> Reporter: Giorgio Gallo
> Assignee: fabrizio giustina
>
>
> Eclipse plugin handles as if it was a path into the repository,
> transforming a dependency like this one:
>
>...
> system
> ${basebir}/lib/myjdbcdriver.jar
>
> into
> M2_REPO//lib/myjdbcdriver.jar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52081 ] Vincent Massol commented on MNG-678: Hi Bart, Good catch! The primary DNS provided by my ISP is effectively not responding to pings. I've switched the DNS and the m2 build was able to go futher but it still failed with the same error (just a bit further): [INFO] [deploy:deploy] [INFO] Retrieving previous build number from cargo-snapshot Uploading: scp://beaver.codehaus.org/home/projects/cargo/dist2-snapshot/org/codehaus/cargo/cargo-core-api-util/0.7-SNAPSHOT/cargo- core-api-util-0.7-20051126.195123-1.jar 11K uploaded [INFO] Retrieving previous metadata from cargo-snapshot [INFO] Uploading project information for cargo-core-api-util 0.7-20051126.195123-1 [INFO] Retrieving previous metadata from cargo-snapshot [INFO] Uploading repository metadata for: 'snapshot org.codehaus.cargo:cargo-core-api-util:0.7-SNAPSHOT' [INFO] Retrieving previous metadata from cargo-snapshot [INFO] Uploading repository metadata for: 'artifact org.codehaus.cargo:cargo-core-api-util' [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error installing artifact's metadata: Error while deploying metadata: Error performing commands for file transfer session is down Note: the build was very slow so I still suspect that there were some network latencies happening somewhere (could be beaver.codehaus.org to which I'm dpeloying). All this seems to point to jsch beeing overly sensitive to network conditions. In any case it's not working well enough to be usable right now. Thanks > scp intermittently failing deploying artifact > - > > Key: MNG-678 > URL: http://jira.codehaus.org/browse/MNG-678 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0-alpha-3 > Environment: JDK 1.5, Red Hat 9 > Reporter: Joe Futrelle > Assignee: Brett Porter > Fix For: 2.0.1 > > > Some of the time, deploying artifacts fails during the scp transfer. The > bottom of the stack trace is reproduced below. If I run the m2 deploy enough > times, it succeeds; not sure why. > This is not an unknown issue with Jsch; apparently client code can cause > behavior like this if it doesn't dispose of connections properly. Possibly a > plugin that's runs before the deploy phase is messing up the connection state > somehow? > Caused by: org.apache.maven.wagon.TransferFailedException: Error occured > while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' > to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) > ... 17 more > Caused by: com.jcraft.jsch.JSchException: session is down > at com.jcraft.jsch.Channel.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) > ... 20 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1691) [maven-par-plugin] NPE in ParMojo.java
[maven-par-plugin] NPE in ParMojo.java -- Key: MNG-1691 URL: http://jira.codehaus.org/browse/MNG-1691 Project: Maven 2 Type: Bug Components: Sandbox Reporter: Tim Kettler Attachments: maven-par-plugin.patch Same problem as described in MNG-1690. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1690) [maven-ejb3-plugin] NPE in EJB3Mojo.java
[maven-ejb3-plugin] NPE in EJB3Mojo.java Key: MNG-1690 URL: http://jira.codehaus.org/browse/MNG-1690 Project: Maven 2 Type: Bug Components: Sandbox Reporter: Tim Kettler Attachments: maven-ejb3-plugin.patch running mvn package fails with: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error assembling EJB3 [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling EJB3 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:544) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error assembling EJB3 at org.apache.maven.plugin.ejb3.Ejb3Mojo.execute(Ejb3Mojo.java:146) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) ... 16 more Caused by: java.lang.NullPointerException at org.apache.maven.plugin.ejb3.Ejb3Mojo.execute(Ejb3Mojo.java:136) ... 18 more A look at the source shows that the archiver is never initialized. The attached patch initializes the archiver with a JarArchiver. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1689) Only print relocation warnings in standard output for the current pom
Only print relocation warnings in standard output for the current pom - Key: MNG-1689 URL: http://jira.codehaus.org/browse/MNG-1689 Project: Maven 2 Type: Improvement Components: Logging Versions: 2.0 Reporter: Carlos Sanchez Fix For: 2.0.1 Relocation warnings of transitive dependencies shouldn't be printed in standard output because people gets confused, ask questions and try to change other people poms although they work correctly We should only print the warnings of the current pom so the author can improve it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-231) OJB should list commons-dbcp as a dependency
[ http://jira.codehaus.org/browse/MEV-231?page=comments#action_52080 ] Carlos Sanchez commented on MEV-231: >From Thomas Dudziak here is the list for current OJB 1.0.4rc, 1.0.3 shouldn't be too different: Necessary: commons-beanutils-1.7.0.jar commons-collections-3.1.jar commons-dbcp-1.2.1.jar commons-lang-2.0.jar commons-logging-1.0.4.jar commons-pool-1.2.jar For ODMG/JDO Api: antlr-2.7.5.jar jdo.jar jdori.jar jdori-enhancer.jar Optional: asm.jar (1.5.3) cglib-2.1.jar commons-transaction-1.1.jar log4j-1.2.8.jar jcs.jar (1.0 dev, but should work with newer) p6spy-1.3-patched.jar prevayler.jar jakarta-regexp-1.3.jar For compilation: ant-1.6.2.jar ant-junit-1.6.2.jar ant-launcher-1.6.2.jar ant-swing-1.6.2.jar ant-trax-1.6.2.jar geronimo-spec-jta-1.0.1B-rc2.jar geronimo-spec-servlet-2.4-rc2.jar geronimo-spec-j2ee-1.4-rc2.jar hsqldb.jar (1.8) junit.jar (3.8.1) torque-gen-3.1.1.jar velocity-1.3.1.jar village-2.0-dev-20030825.jar xalan.jar xdoclet-1.2.3.jar xdoclet-ojb-module-1.2.3.jar xercesImpl.jar xjavadoc-1.1.jar xml-apis.jar > OJB should list commons-dbcp as a dependency > > > Key: MEV-231 > URL: http://jira.codehaus.org/browse/MEV-231 > Project: Maven Evangelism > Type: Bug > Components: Invalid POM > Reporter: Matt Raible > Assignee: Edwin Punzalan > > > This POM works much better than the one at: > http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.3/db-ojb-1.0.3.pom > > 4.0.0 > ojb > db-ojb > 1.0.3 > > > > commons-dbcp > commons-dbcp > 1.2 > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-232) DWR POM should list dependencies as optional
[ http://jira.codehaus.org/browse/MEV-232?page=comments#action_52079 ] Matt Raible commented on MEV-232: - The servletapi dependency needs updating as well - to prevent warnings when using Maven 2's Ant Tasks. It should use the new group/artifactId's, as well as set the scope to provided. javax.servlet servlet-api 2.3 provided > DWR POM should list dependencies as optional > > > Key: MEV-232 > URL: http://jira.codehaus.org/browse/MEV-232 > Project: Maven Evangelism > Type: Bug > Components: Invalid POM > Reporter: Matt Raible > > > AFAIK, DWR doesn't require any dependencies at runtime, therefore all it's > dependencies should be marked optional (except servlet which should be > provided). > Current: http://www.ibiblio.org/maven2/uk/ltd/getahead/dwr/1.0/dwr-1.0.pom > Updated: > http://static.appfuse.org/repository/uk/ltd/getahead/dwr/1.0/dwr-1.0.pom -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-238) jWebunit 1.2 has invalid artifact/groupId for servletapi
[ http://jira.codehaus.org/browse/MEV-238?page=comments#action_52078 ] Matt Raible commented on MEV-238: - Should also have scope set to "provided". > jWebunit 1.2 has invalid artifact/groupId for servletapi > > > Key: MEV-238 > URL: http://jira.codehaus.org/browse/MEV-238 > Project: Maven Evangelism > Type: Bug > Components: Invalid POM > Reporter: Matt Raible > > > Currently is: > > servletapi > servletapi > 2.3 > > Should be: > > javax.servlet > servlet-api > 2.3 > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-238) jWebunit 1.2 has invalid artifact/groupId for servletapi
jWebunit 1.2 has invalid artifact/groupId for servletapi Key: MEV-238 URL: http://jira.codehaus.org/browse/MEV-238 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible Currently is: servletapi servletapi 2.3 Should be: javax.servlet servlet-api 2.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPCLOVER-50) Add support for span
[ http://jira.codehaus.org/browse/MPCLOVER-50?page=comments#action_52077 ] Vincent Massol commented on MPCLOVER-50: Hi Matt, Sure please submit a patch and I'll apply it (make sure you also patch the documentation). Thanks > Add support for span > > > Key: MPCLOVER-50 > URL: http://jira.codehaus.org/browse/MPCLOVER-50 > Project: maven-clover-plugin > Type: Improvement > Versions: 1.10 > Reporter: Matt Read > Priority: Minor > > > Would it be possible add support for the span attribute of the appropriate > ant tasks? Currently I modify plugin.jelly each time I upgrade to a new > version by adding span="5h" to all the tags and the > tag. > The reason being my Maven project delegates out to a number of legacy ant > scripts, each of which may run a clover-enabled task. Without the addition of > the span attribute, the reports do not include all of the results I want. > If you want me to supply a patch to the plugin then please let me know. > Matt. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPECLIPSE-108) Scope system in dependencies not supported
[ http://jira.codehaus.org/browse/MPECLIPSE-108?page=all ]
fabrizio giustina closed MPECLIPSE-108:
---
Assign To: fabrizio giustina
Resolution: Duplicate
Fix Version: 1.10
this is related to the M2 eclipse plugin and it has already been fixed in SVN
time ago. The patched EclipseClasspathWriter.java is pretty old, be sure to
checkout the code from trunk when posting patches.
> Scope system in dependencies not supported
> --
>
> Key: MPECLIPSE-108
> URL: http://jira.codehaus.org/browse/MPECLIPSE-108
> Project: maven-eclipse-plugin
> Type: Bug
> Environment: Maven2-maven-eclipse-plugin 2.0-beta-2 + Windows XP
> Reporter: J-C
> Assignee: fabrizio giustina
> Fix For: 1.10
> Attachments: EclipseClasspathWriter.java
>
>
> In my pom.xml, I have a dependency:
>
> javax.persistence
> ejb
> system
> 3.0
>
>
> ${jboss.deploy}/ejb3.deployer/ejb3-persistence.jar
>
>
> With scope sytem, in .classpath file, a lib shoud be generated insted of a
> var.
> To fix that see EclipseClasspathWriter.addDependency in attachment.
> //
> //path = "M2_REPO/" //$NON-NLS-1$
> //+ EclipseUtils.toRelativeAndFixSeparator(
> // localRepositoryFile, fullPath, false);
> //MODIF///
> if
> (Artifact.SCOPE_SYSTEM.equalsIgnoreCase(artifact.getScope())) {
> path = EclipseUtils.toRelativeAndFixSeparator(
> localRepositoryFile, fullPath,
> false);
> kind = "lib"; //$NON-NLS-1$
> } else {
> path = "M2_REPO/" //$NON-NLS-1$
> +
> EclipseUtils.toRelativeAndFixSeparator(
>
> localRepositoryFile, fullPath, false);
> kind = "var"; //$NON-NLS-1$
> }
> //
> //END MODIF///
> .
> /// REMOVED
> /// kind = "var"; //$NON-NLS-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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/26-Nov-2005_12.30.55/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1412) .classpath should have nearest order
[ http://jira.codehaus.org/browse/MNG-1412?page=all ] fabrizio giustina closed MNG-1412: -- Resolution: Won't Fix Please reopen the issue if you can find a valid reason why this kind of order is needed; in the meanwhile I'm closing the issue since the order actually used for the eclipse classpath is the same order used by maven during compilation and IMHO this is definitively the correct behaviour. > .classpath should have nearest order > > > Key: MNG-1412 > URL: http://jira.codehaus.org/browse/MNG-1412 > Project: Maven 2 > Type: Bug > Components: maven-eclipse-plugin > Versions: 2.0 > Reporter: Mark Hobson > Assignee: fabrizio giustina > > > The .classpath file entries should be ordered by nearest transitiveness (if > that's a word). > For example, I have project A that depends on B that depends on C. The > classpath for A is generated in the order C, B. Ideally the classpath should > be in order of how near they are to the project, i.e. B, C. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=all ] fabrizio giustina closed MNG-1605: -- Assign To: fabrizio giustina Resolution: Won't Fix > But when you say "remote" repository, do you mean anything other then the > local cache? anything other than the (single) local repository specified in settings.xml. Since you agree on the current solution I close this issue as fixed. A new version of the plugin with the fixed download flag will be out ASAP, in the meanwhile you can install the version currently in SVN by running: svn checkout http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin maven-eclipse-plugin cd maven-eclipse-plugin mvn install > Allow eclipse source to be specified at the dependency level > > > Key: MNG-1605 > URL: http://jira.codehaus.org/browse/MNG-1605 > Project: Maven 2 > Type: New Feature > Components: maven-eclipse-plugin > Versions: 2.0 > Reporter: Barry Kaplan > Assignee: fabrizio giustina > > > Many (most?) projects do not have sources uploaded. And in any case, most > projects only need a small subset of the sources. Source downloading, even > (especially?) for sources that don't exist, is very time consuming. > Therefore, it would be nice to specify this eclipse plugin specific option as > the dependency level. Maybe something like: > > backport-util-concurrent > backport-util-concurrent > 2.0_01_pd > runtime > > > > > (For this to be general, it would of course require a much different model > than the simple plugin-level property injection. ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPECLIPSE-108) Scope system in dependencies not supported
Scope system in dependencies not supported
--
Key: MPECLIPSE-108
URL: http://jira.codehaus.org/browse/MPECLIPSE-108
Project: maven-eclipse-plugin
Type: Bug
Environment: Maven2-maven-eclipse-plugin 2.0-beta-2 + Windows XP
Reporter: J-C
Attachments: EclipseClasspathWriter.java
In my pom.xml, I have a dependency:
javax.persistence
ejb
system
3.0
${jboss.deploy}/ejb3.deployer/ejb3-persistence.jar
With scope sytem, in .classpath file, a lib shoud be generated insted of a var.
To fix that see EclipseClasspathWriter.addDependency in attachment.
//
//path = "M2_REPO/" //$NON-NLS-1$
//+ EclipseUtils.toRelativeAndFixSeparator(
// localRepositoryFile, fullPath, false);
//MODIF///
if
(Artifact.SCOPE_SYSTEM.equalsIgnoreCase(artifact.getScope())) {
path = EclipseUtils.toRelativeAndFixSeparator(
localRepositoryFile, fullPath,
false);
kind = "lib"; //$NON-NLS-1$
} else {
path = "M2_REPO/" //$NON-NLS-1$
+
EclipseUtils.toRelativeAndFixSeparator(
localRepositoryFile, fullPath, false);
kind = "var"; //$NON-NLS-1$
}
//
// END MODIF///
.
/// REMOVED
/// kind = "var"; //$NON-NLS-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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=comments#action_52072 ] Barry Kaplan commented on MNG-1605: --- If [in the non-broke state] the sources will be used if they exists even without the flag, then running with the flag once in a while should be fine. Much simpler than adding dependency-level complexity, and agree with the "wont-fix". But when you say "remote" repository, do you mean anything other then the local cache? Or are repositories explictly defined considered non-remote also? > Allow eclipse source to be specified at the dependency level > > > Key: MNG-1605 > URL: http://jira.codehaus.org/browse/MNG-1605 > Project: Maven 2 > Type: New Feature > Components: maven-eclipse-plugin > Versions: 2.0 > Reporter: Barry Kaplan > > > Many (most?) projects do not have sources uploaded. And in any case, most > projects only need a small subset of the sources. Source downloading, even > (especially?) for sources that don't exist, is very time consuming. > Therefore, it would be nice to specify this eclipse plugin specific option as > the dependency level. Maybe something like: > > backport-util-concurrent > backport-util-concurrent > 2.0_01_pd > runtime > > > > > (For this to be general, it would of course require a much different model > than the simple plugin-level property injection. ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1430) add j2ee project nature/builders to generated .project file
[ http://jira.codehaus.org/browse/MNG-1430?page=comments#action_52070 ] Dan Allen commented on MNG-1430: Awesome! Good work. I like your idea for the wtpversion. I am assuming to override the output location, one would just use the project.build.outputDirectory and set it to .deployables > add j2ee project nature/builders to generated .project file > --- > > Key: MNG-1430 > URL: http://jira.codehaus.org/browse/MNG-1430 > Project: Maven 2 > Type: Improvement > Components: maven-eclipse-plugin > Versions: 2.0 > Environment: maven 2.0 on linux > Reporter: Dan Allen > Assignee: fabrizio giustina > Attachments: MNG-1430.txt > > > When the eclipse:eclipse target generates the .project file for a war project > in maven, the .project file contains only the natures and builders for a > regular java project. The additional information is as follows for WTP 0.71 > > > org.eclipse.wst.common.modulecore.ComponentStructuralBuilder > > > > > > org.eclipse.wst.validation.validationbuilder > > > > > > org.eclipse.wst.common.modulecore.ComponentStructuralBuilderDependen > > > > > > org.eclipse.wst.common.modulecore.DependencyGraphBuilder > > > > org.eclipse.jem.workbench.JavaEMFNature > org.eclipse.wst.common.modulecore.ModuleCoreNature -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPECLIPSE-60) Downloading source zips
[ http://jira.codehaus.org/browse/MPECLIPSE-60?page=all ]
fabrizio giustina updated MPECLIPSE-60:
---
Fix Version: (was: 1.9)
> Downloading source zips
> ---
>
> Key: MPECLIPSE-60
> URL: http://jira.codehaus.org/browse/MPECLIPSE-60
> Project: maven-eclipse-plugin
> Type: New Feature
> Versions: 1.9
> Reporter: Krystian Nowak
> Attachments: plugin.jelly.patch
>
> Original Estimate: 30 minutes
> Remaining: 30 minutes
>
> I've attached plugin.jelly for maven-eclipse-plugin downloading sources from
> ${repo}/${groupId}/src/${artifactId}-${version}.zip and installing it as
> ${maven.repo.local}/${groupId}/src/${artifactId}-${version}.zip.
> It does it for all jar dependencies having eclipse.source property set to
> true. Example project.xml:
> (...)
>
>
> junit
> junit
> 3.8.1
> http://www.junit.org/
>
> true
>
>
>
> (...)
> What you have to do now is to call "maven eclipse" and refresh your project
> in Eclipse.
> And here is the code of plugin.jelly - a patch made in Eclipse:
> Index: plugin.jelly
> ===
> RCS file: /home/cvspublic/maven-plugins/eclipse/plugin.jelly,v
> retrieving revision 1.31
> diff -u -r1.31 plugin.jelly
> --- plugin.jelly 16 Nov 2004 10:48:15 - 1.31
> +++ plugin.jelly 6 Dec 2004 08:10:33 -
> @@ -78,7 +78,8 @@
>
>
>
> -description="Generate Eclipse .classpath file">
> +description="Generate Eclipse .classpath file"
> +prereqs="eclipse:sources:download">
>
> Creating ${basedir}/.classpath ...
> xmlns="dummy">
> @@ -263,5 +264,73 @@
>
> Cleaned up eclipse generated files
>
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + test="${depItem.getType().equalsIgnoreCase('jar')}">
> + test="${depItem.getProperty('eclipse.source') == 'true'}">
> + value="${depItem.getGroupId()}"/>
> + value="${depItem.getArtifactId()}"/>
> + value="${depItem.getVersion()}"/>
> + name="eclipse:source:download"/>
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + Checking sources for ${groupId}:${artifactId}
> ver.${version}
> + name="${maven.repo.local}/${groupId}/src/${artifactId}-${version}.zip" />
> +
> +
> + ${maven.repo.remote}
> + delim=",">${repoList.trim()}
> +
> + repo is '${repo}'
> + value="${repo}/${groupId}/src/${artifactId}-${version}.zip" />
> + trying to download ${remoteFile}
> +
> +className="org.apache.maven.util.HttpUtils">
> + value="${remoteFile}" />
> +
> +
> +
> + value="${maven.proxy.host}" />
> + value="${maven.proxy.port}" />
> + value="${maven.proxy.username}" />
> + value="${maven.proxy.password}" />
> +
> +
> +
> +
> +
> +
> +
> + WARN: Could not download sources for
> ${groupId}:${artifactId} ver.${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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPECLIPSE-84) PATCH - Add project name prefix for working with multiple versions of artifact.
[ http://jira.codehaus.org/browse/MPECLIPSE-84?page=all ]
fabrizio giustina updated MPECLIPSE-84:
---
Fix Version: (was: 1.10)
> PATCH - Add project name prefix for working with multiple versions of
> artifact.
> ---
>
> Key: MPECLIPSE-84
> URL: http://jira.codehaus.org/browse/MPECLIPSE-84
> Project: maven-eclipse-plugin
> Type: New Feature
> Versions: 1.10
> Environment: Maven 1.0.2 and Eclipse (OS neutral)
> Reporter: Joakim Erdfelt
> Priority: Minor
> Attachments: eclipse-plugin-prefix.diff
>
>
> The maven-eclipse-plugin creates a .project file with a name of
> ${pom.artifactId}, which is fine if working with a single version of that
> single project, but when working on multiple version (maintenance on an old
> version, bug fixing current release, and active research on a future release)
> then that simple of a name makes things confusing in eclipse.
> The patch (hopefully attached) will allow for a maven.eclipse.project.prefix
> variable that will prepend some text to the project name to allow for eclipse
> to have multiple versions of the same project loaded.
> Ideally, this approach would also allow for a multiproject ecilpse generation
> with all of the projects having the same prefix (since Eclipse sorts the
> projects by name, this would have the effect of grouping all of those related
> multiprojects together)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPECLIPSE-69) Make plugin work better "out of the box"
[ http://jira.codehaus.org/browse/MPECLIPSE-69?page=all ]
fabrizio giustina updated MPECLIPSE-69:
---
Fix Version: (was: 1.9)
> Make plugin work better "out of the box"
>
>
> Key: MPECLIPSE-69
> URL: http://jira.codehaus.org/browse/MPECLIPSE-69
> Project: maven-eclipse-plugin
> Type: Improvement
> Versions: 1.9
> Reporter: Chad Woolley
> Attachments: maven_eclipse_plugin_patch.txt
>
>
> Hi,
> Attached is a patch which makes the following changes to the
> eclipse:external-tools-21 goal:
> 1. Makes default action to run goal against project.xml in the current
> project.
> 2. Makes default to refresh project containing the selected resource
> 3. Removes code to add each entry to favorites list, because they fill up the
> list and makes user have to scroll to see the bottom of the external tools
> menu.
> I think these would be much more intuitive and convenient defaults for the
> majority of the plugin users.
> Thanks,
> Chad
> Index: eclipse/src/plugin-resources/templates/launch.jelly
> ===
> RCS file:
> /home/cvspublic/maven-plugins/eclipse/src/plugin-resources/templates/launch.jelly,v
> retrieving revision 1.4
> diff -u -r1.4 launch.jelly
> --- eclipse/src/plugin-resources/templates/launch.jelly 4 Mar 2004
> 18:04:37 - 1.4
> +++ eclipse/src/plugin-resources/templates/launch.jelly 1 Feb 2005
> 06:55:58 -
> @@ -19,13 +19,17 @@
>
> type="org.eclipse.ui.externaltools.ProgramLaunchConfigurationType">
> -key="org.eclipse.ui.externaltools.ATTR_TOOL_ARGUMENTS" value="-e -p
> $${resource_name} ${goal}"/>
> +key="org.eclipse.ui.externaltools.ATTR_TOOL_ARGUMENTS" value="-e -p
> project.xml ${goal}"/>
>key="org.eclipse.ui.externaltools.ATTR_REFRESH_SCOPE"
> value="$${project}"/>
> + +key="org.eclipse.debug.core.ATTR_REFRESH_SCOPE" value="$${project}"/>
> +
> -key="org.eclipse.ui.externaltools.ATTR_WORKING_DIRECTORY"
> value="$${container_loc}"/>
> +key="org.eclipse.ui.externaltools.ATTR_WORKING_DIRECTORY"
> value="$${project_loc}"/>
> value="${tool.loc}"/>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPECLIPSE-104) Improve JRE_CONTAINER classpath entry
[ http://jira.codehaus.org/browse/MPECLIPSE-104?page=all ] fabrizio giustina updated MPECLIPSE-104: Fix Version: (was: 1.10) > Improve JRE_CONTAINER classpath entry > - > > Key: MPECLIPSE-104 > URL: http://jira.codehaus.org/browse/MPECLIPSE-104 > Project: maven-eclipse-plugin > Type: Improvement > Versions: 1.9 > Environment: Windows XP, JDK 1.5 > Reporter: Holger Hoffstätte > > > Situation: Sun's jaxrpc has a QName class but also put out a fix jar with an > update to make that class compatible with JDK 1.5. In mule we missed out on > the patch jar but since the .classpath generated by maven-eclipse-plugin-1.9 > references the JRE_CONTAINER ahead of other jars, people who used JDK 1.5 for > development missed this since a working QName was found when it really should > not have been (correctly raising an error caused by the 'bad' class and the > lack of the patch jar instead). > Solution and proposed fix: move the JRE_CONTAINER to the end of the > dependency list, after the j:forEach block that follows in the current > version. > IMHO the JRE_CONTAINER should *always* come last. This is unlikely to cause > problems because you cannot accidentally override essential classes (e.g. > java.lang), but it is essential when you do want to handle optional packages > correctly (say a working QName or JMX). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPECLIPSE-88) allow relative paths for overriden jars
[ http://jira.codehaus.org/browse/MPECLIPSE-88?page=all ]
fabrizio giustina updated MPECLIPSE-88:
---
Fix Version: (was: 1.10)
> allow relative paths for overriden jars
> ---
>
> Key: MPECLIPSE-88
> URL: http://jira.codehaus.org/browse/MPECLIPSE-88
> Project: maven-eclipse-plugin
> Type: Improvement
> Versions: 1.9
> Environment: All
> Reporter: Guido Schreuder
> Priority: Trivial
>
> Original Estimate: 5 minutes
> Remaining: 5 minutes
>
> Please consider the following;
> A very small change will allow for jars to be kept inside your project folders
> without hardcoded paths ending up in your Eclipse .classpath file.
> Excuse me for the format, but i've no diff available at the moment
> in file templates/classpath.jelly, near the end change the following
> Old:
>
>
>
> New:
>
>path="${lib.path}" separator="/"/>
>
>
> will leave the path as it is not relative to
> "basedir"
> kind regards,
> Guido
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPECLIPSE-105) Ability to add projects of local group to build path
[ http://jira.codehaus.org/browse/MPECLIPSE-105?page=all ] fabrizio giustina updated MPECLIPSE-105: Fix Version: (was: 1.9) > Ability to add projects of local group to build path > > > Key: MPECLIPSE-105 > URL: http://jira.codehaus.org/browse/MPECLIPSE-105 > Project: maven-eclipse-plugin > Type: Improvement > Versions: 1.9 > Reporter: Rodion Zhitomirsky > Attachments: PATCH > > > We are using eclipse and maven for our internal project. > Our project is splitted up into multiple semi-independent projects (modules). > So, using repository and maven eclipse plugin we were able to work. However, > there is still one important feature of Eclipse that is not available anymore > after we swtiched to maven: sources of different projects got decoupled and > you can not search, for instance, for references to some class or method. > This could be only fixed by adding referencing projects' source code from > other projects. > So, I decided to write a patch for this. > The point is: during generation of .classpath plugin behaves as usually, with > an exception of cases, where groupId is the same as > maven.eclipse.localgroupid. For this case there will be an additional > classpathentry with reference to project. > Hope, my patch explains more then this text (it is a little bit mixed :). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPECLIPSE-103) Allow to skip dependencies from being included in .classpath file
[ http://jira.codehaus.org/browse/MPECLIPSE-103?page=all ] fabrizio giustina closed MPECLIPSE-103: --- Assign To: fabrizio giustina Resolution: Won't Fix Fix Version: 1.9 > In my project, we generate some enumerations using Castor (using xerces-2.4). > The generated > code is completely independent of XML or Castor. If I understood correclty, you added the castor dependency in order to generate source code: the castor dependency, however, should not be a project dependency but a plugin dependency. For example this should work if you are using the maven castor plugin at http://maven.apache.org/maven-1.x/reference/plugins/castor/index.html (do you?). If you are using a custom ant task you will need castor and xerces in the classpath, but this is not the recommended way. First of all, castor will be in the classpath used by maven when executing tests, and this is the same situation you are seeing in eclipse (so, it SHOULD fail in eclipse if it fails with maven). As a solution you should: - use a plugin to generate sources and, if such plugin doesn't exist, extract your code from maven.xml and put it in a plugin (recommended) - manually modify the classpath before calling the ant task used to generate sources, removing the castor jar from project.xml > Allow to skip dependencies from being included in .classpath file > - > > Key: MPECLIPSE-103 > URL: http://jira.codehaus.org/browse/MPECLIPSE-103 > Project: maven-eclipse-plugin > Type: New Feature > Versions: 1.9 > Reporter: Werner Schulz > Assignee: fabrizio giustina > Fix For: 1.9 > > > Need a means to specify that some maven dependencies are NOT included in the > generated .classpath file. > Reason: Maven builds a project. This may include generating source via > castor, InjectJ, etc. > Once the source code is generated, the generated source may not depend on the > various jars that helped generate it. > That means, the Eclipse project should not depend on these jars. Currently, > it is not possible to exclude these jars. > Can you add an additional property, like > no, which will > not add the dependency to the generated 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52068 ] Bart Selders commented on MNG-678: -- I "was" also affected by this "session is down" problem. It just started at once, no explanation, while it used to work fine before. For us, it turned out to be a DNS problem: in this case primary DNS server down, the repository server was resolving network addresses using its secondary DNS server. We did not notice it that quick, although some other things did not work as fast as well. After correcting this, everything turned back to normal, and scp deployment works fine again. I am not suggesting that this is the root cause for this issue, but i would at least recommend to investigate your network to see whether there are any network issues known. > scp intermittently failing deploying artifact > - > > Key: MNG-678 > URL: http://jira.codehaus.org/browse/MNG-678 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0-alpha-3 > Environment: JDK 1.5, Red Hat 9 > Reporter: Joe Futrelle > Assignee: Brett Porter > Fix For: 2.0.1 > > > Some of the time, deploying artifacts fails during the scp transfer. The > bottom of the stack trace is reproduced below. If I run the m2 deploy enough > times, it succeeds; not sure why. > This is not an unknown issue with Jsch; apparently client code can cause > behavior like this if it doesn't dispose of connections properly. Possibly a > plugin that's runs before the deploy phase is messing up the connection state > somehow? > Caused by: org.apache.maven.wagon.TransferFailedException: Error occured > while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' > to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) > ... 17 more > Caused by: com.jcraft.jsch.JSchException: session is down > at com.jcraft.jsch.Channel.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) > ... 20 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPECLIPSE-105) Ability to add projects of local group to build path
[ http://jira.codehaus.org/browse/MPECLIPSE-105?page=comments#action_52067 ] fabrizio giustina commented on MPECLIPSE-105: - why the eclipse.dependency in project.xml can't be used in this situation? Just add: true to the dependencies you want to link as project references in eclipse and you should achieve the same result. Is this correct (and so we can close the issue) or I'm missing something? > Ability to add projects of local group to build path > > > Key: MPECLIPSE-105 > URL: http://jira.codehaus.org/browse/MPECLIPSE-105 > Project: maven-eclipse-plugin > Type: Improvement > Versions: 1.9 > Reporter: Rodion Zhitomirsky > Fix For: 1.9 > Attachments: PATCH > > > We are using eclipse and maven for our internal project. > Our project is splitted up into multiple semi-independent projects (modules). > So, using repository and maven eclipse plugin we were able to work. However, > there is still one important feature of Eclipse that is not available anymore > after we swtiched to maven: sources of different projects got decoupled and > you can not search, for instance, for references to some class or method. > This could be only fixed by adding referencing projects' source code from > other projects. > So, I decided to write a patch for this. > The point is: during generation of .classpath plugin behaves as usually, with > an exception of cases, where groupId is the same as > maven.eclipse.localgroupid. For this case there will be an additional > classpathentry with reference to project. > Hope, my patch explains more then this text (it is a little bit mixed :). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1688) Link to source repository broken
[ http://jira.codehaus.org/browse/MNG-1688?page=all ] fabrizio giustina closed MNG-1688: -- Assign To: fabrizio giustina Resolution: Fixed Fixed in SVN and uploaded. > Link to source repository broken > > > Key: MNG-1688 > URL: http://jira.codehaus.org/browse/MNG-1688 > Project: Maven 2 > Type: Bug > Components: maven-eclipse-plugin > Reporter: Jochen Wiedmann > Assignee: fabrizio giustina > > > According to > > http://maven.apache.org/plugins/maven-eclipse-plugin/source-repository.html > the eclipse plugins source can be found at > > http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-plugins/maven-eclipse-plugin > or > > http://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-eclipse-plugin > However, both URL's are obviously broken: There is no directory > "maven-plugins" in components/trunk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-441) surefire plugin needs to be able to fork tests
[ http://jira.codehaus.org/browse/MNG-441?page=comments#action_52064 ] Mark Proctor commented on MNG-441: -- Is that .java and .pom working? If so any chance we could have a surefire snapshot release? We are currently blocked from moving Drools to M2 as maven tests for jython fail if we can't fork. > surefire plugin needs to be able to fork tests > -- > > Key: MNG-441 > URL: http://jira.codehaus.org/browse/MNG-441 > Project: Maven 2 > Type: Improvement > Components: maven-surefire-plugin > Reporter: Brett Porter > Fix For: 2.0.1 > Attachments: SurefirePlugin.java, pom.xml > > > they can leak memory, so a "fork once for all" option would be good. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1688) Link to source repository broken
Link to source repository broken Key: MNG-1688 URL: http://jira.codehaus.org/browse/MNG-1688 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Reporter: Jochen Wiedmann According to http://maven.apache.org/plugins/maven-eclipse-plugin/source-repository.html the eclipse plugins source can be found at http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-plugins/maven-eclipse-plugin or http://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-eclipse-plugin However, both URL's are obviously broken: There is no directory "maven-plugins" in components/trunk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1020) Improve JRE_CONTAINER classpath entry
[ http://jira.codehaus.org/browse/MNG-1020?page=all ] fabrizio giustina updated MNG-1020: --- Environment: type: Improvement (was: Bug) > Improve JRE_CONTAINER classpath entry > - > > Key: MNG-1020 > URL: http://jira.codehaus.org/browse/MNG-1020 > Project: Maven 2 > Type: Improvement > Components: maven-eclipse-plugin > Versions: 2.0-beta-1 > Reporter: Mark Hobson > > > Same as MPECLIPSE-104 but for m2, although this only really makes sense for > dependencies in the bootclasspath as only they can override the JRE. Hence > this issue depends on MNG-973. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1604) Boot classpath incomplete in generated .classpath
[ http://jira.codehaus.org/browse/MNG-1604?page=all ] fabrizio giustina closed MNG-1604: -- Assign To: fabrizio giustina Resolution: Fixed Already fixed in svn, javadocs for plugin properties have been updated > Boot classpath incomplete in generated .classpath > - > > Key: MNG-1604 > URL: http://jira.codehaus.org/browse/MNG-1604 > Project: Maven 2 > Type: Bug > Components: maven-eclipse-plugin > Versions: 2.0 > Environment: Eclipse 3.2M3 > Reporter: Jochen Wiedmann > Assignee: fabrizio giustina > > > The .classpath file, which is generated by the maven-eclipse-plugin, > specifies the boot classpath as follows: > sourcepath="JRE_SRC"/> > Unfortunately, this entry doesn't include the complete boot classpath, but > rt.jar only. But a modern JRE's (>= 1.4) boot classpath includes more jar > files, for example jsse.jar, or jce.jar. > Current workaround: Edit the generated .classpath file manually and replace > the above line with > path="org.eclipse.jdt.launching.JRE_CONTAINER"/> > Specifying this container in the classpathContainers property does *not* > work: In that case, Eclipse refuses the generated .classpath file, because it > contains both of the above two lines: The rt.jar file is specified twice. > Suggested solutions: > a) Replace the JRE_LIB line with the container definition. I must admit, > that I have no idea, whether this > works with previous Eclipse versions and which. Side effects seem > possible. > b) Same thing than a), but optional: User must set a certain plugin > property. > c) Check the classpathContainers property: If it does include the > JRE_CONTAINER, then omit > the JRE_LIB line. > I am ready to specify a patch for the plugin, if a developer decides which of > the above solutions is the way to go or has another idea. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1020) Improve JRE_CONTAINER classpath entry
[ http://jira.codehaus.org/browse/MNG-1020?page=comments#action_52061 ] fabrizio giustina commented on MNG-1020: Now you can add optional _container_ classpath in front of the JRE. Just specify a list of container classpath entries with the "org.eclipse.jdt.launching.JRE_CONTAINER" and this list will not be modified. Not sure about allowing project dependencies (jar) before the JRE classpath, since the resulting project will have a classpath different from the one used in maven and the scope of the plugin is to make a maven project usable with eclipse. > Improve JRE_CONTAINER classpath entry > - > > Key: MNG-1020 > URL: http://jira.codehaus.org/browse/MNG-1020 > Project: Maven 2 > Type: Bug > Components: maven-eclipse-plugin > Versions: 2.0-beta-1 > Reporter: Mark Hobson > > > Same as MPECLIPSE-104 but for m2, although this only really makes sense for > dependencies in the bootclasspath as only they can override the JRE. Hence > this issue depends on MNG-973. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/26-Nov-2005_08.30.45/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
plexus and meta component
Hi, Is there a way in plexus to define a meta component without going in endless regression ? role meta meta-component role little-brothers I just need to exclude the role-hint 'meta' in the little-brothers map. Regards. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1648) Use canonical paths in eclipse project files
[ http://jira.codehaus.org/browse/MNG-1648?page=all ] fabrizio giustina closed MNG-1648: -- Assign To: fabrizio giustina Resolution: Fixed fixed in SVN. All the existing tests now works also using cygwin under windows. Also absolute paths returned by maven are converted to canonical paths, and this required many changes to the existing code, please test it and report any issue found. > Use canonical paths in eclipse project files > > > Key: MNG-1648 > URL: http://jira.codehaus.org/browse/MNG-1648 > Project: Maven 2 > Type: Bug > Components: maven-eclipse-plugin > Versions: 2.0 > Reporter: Mark Hobson > Assignee: fabrizio giustina > > > Need to ensure all absolute file paths are moved to canonical paths as > discussed on dev: > http://www.nabble.com/-m2-eclipse-plugin-test-failures-t488244.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1412) .classpath should have nearest order
[ http://jira.codehaus.org/browse/MNG-1412?page=comments#action_52058 ] fabrizio giustina commented on MNG-1412: Is there a reason for this order or it's only a "cosmetic" reason? AFAIK unless you have the same classes in multiple dependencies the order has no effect. > .classpath should have nearest order > > > Key: MNG-1412 > URL: http://jira.codehaus.org/browse/MNG-1412 > Project: Maven 2 > Type: Bug > Components: maven-eclipse-plugin > Versions: 2.0 > Reporter: Mark Hobson > > > The .classpath file entries should be ordered by nearest transitiveness (if > that's a word). > For example, I have project A that depends on B that depends on C. The > classpath for A is generated in the order C, B. Ideally the classpath should > be in order of how near they are to the project, i.e. B, C. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1324) "System" dependencies path non correctly added to eclipse buildpath
[ http://jira.codehaus.org/browse/MNG-1324?page=all ]
fabrizio giustina closed MNG-1324:
--
Resolution: Fixed
this is definitively fixed in the current svn version of the eclipse plugin.
Just try to update the maven-eclipse-plugin dir and install it, it will work.
> "System" dependencies path non correctly added to eclipse buildpath
> ---
>
> Key: MNG-1324
> URL: http://jira.codehaus.org/browse/MNG-1324
> Project: Maven 2
> Type: Bug
> Components: maven-eclipse-plugin
> Environment: SVN snapshot a few days old
> Reporter: Giorgio Gallo
> Assignee: fabrizio giustina
>
>
> Eclipse plugin handles as if it was a path into the repository,
> transforming a dependency like this one:
>
>...
> system
> ${basebir}/lib/myjdbcdriver.jar
>
> into
> M2_REPO//lib/myjdbcdriver.jar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1430) add j2ee project nature/builders to generated .project file
[ http://jira.codehaus.org/browse/MNG-1430?page=all ] fabrizio giustina closed MNG-1430: -- Assign To: fabrizio giustina Resolution: Fixed Committed to svn, with a few changes: - the output dir is always set to "target". This is required for compatibility with users that don't use wtp and WTP can handle it without problems (as you already saw, you can override it as you like and WTP will always use ".deployables") - added a new switch "wtpversion" for forward compatibility. At the moment the plugin will add configuration for wtp R7 only > add j2ee project nature/builders to generated .project file > --- > > Key: MNG-1430 > URL: http://jira.codehaus.org/browse/MNG-1430 > Project: Maven 2 > Type: Improvement > Components: maven-eclipse-plugin > Versions: 2.0 > Environment: maven 2.0 on linux > Reporter: Dan Allen > Assignee: fabrizio giustina > Attachments: MNG-1430.txt > > > When the eclipse:eclipse target generates the .project file for a war project > in maven, the .project file contains only the natures and builders for a > regular java project. The additional information is as follows for WTP 0.71 > > > org.eclipse.wst.common.modulecore.ComponentStructuralBuilder > > > > > > org.eclipse.wst.validation.validationbuilder > > > > > > org.eclipse.wst.common.modulecore.ComponentStructuralBuilderDependen > > > > > > org.eclipse.wst.common.modulecore.DependencyGraphBuilder > > > > org.eclipse.jem.workbench.JavaEMFNature > org.eclipse.wst.common.modulecore.ModuleCoreNature -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1605) Allow eclipse source to be specified at the dependency level
[ http://jira.codehaus.org/browse/MNG-1605?page=comments#action_52055 ] fabrizio giustina commented on MNG-1605: > Source downloading, even (especially?) for sources that don't exist, is very > time consuming. Time consuming only for sources that don't exist in the local repository. Once a source jar has been downloaded, the eclipse plugin will never spend time anymore for checking remote repositories. I don't think adding a dependency-specific flag could be a good solution, the eclipse.downloadSources should remain a global flag. You have the following options: - don't set eclipse.downloadSources to true and only sources in the local repo will be used (note that this is broken in the current release, but it's how it's expected to work) - if you want to download sources for artifact run eclipse:eclipse with eclipse.downloadSources=true once a while. If a source jar is available on the remote repo it will be downloaded, and it will be used in future without the need for additional checks. - You can manually add source jars to your local repositories for dependencies that don't exist in the remote repo. The eclipse plugin will use those and will not try do download them anymore. Also note that recently a good number of source jars have been uploaded to the m2 repository, and the number of sources available is expected to grow. Said that, I would like to close this issue as a won't fix. Other thoughts? > Allow eclipse source to be specified at the dependency level > > > Key: MNG-1605 > URL: http://jira.codehaus.org/browse/MNG-1605 > Project: Maven 2 > Type: New Feature > Components: maven-eclipse-plugin > Versions: 2.0 > Reporter: Barry Kaplan > > > Many (most?) projects do not have sources uploaded. And in any case, most > projects only need a small subset of the sources. Source downloading, even > (especially?) for sources that don't exist, is very time consuming. > Therefore, it would be nice to specify this eclipse plugin specific option as > the dependency level. Maybe something like: > > backport-util-concurrent > backport-util-concurrent > 2.0_01_pd > runtime > > > > > (For this to be general, it would of course require a much different model > than the simple plugin-level property injection. ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52050 ] Vincent Massol commented on MNG-678: FYI, I've just rebuilt m2 from trunk (26 Nov 2005 - 9:33GMT+1) and I still get the "session is down" error message: [...] [INFO] [deploy:deploy] [INFO] Retrieving previous build number from cargo-snapshot [DEBUG] repository metadata for: 'snapshot org.codehaus.cargo:cargo-core-api-util:0.7-SNAPSHOT' could not be found on repository: cargo-snapshot [DEBUG] adding permissions to wagon connection: 664 775 Uploading: scp://beaver.codehaus.org/home/projects/cargo/dist2-snapshot/org/codehaus/cargo/cargo-core-api-util/0.7-SNAPSHOT/cargo- core-api-util-0.7-20051126.083301-1.jar 11K uploaded [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Error performing commands for file transfer session is down [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying artifact: Error performing commands for file transfer at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:544) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying artifact: Error performing commands for file transfer at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:158) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) ... 16 more Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error deploying artifact: Error performing commands for file transfer at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:147) ... 18 more Caused by: org.apache.maven.wagon.TransferFailedException: Error performing commands for file transfer at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:91) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:202) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:77) ... 19 more Caused by: org.apache.maven.wagon.CommandExecutionException: Cannot execute remote command: umask 2 at org.apache.maven.wagon.providers.ssh.AbstractSshWagon.executeCommand(AbstractSshWagon.java:292) at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:81) ... 22 more Caused by: com.jcraft.jsch.JSchException: session is down at com.jcraft.jsch.Channel.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.AbstractSshWagon.executeCommand(AbstractSshWagon.java:279) ... 23 more > scp intermittently failing deploying artifact > - > > Key: MNG-678 > URL: http://jira.codehaus.org/browse/MNG-678 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0-alpha-3 > Environment: JDK 1.5,
