Re: How do I prevent maven from searching my own artifacts in public repositories ?
Hi all, thank you very mutch. I think Anders is right saying to use a repo manager, wich has to filter the artifact request if it matchs a predefined pattern of my project. Do anyone of you have experience with such a manager ? Nexus or Archiva ? Torsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Putting a Release in the Repository
Which version of the release-plugin are you using? MRELEASE-216[0], which seems very related, was fixed for version 2.0-beta-10, but this version is not yet released! hth, - martin [0] http://jira.codehaus.org/browse/MRELEASE-261 Am Donnerstag, 19. November 2009 20:43:26 schrieb Neil Chaudhuri: I have done those things, but I get the following error: [INFO] [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one. I thought that error only occurred when the URL to the repo was incorrect. Since I am able to do a release:prepare and see the project tagged in SVN, I imagine that isn't the case. It occurred to me that this could be a flatness issue. My release in SVN looks like this: myapp-0.8.1 --parent --persistence --services Each of these represents a module with its own pom. Shockingly, parent is the parent module for the others. There is no pom at the myapp-0.8.1 level, so that would explain the error. Because of the flatness issue, I had to add configure the release plugin in the following fashion for it to work: configuration tagWorkingDirectory${basedir}/../tagWorkingDirectory updateWorkingCopyVersionsfalse/updateWorkingCopyVersions preparationGoalsclean install/preparationGoals goalsclean install/goals arguments-Dmaven.test.skip/arguments tagBasesvn://url/data/svn/project/tags/tagBase autoVersionSubmodulestrue/autoVersionSubmodules /configuration Given this setup, how can I do the release? Any insight is appreciated. Thanks. -Original Message- From: Stevo Slavić [mailto:ssla...@gmail.com] Sent: Thursday, November 19, 2009 2:22 PM To: Maven Users List Subject: Re: Putting a Release in the Repository http://weblogs.java.net/blog/2008/08/31/using-maven-release-plugin http://www.vineetmanohar.com/2009/10/23/how-to-automate-project-versioning- and-release-with-maven/ Regards, Stevo. On Thu, Nov 19, 2009 at 8:19 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: mvn release:perform after the prepare Sent from my [rhymes with tryPod] ;-) On 19 Nov 2009, at 19:11, Neil Chaudhuri nchaudh...@potomacfusion.com wrote: I am using the prepare goal of the Maven Release Plugin to publish a release in SVN. The result of course is that the poms in the trunk and in my local copy are updated to the next version snapshot. What I want to do is to take the release in SVN and publish it to my local Nexus repository in the releases portion of the site. I am doing the same for snapshots by using the Maven Deploy Plugin. I suppose my question is how can I get the Maven Release and Deploy Plugins to work in tandem so that I can release something to SVN and then have it be deployed to my local Nexus repository. Thanks. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Martin Höller | martin.hoel...@xss.co.at *x Software + Systeme | http://www.xss.co.at/ Karmarschgasse 51/2/20 | Tel: +43-1-6060114-40 A-1100 Vienna, Austria | Fax: +43-1-6060114-71 signature.asc Description: This is a digitally signed message part.
Excluding repositories
Hello, One of the dependencies is trying to access a repository at download.java.net, and this site is blocked by our firewall. Is there a way to tell Maven to skip this repository? Either in settings.xml or pom.xml Thanks, Csaba - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Alternative output directory for javadocs
Hey list! I'm trying to change the output directory for the generated javadocs from /apidocs to something like /api. According to the plugin documentation[1] this is easily achieved by specifying an alternative destDir. However when I'm using the alternative directory (name doesn't matter) the test documentation will not be created giving the following info: [INFO] Skipped Test JavaDocs report, file api/index.html already exists for the English version. The page mentioned at [1] talks about testDestDir as the way to specify the test javadoc location but the configuration option is missing from the javadoc:javadoc and javadoc:test-javadoc goals and thus does not work. Apart from that it labels the generated javadoc report for the main sources as Test JavaDocs but links to the main javadoc at (in my case) /api. So how do you specify alternative output directories for javadocs? Any help on that is appreciated :-) Greets, Sebastian P.S.: I'm using version 2.6.1 of the javadoc plugin and maven version 2.2.1. [1]: http://maven.apache.org/plugins/maven-javadoc-plugin/examples/output-configuration.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How do I prevent maven from searching my own artifacts in public repositories ?
I think that the battle today is between Nexus and Artifactory. Archiva has a few features that Nexus for instance lacks, but the development of Archiva is slower than Nexus for instance. Regarding Nexus or Artifactory you should which one fits your needs the best. Nexus supports the filtering you're talking about below (it's called routing rules in Nexus). Not sure about Artifactory. /Anders On Fri, Nov 20, 2009 at 09:03, TorstenKarusseit torsten.karuss...@gmx.dewrote: Hi all, thank you very mutch. I think Anders is right saying to use a repo manager, wich has to filter the artifact request if it matchs a predefined pattern of my project. Do anyone of you have experience with such a manager ? Nexus or Archiva ? Torsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Alternative output directory for javadocs
On Fri, 20 Nov 2009 11:48:09 +0100 Sebastian Hoß m...@shoss.de wrote: Hey list! .. So how do you specify alternative output directories for javadocs? Any help on that is appreciated :-) Ah well, I've done it: Using reportSets you can specify the destDir for the javadoc:javadoc goal and the javadoc:test-javadoc goal independently [1]. So I ended up with something like this: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.6.1/version reportSets reportSet idmain-html/id configuration destDirapi/destDir /configuration reports reportjavadoc/report /reports /reportSet reportSet idtest-html/id configuration destDirtestapi/destDir /configuration reports reporttest-javadoc/report /reports /reportSet /reportSets /plugin That gives me the desired result but I still think that the plugin documentation mentioned in my last mail is wrong.. [1]: http://maven.apache.org/plugins/maven-javadoc-plugin/examples/test-javadocs.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Alternative output directory for javadocs
The example from the website worked fine for me, it placed the javadocs into an alternative directory, though maybe I didn't understand what exactly you're trying to archive. Regards, Csaba Sebastian Hoß wrote: On Fri, 20 Nov 2009 11:48:09 +0100 Sebastian Hoß m...@shoss.de wrote: Hey list! .. So how do you specify alternative output directories for javadocs? Any help on that is appreciated :-) Ah well, I've done it: Using reportSets you can specify the destDir for the javadoc:javadoc goal and the javadoc:test-javadoc goal independently [1]. So I ended up with something like this: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.6.1/version reportSets reportSet idmain-html/id configuration destDirapi/destDir /configuration reports reportjavadoc/report /reports /reportSet reportSet idtest-html/id configuration destDirtestapi/destDir /configuration reports reporttest-javadoc/report /reports /reportSet /reportSets /plugin That gives me the desired result but I still think that the plugin documentation mentioned in my last mail is wrong.. [1]: http://maven.apache.org/plugins/maven-javadoc-plugin/examples/test-javadocs.html - 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: Isn't listing a dependency supposed to download that JAR file into your WEB-INF/lib folder?
If you add this to your pom.xml: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.1/version executions execution phaseprocess-resources/phase goals goalcopy-dependencies/goal /goals configuration outputDirectory${project.basedir}/WEB-INF/lib/outputDirectory excludeScopetest/excludeScope /configuration /execution /executions /plugin All your dependencies (that is not in the test-scope) should be copied to /WEB-INF/lib during the specified phase (here, process-resources). If you then run mvn package, your war-file is created anf the jars are included. /Ludwig -Original Message- From: laredotornado [mailto:laredotorn...@gmail.com] Sent: den 19 november 2009 23:04 To: users@maven.apache.org Subject: Isn't listing a dependency supposed to download that JAR file into your WEB-INF/lib folder? I'm using Maven 2.2 on Mac 10.5.6 with JBoss 5.1. I have these two dependencies in my pom.xml (I'm building a WAR file) ... dependency groupIdcom.myco.jsf/groupId artifactIdcom-myco-jsf/artifactId version1.11/version /dependency dependency groupIdmyco.util.jsf/groupId artifactIdmyco-util-jsf/artifactId version1.3/version /dependency I can compile and build my project fine using mvn clean install jboss:redeploy However when I open up my WAR file, the two JAR files listed above are not there. Why not? Anyone know how to include them? Thanks, - Dave -- View this message in context: http://old.nabble.com/Isn%27t-listing-a-dependency-supposed-to-download-that -JAR-file-into-your-WEB-INF-lib-folder--tp26421497p26421497.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: Isn't listing a dependency supposed to download that JAR file into your WEB-INF/lib folder?
The war plugin automatically puts all your dependencies on runtime and compile in your war file, so I guess the dependencies aren't in one of those scopes. Look at mvn dependencies:tree output to see in what scope they are. With regards, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Fri, Nov 20, 2009 at 12:09 PM, Ludwig Magnusson lud...@itcatapult.com wrote: If you add this to your pom.xml: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.1/version executions execution phaseprocess-resources/phase goals goalcopy-dependencies/goal /goals configuration outputDirectory${project.basedir}/WEB-INF/lib/outputDirectory excludeScopetest/excludeScope /configuration /execution /executions /plugin All your dependencies (that is not in the test-scope) should be copied to /WEB-INF/lib during the specified phase (here, process-resources). If you then run mvn package, your war-file is created anf the jars are included. /Ludwig -Original Message- From: laredotornado [mailto:laredotorn...@gmail.com] Sent: den 19 november 2009 23:04 To: users@maven.apache.org Subject: Isn't listing a dependency supposed to download that JAR file into your WEB-INF/lib folder? I'm using Maven 2.2 on Mac 10.5.6 with JBoss 5.1. I have these two dependencies in my pom.xml (I'm building a WAR file) ... dependency groupIdcom.myco.jsf/groupId artifactIdcom-myco-jsf/artifactId version1.11/version /dependency dependency groupIdmyco.util.jsf/groupId artifactIdmyco-util-jsf/artifactId version1.3/version /dependency I can compile and build my project fine using mvn clean install jboss:redeploy However when I open up my WAR file, the two JAR files listed above are not there. Why not? Anyone know how to include them? Thanks, - Dave -- View this message in context: http://old.nabble.com/Isn%27t-listing-a-dependency-supposed-to-download-that -JAR-file-into-your-WEB-INF-lib-folder--tp26421497p26421497.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: findbugs-plugin: Premature end of file.
Perhaps I found the problem. It seems the reports gets generated twice. I had following configuration of the site plugin: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version2.0.1/version inheritedtrue/inherited configuration localesde, en/locales /configuration /plugin When I change to only one locales localesde/locales everthing things works fine. Also Findbugs-Plugin 2.2/2.1/2.0.1 plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version2.0.1/version inheritedtrue/inherited configuration localesde/locales /configuration /plugin duality72 wrote: I'm having the same problem today. Looks like the findbugs plugin has been updated to version 2.2 and is causing the problem. Reverting to version 2.0.1 has removed the problem. -- View this message in context: http://old.nabble.com/findbugs-plugin%3A-Premature-end-of-file.-tp26421353p26438771.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: Alternative output directory for javadocs
On Fri, 20 Nov 2009 12:03:26 +0100 Gajo Csaba csaba.g...@cosylab.com wrote: The example from the website worked fine for me, it placed the javadocs into an alternative directory, though maybe I didn't understand what exactly you're trying to archive. Well I simply wanted to change the default javadoc location. Using the example from the website gave me two problems: 1) No test javadocs were generated (no javadocs for the code under /test) 2) The main javadocs were placed in the correct directory but the link pointing to them had the wrong label. It said Test JavaDocs but should have JavaDocs. In my last mail I explained the workaround I found for these problems. Is that any clearer? :-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Fwd: Urgent-kindly help in installing maven assembly plugin
-- Forwarded message -- From: Dipankar Das dipankar.dipnil2...@gmail.com Date: Fri, Nov 20, 2009 at 3:31 AM Subject: Urgent-kindly help in installing maven assembly plugin To: bri...@apache.org, br...@apache.org Dear Sir, I am using both of the following packages (apache-maven-2.2.1-bin apache-maven-2.0.10-bin) but it gives the same error after executing the *command *prompt. Please help me to cope up with this problem. I have changed the proxy of settings.xml for this purpose but nothing has yet been improved. proxy activetrue/active protocolhttp/protocol hostwww.jadavpur.edu/host port8080/port /proxy * command * C:\Documents and Settings\dipankarmvn install assembly:assembly [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'assembly'. [INFO] org.apache.maven.plugins: checking for updates from central [WARNING] repository metadata for: 'org.apache.maven.plugins' could not be retri eved from repository: central due to an error: Error transferring file [INFO] Repository 'central' will be blacklisted Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-assemb ly-plugin/2.2-beta-2/maven-assembly-plugin-2.2-beta-2.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.plugins:maven-assembly-plugin Reason: POM 'org.apache.maven.plugins:maven-assembly-plugin' not found in reposi tory: Unable to download the artifact from any repository org.apache.maven.plugins:maven-assembly-plugin:pom:2.2-beta-2 from the specified remote repositories: central (http://repo1.maven.org/maven2) for project org.apache.maven.plugins:maven-assembly-plugin [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 26 seconds [INFO] Finished at: Fri Nov 20 16:22:32 PST 2009 [INFO] Final Memory: 1M/4M [INFO]
Re: Urgent-kindly help in installing maven assembly plugin
Does any maven command work? Like mvn compile ? My guess would be that the proxy configuration isn't correct. Talk to your network/firewall/proxy staff. Also, executing mvn install -X would give you debug output. /Anders On Fri, Nov 20, 2009 at 12:45, Dipankar Das dipankar.dipnil2...@gmail.comwrote: -- Forwarded message -- From: Dipankar Das dipankar.dipnil2...@gmail.com Date: Fri, Nov 20, 2009 at 3:31 AM Subject: Urgent-kindly help in installing maven assembly plugin To: bri...@apache.org, br...@apache.org Dear Sir, I am using both of the following packages (apache-maven-2.2.1-bin apache-maven-2.0.10-bin) but it gives the same error after executing the *command *prompt. Please help me to cope up with this problem. I have changed the proxy of settings.xml for this purpose but nothing has yet been improved. proxy activetrue/active protocolhttp/protocol hostwww.jadavpur.edu/host port8080/port /proxy * command * C:\Documents and Settings\dipankarmvn install assembly:assembly [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'assembly'. [INFO] org.apache.maven.plugins: checking for updates from central [WARNING] repository metadata for: 'org.apache.maven.plugins' could not be retri eved from repository: central due to an error: Error transferring file [INFO] Repository 'central' will be blacklisted Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-assemb ly-plugin/2.2-beta-2/maven-assembly-plugin-2.2-beta-2.pomhttp://repo1.maven.org/maven2/org/apache/maven/plugins/maven-assemb%0Aly-plugin/2.2-beta-2/maven-assembly-plugin-2.2-beta-2.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.plugins:maven-assembly-plugin Reason: POM 'org.apache.maven.plugins:maven-assembly-plugin' not found in reposi tory: Unable to download the artifact from any repository org.apache.maven.plugins:maven-assembly-plugin:pom:2.2-beta-2 from the specified remote repositories: central (http://repo1.maven.org/maven2) for project org.apache.maven.plugins:maven-assembly-plugin [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 26 seconds [INFO] Finished at: Fri Nov 20 16:22:32 PST 2009 [INFO] Final Memory: 1M/4M [INFO]
Resources in source folder
Hi, I have an Eclipse-project that are managed with Maven2. This project depends on resource-files in the source-folders (HTML-files, it's a Wicket project), but recently Eclipse stopped copying those files to the target automatically. Project properties-build path-source folders for the relevant source folder is set to Included: **/*.java and Excluded: (None), and if I clear included to (all) it works -- however, this is overwritten when I run mvn eclipse:eclipse. The change corresponds to classpathentry kind=src path=src/main/java including=**/*.java/ to classpathentry kind=src path=src/main/java/ I've tried various manglings of the resources section of the pom.xml file, but I can't get it to do anything different. Also, mvn resources:resource works as expected, so I'm suspecting that I'm looking in the wrong place. How do I get Maven to output the right classpathentry ? Thanks, Martin Seebach
[ANN] Maven Plugin Testing 2.0-alpha-1 Released
The Maven team is pleased to announce the release of the Maven Plugin Testing, version 2.0-alpha-1. This harness assists in creating unit or integration tests for Maven plugins. See the component's site for more details: http://maven.apache.org/plugin-testing/ This new version of the harness targets Maven 3.0. Release Notes - Maven 2.x Plugin Testing - Version 2.0-alpha-1 ** Bug * [MPLUGINTESTING-11] - plugin-testing-mvn-3.x branch does not compile/work with latest maven 3.0-SNAPSHOT * [MPLUGINTESTING-16] - update to build with latest maven 3.0-SNAPSHOT Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[WAR-plugin] Can I put my resources in their original folder?
The first example on this page http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering- webresources.html http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-w ebresources.html says that resources outside the src folder will be placed in the root of the war Ex, with this filestructure: |-- pom.xml |-- resource2 | |-- external-resource.jpg | `-- image2 | `-- external-resource2.jpg //more structure And this configuration of the war-plugin configuration webResources resource !-- this is relative to the pom.xml directory -- directoryresource2/directory /resource /webResources /configuration The war file will be structured like this: //more structure |-- external-resource.jpg |-- image2 | `-- external-resource2.jpg Is it possible to structure the war-file like the original filestructure? I.e having all the extra resources in the resource2-folder, and that folder in the root of the war-file? /Ludwig
Re: [WAR-plugin] Can I put my resources in their original folder?
Hi Ludwig, I would recommend putting those directories and files in the src/main/webapp directory. The maven war plugin puts everything under src/main/webapp into the base of the war. In your case: src/main/webapp/external-resource.jpg src/main/webapp/image2/external-resource2.jpg would give you the war layout: ./external-resource.jpg ./image2/external-resource2.jpg Hope this helps, Joe Hindsley Ludwig Magnusson wrote: The first example on this page http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering- webresources.html http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-w ebresources.html says that resources outside the src folder will be placed in the root of the war Ex, with this filestructure: |-- pom.xml |-- resource2 | |-- external-resource.jpg | `-- image2 | `-- external-resource2.jpg //more structure And this configuration of the war-plugin configuration webResources resource !-- this is relative to the pom.xml directory -- directoryresource2/directory /resource /webResources /configuration The war file will be structured like this: //more structure |-- external-resource.jpg |-- image2 | `-- external-resource2.jpg Is it possible to structure the war-file like the original filestructure? I.e having all the extra resources in the resource2-folder, and that folder in the root of the war-file? /Ludwig - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] JBoss Packaging Maven Plugin 2.1.1 Released
The Mojo team is pleased to announce the release of the JBoss Packaging Maven Plugin version 2.1.1. http://mojo.codehaus.org/jboss-packaging-maven-plugin/ This release includes some minor bug fixes and updates to the plugin site. To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId version2.1.1/version /plugin A comprehensive list of changes is attached at the end of this mail. Regards, The Mojo team. Release Notes - Maven 2.x JBoss Packaging Plugin - Version 2.1.1 ** Bug * [MJBOSSPACK-31] - problems importing 'ejb-client' artifact in PAR ** Improvement * [MJBOSSPACK-32] - Add ability to attach generated .sar to the project, even if classifier is not specifed * [MJBOSSPACK-33] - Packaging types archiver should be matched to JarArchiver instead of ZipArchiver * [MJBOSSPACK-34] - Add site docs about describing attached artifacts - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Custom Archetypes: Creating empty directories
http://jira.codehaus.org/browse/ARCHETYPE-57 gives an example of how to do this. Thanks for your time! Matthew Runo Software Engineer, Zappos.com mr...@zappos.com - 702-943-7833 On Nov 19, 2009, at 11:37 PM, Richard Hauswald wrote: Hello list, I'm trying to create a custom archetype. All is working fine except that I can't create empty directories. Is this impossible or do miss something? Thanks, Richard -- Richard Hauswald Blog: http://tnfstacc.blogspot.com/ LinkedIn: http://www.linkedin.com/in/richardhauswald Xing: http://www.xing.com/profile/Richard_Hauswald - 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: [WARNING] POM is invalid. error messages in Maven 2.2.1 but not in 2.0.10
Maybe 2.2.2 will fix it. =) Not likely. The pom is plain wrong an it was a bug in 2.x which allowed it to go unnoticed. On Fri, Nov 20, 2009 at 3:42 PM, Brett Randall javabr...@gmail.com wrote: http://jira.codehaus.org/browse/MNG-4379 ... or did your team log that :). On Fri, Nov 20, 2009 at 2:59 PM, Ellecer Valencia elle...@gmail.com wrote: Hi Brett, Thanks for the suggestion. I may have found the issue. Would it be this: Validation Errors: [DEBUG] For dependency Dependency {groupId=weblogic, artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency must specify an absolute path systemPath. [DEBUG] For managed dependency Dependency {groupId=weblogic, artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency must specify an absolute path systemPath. [DEBUG] [DEBUG] mypackage:myartifact:jar:1.0.2:compile (selected for compile) [DEBUG] Skipping disabled repository central [DEBUG] myartifact: using locally installed snapshot [WARNING] POM for 'mypackage:myartifact:pom:1.0.2-SNAPSHOT:test' is invalid. Its dependencies (if any) will NOT be available to the current build. [DEBUG] Reason: Failed to validate POM for project mypackage:myartifact at Artifact [mypackage:myartifact:pom:1.0.2-SNAPSHOT:test] [DEBUG] Validation Errors: [DEBUG] For dependency Dependency {groupId=weblogic, artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency must specify an absolute path systemPath. [DEBUG] For dependency Dependency {groupId=weblogic, artifactId=webservices, version=10.0, type=jar}: system-scoped dependency must specify an absolute path systemPath. [DEBUG] For managed dependency Dependency {groupId=weblogic, artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency must specify an absolute path systemPath. [DEBUG] For managed dependency Dependency {groupId=weblogic, artifactId=webservices, version=10.0, type=jar}: system-scoped dependency must specify an absolute path systemPath. [DEBUG] Now in this project, we are inheriting from a parent POM (standardised for our department) with entries like this: (WL_HOME is Weblogic install directory) dependency groupIdcom.sun/groupId artifactIdtools/artifactId version1.5.0.11/version scopesystem/scope systemPath${java.home}/../lib/tools.jar/systemPath /dependency dependency groupIdcom.sun/groupId artifactIdrt/artifactId version1.5.0.11/version scopesystem/scope systemPath${java.home}/lib/rt.jar/systemPath /dependency dependency groupIdweblogic/groupId artifactIdweblogic/artifactId version10.0/version scopesystem/scope systemPath${env.WL_HOME}/server/lib/weblogic.jar/ systemPath /dependency dependency groupIdweblogic/groupId artifactIdwebservices/artifactId version10.0/version scopesystem/scope systemPath${env.WL_HOME}/server/lib/webservices.jar/ systemPath /dependency Now it only fails on the Weblogic related entries. With the Java system dependencies it seems to do fine. Has the handling of this changed from 2.0.* to 2.2.*? If so, what should we replace it with? And will these settings also work for people still using maven 2.0.10? Ellecer On Fri, Nov 20, 2009 at 1:01 PM, Brett Randall javabr...@gmail.com wrote: Hi Ellecer What is the output of mvn -e -X ... Brett On Fri, Nov 20, 2009 at 11:41 AM, Ellecer Valencia elle...@gmail.com wrote: Hi, How come when I try a build using Maven 2.2.1 I get multiple messages like this: [WARNING] POM for 'mypackage.artifact:pom:1.0.2- SNAPSHOT:compile' is invalid. Its dependencies (if any) will NOT be available to the current build. These errors weren't displaying when I was using Maven 2.0.10 I'm trying to use the newer version of Maven but I can't proceed with these error messages. How can I find out what are the actual errors it's referring to? I didn't come across any mention of relevant POM format changes going from Maven 2.0.* to 2.1.* or 2.2.* - if anyone has any info on this it would be a great help! Is there a way to validate the pom and get format error details from Maven? thanks, Ellecer --- -- 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 - 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
Re: [WAR-plugin] Can I put my resources in their original folder?
Ludwig, I think I misunderstood what you were asking in the original email. Let me try again... If I understand correctly, you want to keep the 'external' resource directory name in the root of the war instead of copying it's contents to the root of the war. This can be accomplished by adding a targetPath element to the resource definition. My example below assumes you are renaming the resource2 directory to myTarget in the war. In your case, with a webResource definition like: configuration webResources resource directoryresource2/directory targetPathmyTarget/targetPath /resource /webResources /configuration Applied to a project layout like: pom.xml resource2/external-resource.jpg resource2/image2/external-resource2.jpg src/main/webapp/WEB-INF/web.xml ... Would produce a war layout like: myTarget/external-resource.jpg myTarget/image2/external-resource2.jpg WEB-INF/web.xml Hopefully this is the answer you're looking for. Joe Hindsley Ludwig Magnusson wrote: But the problem is that I configure my webapp with property files. Some properties point to other files. Won't those links be wrong in any case since the files will be in a new directory? I suppose I could use separate configurations for development and live but it seems like a lot of work. I don't really understand why the structure needs to be different. /Ludwig -Original Message- From: Joe Hindsley [mailto:jhinds...@gmail.com] Sent: den 20 november 2009 17:02 To: Maven Users List Subject: Re: [WAR-plugin] Can I put my resources in their original folder? Hi Ludwig, I would recommend putting those directories and files in the src/main/webapp directory. The maven war plugin puts everything under src/main/webapp into the base of the war. In your case: src/main/webapp/external-resource.jpg src/main/webapp/image2/external-resource2.jpg would give you the war layout: ./external-resource.jpg ./image2/external-resource2.jpg Hope this helps, Joe Hindsley Ludwig Magnusson wrote: The first example on this page http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering- webresources.html http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-w ebresources.html says that resources outside the src folder will be placed in the root of the war Ex, with this filestructure: |-- pom.xml |-- resource2 | |-- external-resource.jpg | `-- image2 | `-- external-resource2.jpg //more structure And this configuration of the war-plugin configuration webResources resource !-- this is relative to the pom.xml directory -- directoryresource2/directory /resource /webResources /configuration The war file will be structured like this: //more structure |-- external-resource.jpg |-- image2 | `-- external-resource2.jpg Is it possible to structure the war-file like the original filestructure? I.e having all the extra resources in the resource2-folder, and that folder in the root of the war-file? /Ludwig - 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: [WAR-plugin] Can I put my resources in their original folder?
Great! It works now. Thanks very much, I was worried there for a while =) /Ludwig -Original Message- From: Joe Hindsley [mailto:jhinds...@gmail.com] Sent: den 20 november 2009 20:57 To: Ludwig Magnusson Cc: 'Maven Users List' Subject: Re: [WAR-plugin] Can I put my resources in their original folder? Ludwig, I think I misunderstood what you were asking in the original email. Let me try again... If I understand correctly, you want to keep the 'external' resource directory name in the root of the war instead of copying it's contents to the root of the war. This can be accomplished by adding a targetPath element to the resource definition. My example below assumes you are renaming the resource2 directory to myTarget in the war. In your case, with a webResource definition like: configuration webResources resource directoryresource2/directory targetPathmyTarget/targetPath /resource /webResources /configuration Applied to a project layout like: pom.xml resource2/external-resource.jpg resource2/image2/external-resource2.jpg src/main/webapp/WEB-INF/web.xml ... Would produce a war layout like: myTarget/external-resource.jpg myTarget/image2/external-resource2.jpg WEB-INF/web.xml Hopefully this is the answer you're looking for. Joe Hindsley Ludwig Magnusson wrote: But the problem is that I configure my webapp with property files. Some properties point to other files. Won't those links be wrong in any case since the files will be in a new directory? I suppose I could use separate configurations for development and live but it seems like a lot of work. I don't really understand why the structure needs to be different. /Ludwig -Original Message- From: Joe Hindsley [mailto:jhinds...@gmail.com] Sent: den 20 november 2009 17:02 To: Maven Users List Subject: Re: [WAR-plugin] Can I put my resources in their original folder? Hi Ludwig, I would recommend putting those directories and files in the src/main/webapp directory. The maven war plugin puts everything under src/main/webapp into the base of the war. In your case: src/main/webapp/external-resource.jpg src/main/webapp/image2/external-resource2.jpg would give you the war layout: ./external-resource.jpg ./image2/external-resource2.jpg Hope this helps, Joe Hindsley Ludwig Magnusson wrote: The first example on this page http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering- webresources.html http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-w ebresources.html says that resources outside the src folder will be placed in the root of the war Ex, with this filestructure: |-- pom.xml |-- resource2 | |-- external-resource.jpg | `-- image2 | `-- external-resource2.jpg //more structure And this configuration of the war-plugin configuration webResources resource !-- this is relative to the pom.xml directory -- directoryresource2/directory /resource /webResources /configuration The war file will be structured like this: //more structure |-- external-resource.jpg |-- image2 | `-- external-resource2.jpg Is it possible to structure the war-file like the original filestructure? I.e having all the extra resources in the resource2-folder, and that folder in the root of the war-file? /Ludwig - 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
Does Maven download jars every time it does any thing?
I understand that local repos need to have all the dependency jars first time but does maven really download jars every time I do compile,install etc. Cause the info messages seem to suggest some thing like that? -- View this message in context: http://old.nabble.com/Does-Maven-download-jars-every-time-it-does-any-thing--tp26448882p26448882.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: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
This isn't exactly true. First, lets take a look at the stack trace: -- 1 required artifact is missing. for artifact: com.example:mod_b:jar:1.0 from the specified remote repositories: mynexus (http://192.168.101.21:8081/nexus/content/groups/public) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra nsitively(DefaultArtifactResolver.java:360) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra nsitively(DefaultArtifactResolver.java:304) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende ncies(DefaultPluginManager.java:1499) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:442) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:694) ... 17 more Notice this is all core code. It's trying to resolve the dependencies prior to invoking the plugin. As I mentioned earlier in the thread, the plugin sets @requiresDependencyResolution test which tells Maven to resolve the test scope (which means everything) before invoking the plugin. If you only run mvn dependency:tree there are no references to the other projects in the reactor for Maven to find and use. Try running mvn compile dependency:tree: and you'll see that it does in fact work. This is just a side effect of how maven 2.x does the resolution. Could we rewrite the dependency tree goal to completely work around this? Probably, but it would mean duplicating tons of core logic to make the resolution work in all cases and running tree on a not-yet compiled or installed project is an edge case imo. 2009/11/19 Jamie Whitehouse jamie.whiteho...@genesyslab.com: Many of the dependency plugin goals are reactor aware, but dependency:tree isn't. I'm not too sure why, but you could search the issue tracker and if there's no issue for this file one. -Original Message- From: Jonathan Gold [mailto:jgold...@gmail.com] Sent: Thursday, November 19, 2009 3:00 PM To: users@maven.apache.org Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works? Jamie -- Thanks for trying it out, and for the explanation. This makes sense in terms of why things are happening, so that's nice. I'm not familiar with the dependency plugin developers (are you one?), and wonder if having the dependency plugin be reactor-aware is something they would consider? Perhaps its an old tired discussion and the decision to build that plugin the way it is is said and done. Thanks for your help! jon On Thu, Nov 19, 2009 at 11:43:33AM -0800, Jamie Whitehouse wrote: What maven commands did you issue to test this? I used the attached project and here's the results. 1) extract zip 2) mvn dependency:tree failed due to dependency resolution 3) mvn clean install 4) mvn dependency:tree see the tree output I think you're misunderstanding how the local maven repo is used and the affect reactor builds and plugins that are reactor aware vs not. AFAIK the dependency:tree goal is not reactor aware. It needs to resolve artifacts from the local repo (or download from remote repos if not present locally). Since you haven't mvn installed these into your local repo the tree goal states that the artifact is missing. The compile goal is reactor aware, and hence if you invoke mvn compile it determines the correct order in your multi-module build in order for mod_b to resolve the reference to mod_a. To test this reverse the order of the module definitions in the root pom and see that the reactor summary builds mod_a first despite the modules list having mod_b first. If you want to simulate what dependency:tree does using the compile goal, just try to compile mod_b on it's own, in it's own sub module (e.g. c:\maven-repro1\mod_b mvn compile ), you'll get the same error about not being able to resolve dependencies. Hope that helps. Jamie. -Original Message- From: Jonathan Gold [mailto:jgold...@gmail.com] Sent: Thursday, November 19, 2009 12:52 PM To: users@maven.apache.org Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works? Brian -- Thanks for your help so far. I did put together a very small sample project that will repro what I'm seeing (attached as a zip). Just run 'mvn dependency:tree' in the root of the project and see if you get the same error (mod_a is not found, required by mod_b). It does compile fine. I'll be interested to see if you get the same results, or have some insights. It's totally likely that I'm not setting my poms up correctly. Thanks for any help you can give! jon On Wed, Nov 18, 2009 at 05:53:34PM -0500, Brian Fox wrote: This is not related. The dependency plugin has some issues resolving things from the reactor and ranges in the following goals only: copy unpack go-offline resolve-plugins All the other goals
Re: Does Maven download jars every time it does any thing?
No, if it's already in your local repo it will not download it again. -Dave On Fri, Nov 20, 2009 at 1:52 PM, chicagopooldude seshu.pit...@cmegroup.comwrote: I understand that local repos need to have all the dependency jars first time but does maven really download jars every time I do compile,install etc. Cause the info messages seem to suggest some thing like that? -- View this message in context: http://old.nabble.com/Does-Maven-download-jars-every-time-it-does-any-thing--tp26448882p26448882.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: Does Maven download jars every time it does any thing?
No it doesn't. They are stored in your local repo. Snapshots are checked once a day for updates. If however you are using something that doesn't have a pom, then it will try everytime looking for it. On Fri, Nov 20, 2009 at 3:52 PM, chicagopooldude seshu.pit...@cmegroup.com wrote: I understand that local repos need to have all the dependency jars first time but does maven really download jars every time I do compile,install etc. Cause the info messages seem to suggest some thing like that? -- View this message in context: http://old.nabble.com/Does-Maven-download-jars-every-time-it-does-any-thing--tp26448882p26448882.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: Putting a Release in the Repository
Sounds like your scm urls aren't right and the perform goal is checking out the wrong folder. There should be a pom.xml for the thing you're trying to release in /target/checkout/ On Thu, Nov 19, 2009 at 2:43 PM, Neil Chaudhuri nchaudh...@potomacfusion.com wrote: I have done those things, but I get the following error: [INFO] [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one. I thought that error only occurred when the URL to the repo was incorrect. Since I am able to do a release:prepare and see the project tagged in SVN, I imagine that isn't the case. It occurred to me that this could be a flatness issue. My release in SVN looks like this: myapp-0.8.1 --parent --persistence --services Each of these represents a module with its own pom. Shockingly, parent is the parent module for the others. There is no pom at the myapp-0.8.1 level, so that would explain the error. Because of the flatness issue, I had to add configure the release plugin in the following fashion for it to work: configuration tagWorkingDirectory${basedir}/../tagWorkingDirectory updateWorkingCopyVersionsfalse/updateWorkingCopyVersions preparationGoalsclean install/preparationGoals goalsclean install/goals arguments-Dmaven.test.skip/arguments tagBasesvn://url/data/svn/project/tags/tagBase autoVersionSubmodulestrue/autoVersionSubmodules /configuration Given this setup, how can I do the release? Any insight is appreciated. Thanks. -Original Message- From: Stevo Slavić [mailto:ssla...@gmail.com] Sent: Thursday, November 19, 2009 2:22 PM To: Maven Users List Subject: Re: Putting a Release in the Repository http://weblogs.java.net/blog/2008/08/31/using-maven-release-plugin http://www.vineetmanohar.com/2009/10/23/how-to-automate-project-versioning-and-release-with-maven/ Regards, Stevo. On Thu, Nov 19, 2009 at 8:19 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: mvn release:perform after the prepare Sent from my [rhymes with tryPod] ;-) On 19 Nov 2009, at 19:11, Neil Chaudhuri nchaudh...@potomacfusion.com wrote: I am using the prepare goal of the Maven Release Plugin to publish a release in SVN. The result of course is that the poms in the trunk and in my local copy are updated to the next version snapshot. What I want to do is to take the release in SVN and publish it to my local Nexus repository in the releases portion of the site. I am doing the same for snapshots by using the Maven Deploy Plugin. I suppose my question is how can I get the Maven Release and Deploy Plugins to work in tandem so that I can release something to SVN and then have it be deployed to my local Nexus repository. 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: ejb-jar plug-in - Can we add dependency jars to ejb-jar.jar
In my current project, they use ant and pack all the jars inside the ejb-jar.jar. Now, they are thinking of migrating to maven from ant, but still want to pack the jars inside ejb-jar.jar. Is there anyway to do this without exploding the dependencies into my jar. Other way is to keep the jars in ear lib directory. But I don't want to do this because these jars are being used only by one ejb project and other ejb and web modules doesn't need these jars. Stephen Connolly-2 wrote: the jar spec does not support jar files within jar files (technically Java's URL support only goes one level deep: eg jar:url/to/file!path/ in/jar is allowed, but jar:jar:url/to/file!path/in/jar!path/in/jar is not) so while you could copy the jar files inside your ejb jar, nothing will be loaded from it what you can do is explode your dependencies into your jar. there are two tools you can use for this: dependency:unpack-dependencies or the maven-shade-plugin Sent from my [rhymes with tryPod] ;-) On 19 Nov 2009, at 19:00, Medishetty, Rajendar rajendar.medishe...@gs.com wrote: Hi, I'm using ejb-jar plugin to generate the ejb-jar.jar. I have some library jars, which are only used by this ejbModule. So I want them to be packaged inside ejb-jar.jar file only and I don't want them to place them in ear lib directory. I couldn't find anything with ejb-jar plug-in to package these jars into ejb-jar.jar file. Is there any way to do that. Thanks, Rajendar - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://old.nabble.com/ejb-jar-plug-in---Can-we-add-dependency-jars-to-ejb-jar.jar-tp26433953p26449223.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: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
Brian -- Thanks for this. I did run the combo 'mvn compile dependency:tree' as you mention below, and it works. What I'm taking away from this is that dependency:tree will work if it's part of the *same* mvn invocation as something like compile, which forces maven to do the resolution of the local workspace. Doing 'mvn compile' and then 'mvn dependency:tree' thus does not work. As a new user, this was (and still is) a bit bizarre, but I'm happy to know how to get it to work. Thanks! jon On Fri, Nov 20, 2009 at 03:54:11PM -0500, Brian Fox wrote: This isn't exactly true. First, lets take a look at the stack trace: -- 1 required artifact is missing. for artifact: com.example:mod_b:jar:1.0 from the specified remote repositories: mynexus (http://192.168.101.21:8081/nexus/content/groups/public) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra nsitively(DefaultArtifactResolver.java:360) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra nsitively(DefaultArtifactResolver.java:304) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende ncies(DefaultPluginManager.java:1499) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:442) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:694) ... 17 more Notice this is all core code. It's trying to resolve the dependencies prior to invoking the plugin. As I mentioned earlier in the thread, the plugin sets @requiresDependencyResolution test which tells Maven to resolve the test scope (which means everything) before invoking the plugin. If you only run mvn dependency:tree there are no references to the other projects in the reactor for Maven to find and use. Try running mvn compile dependency:tree: and you'll see that it does in fact work. This is just a side effect of how maven 2.x does the resolution. Could we rewrite the dependency tree goal to completely work around this? Probably, but it would mean duplicating tons of core logic to make the resolution work in all cases and running tree on a not-yet compiled or installed project is an edge case imo. 2009/11/19 Jamie Whitehouse jamie.whiteho...@genesyslab.com: Many of the dependency plugin goals are reactor aware, but dependency:tree isn't. I'm not too sure why, but you could search the issue tracker and if there's no issue for this file one. -Original Message- From: Jonathan Gold [mailto:jgold...@gmail.com] Sent: Thursday, November 19, 2009 3:00 PM To: users@maven.apache.org Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works? Jamie -- Thanks for trying it out, and for the explanation. This makes sense in terms of why things are happening, so that's nice. I'm not familiar with the dependency plugin developers (are you one?), and wonder if having the dependency plugin be reactor-aware is something they would consider? Perhaps its an old tired discussion and the decision to build that plugin the way it is is said and done. Thanks for your help! jon On Thu, Nov 19, 2009 at 11:43:33AM -0800, Jamie Whitehouse wrote: What maven commands did you issue to test this? I used the attached project and here's the results. 1) extract zip 2) mvn dependency:tree failed due to dependency resolution 3) mvn clean install 4) mvn dependency:tree see the tree output I think you're misunderstanding how the local maven repo is used and the affect reactor builds and plugins that are reactor aware vs not. AFAIK the dependency:tree goal is not reactor aware. It needs to resolve artifacts from the local repo (or download from remote repos if not present locally). Since you haven't mvn installed these into your local repo the tree goal states that the artifact is missing. The compile goal is reactor aware, and hence if you invoke mvn compile it determines the correct order in your multi-module build in order for mod_b to resolve the reference to mod_a. To test this reverse the order of the module definitions in the root pom and see that the reactor summary builds mod_a first despite the modules list having mod_b first. If you want to simulate what dependency:tree does using the compile goal, just try to compile mod_b on it's own, in it's own sub module (e.g. c:\maven-repro1\mod_b mvn compile ), you'll get the same error about not being able to resolve dependencies. Hope that helps. Jamie. -Original Message- From: Jonathan Gold [mailto:jgold...@gmail.com] Sent: Thursday, November 19, 2009 12:52 PM To: users@maven.apache.org Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works? Brian -- Thanks for your help so far. I did put together a very small sample
Re: Does Maven download jars every time it does any thing?
Thanks Brian but home i see downloading downloading every time i do some thing as this is not the first time i am doing this. is there any way we can disable this atleast visually? -- View this message in context: http://old.nabble.com/Does-Maven-download-jars-every-time-it-does-any-thing--tp26448882p26450265.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: Does Maven download jars every time it does any thing?
On Fri, Nov 20, 2009 at 2:26 PM, chicagopooldude seshu.pit...@cmegroup.com wrote: Thanks Brian but home i see downloading downloading every time i do some thing as this is not the first time i am doing this. is there any way we can disable this atleast visually? Paste a small section of the build log so someone can take a look. Most likely it's what Brian said, there is a missing pom and it's looking for that, not the jar. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
Yes, thanks for clarifying Brian. Jon, I'm still wondering why you're adverse to running mvn clean install? -Original Message- From: Jonathan Gold [mailto:jgold...@gmail.com] Sent: Friday, November 20, 2009 4:26 PM To: users@maven.apache.org Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works? Brian -- Thanks for this. I did run the combo 'mvn compile dependency:tree' as you mention below, and it works. What I'm taking away from this is that dependency:tree will work if it's part of the *same* mvn invocation as something like compile, which forces maven to do the resolution of the local workspace. Doing 'mvn compile' and then 'mvn dependency:tree' thus does not work. As a new user, this was (and still is) a bit bizarre, but I'm happy to know how to get it to work. Thanks! jon On Fri, Nov 20, 2009 at 03:54:11PM -0500, Brian Fox wrote: This isn't exactly true. First, lets take a look at the stack trace: -- 1 required artifact is missing. for artifact: com.example:mod_b:jar:1.0 from the specified remote repositories: mynexus (http://192.168.101.21:8081/nexus/content/groups/public) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra nsitively(DefaultArtifactResolver.java:360) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra nsitively(DefaultArtifactResolver.java:304) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende ncies(DefaultPluginManager.java:1499) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:442) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:694) ... 17 more Notice this is all core code. It's trying to resolve the dependencies prior to invoking the plugin. As I mentioned earlier in the thread, the plugin sets @requiresDependencyResolution test which tells Maven to resolve the test scope (which means everything) before invoking the plugin. If you only run mvn dependency:tree there are no references to the other projects in the reactor for Maven to find and use. Try running mvn compile dependency:tree: and you'll see that it does in fact work. This is just a side effect of how maven 2.x does the resolution. Could we rewrite the dependency tree goal to completely work around this? Probably, but it would mean duplicating tons of core logic to make the resolution work in all cases and running tree on a not-yet compiled or installed project is an edge case imo. 2009/11/19 Jamie Whitehouse jamie.whiteho...@genesyslab.com: Many of the dependency plugin goals are reactor aware, but dependency:tree isn't. I'm not too sure why, but you could search the issue tracker and if there's no issue for this file one. -Original Message- From: Jonathan Gold [mailto:jgold...@gmail.com] Sent: Thursday, November 19, 2009 3:00 PM To: users@maven.apache.org Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works? Jamie -- Thanks for trying it out, and for the explanation. This makes sense in terms of why things are happening, so that's nice. I'm not familiar with the dependency plugin developers (are you one?), and wonder if having the dependency plugin be reactor-aware is something they would consider? Perhaps its an old tired discussion and the decision to build that plugin the way it is is said and done. Thanks for your help! jon On Thu, Nov 19, 2009 at 11:43:33AM -0800, Jamie Whitehouse wrote: What maven commands did you issue to test this? I used the attached project and here's the results. 1) extract zip 2) mvn dependency:tree failed due to dependency resolution 3) mvn clean install 4) mvn dependency:tree see the tree output I think you're misunderstanding how the local maven repo is used and the affect reactor builds and plugins that are reactor aware vs not. AFAIK the dependency:tree goal is not reactor aware. It needs to resolve artifacts from the local repo (or download from remote repos if not present locally). Since you haven't mvn installed these into your local repo the tree goal states that the artifact is missing. The compile goal is reactor aware, and hence if you invoke mvn compile it determines the correct order in your multi-module build in order for mod_b to resolve the reference to mod_a. To test this reverse the order of the module definitions in the root pom and see that the reactor summary builds mod_a first despite the modules list having mod_b first. If you want to simulate what dependency:tree does using the compile goal, just try to compile mod_b on it's own, in it's own sub module (e.g. c:\maven-repro1\mod_b mvn compile ), you'll get the same error about not being able to resolve dependencies.
[ANN} Signatures of Java Runtimes for use with Animal Sniffer released
The Mojo team is pleased to announce the release of a number of signatures of various versions of the Java Runtime for use with the Animal Sniffer set of utilities. The following signatures have been released: Generic Signatures (only includes public API classes) * Java 1.4 (http://mojo.codehaus.org/signatures/java14/) * Java 1.5 (http://mojo.codehaus.org/signatures/java15/) * Java 1.6 (http://mojo.codehaus.org/signatures/java16/) Signatures including Sun implementation classes: * Sun Java 1.4 (http://mojo.codehaus.org/signatures/java14-sun/) * Sun Java 1.5 (http://mojo.codehaus.org/signatures/java15-sun/) * Sun Java 1.6 (http://mojo.codehaus.org/signatures/java16-sun/) Signatures including IBM implementation classes: * IBM Java 1.5 (http://mojo.codehaus.org/signatures/java15-ibm/) * IBM Java 1.6 (http://mojo.codehaus.org/signatures/java16-ibm/) Signatures including Oracle JRockit implementation classes: * Oraacle JRockit Java 1.5 (http://mojo.codehaus.org/signatures/java15-jrockit/) * Oraacle JRockit Java 1.6 (http://mojo.codehaus.org/signatures/java16-jrockit/) Signatures including Apache Harmony implementation classes: * Apache Harmony M11 Java 1.5 (http://mojo.codehaus.org/signatures/java15-harmony/) Animal Sniffer provides three tools that can use these signatures: * A Maven Plugin (http://mojo.codehaus.org/animal-sniffer-maven-plugin/index.html) * ANT Tasks (http://mojo.codehaus.org/animal-sniffer/animal-sniffer-ant-tasks/index.html) * A Maven Enforcer Rule (http://mojo.codehaus.org/animal-sniffer/animal-sniffer-enforcer-rule/index.html) The artifacts have been deployed to the codehaus repository and have been/will be mirrored to central. The Mojo Team. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How do I prevent maven from searching my own artifacts in public repositories ?
Yes, Artifactory supports filtering with include/exclude patterns for both proxied and hosted repositories. On Fri, Nov 20, 2009 at 12:55 PM, Anders Hammar and...@hammar.net wrote: I think that the battle today is between Nexus and Artifactory. Archiva has a few features that Nexus for instance lacks, but the development of Archiva is slower than Nexus for instance. Regarding Nexus or Artifactory you should which one fits your needs the best. Nexus supports the filtering you're talking about below (it's called routing rules in Nexus). Not sure about Artifactory. /Anders On Fri, Nov 20, 2009 at 09:03, TorstenKarusseit torsten.karuss...@gmx.de wrote: Hi all, thank you very mutch. I think Anders is right saying to use a repo manager, wich has to filter the artifact request if it matchs a predefined pattern of my project. Do anyone of you have experience with such a manager ? Nexus or Archiva ? Torsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Release Maven Findbugs plugin version 2.2
The Findbugs Maven plugin team is pleased to announce the release of version 2.2. FindBugs uses static analysis to inspect Java bytecode for occurrences of bug patterns. You can see more about the plugin att: http://mojo.codehaus.org/findbugs-maven-plugin/2.2/ You can find release notes for this version below, or at: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11701version=15548 Release Notes - Maven 2.x FindBugs Plugin - Version 2.2 ** Bug * [MFINDBUGS-81] - Unable to provide references to resources in excludeFilterFile/includeFilterFile configuration parameters in seperate project * [MFINDBUGS-82] - findbugs:findbugs fails if the target directory does not exist * [MFINDBUGS-86] - Changing project sourceEncoding to UTF-8 causing SAX parse error * [MFINDBUGS-89] - Dependencies no longer properly passed to findbugs for analysis * [MFINDBUGS-91] - Don't remove deprecated fields like findbugsXmlOutput * [MFINDBUGS-93] - Unable to parse XML Findbugs report when errors are reported on java code using generics ** New Feature * [MFINDBUGS-18] - Allow to fork a VM that runs findbugs * [MFINDBUGS-45] - Add timeout option * [MFINDBUGS-46] - Add abilty set memory as an option ** Wish * [MFINDBUGS-72] - Add option to generate html output for findbugs:check Enjoy,