Duplicate dependency with different scopes
Hello, I have a problem with my dependency pattern and I am not sure that maven behaves correctly in this case. Here is my case : - I am using Maven 2.2.1. - I have a project A which defines a dependency D with scope test. - I have a project B whose parent is A and which defines D as a dependency in scope compile. - My project hierarchy defines a lot of projects whose parent is A and who have B as a dependency. My problem is : all these subprojects have D as dependency in scope test (from A). I think that the correct behaviour would be to have D with scope compile (from their dependency on B) because scope compile 'contains' scope test. But Maven 2.2.1 does not work that way :-). Is there any way to force my projects to use the D scope from project B instead of the one from its parent (project A) ? Thanks in avance, -- Signature Graham CROSMARIE RD Engineer Linagora GSO -- www.linagora.com http://www.linagora.com
Re: Duplicate dependency with different scopes
As project A is a parent it's a pom project, right? IMHO a pom project should NEVER have a dependency. Remove that dependency and state that test scope dependency where it actually is a dependency instead. Project A could however have dependencyManagement declared for D stating test as default scope (and version). /Anders On Tue, Jul 17, 2012 at 9:15 AM, Graham Crosmarie graham.crosma...@linagora.com wrote: Hello, I have a problem with my dependency pattern and I am not sure that maven behaves correctly in this case. Here is my case : - I am using Maven 2.2.1. - I have a project A which defines a dependency D with scope test. - I have a project B whose parent is A and which defines D as a dependency in scope compile. - My project hierarchy defines a lot of projects whose parent is A and who have B as a dependency. My problem is : all these subprojects have D as dependency in scope test (from A). I think that the correct behaviour would be to have D with scope compile (from their dependency on B) because scope compile 'contains' scope test. But Maven 2.2.1 does not work that way :-). Is there any way to force my projects to use the D scope from project B instead of the one from its parent (project A) ? Thanks in avance, -- Signature Graham CROSMARIE RD Engineer Linagora GSO -- www.linagora.com http://www.linagora.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Duplicate dependency with different scopes
Thanks for your answer, But somehow I disagree with you : a pom project might have to define dependencies. IMHO defining such a dependency (besides defining its version and scope in the dependency management) is legitimate if all of the projects having this pom as parent should have this dependency. For example our parent pom which is the parent of all our other projects defines Junit as a dependency because we know all of our prejects are going to use Junit. In my case all subprojects of A need D at least in scope test but some of them (which depends on B) appears to 'also' need D in scope compile. On 17/07/2012 09:43, Anders Hammar wrote: As project A is a parent it's a pom project, right? IMHO a pom project should NEVER have a dependency. Remove that dependency and state that test scope dependency where it actually is a dependency instead. Project A could however have dependencyManagement declared for D stating test as default scope (and version). /Anders On Tue, Jul 17, 2012 at 9:15 AM, Graham Crosmarie graham.crosma...@linagora.com wrote: Hello, I have a problem with my dependency pattern and I am not sure that maven behaves correctly in this case. Here is my case : - I am using Maven 2.2.1. - I have a project A which defines a dependency D with scope test. - I have a project B whose parent is A and which defines D as a dependency in scope compile. - My project hierarchy defines a lot of projects whose parent is A and who have B as a dependency. My problem is : all these subprojects have D as dependency in scope test (from A). I think that the correct behaviour would be to have D with scope compile (from their dependency on B) because scope compile 'contains' scope test. But Maven 2.2.1 does not work that way :-). Is there any way to force my projects to use the D scope from project B instead of the one from its parent (project A) ? Thanks in avance, -- Signature Graham CROSMARIE RD Engineer Linagora GSO -- www.linagora.com http://www.linagora.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Signature Graham CROSMARIE RD Engineer Linagora GSO -- www.linagora.com http://www.linagora.com
Re: Duplicate dependency with different scopes
Hi Graham, Graham Crosmarie wrote: Thanks for your answer, But somehow I disagree with you : a pom project might have to define dependencies. IMHO defining such a dependency (besides defining its version and scope in the dependency management) is legitimate if all of the projects having this pom as parent should have this dependency. For example our parent pom which is the parent of all our other projects defines Junit as a dependency because we know all of our prejects are going to use Junit. In my case all subprojects of A need D at least in scope test but some of them (which depends on B) appears to 'also' need D in scope compile. well, Maven gives you, what you have defined. If you define D for all projects directly as scope test, why do you complain at all? - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Duplicate dependency with different scopes
Well, I disagree with you. A pom project doesn't have a dependency. It doesn't have any code and thus no dependencies. Also, based on my experience, there will always be exceptions to the rule all children will have this dependency. A very common one is thinking that all children will have a junit test dependency. Sounds reasonable in the beginning, but what happens when you have an API module? This one is very unlikely to have any tests as it only includes interfaces (or possibly very simple classes). And then it will get an incorrect dependency. Sure, an extra test scope dependency will not affect any project having a dependency, but this is still an incorrect dependency. /Anders On Tue, Jul 17, 2012 at 10:57 AM, Graham Crosmarie graham.crosma...@linagora.com wrote: Thanks for your answer, But somehow I disagree with you : a pom project might have to define dependencies. IMHO defining such a dependency (besides defining its version and scope in the dependency management) is legitimate if all of the projects having this pom as parent should have this dependency. For example our parent pom which is the parent of all our other projects defines Junit as a dependency because we know all of our prejects are going to use Junit. In my case all subprojects of A need D at least in scope test but some of them (which depends on B) appears to 'also' need D in scope compile. On 17/07/2012 09:43, Anders Hammar wrote: As project A is a parent it's a pom project, right? IMHO a pom project should NEVER have a dependency. Remove that dependency and state that test scope dependency where it actually is a dependency instead. Project A could however have dependencyManagement declared for D stating test as default scope (and version). /Anders On Tue, Jul 17, 2012 at 9:15 AM, Graham Crosmarie graham.crosma...@linagora.com wrote: Hello, I have a problem with my dependency pattern and I am not sure that maven behaves correctly in this case. Here is my case : - I am using Maven 2.2.1. - I have a project A which defines a dependency D with scope test. - I have a project B whose parent is A and which defines D as a dependency in scope compile. - My project hierarchy defines a lot of projects whose parent is A and who have B as a dependency. My problem is : all these subprojects have D as dependency in scope test (from A). I think that the correct behaviour would be to have D with scope compile (from their dependency on B) because scope compile 'contains' scope test. But Maven 2.2.1 does not work that way :-). Is there any way to force my projects to use the D scope from project B instead of the one from its parent (project A) ? Thanks in avance, -- Signature Graham CROSMARIE RD Engineer Linagora GSO -- www.linagora.com http://www.linagora.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Signature Graham CROSMARIE RD Engineer Linagora GSO -- www.linagora.com http://www.linagora.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
problems with deploying to a remote repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. How do you use mvn command line to deploy an artifact to a remote repository? it says it doesn't have a proper vagon provider for sftp/scp so... and it doesn't autodownload it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBUxWAAoJEIm05B02l8E69t0P/jowMiX4G+mxBakLGVAv6wtM utDKJGLd3IGf7po105+i7bsv+8VUtO7rvqOMaqyb9M10SYxW1e4aYFLkeK/vTB9i JgezVJPcxbGGmrWe5v5VpTeUZnzNV9dQpCIRS6G9ncnbEoJ6obSsqEd7+6iFf75R RtKXXxja2RqaSorUtjhA89bonvnE06P43kuqROyJVElEDdpsLWgEqFWSpb10vEBN xOHAfkrT3lvZeO4r6OPRIj5D3KHBuGA5/IRaFLj5Ar+XqR0uguIq431r63RzXOge 7ByzgVTRdbRIPaYWTJCiYmdYcHGoAvWy1dKLCrNDfTrBc4gRjj/EJW9BL47LWlG7 y/viV7WAIM4B6w5nBsygHeZCGvoJUB19RRwrj3ZRAXJE9aZP6/QDtQZ+vi/Is5c1 MPTSbyljS5+xufdVyODfgRRm+AYoh3I5ndk/cg1Kr3wUqz+aZlRgQSfX0zyzx5i/ BI4SEmicXyCy47A7juD5BsSybuqQCT7VeoU669daj4RVklk5vEL7PuJsbNA9yuuT e+EIVzhHd6kyFkQEl74yeX6gVLLaPDjIwUqNR4M8XiXsr7iTgd15/wFxtxNsM39f yuZgIo6a/A3amnu8VvKnbNa3BK1JT8bJnl2KfWKuZ+QuU+mANAo7q8By8vQtaITz H22jJPungGtZfGlokAJN =jcXr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Dependencies between the test sections of modules?
I have a multi-module project P, with modules P.Core, P.A, P.B. Both P.A and P.B are different implementations of an API specified in P.Core. In order to test that all implementations of P.Core have the same semantics, P.Core exports a set of abstract classes containing junit 4 tests which are then completed by P.A and P.B. The problem is this: classes defined in p-core/src/main/test are not visible from p-a/src/main/test or p-b/src/main/test. Moving the classes into p-core/src/main/java makes them visible to the tests defined in the other modules, but then this means that the junit dependency has to be moved from the test phase of P.Core to the compile phase, which is somewhat irritating. Is there a way allow the 'test' sections of modules to see each other? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
transitive provided dependencies: a little question
Hi all...
a friend of mine and I have experienced a compilation error when we
have tried to compile this project:
prj.a:
public class A extends B{}
prj.b:
public class B extends C{}
prj.c:
public class C{}
where their pom are:
prj.a - prj.b (provided scope)
prj.b - prj.c (provided scope)
our compilation fails because C is not included in A's compile
classpath as shown in the table [1]
My question is... why the transitive 'provided' dependencies of a
'provided' dependency are not transitive and the transitive
*'runtime'* dependencies of a 'provided' dependency is transitive?
IMHO would be better that provided dependencies are transitive and
runtime dependencies not, it isn't?
have a nice day... :-)
[1]:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
--
Marco Speranza marcospera...@apache.org
Google Code: http://code.google.com/u/marco.speranza79/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependencies between the test sections of modules?
Yes, create a jar of the test classes: http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html There are some limitations in this though (test dependencies are not transitive). Moving these test classes to a separate project solves that. /Anders On Tue, Jul 17, 2012 at 2:39 PM, org.apache.maven.u...@io7m.com wrote: I have a multi-module project P, with modules P.Core, P.A, P.B. Both P.A and P.B are different implementations of an API specified in P.Core. In order to test that all implementations of P.Core have the same semantics, P.Core exports a set of abstract classes containing junit 4 tests which are then completed by P.A and P.B. The problem is this: classes defined in p-core/src/main/test are not visible from p-a/src/main/test or p-b/src/main/test. Moving the classes into p-core/src/main/java makes them visible to the tests defined in the other modules, but then this means that the junit dependency has to be moved from the test phase of P.Core to the compile phase, which is somewhat irritating. Is there a way allow the 'test' sections of modules to see each other? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependencies between the test sections of modules?
On Tue, Jul 17, 2012 at 2:39 PM, org.apache.maven.u...@io7m.com wrote: I have a multi-module project P, with modules P.Core, P.A, P.B. Both P.A and P.B are different implementations of an API specified in P.Core. In order to test that all implementations of P.Core have the same semantics, P.Core exports a set of abstract classes containing junit 4 tests which are then completed by P.A and P.B. The problem is this: classes defined in p-core/src/main/test are not visible from p-a/src/main/test or p-b/src/main/test. Moving the classes into p-core/src/main/java makes them visible to the tests defined in the other modules, but then this means that the junit dependency has to be moved from the test phase of P.Core to the compile phase, which is somewhat irritating. Is there a way allow the 'test' sections of modules to see each other? Sure, add a dependency on the test-jar (and of course generate and attach it in P.Core). See http://maven.apache.org/guides/mini/guide-attached-tests.html -- Thomas Broyer /tɔ.ma.bʁwa.je/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependencies between the test sections of modules?
On Tue, 17 Jul 2012 14:44:57 +0200 Anders Hammar and...@hammar.net wrote: Yes, create a jar of the test classes: http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html There are some limitations in this though (test dependencies are not transitive). Moving these test classes to a separate project solves that. On Tue, 17 Jul 2012 14:45:37 +0200 Thomas Broyer t.bro...@gmail.com wrote: Sure, add a dependency on the test-jar (and of course generate and attach it in P.Core). See http://maven.apache.org/guides/mini/guide-attached-tests.html Thanks, all. I'll try it. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
best practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. What is the best way to do things like: Some artifact exists in a central repository and it's a transitive dependency of some of my project's direct dependencies. Then, I have a really good reason to modify the artifact and store it in my own repository. Should I distinguish the new version of it using a classifier, a version like 0.0-modified, or I should make the coordinates the same as in central? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBWiTAAoJEIm05B02l8E6S6YP/i2OTRi04zHS/8yEBMabeI6g e0BVVir6EI/l8+0NvuOVj0WI6gBxFDvajr6NHaQC/Eg1C6NHyTdCXrMXjeHLxcst Z8Fqe+dOSF3zkvjUFpgU4NgvSxiuUKPc/2hcezYBMF/Q8IIDUJpR2sZpHmp0JdH+ iZIpcxPp1wzqwtWUvherMtjI351vyBSVWaPfoRPNFTeOXxCyR4WQmXeGQkMnG+9S MpMAAACfdT6Hsjhvnq4CzrzItBpfIrgXWcXtM6mmyN92t2CumYTvpwWlF2iHNWyS VvoIOoSntm6TBtk8vPtrMvC0vDTVJ6Cd3YdWAFacByy9kh+cjeATTUMKc/W+lbMn FfTK4FAxQNqRUUa93MBBZydw0dKeLg4w+YulI4u6p219HtBNjtq1UuMAyXrEn/xk xRysKjqpM2d2kkUiPvCJde/p6AarLpUK1GfVvzF9a/tff6nkOlt9AgaBmiJ/OiTt o0yXIjo3ovJcBoGoPUC60qswDH5goKYJH1vkVaAj2ey8cFuwGNPrqGbjEiGgDtij xU9KSzUOoOLxB6feskXEivgL+gxDK8+okJ4vLgglLezRaFMX5CXF+yttybXVyuK+ kE/mnl4Yx8gIIcogZLb1+kHsFqp1VHQvyfrzOadplOLTchbQUDfWpaS2EwztODQk JtJsjfipQYirRjF5RfnD =WGSq -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Duplicate dependency with different scopes
Hi! In parent A, so you define scope in dependency or dependency management section. If the latter, then it overrides scope of the transitive dependency. In which scope is dependency B? If it's in test scope, than its dependencies will be in test scope, too. It would be much easier if you could show the POMs. Regards, htfv (Aliaksei Lahachou) Am 17.07.2012 09:15 schrieb Graham Crosmarie graham.crosma...@linagora.com: Hello, I have a problem with my dependency pattern and I am not sure that maven behaves correctly in this case. Here is my case : - I am using Maven 2.2.1. - I have a project A which defines a dependency D with scope test. - I have a project B whose parent is A and which defines D as a dependency in scope compile. - My project hierarchy defines a lot of projects whose parent is A and who have B as a dependency. My problem is : all these subprojects have D as dependency in scope test (from A). I think that the correct behaviour would be to have D with scope compile (from their dependency on B) because scope compile 'contains' scope test. But Maven 2.2.1 does not work that way :-). Is there any way to force my projects to use the D scope from project B instead of the one from its parent (project A) ? Thanks in avance, -- Signature Graham CROSMARIE RD Engineer Linagora GSO -- www.linagora.com http://www.linagora.com
Re: best practices
I think it would depend on what kind of changes you make. But if it's a patch or similar, you should just change the version to a.b.c-PATCH123 or something (keep artifactId and groupId as the original). But if you make bigger changes to it, it would probably make sense to put it under your groupId. /Anders On Tue, Jul 17, 2012 at 3:28 PM, Michał Zegan webczat_...@poczta.onet.pl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. What is the best way to do things like: Some artifact exists in a central repository and it's a transitive dependency of some of my project's direct dependencies. Then, I have a really good reason to modify the artifact and store it in my own repository. Should I distinguish the new version of it using a classifier, a version like 0.0-modified, or I should make the coordinates the same as in central? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBWiTAAoJEIm05B02l8E6S6YP/i2OTRi04zHS/8yEBMabeI6g e0BVVir6EI/l8+0NvuOVj0WI6gBxFDvajr6NHaQC/Eg1C6NHyTdCXrMXjeHLxcst Z8Fqe+dOSF3zkvjUFpgU4NgvSxiuUKPc/2hcezYBMF/Q8IIDUJpR2sZpHmp0JdH+ iZIpcxPp1wzqwtWUvherMtjI351vyBSVWaPfoRPNFTeOXxCyR4WQmXeGQkMnG+9S MpMAAACfdT6Hsjhvnq4CzrzItBpfIrgXWcXtM6mmyN92t2CumYTvpwWlF2iHNWyS VvoIOoSntm6TBtk8vPtrMvC0vDTVJ6Cd3YdWAFacByy9kh+cjeATTUMKc/W+lbMn FfTK4FAxQNqRUUa93MBBZydw0dKeLg4w+YulI4u6p219HtBNjtq1UuMAyXrEn/xk xRysKjqpM2d2kkUiPvCJde/p6AarLpUK1GfVvzF9a/tff6nkOlt9AgaBmiJ/OiTt o0yXIjo3ovJcBoGoPUC60qswDH5goKYJH1vkVaAj2ey8cFuwGNPrqGbjEiGgDtij xU9KSzUOoOLxB6feskXEivgL+gxDK8+okJ4vLgglLezRaFMX5CXF+yttybXVyuK+ kE/mnl4Yx8gIIcogZLb1+kHsFqp1VHQvyfrzOadplOLTchbQUDfWpaS2EwztODQk JtJsjfipQYirRjF5RfnD =WGSq -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: best practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 But it would not work for transitive ependencies if I'll put it in a different group id, I think. because they are different projects. W dniu 2012-07-17 15:39, Anders Hammar pisze: I think it would depend on what kind of changes you make. But if it's a patch or similar, you should just change the version to a.b.c-PATCH123 or something (keep artifactId and groupId as the original). But if you make bigger changes to it, it would probably make sense to put it under your groupId. /Anders On Tue, Jul 17, 2012 at 3:28 PM, Michał Zegan webczat_...@poczta.onet.pl wrote: Hello. What is the best way to do things like: Some artifact exists in a central repository and it's a transitive dependency of some of my project's direct dependencies. Then, I have a really good reason to modify the artifact and store it in my own repository. Should I distinguish the new version of it using a classifier, a version like 0.0-modified, or I should make the coordinates the same as in central? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBW12AAoJEIm05B02l8E6x4oP/27oOsR5oOw5qYqYc/HSjs6z awbD/mw9MFocKF3XnzWbkF/AnxAK+kxxyJAtFjQ6dY9e6xEMrZKVGJ61ahuzz7hn H//PlXavX9tyRE0eqmmauanNFZaohr6SoXOgHAvTeCh5HAizHf8nAT0FT4HJTb9J LCMbpcE1ZFdSJ+rQMFS+IGPtYBYNQKylEaG1C9eP7os2hxIrwuxe0SVOPdrhmzrB KbFaORYbVa5660AcX/i7F6DZae8Bnp1AShLYa/2ecyDx6352z/olKju9iFbwkoEb 3WtFrzhIdDtKEPh7NzU2wCYPwXwhhkgTgGjDkLkC6/WjRTfZQoQJzMo/nGQn0uGB GY7uuGT82VpqI6IhubhKzJh4ddFmucu2AtCnxpuwhQ3q09h8UaHCCVmA3QLcnBVg moLbHGk/4bnub+sspoSH4gHPdhNiLWJbWXoj2SpR8v6IyeSenGxwndjrrf1j/bHX bplkMmAINlyaPhOBmt41iy1kzLhz4BNbBSaFCUbS71yyNh0AUBRNC1HDgzA8VSe+ J4lBv/UFcI+gWZjyN3ih+S35oIVymjSUwjeU32XJq7zWkdLGi5x9AqhsEsTYzKyf zGLhIxdKMDIirTvX4nS2dlv7F8fx+8X06Vg1JgR1F0zZRnuGk+Sw1sPyy67aSlhj kjk+CPQAjzMTS5xKkdig =/tS3 -END PGP SIGNATURE-
Re: best practices
If you exclude the stock version from the direct dependencies and add your version as a dependency, you: a) get the configuration that you want b) you have documented in your POM, the exact configuration of software bits and pieces that are required to build what you want (your friends will someday love you for doing this or hate you if you don't) Being sneaky sometimes looks efficient but seldom is in the long term. Ron On 17/07/2012 9:49 AM, Michał Zegan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 But it would not work for transitive ependencies if I'll put it in a different group id, I think. because they are different projects. W dniu 2012-07-17 15:39, Anders Hammar pisze: I think it would depend on what kind of changes you make. But if it's a patch or similar, you should just change the version to a.b.c-PATCH123 or something (keep artifactId and groupId as the original). But if you make bigger changes to it, it would probably make sense to put it under your groupId. /Anders On Tue, Jul 17, 2012 at 3:28 PM, Michał Zegan webczat_...@poczta.onet.pl wrote: Hello. What is the best way to do things like: Some artifact exists in a central repository and it's a transitive dependency of some of my project's direct dependencies. Then, I have a really good reason to modify the artifact and store it in my own repository. Should I distinguish the new version of it using a classifier, a version like 0.0-modified, or I should make the coordinates the same as in central? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBW12AAoJEIm05B02l8E6x4oP/27oOsR5oOw5qYqYc/HSjs6z awbD/mw9MFocKF3XnzWbkF/AnxAK+kxxyJAtFjQ6dY9e6xEMrZKVGJ61ahuzz7hn H//PlXavX9tyRE0eqmmauanNFZaohr6SoXOgHAvTeCh5HAizHf8nAT0FT4HJTb9J LCMbpcE1ZFdSJ+rQMFS+IGPtYBYNQKylEaG1C9eP7os2hxIrwuxe0SVOPdrhmzrB KbFaORYbVa5660AcX/i7F6DZae8Bnp1AShLYa/2ecyDx6352z/olKju9iFbwkoEb 3WtFrzhIdDtKEPh7NzU2wCYPwXwhhkgTgGjDkLkC6/WjRTfZQoQJzMo/nGQn0uGB GY7uuGT82VpqI6IhubhKzJh4ddFmucu2AtCnxpuwhQ3q09h8UaHCCVmA3QLcnBVg moLbHGk/4bnub+sspoSH4gHPdhNiLWJbWXoj2SpR8v6IyeSenGxwndjrrf1j/bHX bplkMmAINlyaPhOBmt41iy1kzLhz4BNbBSaFCUbS71yyNh0AUBRNC1HDgzA8VSe+ J4lBv/UFcI+gWZjyN3ih+S35oIVymjSUwjeU32XJq7zWkdLGi5x9AqhsEsTYzKyf zGLhIxdKMDIirTvX4nS2dlv7F8fx+8X06Vg1JgR1F0zZRnuGk+Sw1sPyy67aSlhj kjk+CPQAjzMTS5xKkdig =/tS3 -END PGP SIGNATURE- -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: best practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't want to add exclusions for everything that requires that. W dniu 2012-07-17 15:57, Ron Wheeler pisze: If you exclude the stock version from the direct dependencies and add your version as a dependency, you: a) get the configuration that you want b) you have documented in your POM, the exact configuration of software bits and pieces that are required to build what you want (your friends will someday love you for doing this or hate you if you don't) Being sneaky sometimes looks efficient but seldom is in the long term. Ron On 17/07/2012 9:49 AM, Michał Zegan wrote: -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBXB7AAoJEIm05B02l8E6VdUP/2yMZaMfDuf9QOPQty1B9Fo+ hJ53Zn/anEIadj+TyWQKEkBRPzxP6WgZdP2eXJhEA6GeZAaSmjqOq6cePLycJ/bM yRabZ9mlWFb6DTw5Dc7wQ7snpJPIZRnA760tvNTwxFS/lb/7kjkLbTfJfTLfaVp6 HvFbJgs72CTazUBiJabZx8ryVVQMUEwzTRdlr7p/w9VdKqN11Q2JCzJmcrH++Tk5 AYInsKYgInlQjluYEpTfXSqAfQj9oJz9T1UXihS6dUzpd8DIbYLdcwUkQYB+bWUv pQJsGQmB14q8eXM2xtDkbIu5cpoJTncFMpnA/3ht4CKTbbFV+3hXLx3s9r638bbQ g6jK6LnH4kxoIWNBizm8I1eHpk25SwzK/mSZKmr2p4acma3naNn7qxastdApjbWu IqKXRMukhyOeXS8XM5C4j0aoHEpMYiVWDbVjCSkG0ptLTUoGoKYWOl1C84J8Jbpd 2gnnMOSHvucV8+jxHq3Zh0rXoR4z9r3jRoCsopEE3UPy/r6YqxO3A5PTwK2RIYHN ZsGRnpHzjyn/GK7YteZ48KwbC6Sl1TE3expL3gCPQNbI2t/zDvk6XSgzGuf+t+gY hXhnYBjwMcUSfC7eoLLE7chYiMr0g3yWNEII4iyj8VnqP6dlnETudFyrQvOsY+6h rwN/9SRuRuwqpRiGSI31 =znFZ -END PGP SIGNATURE-
Re: best practices
What none of us know is the scope of changes between this artifact and the original... if all you are doing is rolling a cut from the latest SCM head because you cannot wait for the next release = just change the version if you are majorly refactoring in such a way that the API or behaviour contract will be changed = change the groupId if you are somewhere in between, you are going to have to make that call -Stephen On 17 July 2012 15:02, Michał Zegan webczat_...@poczta.onet.pl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't want to add exclusions for everything that requires that. W dniu 2012-07-17 15:57, Ron Wheeler pisze: If you exclude the stock version from the direct dependencies and add your version as a dependency, you: a) get the configuration that you want b) you have documented in your POM, the exact configuration of software bits and pieces that are required to build what you want (your friends will someday love you for doing this or hate you if you don't) Being sneaky sometimes looks efficient but seldom is in the long term. Ron On 17/07/2012 9:49 AM, Michał Zegan wrote: -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBXB7AAoJEIm05B02l8E6VdUP/2yMZaMfDuf9QOPQty1B9Fo+ hJ53Zn/anEIadj+TyWQKEkBRPzxP6WgZdP2eXJhEA6GeZAaSmjqOq6cePLycJ/bM yRabZ9mlWFb6DTw5Dc7wQ7snpJPIZRnA760tvNTwxFS/lb/7kjkLbTfJfTLfaVp6 HvFbJgs72CTazUBiJabZx8ryVVQMUEwzTRdlr7p/w9VdKqN11Q2JCzJmcrH++Tk5 AYInsKYgInlQjluYEpTfXSqAfQj9oJz9T1UXihS6dUzpd8DIbYLdcwUkQYB+bWUv pQJsGQmB14q8eXM2xtDkbIu5cpoJTncFMpnA/3ht4CKTbbFV+3hXLx3s9r638bbQ g6jK6LnH4kxoIWNBizm8I1eHpk25SwzK/mSZKmr2p4acma3naNn7qxastdApjbWu IqKXRMukhyOeXS8XM5C4j0aoHEpMYiVWDbVjCSkG0ptLTUoGoKYWOl1C84J8Jbpd 2gnnMOSHvucV8+jxHq3Zh0rXoR4z9r3jRoCsopEE3UPy/r6YqxO3A5PTwK2RIYHN ZsGRnpHzjyn/GK7YteZ48KwbC6Sl1TE3expL3gCPQNbI2t/zDvk6XSgzGuf+t+gY hXhnYBjwMcUSfC7eoLLE7chYiMr0g3yWNEII4iyj8VnqP6dlnETudFyrQvOsY+6h rwN/9SRuRuwqpRiGSI31 =znFZ -END PGP SIGNATURE-
Re: best practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For example recompiling to drop compatibility with unsupported jsr14 (namely osgi 4.3). W dniu 2012-07-17 16:05, Stephen Connolly pisze: What none of us know is the scope of changes between this artifact and the original... if all you are doing is rolling a cut from the latest SCM head because you cannot wait for the next release = just change the version if you are majorly refactoring in such a way that the API or behaviour contract will be changed = change the groupId if you are somewhere in between, you are going to have to make that call -Stephen On 17 July 2012 15:02, Michał Zegan webczat_...@poczta.onet.pl wrote: I don't want to add exclusions for everything that requires that. W dniu 2012-07-17 15:57, Ron Wheeler pisze: If you exclude the stock version from the direct dependencies and add your version as a dependency, you: a) get the configuration that you want b) you have documented in your POM, the exact configuration of software bits and pieces that are required to build what you want (your friends will someday love you for doing this or hate you if you don't) Being sneaky sometimes looks efficient but seldom is in the long term. Ron On 17/07/2012 9:49 AM, Michał Zegan wrote: -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBXH8AAoJEIm05B02l8E6CKsP/RBlMDopk2hlWwkZGd3WkWyU zNiBSW0HPaAVffsr6aniscYBhPviqywOd/IklRhuqBtPtszrCGyO1SXem4zuW1jq FZTTG5Zj+NzsIIG/FVYZKhudIc99eBRrgkuy5VM+cutpuq1+NyWdEZLDtYGR+bGy YlO9qGB59sWTxXbk2Om5C2z5+1QreNT8soCMHPbULg+SxyLI8yNCD1N6+bx7zvhU JRsrA51fA76kQx2ch31I/pIxTdK3c9f9mttB7Wuf1zGXkmhv9NTDljZ03DzlD4IW XxahO6E5KC79NN16q+fvUwFPcjw2HR3FmyYQGiOc5XmqUC/fUBySFTj9G9mKwQGn BRl8K2jO0C3X44hscEJjhXS204nGlwGpH0IUQTLGyF2f+dz+7meE4i6GqlvwEjaT ZENnLzX0eS0dbQYem3FJeUXIoUjjUp70myq4rq7bvKHerrRQFHlGL7f+ApLStJX5 Ps0qTH/xGtsU+PjPTNd3RJKyWfk4WvbXNVWjT+kLrlqL6pXommgI5/MZrAozot8m jR3Slbhy/J1KI7xcu4yL6aEyWVDU7qwZHXVvyVj6SjFAMvlMX3YwtcpilG2P1Ljh en/MKDTdUF8GKO4M/iOk59QJ7IPlD1FJq88UEiL/M6k0CuZzY/nRIZ6MnXTDBVoa +KHubq8FPLWhrg3Ma3Al =eu/j -END PGP SIGNATURE-
Re: best practices
What happens if any dependencies are looking for that support? Will they bomb out or fail gracefully? I.O.W. if you can still drop it in as a generic replacement = version change If you cannot use it as a generic replacement = different artifact = change groupId for example... I have https://github.com/stephenc/redmine-java-api which is https://github.com/taskadapter/redmine-java-api switched to use slf4j in place of some crappy piece of sh1t logging adapter code they rolled themselves. Because I have altered the API contract by removing their logging adapter code I maintain that at a different groupId. It is otherwise API compatible, but the changes I have made are breaking changes so I moved the groupId (never mind I needed a working version in central so I had to change the groupId anyway... I *could* have got away with pushing an alternative version number to our corp maven repo) On 17 July 2012 15:09, Michał Zegan webczat_...@poczta.onet.pl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For example recompiling to drop compatibility with unsupported jsr14 (namely osgi 4.3). W dniu 2012-07-17 16:05, Stephen Connolly pisze: What none of us know is the scope of changes between this artifact and the original... if all you are doing is rolling a cut from the latest SCM head because you cannot wait for the next release = just change the version if you are majorly refactoring in such a way that the API or behaviour contract will be changed = change the groupId if you are somewhere in between, you are going to have to make that call -Stephen On 17 July 2012 15:02, Michał Zegan webczat_...@poczta.onet.pl wrote: I don't want to add exclusions for everything that requires that. W dniu 2012-07-17 15:57, Ron Wheeler pisze: If you exclude the stock version from the direct dependencies and add your version as a dependency, you: a) get the configuration that you want b) you have documented in your POM, the exact configuration of software bits and pieces that are required to build what you want (your friends will someday love you for doing this or hate you if you don't) Being sneaky sometimes looks efficient but seldom is in the long term. Ron On 17/07/2012 9:49 AM, Michał Zegan wrote: -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBXH8AAoJEIm05B02l8E6CKsP/RBlMDopk2hlWwkZGd3WkWyU zNiBSW0HPaAVffsr6aniscYBhPviqywOd/IklRhuqBtPtszrCGyO1SXem4zuW1jq FZTTG5Zj+NzsIIG/FVYZKhudIc99eBRrgkuy5VM+cutpuq1+NyWdEZLDtYGR+bGy YlO9qGB59sWTxXbk2Om5C2z5+1QreNT8soCMHPbULg+SxyLI8yNCD1N6+bx7zvhU JRsrA51fA76kQx2ch31I/pIxTdK3c9f9mttB7Wuf1zGXkmhv9NTDljZ03DzlD4IW XxahO6E5KC79NN16q+fvUwFPcjw2HR3FmyYQGiOc5XmqUC/fUBySFTj9G9mKwQGn BRl8K2jO0C3X44hscEJjhXS204nGlwGpH0IUQTLGyF2f+dz+7meE4i6GqlvwEjaT ZENnLzX0eS0dbQYem3FJeUXIoUjjUp70myq4rq7bvKHerrRQFHlGL7f+ApLStJX5 Ps0qTH/xGtsU+PjPTNd3RJKyWfk4WvbXNVWjT+kLrlqL6pXommgI5/MZrAozot8m jR3Slbhy/J1KI7xcu4yL6aEyWVDU7qwZHXVvyVj6SjFAMvlMX3YwtcpilG2P1Ljh en/MKDTdUF8GKO4M/iOk59QJ7IPlD1FJq88UEiL/M6k0CuZzY/nRIZ6MnXTDBVoa +KHubq8FPLWhrg3Ma3Al =eu/j -END PGP SIGNATURE-
Re: best practices
Sometimes a best practice requires you to do things that you don't want to do for short term reasons. Why not add an exclusion for stuff you want Maven to exclude? Ron On 17/07/2012 10:02 AM, Michał Zegan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't want to add exclusions for everything that requires that. W dniu 2012-07-17 15:57, Ron Wheeler pisze: If you exclude the stock version from the direct dependencies and add your version as a dependency, you: a) get the configuration that you want b) you have documented in your POM, the exact configuration of software bits and pieces that are required to build what you want (your friends will someday love you for doing this or hate you if you don't) Being sneaky sometimes looks efficient but seldom is in the long term. Ron On 17/07/2012 9:49 AM, Michał Zegan wrote: -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBXB7AAoJEIm05B02l8E6VdUP/2yMZaMfDuf9QOPQty1B9Fo+ hJ53Zn/anEIadj+TyWQKEkBRPzxP6WgZdP2eXJhEA6GeZAaSmjqOq6cePLycJ/bM yRabZ9mlWFb6DTw5Dc7wQ7snpJPIZRnA760tvNTwxFS/lb/7kjkLbTfJfTLfaVp6 HvFbJgs72CTazUBiJabZx8ryVVQMUEwzTRdlr7p/w9VdKqN11Q2JCzJmcrH++Tk5 AYInsKYgInlQjluYEpTfXSqAfQj9oJz9T1UXihS6dUzpd8DIbYLdcwUkQYB+bWUv pQJsGQmB14q8eXM2xtDkbIu5cpoJTncFMpnA/3ht4CKTbbFV+3hXLx3s9r638bbQ g6jK6LnH4kxoIWNBizm8I1eHpk25SwzK/mSZKmr2p4acma3naNn7qxastdApjbWu IqKXRMukhyOeXS8XM5C4j0aoHEpMYiVWDbVjCSkG0ptLTUoGoKYWOl1C84J8Jbpd 2gnnMOSHvucV8+jxHq3Zh0rXoR4z9r3jRoCsopEE3UPy/r6YqxO3A5PTwK2RIYHN ZsGRnpHzjyn/GK7YteZ48KwbC6Sl1TE3expL3gCPQNbI2t/zDvk6XSgzGuf+t+gY hXhnYBjwMcUSfC7eoLLE7chYiMr0g3yWNEII4iyj8VnqP6dlnETudFyrQvOsY+6h rwN/9SRuRuwqpRiGSI31 =znFZ -END PGP SIGNATURE- -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: problems with deploying to a remote repository
Hi there, Try with mvn deploy:deployfile, http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html Thanks, Krishna Kurnala On Tue, Jul 17, 2012 at 4:28 AM, Michał Zegan webczat_...@poczta.onet.plwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. How do you use mvn command line to deploy an artifact to a remote repository? it says it doesn't have a proper vagon provider for sftp/scp so... and it doesn't autodownload it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBUxWAAoJEIm05B02l8E69t0P/jowMiX4G+mxBakLGVAv6wtM utDKJGLd3IGf7po105+i7bsv+8VUtO7rvqOMaqyb9M10SYxW1e4aYFLkeK/vTB9i JgezVJPcxbGGmrWe5v5VpTeUZnzNV9dQpCIRS6G9ncnbEoJ6obSsqEd7+6iFf75R RtKXXxja2RqaSorUtjhA89bonvnE06P43kuqROyJVElEDdpsLWgEqFWSpb10vEBN xOHAfkrT3lvZeO4r6OPRIj5D3KHBuGA5/IRaFLj5Ar+XqR0uguIq431r63RzXOge 7ByzgVTRdbRIPaYWTJCiYmdYcHGoAvWy1dKLCrNDfTrBc4gRjj/EJW9BL47LWlG7 y/viV7WAIM4B6w5nBsygHeZCGvoJUB19RRwrj3ZRAXJE9aZP6/QDtQZ+vi/Is5c1 MPTSbyljS5+xufdVyODfgRRm+AYoh3I5ndk/cg1Kr3wUqz+aZlRgQSfX0zyzx5i/ BI4SEmicXyCy47A7juD5BsSybuqQCT7VeoU669daj4RVklk5vEL7PuJsbNA9yuuT e+EIVzhHd6kyFkQEl74yeX6gVLLaPDjIwUqNR4M8XiXsr7iTgd15/wFxtxNsM39f yuZgIo6a/A3amnu8VvKnbNa3BK1JT8bJnl2KfWKuZ+QuU+mANAo7q8By8vQtaITz H22jJPungGtZfGlokAJN =jcXr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Duplicate dependency with different scopes
A defines a dependency on D with scope test and is a pom project B defines a dependency on D with compile (default) and is a jar project. A is the parent pom of B. When I run dependency:tree I get what I want for B : D with scope compile. I have other projects (C) whose parent is A and which depend on B with scope compile(default). My problem is that the D dependency for such projects is in scope test (inherited from A) instead of scope compile (retrieved through the dependency on B). In other words Maven chooses the wrong scope for my C projects. In fact, I think it always takes the one from the before parent and ignores the one from the dependency. On 17/07/2012 15:29, Aliaksei Lahachou wrote: Hi! In parent A, so you define scope in dependency or dependency management section. If the latter, then it overrides scope of the transitive dependency. In which scope is dependency B? If it's in test scope, than its dependencies will be in test scope, too. It would be much easier if you could show the POMs. Regards, htfv (Aliaksei Lahachou) Am 17.07.2012 09:15 schrieb Graham Crosmarie graham.crosma...@linagora.com: Hello, I have a problem with my dependency pattern and I am not sure that maven behaves correctly in this case. Here is my case : - I am using Maven 2.2.1. - I have a project A which defines a dependency D with scope test. - I have a project B whose parent is A and which defines D as a dependency in scope compile. - My project hierarchy defines a lot of projects whose parent is A and who have B as a dependency. My problem is : all these subprojects have D as dependency in scope test (from A). I think that the correct behaviour would be to have D with scope compile (from their dependency on B) because scope compile 'contains' scope test. But Maven 2.2.1 does not work that way :-). Is there any way to force my projects to use the D scope from project B instead of the one from its parent (project A) ? Thanks in avance, -- Signature Graham CROSMARIE RD Engineer Linagora GSO -- www.linagora.com http://www.linagora.com -- Signature Graham CROSMARIE RD Engineer Linagora GSO -- www.linagora.com http://www.linagora.com
Re: best practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 THere are many dependencies using that one as a transitive, so I don't want to be in a situation when I would forget to exclude them. Changing a version using dependency management works for all. W dniu 2012-07-17 16:40, Ron Wheeler pisze: Sometimes a best practice requires you to do things that you don't want to do for short term reasons. Why not add an exclusion for stuff you want Maven to exclude? Ron On 17/07/2012 10:02 AM, Michał Zegan wrote: W dniu 2012-07-17 15:57, Ron Wheeler pisze: If you exclude the stock version from the direct dependencies and add your version as a dependency, you: a) get the configuration that you want b) you have documented in your POM, the exact configuration of software bits and pieces that are required to build what you want (your friends will someday love you for doing this or hate you if you don't) Being sneaky sometimes looks efficient but seldom is in the long term. Ron On 17/07/2012 9:49 AM, Michał Zegan wrote: -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQBYDKAAoJEIm05B02l8E6sx8P/0KDjRu5k0dh7dB3z2IFsMOq u3tHIPInudanW+yLtvRL98NQ8twJ+pfwpq4t6pxtwKoFCU0LYxqgK4n7JOtHF2c1 IVLQMQK2GGN+NlSQGRPIhf5vCc23q4aXOx5slQavDbkR/tAF/AdB/hecwhd3N4G0 Y3t/oYLEW8x9heSxf5Z3+nVJhu4/dfRD2GRTR0IwKLZ3sPORZ/GeZmxza9jEn1+M 0S8NVHxgKPv0KTlJuVpZ+VOsqzYUZw5b/6Cxm5vqbMgM5RrVCuSe05PdJdyt+U9r iKDpzxrO/b3WmfU+VvgMD/W538hq2uy2AHO2//oSpA7aQpeq3LR03JfguYIRFCwG VgoFihkZcs9WcaVqLxY65Wkd5FXJYvETgktornCqDdxMsm/hiMxi8PLn7zVrsmvI bz66GpBTdByoUPotEv66d5jBONhmHIjVDnNKqhZcwDMd7M+pWFwdpz4oqM8aUwPS oifn+NBee/fFNNKRVFSoKZjrSKEBWcS72+4JTVdKs7w+/s4Q8QHGg8baoz22odaq 7SexT4e/ItlA/fo8qr7mdsyeof6STnWPvP14SDXttYBP0U7PvMssee+ZQGljVKfi tCliK80wNYxECRgwMuOhnaYXmjwtwyqpzn5hQQx/tplrddzt+2tv2phtNiOT/e+t quAhpbvI0jrdBnqAwUlU =/LKX -END PGP SIGNATURE-
Managing alternate source types to Java/Script/Resource across pluggins
I'm looking at Native compilation, particularly with NAR and want to make some other extensions that will add sources for NAR to compile - if it is being used already. For instance XSD code generation like XMLBeans. For Java the MavenProject provides access to the CompileSourceRoots/TestCompileSourceRoots adding across plugins. NAR also goes through these locations to potentially add files to compile (I think it should not because it adds for all native types) Is there some appropriate location to do the same for Extension Plugins for alternate file types? I've had a look around extending MavenProject, Build/BuildOverlay and this just doesn't seem right. It seems like MavenProject.getBuildExtensions might be a way to go, the other projects needing to depend on NAR seems a bit heavy at the moment. -- View this message in context: http://maven.40175.n5.nabble.com/Managing-alternate-source-types-to-Java-Script-Resource-across-pluggins-tp5714310.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: OT: Re: Issue-wise Crowdfunding platform for Maven
It is extremely unlikely that the Foundation will be interested in any participation except to gratefully accept any unrestricted donations your organization might happen to make. If you want to state on your website that you are going to donate something to the ASF when the issue is an ASF project JIRA, and you conform the ASF trademark and branding guidelines, I predict (speaking without wearing any official ASF hat) that all will be well. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
problem in installing/running maven
hi I new to maven project and first time i to runand install maven I followed the following steps which instruct by apache maven 1. Add the M2_HOME environment variable by opening up the system properties (WinKey + Pause), selecting the Advanced tab, and the Environment Variables button, then adding the M2_HOME variable in the user variables with the value *C:\Program Files\apache-maven-3.0.4* 2. In the same dialog, add the M2 environment variable in the user variables with the value %M2_HOME%\bin. 3. In the same dialog, update/create the Path environment variable in the user variables and prepend the value %M2% to add Maven available in the command line. 4. In the same dialog, make JAVA_HOME in user variables with the value C:\Program Files\Java\jdk1.6.0_21 and that %JAVA_HOME%\bin is in your Path environment variable. 5. Open a *new* command prompt (Winkey + R then type cmd) and run mvn --version to verify that it is correctly installed. *C:\Users\sahilmvn --version* 'mvn' is not recognized as an internal or external command, operable program or batch file if the directory is changes to* C:\Program Files\apache-maven-3.0.4\bin* then it runs . now please tell me what is problem when i try to issue a command from * C:\Users\sahil* directory -- Regards Rahul Bhalla (9953225211)
Re: Duplicate dependency with different scopes
I believe what happens here is that the dependency declared closest to your project wins. But you can control this through dependencyManagement in your project. /Anders On Tue, Jul 17, 2012 at 5:06 PM, Graham Crosmarie graham.crosma...@linagora.com wrote: A defines a dependency on D with scope test and is a pom project B defines a dependency on D with compile (default) and is a jar project. A is the parent pom of B. When I run dependency:tree I get what I want for B : D with scope compile. I have other projects (C) whose parent is A and which depend on B with scope compile(default). My problem is that the D dependency for such projects is in scope test (inherited from A) instead of scope compile (retrieved through the dependency on B). In other words Maven chooses the wrong scope for my C projects. In fact, I think it always takes the one from the before parent and ignores the one from the dependency. On 17/07/2012 15:29, Aliaksei Lahachou wrote: Hi! In parent A, so you define scope in dependency or dependency management section. If the latter, then it overrides scope of the transitive dependency. In which scope is dependency B? If it's in test scope, than its dependencies will be in test scope, too. It would be much easier if you could show the POMs. Regards, htfv (Aliaksei Lahachou) Am 17.07.2012 09:15 schrieb Graham Crosmarie graham.crosma...@linagora.com: Hello, I have a problem with my dependency pattern and I am not sure that maven behaves correctly in this case. Here is my case : - I am using Maven 2.2.1. - I have a project A which defines a dependency D with scope test. - I have a project B whose parent is A and which defines D as a dependency in scope compile. - My project hierarchy defines a lot of projects whose parent is A and who have B as a dependency. My problem is : all these subprojects have D as dependency in scope test (from A). I think that the correct behaviour would be to have D with scope compile (from their dependency on B) because scope compile 'contains' scope test. But Maven 2.2.1 does not work that way :-). Is there any way to force my projects to use the D scope from project B instead of the one from its parent (project A) ? Thanks in avance, -- Signature Graham CROSMARIE RD Engineer Linagora GSO -- www.linagora.com http://www.linagora.com -- Signature Graham CROSMARIE RD Engineer Linagora GSO -- www.linagora.com http://www.linagora.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
BUILD FAILURE to create project structure
hi i new to maven and try to create project structure with help of maven. I m using Maven 3.0.4 version Every time i try to run given command* C:\Program Files\apache-maven-3.0.4\binmvn archetype:generate* it ask : - Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 205: 596 Choose org.springframework.osgi:spring-osgi-bundle-archetype version: 1: 1.0 2: 1.0.1 3: 1.0.2 4: 1.0.3 5: 1.1.0 6: 1.1.1 7: 1.1.2 8: 1.1.3 9: 1.2.0 10: 1.2.1 Choose a number: 10: 10 Define value for property 'groupId': : com.rahul Define value for property 'artifactId': : gallery Define value for property 'version': 1.0-SNAPSHOT: : Define value for property 'package': com.rahul: : Confirm properties configuration: groupId: com.rahul artifactId: gallery version: 1.0-SNAPSHOT package: com.rahul Y: : y [INFO] [INFO] Using following parameters for creating project from Old (1.x) Archetype: spring-osgi-bundle-archetype:1.2.1 [INFO] [INFO] Parameter: groupId, Value: com.rahul [INFO] Parameter: packageName, Value: com.rahul [INFO] Parameter: package, Value: com.rahul [INFO] Parameter: artifactId, Value: gallery [INFO] Parameter: basedir, Value: C:\Program Files\apache-maven-3.0.4\bin [INFO] Parameter: version, Value: 1.0-SNAPSHOT [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 1:53.783s [INFO] Finished at: Wed Jul 18 01:34:34 IST 2012 [INFO] Final Memory: 7M/17M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.2:generate (default-cli) on project standalone-pom: Error merging velocity templates - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException please help me solve above issue thanking you -- Regards Rahul Bhalla
Re: problem in installing/running maven
*C:\Users\sahilmvn --version* 'mvn' is not recognized as an internal or external command, operable program or batch file if the directory is changes to* C:\Program Files\apache-maven-3.0.4\bin* then it runs . Please do not install Maven (or really anything) under Program Files, or any other directory with a space in it. Spaces in directory names can and will make your life more difficult. Make a c:\dev or c:\code or c:\projects, really anything, and install there. Then try to follow the instructions again and see if it works. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: problem in installing/running maven
Hi Please run the command SET in a command window and paste the relevant parts here, i.e. M2_HOME, M2, JAVA_HOME and PATH. On 2012-07-17 22:01, rahul bhalla wrote: hi I new to maven project and first time i to runand install maven I followed the following steps which instruct by apache maven 1. Add the M2_HOME environment variable by opening up the system properties (WinKey + Pause), selecting the Advanced tab, and the Environment Variables button, then adding the M2_HOME variable in the user variables with the value *C:\Program Files\apache-maven-3.0.4* 2. In the same dialog, add the M2 environment variable in the user variables with the value %M2_HOME%\bin. 3. In the same dialog, update/create the Path environment variable in the user variables and prepend the value %M2% to add Maven available in the command line. 4. In the same dialog, make JAVA_HOME in user variables with the value C:\Program Files\Java\jdk1.6.0_21 and that %JAVA_HOME%\bin is in your Path environment variable. 5. Open a *new* command prompt (Winkey + R then type cmd) and run mvn --version to verify that it is correctly installed. *C:\Users\sahilmvn --version* 'mvn' is not recognized as an internal or external command, operable program or batch file if the directory is changes to* C:\Program Files\apache-maven-3.0.4\bin* then it runs . now please tell me what is problem when i try to issue a command from * C:\Users\sahil* directory -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: BUILD FAILURE to create project structure
hi As you said i do and now it its running *thanks for the help* can please explain me the way how to create project structure/whole project outside the bin folder of maven ?? -- Regards Rahul Bhalla
[ANN] gwt-maven-plugin 2.5.0-rc1 Released
Hi, I'm pleased to announce the release of the gwt-maven-plugin version 2.5.0-rc1. http://mojo.codehaus.org/gwt-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdgwt-maven-plugin/artifactId version2.5.0-rc1/version /plugin Release Notes http://mojo.codehaus.org/gwt-maven-plugin/whats_new.html Enjoy, -- Thomas Broyer /tɔ.ma.bʁwa.je/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Revert Releases usigng Versions Plugin
Hello All We are tryign to use Maven Versions Plugin( http://mojo.codehaus.org/versions-maven-plugin/ ) as a automated way to keep diff module versions in sync in our POM's. The Real Challenge we face is when we decide to Revert/Roll-back from a Release, we currently delete Artifacts from Nexus, delete tags etc which is cumbersome. Wondering if there is an easy way out Reverting/Roll-back Releases using this Plugin or Kindly suggest any other easier way. thanks, Krishna Kurnala
Re: Revert Releases usigng Versions Plugin
On Tue, July 17, 2012 4:40 pm, krishna chaitanya kurnala wrote: Hello All We are tryign to use Maven Versions Plugin( http://mojo.codehaus.org/versions-maven-plugin/ ) as a automated way to keep diff module versions in sync in our POM's. The Real Challenge we face is when we decide to Revert/Roll-back from a Release, we currently delete Artifacts from Nexus, delete tags etc which is cumbersome. Wondering if there is an easy way out Reverting/Roll-back Releases using this Plugin or Kindly suggest any other easier way. I would suggest not to roll back at all but rather cut a new release taking advantage of the fact that version numbers are cheap ;-) or get Nexus Professional and use the staging suite to help you with your release process. Manfred http://simpligility.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: BUILD FAILURE to create project structure
can please explain me the way how to create project structure/whole project outside the bin folder of maven ?? First make sure mvn -v runs and outputs the proper information. Until this is working properly, there is no point to proceed. Make a new directory say c:\code. cd to that directory. Type mvn archetype:generate or whatever and build the project there. If that isn't what you are asking, please ask more specific questions and/or provide examples of what end results you desire. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Revert Releases usigng Versions Plugin
The Real Challenge we face is when we decide to Revert/Roll-back from a Release, we currently delete Artifacts from Nexus, delete tags etc which is cumbersome. Wondering if there is an easy way out Reverting/Roll-back Releases using this Plugin or Kindly suggest any other easier way. As Manfred already said, simply don't ever revert/roll-back, but rather bump/roll the version forward by 0.0.1 and keep truckin'. Reverting is dangerous. You don't know which version 1.0.3 of an artifact is installed in any given Maven repo or repo cache, and things get awful messy in a short period of time. Don't go down this path. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: BUILD FAILURE to create project structure
On Wed, Jul 18, 2012 at 11:57 AM, Wayne Fay wayne...@gmail.com wrote: can please explain me the way how to create project structure/whole project outside the bin folder of maven ?? Have you tried one of the freely available books at http://maven.apache.org/articles.html? Some of these should walk through examples of installing maven and trying something out. Also read http://maven.apache.org/users/index.html and the 5 minute test - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
