Re: how to deploy a nonbuild maven war in tomcat with maven2
First, what you're trying to do is not the normal use case for Maven as a build tool. I'd say you want to use Maven as some kind of utility. Therefore, the way to solve your need is not as straight forward as following the Maven way. So, first, do you really need to use Maven? Why not continue to use Ant (or whatever you use to build the war)? If you still want to use Maven, I'd say the best way to solve things is to deploy the war to a Maven repo in your current build (you can use the Maven Ant task or any proprietary API for your repo manager). You then create a new Maven project with a dependency to this war artifact and use, for example, cargo to launch tomcat with the war deployed. Then use some Maven plugin to do your selenium testing. If you don't install the war in a repository, your need to do some Maven tweaking (not the Maven way!). I don't recommend this and don't really want to explain how to solve this as it will lead to so many questions and a life time support case. :-) But if anyone else wants to have a try, please do so. /Anders On Tue, Mar 29, 2011 at 07:53, ensienne t.zei...@gmail.com wrote: I have a war generated by a non build maven. this war is placed in /home/usr/ws/myapp/target/app.war I want to create a maven project that can deploy this war into installed tomcat (/usr/home/tomcat-6), launch it. The next step is to run some selenium tests on this war. I have created a maven project with the pom linked but it does not work. there is no error displayed and it does nothing ( no war deployed). I hope that this clarify my need. Thank you very much for your help -- View this message in context: http://maven.40175.n5.nabble.com/how-to-deploy-a-nonbuild-maven-war-in-tomcat-with-maven2-tp4267525p4268820.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: how to deploy a nonbuild maven war in tomcat with maven2
thanks Anders. I am beginner on maven. So can you please how to do that If you still want to use Maven, I'd say the best way to solve things is to deploy the war to a Maven repo in your current build (you can use the Maven Ant task or any proprietary API for your repo manager). You then create a new Maven project with a dependency to this war artifact and use, for example, cargo to launch tomcat with the war deployed. Then use some Maven plugin to do your selenium testing. = How can I use the Maven Ant task or any proprietary API for your repo manager. Many thanks -- View this message in context: http://maven.40175.n5.nabble.com/how-to-deploy-a-nonbuild-maven-war-in-tomcat-with-maven2-tp4267525p4268847.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: how to deploy a nonbuild maven war in tomcat with maven2
Ant Maven task: use Google. There info out there. Repo manager API: Talk to the people at your organization who manages this. If you still need help, ask on the users list of that repo manager. /Anders On Tue, Mar 29, 2011 at 08:29, ensienne t.zei...@gmail.com wrote: thanks Anders. I am beginner on maven. So can you please how to do that If you still want to use Maven, I'd say the best way to solve things is to deploy the war to a Maven repo in your current build (you can use the Maven Ant task or any proprietary API for your repo manager). You then create a new Maven project with a dependency to this war artifact and use, for example, cargo to launch tomcat with the war deployed. Then use some Maven plugin to do your selenium testing. = How can I use the Maven Ant task or any proprietary API for your repo manager. Many thanks -- View this message in context: http://maven.40175.n5.nabble.com/how-to-deploy-a-nonbuild-maven-war-in-tomcat-with-maven2-tp4267525p4268847.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: how to deploy a nonbuild maven war in tomcat with maven2
google is your friend: maven ant tasks deploy - 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 29 Mar 2011 07:30, ensienne t.zei...@gmail.com wrote:
eclipse intergration
Does this list also concerns eclipse integration? Zbynek Kind Regards / Mit freundlichen Grüßen / Üdvözlettel / S pozdravem: Zbynek VAVROS (Embedded Development image moved to file: pic14445.gif) Delivery Centre 616 00, Brno Central Europe Technicka 21 Brno SITE Czech Republic (Embedded image moved to file: pic09819.gif)Phone: 420-53341- x6283 Mobile: E-mail: zbynek_vav...@cz.ibm.com IBM Global Services Delivery Center Czech Republic, s.r.o. Registered address: Brno, Technicka 2995/21, Zip code: 61600, Company ID: 26244535 Entered in the Commercial Register maintained by the Regional Court in Brno (Part C, Entry 39922) IBM Global Services Delivery Center Czech Republic, s.r.o. Sídlo: Brno, Technická 2995/21, PSČ 61600 IČ: 26244535 Zapsaná v obchodním rejstříku, vedeném Krajským soudem v Brně oddíl C, vlozka 39922 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: eclipse intergration
You can find the m2eclipse mailing lists here: http://m2eclipse.sonatype.org/project-information.html Manuel 2011/3/29 Zbynek Vavros zbynek_vav...@cz.ibm.com: Does this list also concerns eclipse integration? Zbynek Kind Regards / Mit freundlichen Grüßen / Üdvözlettel / S pozdravem: Zbynek VAVROS (Embedded Development image moved to file: pic14445.gif) Delivery Centre 616 00, Brno Central Europe Technicka 21 Brno SITE Czech Republic (Embedded image moved to file: pic09819.gif) Phone: 420-53341- x6283 Mobile: E-mail: zbynek_vav...@cz.ibm.com IBM Global Services Delivery Center Czech Republic, s.r.o. Registered address: Brno, Technicka 2995/21, Zip code: 61600, Company ID: 26244535 Entered in the Commercial Register maintained by the Regional Court in Brno (Part C, Entry 39922) IBM Global Services Delivery Center Czech Republic, s.r.o. Sídlo: Brno, Technická 2995/21, PSČ 61600 IČ: 26244535 Zapsaná v obchodním rejstříku, vedeném Krajským soudem v Brně oddíl C, vlozka 39922 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Mojo's Cassandra Maven Plugin 0.7.4-1 released
Hi, The Mojo team is pleased to announce the release of Mojo's Cassandra Maven Plugin version 0.7.4-1. Mojo's Cassandra Plugin is used when you want to install and control a test instance of Apache Cassandra from within your Apache Maven build. The plugin has the following goals. * cassandra:start Starts up a test instance of Cassandra in the background. * cassandra:stop Stops the test instance of Cassandra that was started using cassandra:start. * cassandra:run Starts up a test instance of Cassandra in the foreground. * cassandra:load Runs a cassandra-cli script against the test instance of Cassandra. * cassandra:repair Runs nodetool repair against the test instance of Cassandra. * cassandra:flush Runs nodetool flush against the test instance of Cassandra. * cassandra:compact Runs nodetool compact against the test instance of Cassandra. * cassandra:cleanup Runs nodetool cleanup against the test instance of Cassandra. * cassandra:delete Deletes the the test instance of Cassandra. http://mojo.codehaus.org/cassandra-maven-plugin/ To use this version, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdcassandra-maven-plugin/artifactId version0.7.4-1/version /plugin Release Notes - Mojo's Cassandra Maven Plugin - Version 0.7.4-1 ** Improvement * [MCASSANDRA-6] - Upgrade to Cassandra 0.7.4 Enjoy, The Mojo team. Apache, Apache Maven, Apache Cassandra, Maven and Cassandra are trademarks of The Apache Software Foundation. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Antwort: Re: mvn deploy and site in one go
another idea could be to call Maven with the --fail-at-end (-fae) option. But this doesn't seem to work with Maven 3 anymore. Even if 'fail-at-end' was working: wouldn't the artifacts still be deployed, when running 'mvn deploy' ? Yes, You're right - didn't think about that. It could be solved if You add another build configuration (mvn deploy -Dmaven.test.skip=true) that is only triggered when the main build finishes successfully. Our buildtimes vary from 30min to 3hour (yeah - big heavy integration tests). How are the integration tests executed in Your build? You should use the maven-failsave-plugin instead of the maven-surefire-plugin. The maven-failsave-plugin doesn't fail the build, but the test failures will be in Your reports. Another (last) idea, that just occurred to me: You could try to avoid build configurations for multi module projects and have a separate build configuration for every single module (per POM). This should decrease the number of tests per build execution so that it might be affordable if tests are executed twice. Build configurations would be triggered by VCS changes and snapshot dependencies. (Maybe not suitable for You but at least another idea) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven-plugin-tools-ant and sub-projects
I created an Ant plugin with maven-plugin-tools-ant for a certain task, as described here: http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html My plugin works fine otherwise, but I just noticed that it does not recurse into the sub-projects like a normal plugin would. That is, if I call mvn myplugin:myplugin on the level of the parent pom, it only executes the plugin on the level of parent pom and the stops. Is there a way to get the Ant plugin to recurse into the subprojects as well? Juha -- View this message in context: http://maven.40175.n5.nabble.com/Maven-plugin-tools-ant-and-sub-projects-tp4269419p4269419.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
Versions in dependencyManagement vs dependency?
Got a bit of an architecture/style question here. I'm familiar with the use of the dependencyManagement block in a parent pom to fix versions of or otherwise configure a dependency. However, except for cases which need it (for example, when transitive dependencies are otherwise pulling in two versions of the same JAR) I typically don't put versions there, but instead in the pom where I'm declaring the dependency itself. I think this is pretty much SOP, if I'm not mistaken. Now someone on my team has asked why we shouldn't put ALL versions in the parent POM (in dependencyManagement blocks, so as not to create additional dependencies). While my initial gut reaction is that's a bad idea (since dependency info would then be in at least two places) I thought I'd see if anyone else there has tried this and has any pros or cons around the practice. Thanks - Don
Re: Versions in dependencyManagement vs dependency?
it depends on how often you update versions and how often you will release the parent. if you update versions very often, but you don't want to release the parent very often, then don't do it. what I tend to do is aggregate the version info as high up in each independently releasable tree. On 29 March 2011 15:13, Brinker, Don-NONEMP dbrin...@collegeboard.org wrote: Got a bit of an architecture/style question here. I'm familiar with the use of the dependencyManagement block in a parent pom to fix versions of or otherwise configure a dependency. However, except for cases which need it (for example, when transitive dependencies are otherwise pulling in two versions of the same JAR) I typically don't put versions there, but instead in the pom where I'm declaring the dependency itself. I think this is pretty much SOP, if I'm not mistaken. Now someone on my team has asked why we shouldn't put ALL versions in the parent POM (in dependencyManagement blocks, so as not to create additional dependencies). While my initial gut reaction is that's a bad idea (since dependency info would then be in at least two places) I thought I'd see if anyone else there has tried this and has any pros or cons around the practice. Thanks - Don - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Problems with m2e and resource filtering
Hi everyone. I'm having problems with M2Eclipse and resource filtering. I know it concerns to M2E mailing list, but I´m posting it here because maybe someone here has already solve it somehow and could help me with this. All information is in the post I made on M2Eclipse users mailing list (including the project to help you reproduce the error): http://dev.eclipse.org/mhonarc/lists/m2e-users/msg00410.html Thanks and regards, Rafael Vanderlei.
Re: Versions in dependencyManagement vs dependency?
Well, we put all the versions in the parent pom. It makes the versions easy to change from the project's perspective. You don't have to browse through many files to see where the dependency is declared. Also, two or more of the sub-project may have a dependency on a same artifact, and if you put the version in the parent pom, you have the version in only one place. -- View this message in context: http://maven.40175.n5.nabble.com/Versions-in-dependencyManagement-vs-dependency-tp4269473p4269530.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
Compiling modules with different jdk versions
I have a multi-project configuration with a parent pom specifying a compiler plugin with a default of jdk1.5 specified in the parent pom's dependency management section. However, I have two submodules with packaging as jars that need to be compiled with jdk1.4. I tried overriding the compiler plugin in the submodule pom for these two, but instead it tries to compile it twice; first with jdk1.5, then with jdk1.4 (which does nothing because it consideres the output from the previous compile up-to-date). As I understand it, the jar packaging is pulling in the default jdk1.5 compile. How can configure the maven compiler plugin for jdk1.4 for just these modules? Thanks, Mark Jenison This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Apache Maven 3.0.2-RC1
I'm getting this error using Maven 3.0.3 for a maven-metadata-local.xml file Snapshot information corrupted with remote repository data, please verify that no remote repository uses the id 'local' My metadata file looks simply like this: ?xml version=1.0 encoding=UTF-8? org.apache.solr solr-core 4.0-SNAPSHOT 1 20100720183735 I'm not sure what I should do with this error. The code I'm building, Solr, does not have any poms referring to a repo named local. Nor is there one in my settings.xml. I do recall once naming a repo that way but since Maven 3 complained I renamed it. ~ David Smiley - Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book -- View this message in context: http://maven.40175.n5.nabble.com/PLEASE-TEST-Apache-Maven-3-0-2-RC1-tp3329599p4269562.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: Compiling modules with different jdk versions
toolchains On 29 March 2011 17:12, Jenison, Mark A mark.a.jeni...@jpmchase.com wrote: I have a multi-project configuration with a parent pom specifying a compiler plugin with a default of jdk1.5 specified in the parent pom's dependency management section. However, I have two submodules with packaging as jars that need to be compiled with jdk1.4. I tried overriding the compiler plugin in the submodule pom for these two, but instead it tries to compile it twice; first with jdk1.5, then with jdk1.4 (which does nothing because it consideres the output from the previous compile up-to-date). As I understand it, the jar packaging is pulling in the default jdk1.5 compile. How can configure the maven compiler plugin for jdk1.4 for just these modules? Thanks, Mark Jenison This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. - 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: Versions in dependencyManagement vs dependency?
juranta wrote: Well, we put all the versions in the parent pom. It makes the versions easy to change from the project's perspective. You don't have to browse through many files to see where the dependency is declared. Also, two or more of the sub-project may have a dependency on a same artifact, and if you put the version in the parent pom, you have the version in only one place. Same here. No version info in explicit dependencies. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Versions in dependencyManagement vs dependency?
We follow Stephen's path but build aggregation poms that only contain libraries so that our project POMs only depend on our libraries. For example if the war file needs the Apache Commons that we support in our development environment, the project will depend on the current version of ours-lib-commons.pom. This reduces the project poms to 5-6 dependencies that are almost always the same so it is easy to start a new WAR project. This provides central control (only 3 developers) over what versions are used and the JAR file produced by the library pom is shared in Tomcat and has provided scope in the WAR project so the war files are really small with only our code and WEB-INF files included. This makes the developers life easy since the versions of libraries are settled once for each release and are not a PITA for the programmer. This saves a lot of time when building and deploying since we use web services and lots of other big tool kits that can take a 20K of classes, jsps, etc. and turn it into a 20M monster. We have about 10 library POMs and over 50 war file POMs. Ron On 29/03/2011 12:39 PM, Jörg Schaible wrote: juranta wrote: Well, we put all the versions in the parent pom. It makes the versions easy to change from the project's perspective. You don't have to browse through many files to see where the dependency is declared. Also, two or more of the sub-project may have a dependency on a same artifact, and if you put the version in the parent pom, you have the version in only one place. Same here. No version info in explicit dependencies. - Jörg - 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: Versions in dependencyManagement vs dependency?
On Tue, Mar 29, 2011 at 1:22 PM, Ron Wheeler rwhee...@artifact-software.com wrote: We follow Stephen's path but build aggregation poms that only contain libraries so that our project POMs only depend on our libraries. For example if the war file needs the Apache Commons that we support in our development environment, the project will depend on the current version of ours-lib-commons.pom. Just out of curiosity, where is it written down that one can depend on an artifact of type pom? I've always been curious about this. L
Re: Versions in dependencyManagement vs dependency?
On Tue, Mar 29, 2011 at 1:59 PM, Laird Nelson ljnel...@gmail.com wrote: Just out of curiosity, where is it written down that one can depend on an artifact of type pom? I've always been curious about this. Are you asking about import scope? http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Versions in dependencyManagement vs dependency?
On Tue, Mar 29, 2011 at 2:01 PM, Wendy Smoak wsm...@gmail.com wrote: Are you asking about import scope? http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies I guess I am; is it required that when you're using import scope that the type element be set to pom? I assume, therefore, that type pom is not applicable anywhere else except (a) inside a dependency management entry that (b) has scope import? L
Re: Compiling modules with different jdk versions
On Tue, Mar 29, 2011 at 12:12 PM, Jenison, Mark A mark.a.jeni...@jpmchase.com wrote: I have a multi-project configuration with a parent pom specifying a compiler plugin with a default of jdk1.5 specified in the parent pom's dependency management section. However, I have two submodules with packaging as jars that need to be compiled with jdk1.4. Does it really need to be compiled _with_ 1.4, or just _for_ 1.4? You can set the -source and -target arguments for javac by configuring the compiler plugin, and then you'll get a 1.4 compatible jar. http://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html Otherwise, this might help... http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html If you're still having trouble, paste the relevant snippets of your pom into your email so we can see what you're doing, or construct a sample project that someone can try. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Versions in dependencyManagement vs dependency?
On 29/03/2011 1:59 PM, Laird Nelson wrote: On Tue, Mar 29, 2011 at 1:22 PM, Ron Wheelerrwhee...@artifact-software.com wrote: We follow Stephen's path but build aggregation poms that only contain libraries so that our project POMs only depend on our libraries. For example if the war file needs the Apache Commons that we support in our development environment, the project will depend on the current version of ours-lib-commons.pom. Just out of curiosity, where is it written down that one can depend on an artifact of type pom? I've always been curious about this. L In the case that I described, the actual dependency is on the JAR. The aggregation POM produces a JAR that is deployed in our Nexus and is available like any other third party library and installed in Tomcat's /lib as part of the application upgrade. In the days of cloud servers, a Tomcat dedicated to one application is pretty easy to defend if anyone questions the possibility of library conflicts between applications. Sorry for the confusion. A bit of sloppy writing. I will try to defend myself by characterizing my description as over abstracted. We only use scope compile or provided. Ron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Procedure for updating Internal Repo with 3rd party
Hi What's the best procedure for uploading 3rd party artifacts to an internal repository. This doc explains how to update the local cached repository but not a central internal repository. http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html I have used the depoy:deploy-file plugin but this does not seem to include the pom, the md5 and sha1 files. In addition, some projects have a parent pom structure as well. I currently do not use a Repository Manager and am looking for a generic way to perform this task. Here is an example of what I would like to upload to my central repostory Directory of c:\internal_repo1\javax\mail\mail\1.4.2 mail-1.4.2-sources.jar mail-1.4.2-sources.jar.md5 mail-1.4.2-sources.jar.sha1 mail-1.4.2.jar mail-1.4.2.jar.md5 mail-1.4.2.jar.sha1 mail-1.4.2.pom mail-1.4.2.pom.md5 mail-1.4.2.pom.sha1 maven-metadata.xml maven-metadata.xml.md5 maven-metadata.xml.sha1 Please note that this repository already have previous versions so and I would like to make sure it's metadata files are updated correctly in the parent directory. Ie: Directory of c:\internal_repo1\javax\mail\mail DIR 1.3.1 DIR 1.3.2 DIR 1.3.3 DIR 1.3.3_01 DIR 1.4 maven-metadata-local.xml maven-metadata.xml maven-metadata.xml.md5 maven-metadata.xml.sha1 thanks *This e-mail and any attachments may contain content protected under federal law and is also confidential and proprietary in nature. If you received this message in error, please notify the sender immediately and delete the original and destroy all copies of the message and any attachments. Any other use of this e-mail by you including retaining, using, copying, distributing, or otherwise disclosing this information in any manner is prohibited.
Re: Procedure for updating Internal Repo with 3rd party
On Tue, Mar 29, 2011 at 1:06 PM, Godschall, John jgodsch...@firstmarblehead.com wrote: I have used the depoy:deploy-file plugin but this does not seem to include the pom, the md5 and sha1 files. In addition, some projects have a parent pom structure as well. Can you paste the command you used, and what happened? There is an option to generate the pom, or to provide it if you have one for the artifact already. http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html I currently do not use a Repository Manager Well, there's the real solution. ;) Why not? You can run it locally and point to http://localhost instead of (I assume) file:///internal_repo1 . -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Versions in dependencyManagement vs dependency?
Tim talks about this in this blog post: http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/ A pom artifact is an artifact like all others...it's just that the artifact is the pom itself. /Anders On Tue, Mar 29, 2011 at 19:59, Laird Nelson ljnel...@gmail.com wrote: On Tue, Mar 29, 2011 at 1:22 PM, Ron Wheeler rwhee...@artifact-software.com wrote: We follow Stephen's path but build aggregation poms that only contain libraries so that our project POMs only depend on our libraries. For example if the war file needs the Apache Commons that we support in our development environment, the project will depend on the current version of ours-lib-commons.pom. Just out of curiosity, where is it written down that one can depend on an artifact of type pom? I've always been curious about this. L
Re: Procedure for updating Internal Repo with 3rd party
Get your Nexus up and running (local or on a shared server) and then read the Nexus docs. Loading 3rd party lists is easy to do and everyone has to do it because of the ORACLE/Sun licensing policies so you will have lots of friends and lots of docs on the repo side. It is not really a Maven problem. The Nexus forum is the best place for these questions. Nexus is free and makes Maven actually productive and the whole process a lot more transparent. Ron PS: The other repo systems may be just as good but I can vouch for Nexus. On 29/03/2011 3:28 PM, Wendy Smoak wrote: On Tue, Mar 29, 2011 at 1:06 PM, Godschall, John jgodsch...@firstmarblehead.com wrote: I have used the depoy:deploy-file plugin but this does not seem to include the pom, the md5 and sha1 files. In addition, some projects have a parent pom structure as well. Can you paste the command you used, and what happened? There is an option to generate the pom, or to provide it if you have one for the artifact already. http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html I currently do not use a Repository Manager Well, there's the real solution. ;) Why not? You can run it locally and point to http://localhost instead of (I assume) file:///internal_repo1 . - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Versions in dependencyManagement vs dependency?
On Tue, Mar 29, 2011 at 3:35 PM, Anders Hammar and...@hammar.net wrote: Tim talks about this in this blog post: http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/ Thank you, yes, this is the first I've seen this documented. So that seems like you don't need scopeimport/scope in order to depend on an artifact with typepom/type. This is very useful to see. I wish it were documented more prominently. Best, Laird
Re: Maven 2 and axis 1.4
Hi I am also facing the same problem now in my project. The maven is looping and never ends. I have only the following dependency and have axis -1.4 jar axis axis 1.4 jar Thanks, Sakthi -- View this message in context: http://maven.40175.n5.nabble.com/Maven-2-and-axis-1-4-tp117798p4270075.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
Updating Maven Dependencies never ends
Hello, New to the group here. First, I assumed that the developers list was for those developing Maven as opposed to those developing USING Maven. Perhaps this is wrong. By any chance does anyone know why when I installed the 3.0.5 release of the Spring Framework (with its 3.6 Eclipse developer tools suite) that any time a new project is created (or one of Spring's sample projects is loaded) Maven tries to update its dependencies, but gets stuck in a never-finished state that locks up the Eclipse editor forever? I have to kill it with task manager to close it. Shot in the dark here but hopefully someone has some ideas. I have posted in the Spring forums (along with a few others) but so far no luck. Thanks... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Updating Maven Dependencies never ends
I faced a similar issue some times. I think, it's a bug in m2eclipse, thus i call mvn dependency:resolve on the command line, before opening new big projects in eclipse. That prevents eclipse freezing. Manuel On Tue, Mar 29, 2011 at 23:47, Dave DaveLists dbfli...@gmail.com wrote: Hello, New to the group here. First, I assumed that the developers list was for those developing Maven as opposed to those developing USING Maven. Perhaps this is wrong. By any chance does anyone know why when I installed the 3.0.5 release of the Spring Framework (with its 3.6 Eclipse developer tools suite) that any time a new project is created (or one of Spring's sample projects is loaded) Maven tries to update its dependencies, but gets stuck in a never-finished state that locks up the Eclipse editor forever? I have to kill it with task manager to close it. Shot in the dark here but hopefully someone has some ideas. I have posted in the Spring forums (along with a few others) but so far no luck. Thanks... - 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: Updating Maven Dependencies never ends
Your assumption was correct, but even this is the wrong mailing list. The Maven plugin used in STS or Eclipse is M2Eclipse and they have their own development and mailing list [1]. I know it is hard in the beginning to get the right mailing list. Maven and the default plugins (all in group org.apache.maven.plugins) use this list. The plugins at org.codehaus.mojo use the list at codehaus [2]. All the other projects and plugins have (or haven't) their own communication channels. I don't know which issue you ran into, sorry. [1] https://docs.sonatype.org/display/M2ECLIPSE/Project+Information [2] http://mojo.codehaus.org/mail-lists.html Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Tue, Mar 29, 2011 at 11:47 PM, Dave DaveLists dbfli...@gmail.com wrote: Hello, New to the group here. First, I assumed that the developers list was for those developing Maven as opposed to those developing USING Maven. Perhaps this is wrong. By any chance does anyone know why when I installed the 3.0.5 release of the Spring Framework (with its 3.6 Eclipse developer tools suite) that any time a new project is created (or one of Spring's sample projects is loaded) Maven tries to update its dependencies, but gets stuck in a never-finished state that locks up the Eclipse editor forever? I have to kill it with task manager to close it. Shot in the dark here but hopefully someone has some ideas. I have posted in the Spring forums (along with a few others) but so far no luck. Thanks... - 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: Updating Maven Dependencies never ends
Nick Stolwijk : thanks for setting me straight on the selection of mailing lists. That will come in handy. Manuel Doninger: I may have used a hail mary to post in this list but your reply was exactly correct and fixed my problem. Thank you!!! -Dave - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Making a report
I want to create a report which presents some results from a build. There is no way to recreate the data in the reporting context; the report must come from the build proper. Is the thing to do here to make the build proper leave the data behind in, for example, an XML file in target, and the reporting plugin to fail if the file is not there? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Making a report
On Wed, Mar 30, 2011 at 9:50 AM, Benson Margulies bimargul...@gmail.com wrote: I want to create a report which presents some results from a build. There is no way to recreate the data in the reporting context; the report must come from the build proper. Is the thing to do here to make the build proper leave the data behind in, for example, an XML file in target, and the reporting plugin to fail if the file is not there? I'm sorry I don't have specific experience in this area. Perhaps someone else can provide more guidance. I'm assuming you've googled http://www.google.com/search?q=maven+writing+a+report+plugin From my quick reading the report plugins are bound to the site phase. Which means, as you notice, no information on what happened in the build. I think I agree with your assumption of writing two plugins. One for the build phase to generate report data, and one report plugin to pretty up the information. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: enforcer plugin rules to prevent circular dependencies
On Mon, Mar 28, 2011 at 10:52 AM, Caoilte O'Connor caoi...@gmail.com wrote: Thanks for the detailed reply Philip, On Sat, Mar 26, 2011 at 3:43 AM, Phillip Hellewell ssh...@gmail.com wrote: In other words, if any of my dependencies are myself, then it throws an exception. Were you able to release this anywhere or is it something I could re-develop easily enough with the DependencyTreeBuilder. It's not released anywhere but I could check with my boss to find out if we could contribute back to the community. But we're only talking about a few dozen lines of code, so you could probably figure it out. Look at the dependency plugin source to give you a hint on how to do it. BTW, we are also using this same plugin to detect version clashes (same dependency appears more than once with different versions). I don't think it is really possible to introduce a cycle when using releases, but it is definitely possible with snapshots (just follow the steps in the bug). I think we were able to introduce this bug by having Version 2 of Project A depending on version 1 of Project B which depends on version 1 of Project A. Oh yes, of course. I'm not sure why I let myself be led to believe this could not happen with releases. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Upgrading maven-embedder from 2.0.4 to 3.0.2
olamy wrote: Hello Matt. This doesn't exists anymore in 3.0.x. So for the maven3 integration in Hudson/Jenkins, I have build a quot;kindquot; of embedder which you can use at least for read projects. It should work to read projects and resolve dependencies. You can have a look at the unit tests here [1] [1] https://github.com/jenkinsci/lib-jenkins-maven-embedder/blob/master/src/test/java/hudson/maven/TestMavenEmbedderSimpleProject.java I copied your MavenEmbedder into my project and got most of the dependencies resolved. However, when I run it, I get the error below. I suspect this has something to do with me trying to use the artifact-common dependency to test artifacts. You can see a patch of what I tried changing on the following JIRA issue. http://issues.appfuse.org/browse/APF-1220 Any advice is greatly appreciated. Running org.appfuse.mojo.installer.InstallArtifactsMojoTest 22:34:21,055 WARN org.sonatype.guice.bean.reflect.NamedClass - Error injecting: org.apache.maven.profiles.DefaultMavenProfilesBuilder java.lang.NoClassDefFoundError: org/codehaus/plexus/util/interpolation/ValueSource at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getDeclaredConstructors(Class.java:1836) at com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:243) at com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:96) at com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:628) at com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:835) at com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:769) at com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:254) at com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:205) at com.google.inject.internal.InjectorImpl.getInternalFactory(InjectorImpl.java:843) at com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:957) at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:990) at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:951) at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1003) at org.sonatype.guice.bean.reflect.AbstractDeferredClass.get(AbstractDeferredClass.java:47) at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40) at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1021) at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40) at com.google.inject.Scopes$1$1.get(Scopes.java:59) at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40) at com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:968) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1021) at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:964) at org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:79) at org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:53) at org.sonatype.guice.plexus.binders.PlexusRequirements$RequirementProvider.get(PlexusRequirements.java:221) at org.sonatype.guice.plexus.binders.ProvidedPropertyBinding.injectProperty(ProvidedPropertyBinding.java:49) at org.sonatype.guice.bean.inject.BeanInjector.doInjection(BeanInjector.java:105) at org.sonatype.guice.bean.inject.BeanInjector.injectMembers(BeanInjector.java:76) at com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:120) at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:94) at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:254) at com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:968) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1021) at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:964) at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1003) at org.sonatype.guice.bean.reflect.AbstractDeferredClass.get(AbstractDeferredClass.java:47) at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40) at
Re: Versions in dependencyManagement vs dependency?
Be aware that you're talking of two different strategies. Using a pom artifact as a dependency and using import scope to import depMgmt declared in another pom. Two different things! /Anders On Tue, Mar 29, 2011 at 22:18, Laird Nelson ljnel...@gmail.com wrote: On Tue, Mar 29, 2011 at 3:35 PM, Anders Hammar and...@hammar.net wrote: Tim talks about this in this blog post: http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/ Thank you, yes, this is the first I've seen this documented. So that seems like you don't need scopeimport/scope in order to depend on an artifact with typepom/type. This is very useful to see. I wish it were documented more prominently. Best, Laird
