Re: How to set JAVA_HOME for maven?
Hi Frederic, fredand44 wrote: Hello! I have just reinstalled my computer to Ubuntu. I have also installed maven 3.0.3.. I set JAVA_HOME in my .bashrc like: JAVA_HOME=/usr/lib/jvm/java-6-openjdk export JAVA_HOME If I print it out with printenv I get: JAVA_HOME=/usr/lib/jvm/java-6-openjdk But If I run mvn --version I get: mvn --version Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /home/fredrik/Applications/apache-maven-3.0.3 Java version: 1.6.0_23, vendor: Sun Microsystems Inc. *Java home: /usr/lib/jvm/java-6-openjdk/jre* Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.0.0-14-generic, arch: i386, family: unix As you can see it points to the JRE, and I guess that is not right. This is normal. (I got the same when I did not set any JAVA_HOME also) What do you think guys? Don't set JAVA_HOME yourself. I don't know Ubuntu, but I guess it sets this variable on its own as other Linux systems (as mine) do anyway. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Odd failure with maven-checkstyle-plugin in pluginManagement
Hi, I have encountered a very odd failure when adding the maven-checkstyle-plugin to my pluginManagement section. Below is the simplest POM that triggers this error (both under Maven 3.0.3 and 3.0.4-RC3): project ... modelVersion4.0.0/modelVersion groupIdorg.example/groupId artifactIdexample/artifactId version0.0.1-SNAPSHOT/version build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ckeckstyle-plugin/artifactId version2.8/version /plugin /pluginManagement /build /project A mvn clean install runs just fine, but as soon as someone actually tries to do something with the pluginManagement entry (a mvn help:effective-pom already triggers this), I get the following warning. [WARNING] The POM for org.apache.maven.plugins:maven-ckeckstyle-plugin:jar:2.8 is missing, no dependency information available [WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-ckeckstyle-plugin:2.8: Plugin org.apache.maven.plugins:maven-ckeckstyle-plugin:2.8 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-ckeckstyle-plugin:jar:2.8 Note the packaging of jar in the above. AFAIK, it should be maven-plugin instead. At any rate, the above is really an error rather than a mere warning. Any attempt to actually use the maven-checkstyle-plugin in build/plugins uses the plugin's default configuration rather than any configuration configured build/pluginManagement/plugins. I strongly suspect this is a bug. Can someone please point me to the right issue tracker for this? (I don't think it's the plugin's fault.) Best wishes, Andreas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Use mvnsh with already installed Maven - how?
Hi I'm looking into mvnsh right now, after having installed Maven 3.0.3 Is there a way to let mvnsh use the installed Maven instead of its own bundled version 3.0.2? Best regards Eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Odd failure with maven-checkstyle-plugin in pluginManagement
Are you sure you know how to spell checkstyle? On 14 December 2011 09:54, Andreas Sewe s...@st.informatik.tu-darmstadt.de wrote: Hi, I have encountered a very odd failure when adding the maven-checkstyle-plugin to my pluginManagement section. Below is the simplest POM that triggers this error (both under Maven 3.0.3 and 3.0.4-RC3): project ... modelVersion4.0.0/modelVersion groupIdorg.example/groupId artifactIdexample/artifactId version0.0.1-SNAPSHOT/version build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ckeckstyle-plugin/artifactId version2.8/version /plugin /pluginManagement /build /project A mvn clean install runs just fine, but as soon as someone actually tries to do something with the pluginManagement entry (a mvn help:effective-pom already triggers this), I get the following warning. [WARNING] The POM for org.apache.maven.plugins:maven-ckeckstyle-plugin:jar:2.8 is missing, no dependency information available [WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-ckeckstyle-plugin:2.8: Plugin org.apache.maven.plugins:maven-ckeckstyle-plugin:2.8 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-ckeckstyle-plugin:jar:2.8 Note the packaging of jar in the above. AFAIK, it should be maven-plugin instead. At any rate, the above is really an error rather than a mere warning. Any attempt to actually use the maven-checkstyle-plugin in build/plugins uses the plugin's default configuration rather than any configuration configured build/pluginManagement/plugins. I strongly suspect this is a bug. Can someone please point me to the right issue tracker for this? (I don't think it's the plugin's fault.) Best wishes, Andreas - 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: Odd failure with maven-checkstyle-plugin in pluginManagement
Stephen Connolly wrote: Are you sure you know how to spell checkstyle? oops, my bad. :-( I thought I had copy-and-pasted the coordinates from search.maven.org throughout my POMs. Apparently, I missed one occurrence. Sorry. Best wishes, Andreas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to set JAVA_HOME for maven?
Hello Guys! Thanks for your replies! I installed jdk 1.7 and reset the JAVA_HOME to that folder. The output of mvn --version now give: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /home/fredrik/Applications/apache-maven-3.0.3 Java version: 1.7.0_02, vendor: Oracle Corporation Java home: /home/fredrik/Applications/jdk1.7.0_02/*jre* Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.0.0-14-generic, arch: i386, family: unix As I see it seems like maven adds the *jre* Best regards Fredrik -- View this message in context: http://maven.40175.n5.nabble.com/How-to-set-JAVA-HOME-for-maven-tp5073695p5074397.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: Building 2 dependent modules
Thanks again folks. Much appreciated! I'll probably specify this in my parent pom then -- View this message in context: http://maven.40175.n5.nabble.com/Building-2-dependent-modules-tp5068822p5074678.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: Multi Module Project Failing - Help Me
There is typo, true but I used some real time project. And names if that project I changed. As I can't give names of that project. But I will tried with ur comments and MainProject pom.xml is working fine. But it's giving this error on execution of module2 so is it like that I have to published module1 ? No way to work locally without that ? On Dec 13, 2011 9:19 PM, Barrie Treloar baerr...@gmail.com wrote: On Wed, Dec 14, 2011 at 3:27 PM, Daivish Shah daivish.s...@gmail.com wrote: Hi Barrie, MainP... Carefully read your error logs and look for typos. Because you have sanitised the output I can not be certain, but there is a typo which Maven reports as MainProject:moduel1:jar:3.0 (instead of module1) - To unsubscribe, e-mail: users...
Re: Failed to determine Java version for profile jdk* @
On Tuesday, December 13, 2011 7:45:29 PM Benson Margulies wrote: On Tue, Dec 13, 2011 at 7:39 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: describe the problem better and point me to some sample code and i will have a think. but profiles containing (compile or runtime scope) deps activated based on the jre that maven is running is wrong wrong wrong, and will only lead to pain. (test and provided scope deps are still wrong in a profile but can be excused as they are non-transitive) The problem is this: different JDKs have different garbage in 'endorsed' in the departments of XML and web services. There are dependencies that have to be ADDED when running in some JDKs, and others that need to be SUBTRACTED. Provided isn't going to work, since (in the first case) we are adding things to the classpath that need to be there to compensate for what isn't there in the particular kit. If you want examples I can go dig them out. Here's a simple example: JAXB On Java5, we have to add both a JAXB-API jar and a JAXB-IMPL jar (and other deps like stax-api) as there is no JAXB stuff built into the JDK. We generally would prefer the latest JAXB stuff (2.2) here as there are no conflicts. On Java6, there is JAXB 2.1 stuff built in. Thus, we DON'T want to add an API jar (extra deps pulled in unnecessarily), but we DO want to pull in a newer JAXB-IMPL that fixes a bunch of bugs. However, it needs to be the latest 2.1.x version, not the newer 2.2 versions as they won't work with the 2.1 API's built into the JDK. (and pulling in a newer API jar would require and endorsing mechanism to override the JDK version) On Java7, JAXB 2.2 is built in. Again, we don't want to bring in an API jar, but we do want the latest 2.2 implementation. Suggestions?It will be a bit easier once we drop support for Java5 and it's just between impls, but at this point, we do need java5 support. Dan - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 14 Dec 2011 00:30, Benson Margulies bimargul...@gmail.com wrote: On Tue, Dec 13, 2011 at 7:24 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: sounds like cxf have been really bold and are adding deps in a profile Yes indeed. *purely for testing* we have profiles that change the dependencies. Got another suggestion? - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 14 Dec 2011 00:02, jaybytez jayby...@yahoo.com wrote: Sorry if this question has already been posted. I have tried running Maven 3.0.3 and Maven 2.2.12 (which is the current version we use for building via Hudson). I have a simple project that has poms it inherits from that were defining a maven-compiler-plugin with the target/source set to jdk1.6. Whether or not this configuration existed, I still get the following error on a project that has dependencies to cxf. I am running Eclipse Helios/m2eclipse. Any thoughts as to why this error exists and how to get rid of it. 12/13/11 3:56:15 PM PST: [WARN] The POM for org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.4.4 is invalid, transitive dependencies (if any) will not be available: 5 problems were encountered while building the effective model for org.apache.cxf:cxf-rt-frontend-jaxws:2.4.4 [ERROR] Failed to determine Java version for profile jdk17 @ [ERROR] Failed to determine Java version for profile jdk15 @ [ERROR] Failed to determine Java version for profile jdk15 @ org.apache.cxf:cxf-parent:2.4.4 [ERROR] Failed to determine Java version for profile jdk17 @ org.apache.cxf:cxf-parent:2.4.4 [ERROR] Failed to determine Java version for profile jdk15 @ org.apache.cxf:cxf:2.4.4 12/13/11 3:56:15 PM PST: [WARN] The POM for org.apache.cxf:cxf-rt-transports-http:jar:2.4.4 is invalid, transitive dependencies (if any) will not be available: 3 problems were encountered while building the effective model for org.apache.cxf:cxf-rt-transports-http:2.4.4 [ERROR] Failed to determine Java version for profile jdk15 @ org.apache.cxf:cxf-parent:2.4.4 [ERROR] Failed to determine Java version for profile jdk17 @ org.apache.cxf:cxf-parent:2.4.4 [ERROR] Failed to determine Java version for profile jdk15 @ org.apache.cxf:cxf:2.4.4 12/13/11 3:56:15 PM PST: [WARN] The POM for org.apache.cxf:cxf-rt-ws-security:jar:2.4.4 is invalid, transitive dependencies (if any) will not be available: 4 problems were encountered while building the effective model for org.apache.cxf:cxf-rt-ws-security:2.4.4 [ERROR] Failed to determine Java version for profile jdk15 @
Re: Failed to determine Java version for profile jdk* @
On 14 December 2011 16:06, Daniel Kulp dk...@apache.org wrote: On Tuesday, December 13, 2011 7:45:29 PM Benson Margulies wrote: On Tue, Dec 13, 2011 at 7:39 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: describe the problem better and point me to some sample code and i will have a think. but profiles containing (compile or runtime scope) deps activated based on the jre that maven is running is wrong wrong wrong, and will only lead to pain. (test and provided scope deps are still wrong in a profile but can be excused as they are non-transitive) The problem is this: different JDKs have different garbage in 'endorsed' in the departments of XML and web services. There are dependencies that have to be ADDED when running in some JDKs, and others that need to be SUBTRACTED. Provided isn't going to work, since (in the first case) we are adding things to the classpath that need to be there to compensate for what isn't there in the particular kit. If you want examples I can go dig them out. Here's a simple example: JAXB On Java5, we have to add both a JAXB-API jar and a JAXB-IMPL jar (and other deps like stax-api) as there is no JAXB stuff built into the JDK. We generally would prefer the latest JAXB stuff (2.2) here as there are no conflicts. On Java6, there is JAXB 2.1 stuff built in. Thus, we DON'T want to add an API jar (extra deps pulled in unnecessarily), but we DO want to pull in a newer JAXB-IMPL that fixes a bunch of bugs. However, it needs to be the latest 2.1.x version, not the newer 2.2 versions as they won't work with the 2.1 API's built into the JDK. (and pulling in a newer API jar would require and endorsing mechanism to override the JDK version) On Java7, JAXB 2.2 is built in. Again, we don't want to bring in an API jar, but we do want the latest 2.2 implementation. Suggestions? It will be a bit easier once we drop support for Java5 and it's just between impls, but at this point, we do need java5 support. Dan Well the key question is who needs these deps? If it is the end users that need the deps... well here's the rub, you will need to produce three artifacts, one for java 5, one for java 6 and one for java 7, in each case pulling in the required deps... [but but but you stammer] This is because if I build on Java 6 an app that targets support for Java 5, then the (helpful) profile activation will bundle the Java 6 deps and not the Java 5 deps I need... making it almost impossible for all but the hero of JDK version dancers to build on their Mac a CXF app that targets a Java 5 environment. On the other hand, it it is unit tests that need the deps... then profiles may be the solution, but I would have a series of aggregator projects with transitive deps to solve your issues, so that you pull in compat-java5 or compat-java6 or compat-java7 with scope test in each module. And while you are at it, order a hit on whoever decided to add JAXB to the endorsed list - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 14 Dec 2011 00:30, Benson Margulies bimargul...@gmail.com wrote: On Tue, Dec 13, 2011 at 7:24 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: sounds like cxf have been really bold and are adding deps in a profile Yes indeed. *purely for testing* we have profiles that change the dependencies. Got another suggestion? - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 14 Dec 2011 00:02, jaybytez jayby...@yahoo.com wrote: Sorry if this question has already been posted. I have tried running Maven 3.0.3 and Maven 2.2.12 (which is the current version we use for building via Hudson). I have a simple project that has poms it inherits from that were defining a maven-compiler-plugin with the target/source set to jdk1.6. Whether or not this configuration existed, I still get the following error on a project that has dependencies to cxf. I am running Eclipse Helios/m2eclipse. Any thoughts as to why this error exists and how to get rid of it. 12/13/11 3:56:15 PM PST: [WARN] The POM for org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.4.4 is invalid, transitive dependencies (if any) will not be available: 5 problems were encountered while building the effective model for org.apache.cxf:cxf-rt-frontend-jaxws:2.4.4 [ERROR] Failed to determine Java version for profile jdk17 @ [ERROR] Failed to determine Java version for profile jdk15 @ [ERROR] Failed to determine Java version for profile jdk15 @ org.apache.cxf:cxf-parent:2.4.4 [ERROR] Failed to determine Java version for profile jdk17 @ org.apache.cxf:cxf-parent:2.4.4
native-maven-plugin suggested patch to avoid redundant relink
I've been asking a question some time ago about redundant relink in native-maven-plugin: http://maven.40175.n5.nabble.com/c-native-maven-plugin-redundant-linking-at-second-run-problem-td3403291.html Finally we've started actually using native-maven-plugin so I've patched the plugin to avoid relink in case of no changes. We have some other modifications as well but we don't want to fork too much from publicly available source so I'd like to send to upstream as much as possible. Please consider the patch http://maven.40175.n5.nabble.com/file/n5075095/maven-native-api.patch maven-native-api.patch http://maven.40175.n5.nabble.com/file/n5075095/native-maven-plugin.patch native-maven-plugin.patch -- View this message in context: http://maven.40175.n5.nabble.com/native-maven-plugin-suggested-patch-to-avoid-redundant-relink-tp5075095p5075095.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: Failed to determine Java version for profile jdk* @
The jdk profile is something I tried to address locally as well by defining my own jdk profiles, but I finally removed them since we are only building against jdk16 and most of the reason I was using the profiles was to fix jdk15 issues. These profiles are gone. The question I have is why do I get the Failed to determine Java version for profile. I know previous versions of m2eclipse did not enable the jdk profile by default. I have my projects set to use the workspace JRE (which is a 1.6.0_21) and for suggested performance, my Helios eclipse.ini points to: -vm C:/Development/dev/java/jdk1.6.0_21/jre/bin/client/jvm.dll Should Maven or m2eclipse establish that my JDK is 1.6 and activate the correct profiles in the 3rd party libraries? The interesting thing is that I pretty much seem to get these related errors with apis that have to interact with XML (and I understand why because of the endorsed). So xstream and hibernate are throwing the same issue. 12/14/11 9:17:10 AM PST: [WARN] The POM for com.thoughtworks.xstream:xstream:jar:1.3.1 is invalid, transitive dependencies (if any) will not be available: 6 problems were encountered while building the effective model for com.thoughtworks.xstream:xstream:1.3.1 [ERROR] Failed to determine Java version for profile jdk15 @ [ERROR] Failed to determine Java version for profile jdk16 @ [ERROR] Failed to determine Java version for profile jdk14 @ [ERROR] Failed to determine Java version for profile jdk16 @ com.thoughtworks.xstream:xstream-parent:1.3.1 [ERROR] Failed to determine Java version for profile jdk15 @ com.thoughtworks.xstream:xstream-parent:1.3.1 [ERROR] Failed to determine Java version for profile jdk14 @ com.thoughtworks.xstream:xstream-parent:1.3.1 12/14/11 9:17:10 AM PST: [WARN] The POM for org.hibernate:hibernate-entitymanager:jar:3.6.0.Final is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for org.hibernate:hibernate-entitymanager:3.6.0.Final [ERROR] Failed to determine Java version for profile jaxb @ Thanks for all your help. I thoroughly love both projects (Maven and CXF) and we have been doing some awesome stuff with these projects. Jay -- View this message in context: http://maven.40175.n5.nabble.com/Failed-to-determine-Java-version-for-profile-jdk-tp5073097p5075150.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: native-maven-plugin suggested patch to avoid redundant relink
Could you create a Jira issue[1], together with these patches. This issue tracking system is a much better place to keep track of an issue instead of a mailinglist. -Robert [1] https://jira.codehaus.org/browse/MOJO/component/11773 Date: Wed, 14 Dec 2011 09:12:22 -0800 From: sintet...@gmail.com To: users@maven.apache.org Subject: native-maven-plugin suggested patch to avoid redundant relink I've been asking a question some time ago about redundant relink in native-maven-plugin: http://maven.40175.n5.nabble.com/c-native-maven-plugin-redundant-linking-at-second-run-problem-td3403291.html Finally we've started actually using native-maven-plugin so I've patched the plugin to avoid relink in case of no changes. We have some other modifications as well but we don't want to fork too much from publicly available source so I'd like to send to upstream as much as possible. Please consider the patch http://maven.40175.n5.nabble.com/file/n5075095/maven-native-api.patch maven-native-api.patch http://maven.40175.n5.nabble.com/file/n5075095/native-maven-plugin.patch native-maven-plugin.patch -- View this message in context: http://maven.40175.n5.nabble.com/native-maven-plugin-suggested-patch-to-avoid-redundant-relink-tp5075095p5075095.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: native-maven-plugin suggested patch to avoid redundant relink
Robert, Done, https://jira.codehaus.org/browse/MOJO-1793. Regards, Sergey. On Wed, Dec 14, 2011 at 9:55 PM, Robert Scholte [via Maven] ml-node+s40175n5075214...@n5.nabble.com wrote: Could you create a Jira issue[1], together with these patches. This issue tracking system is a much better place to keep track of an issue instead of a mailinglist. -Robert [1] https://jira.codehaus.org/browse/MOJO/component/11773 Date: Wed, 14 Dec 2011 09:12:22 -0800 From: [hidden email]http://user/SendEmail.jtp?type=nodenode=5075214i=0 To: [hidden email]http://user/SendEmail.jtp?type=nodenode=5075214i=1 Subject: native-maven-plugin suggested patch to avoid redundant relink I've been asking a question some time ago about redundant relink in native-maven-plugin: http://maven.40175.n5.nabble.com/c-native-maven-plugin-redundant-linking-at-second-run-problem-td3403291.html Finally we've started actually using native-maven-plugin so I've patched the plugin to avoid relink in case of no changes. We have some other modifications as well but we don't want to fork too much from publicly available source so I'd like to send to upstream as much as possible. Please consider the patch http://maven.40175.n5.nabble.com/file/n5075095/maven-native-api.patch maven-native-api.patch http://maven.40175.n5.nabble.com/file/n5075095/native-maven-plugin.patch native-maven-plugin.patch -- View this message in context: http://maven.40175.n5.nabble.com/native-maven-plugin-suggested-patch-to-avoid-redundant-relink-tp5075095p5075095.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=5075214i=2 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=5075214i=3 - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=5075214i=4 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=5075214i=5 -- If you reply to this email, your message will be added to the discussion below: http://maven.40175.n5.nabble.com/native-maven-plugin-suggested-patch-to-avoid-redundant-relink-tp5075095p5075214.html To unsubscribe from native-maven-plugin suggested patch to avoid redundant relink, click herehttp://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5075095code=c2ludGV0aWs3QGdtYWlsLmNvbXw1MDc1MDk1fC0xMzMxOTgyMDc= . NAMLhttp://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespacebreadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://maven.40175.n5.nabble.com/native-maven-plugin-suggested-patch-to-avoid-redundant-relink-tp5075095p5075431.html Sent from the Maven - Users mailing list archive at Nabble.com.
Re: Multi Module Project Failing - Help Me
On Thu, Dec 15, 2011 at 1:38 AM, Daivish Shah daivish.s...@gmail.com wrote: There is typo, true but I used some real time project. And names if that project I changed. As I can't give names of that project. But I will tried with ur comments and MainProject pom.xml is working fine. But it's giving this error on execution of module2 so is it like that I have to published module1 ? No way to work locally without that ? It should work. That's why I suspect you have a typo, or you haven't run mvn install. Double and triple check the output with the values in your poms, and get someone else to have a look at them too. You should spot your problem. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Conflicting Spring versions
I have a multi-module project with a parent pom and several sub-modules. In one of the module, I have a dependency that has a transitive dependency of spring (2.0.6). How do I go about having the rest of my project using Spring 3.0.6.RELEASE? Thanks. -- View this message in context: http://maven.40175.n5.nabble.com/Conflicting-Spring-versions-tp5075558p5075558.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: Multi Module Project Failing - Help Me
Hi Barrie, I got the real problem but still looking for solution. module1 is XSD type project means it generates classes file and JAR file based on XSD information. And i am defining module1 project as dependency of module2 project, Still my eclipse is giving compilation error on import statement of module1 package files in module2 project. Thanks, daivish. On Wed, Dec 14, 2011 at 12:15 PM, Barrie Treloar baerr...@gmail.com wrote: On Thu, Dec 15, 2011 at 1:38 AM, Daivish Shah daivish.s...@gmail.com wrote: There is typo, true but I used some real time project. And names if that project I changed. As I can't give names of that project. But I will tried with ur comments and MainProject pom.xml is working fine. But it's giving this error on execution of module2 so is it like that I have to published module1 ? No way to work locally without that ? It should work. That's why I suspect you have a typo, or you haven't run mvn install. Double and triple check the output with the values in your poms, and get someone else to have a look at them too. You should spot your problem. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Conflicting Spring versions
On 14/12/2011 3:17 PM, scabbage wrote: I have a multi-module project with a parent pom and several sub-modules. In one of the module, I have a dependency that has a transitive dependency of spring (2.0.6). How do I go about having the rest of my project using Spring 3.0.6.RELEASE? You are going to run Spring 3.0.6 when the application is running. 2.0.6 has to go. One Spring at a time. Exclude the transitive dependency on Spring in the sub module's dependency definition. Happens all the time and not just with Spring - a lot of Apache commons versions will get dragged in as transitive dependencies. Look at your dependency graph or list Ron Thanks. -- View this message in context: http://maven.40175.n5.nabble.com/Conflicting-Spring-versions-tp5075558p5075558.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 -- 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: Multi Module Project Failing - Help Me
On 14/12/2011 4:36 PM, Daivish Shah wrote: Hi Barrie, I got the real problem but still looking for solution. module1 is XSD type project means it generates classes file and JAR file based on XSD information. And i am defining module1 project as dependency of module2 project, Still my eclipse is giving compilation error on import statement of module1 package files in module2 project. Try mvn install of module 1 by itself and see if you still have an error. If Module1's jar file in your repo? If you look inside the jar does it have the classes in question? Have you tried -x to get more debugging details? Ron Thanks, daivish. On Wed, Dec 14, 2011 at 12:15 PM, Barrie Treloarbaerr...@gmail.com wrote: On Thu, Dec 15, 2011 at 1:38 AM, Daivish Shahdaivish.s...@gmail.com wrote: There is typo, true but I used some real time project. And names if that project I changed. As I can't give names of that project. But I will tried with ur comments and MainProject pom.xml is working fine. But it's giving this error on execution of module2 so is it like that I have to published module1 ? No way to work locally without that ? It should work. That's why I suspect you have a typo, or you haven't run mvn install. Double and triple check the output with the values in your poms, and get someone else to have a look at them too. You should spot your problem. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- 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: Multi Module Project Failing - Help Me
On Thu, Dec 15, 2011 at 8:06 AM, Daivish Shah daivish.s...@gmail.com wrote: Hi Barrie, I got the real problem but still looking for solution. module1 is XSD type project means it generates classes file and JAR file based on XSD information. And i am defining module1 project as dependency of module2 project, Still my eclipse is giving compilation error on import statement of module1 package files in module2 project. There is your problem right there. This is an Eclipse problem not Maven. p.s when you say I got the real problem but still looking for solution., it would be handy for the archives for you to detail what you did so that others searching the internet can find the answers for next time. How are you configuring Eclipse? You will find that a xmlbean project will generate its source in target/generated-sources/xmlbeans and at least the version of org.codehaus.mojo:xmlbeans-maven-plugin we are using requires us to manually add this source directory via build-helper so that maven-eclipse-plugin can include that directory automatically. I do that like so ... plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId executions execution phasegenerate-sources/phase goals goaladd-source/goal /goals configuration sources sourcetarget/generated-sources/xmlbeans/source /sources /configuration /execution /executions /plugin ... /plugins /build By default maven-eclipse-plugin will use project references. So module2 depends upon module1's project in Eclipse. Because the classpath for module1 has not been correctly setup (i.e. its missing target/generated-sources/xmlbeans) then module2 won't be able to build correctly. If module2 had been setup to use the jars in the repo instead, then you would not be having this problem. (I prefer Eclipse project references and not links to jars in the repo for projects that I am working on) Of course if you are not use maven-eclipse-plugin I dont know what the problem is, but the cause would be similar. Normally I manually fix the build path's in Eclipse to get things working, and then backtrack to determine why this wasn't done automatically for me. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Conflicting Spring versions
On Thu, Dec 15, 2011 at 8:21 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 14/12/2011 3:17 PM, scabbage wrote: I have a multi-module project with a parent pom and several sub-modules. In one of the module, I have a dependency that has a transitive dependency of spring (2.0.6). How do I go about having the rest of my project using Spring 3.0.6.RELEASE? You are going to run Spring 3.0.6 when the application is running. 2.0.6 has to go. One Spring at a time. Exclude the transitive dependency on Spring in the sub module's dependency definition. Happens all the time and not just with Spring - a lot of Apache commons versions will get dragged in as transitive dependencies. Look at your dependency graph or list Use http://maven.apache.org/plugins/maven-dependency-plugin/ Either mvn dependency:tree or mvn dependency:list - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Conflicting Spring versions
Am 14.12.2011 23:49, schrieb Barrie Treloar: Use http://maven.apache.org/plugins/maven-dependency-plugin/ Either mvn dependency:tree or mvn dependency:list Plus: use maven-enforcer-plugin with rule dependencyConvergence http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html Regards Ansgar
Re: Conflicting Spring versions
On Thu, Dec 15, 2011 at 10:10 AM, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Am 14.12.2011 23:49, schrieb Barrie Treloar: Use http://maven.apache.org/plugins/maven-dependency-plugin/ Either mvn dependency:tree or mvn dependency:list Plus: use maven-enforcer-plugin with rule dependencyConvergence http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html +1 on enforcer. Its a great best practice to include to make sure you aren't doing something silly with versions. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Best way to handle an ssh copy?
We have several artifacts that we want to copy to remote servers via scp/ssh. I have looked at the wagon plugin but the documentation seems to have issues. When I try to use it as documented I get an error telling me it can't find a plugin descriptor for wagon-ssh. Is there a good way to get maven to scp files to a remote server and where can I find documentation on how to do this. Thank TOm - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best way to handle an ssh copy?
maybe the ship-maven-plugin could help... though if you want to use a wagon that is non-default for the maven version you are using (eg ssh is non default in maven 3.0.3) you will need to either add that wagon as a dependency of *the plugin* or add that wagon as an extension to *the project's build* - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 15 Dec 2011 00:28, Tom Masterson kd7...@gmail.com wrote: We have several artifacts that we want to copy to remote servers via scp/ssh. I have looked at the wagon plugin but the documentation seems to have issues. When I try to use it as documented I get an error telling me it can't find a plugin descriptor for wagon-ssh. Is there a good way to get maven to scp files to a remote server and where can I find documentation on how to do this. Thank TOm --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Conflicting Spring versions
Great! Thanks for the suggestions. The organization of my project is: parent - module1 - module2 Following your advice, I did: parent: project groupIdtest/groupId artifactIdparent/artifactId version1.0-SNAPSHOT/version packagingpom/packaging modules modulemodule1/module modulemodule2/module /modules dependency groupIdorg.springframework/groupId artifactIdspring-context/artifactId version3.0.6.RELEASE/version /dependency /project module1: project parent groupIdtest/groupId artifactIdparent/artifactId version1.0-SNAPSHOT/version /parent artifactIdmodule1/artifactId dependencies dependency groupIdtest/groupId artifactIdmodule2/artifactId version1.0-SNAPSHOT/version /dependency /dependencies /project module2: project parent groupIdtest/groupId artifactIdparent/artifactId version1.0-SNAPSHOT/version /parent artifactIdmodule2/artifactId dependencies dependency groupIdfoo/groupId artifactIdbar/artifactId version1.0/version exclusions exclusion groupIdorg.springframework/groupId artifactIdspring/artifactId /exclusion /exclusions /dependency /dependencies /project It works like a charm :) -- View this message in context: http://maven.40175.n5.nabble.com/Conflicting-Spring-versions-tp5075558p5076112.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: Conflicting Spring versions
On Thu, Dec 15, 2011 at 11:21 AM, scabbage guans...@gmail.com wrote: Great! Thanks for the suggestions. The organization of my project is: parent - module1 - module2 Following your advice, I did: parent: project groupIdtest/groupId artifactIdparent/artifactId version1.0-SNAPSHOT/version packagingpom/packaging modules modulemodule1/module modulemodule2/module /modules dependency groupIdorg.springframework/groupId artifactIdspring-context/artifactId version3.0.6.RELEASE/version /dependency /project module1: project parent groupIdtest/groupId artifactIdparent/artifactId version1.0-SNAPSHOT/version /parent artifactIdmodule1/artifactId dependencies dependency groupIdtest/groupId artifactIdmodule2/artifactId version1.0-SNAPSHOT/version /dependency /dependencies /project module2: project parent groupIdtest/groupId artifactIdparent/artifactId version1.0-SNAPSHOT/version /parent artifactIdmodule2/artifactId dependencies dependency groupIdfoo/groupId artifactIdbar/artifactId version1.0/version exclusions exclusion groupIdorg.springframework/groupId artifactIdspring/artifactId /exclusion /exclusions /dependency /dependencies /project It works like a charm :) I recommend that your parent stop using dependency and use depenencyManagement. See http://maven.apache.org/ref/3.0.3/maven-model/maven.html If you use dependency you are saying that any child of this project MUST include any dependencies specified in the parent. I also recommend that you removed ALL versions from your child poms. Use the dependencyManagement section of the paren instead. This allows you to adjust version information in one place AND ensure that no one is slipping in a new dependency under the radar. If they try to slip a new dependency in the build will blow up since the parent hasn't got that version defined. I dont think enforcer can enforce this setup, its something you have to actively manage - perhaps at least every release cycle. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Conflicting Spring versions
I'm including a dependencies section in my parent pom to capture all common dependencies of my modules. But I agree that I should use the dependencyManagement to management all versions. -- View this message in context: http://maven.40175.n5.nabble.com/Conflicting-Spring-versions-tp5075558p5076442.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: Conflicting Spring versions
On Thu, Dec 15, 2011 at 2:17 PM, scabbage guans...@gmail.com wrote: I'm including a dependencies section in my parent pom to capture all common dependencies of my modules. But I agree that I should use the dependencyManagement to management all versions. Its not something I do, and I think its considered bad practice. I think there is a new import scope (I've not used it) that would be a better way of capturing this information. On the other hand - how common are these common dependencies. It would have to be the least common denominator, in which case it probably doesn't save you a lot. Just repeat the dependencies in the modules knowing the version management is taken care of by dependencyManagement. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
