Re: API to resolve an artifact in Maven3
t; configure additional dependencies used by my plugin at runtime > > >> outside of the project dependencies. > > >> > > >> I've used a lot of open source projects but I cannot remember one as > > >> opaque as Maven. I'm looking through maven-dependency-plugin now to > > >> see if I can glean any insights. It seems that plugin used the same > > >> technique you did in its DefaultArtifactsResolver utility class. I'm > > >> going to check out the project from svn to see how its initializing. > > >> > > >> -Original Message- > > >> From: Russell Gold [mailto:r...@gold-family.us] > > >> Sent: Monday, July 22, 2013 7:22 AM > > >> To: Maven Users List > > >> Subject: Re: API to resolve an artifact in Maven3 > > >> > > >> Hi Richard, > > >> > > >> Believe me, I share your frustration. Like many open-source projects, > > >> Maven is woefully under-documented. I've spent a significant amount > > >> of time over the past months researching how to do things for the > > >> course I've been writing, and also for the plugins I'm writing. > > >> > > >> Mostly, I've been reading source code - especially the maven-supplied > > >> plugins. The problem, of course, is figuring out what the "official" > > >> and supported way of doing things is. > > >> > > >> To resolve artifacts, I wound up using MavenProject, > > >> ArtifactResolver, ArtifactFactory, and both the local and remote > > >> repositories. I didn't even see DefaultDependencyGraphBuilder. If > > >> that's easier, I may consider revising my approach. > > >> > > >> Thanks, > > >> Russ > > >> > > >> On Jul 22, 2013, at 1:53 AM, Richard Sand > wrote: > > >> > > >>> Hi Russel - > > >>> > > >>> The use case is simple - I've written a plug-in which takes in as > > >>> input a list of dependencies, just like any other plugin or the pom > > >>> itself. So, given a String representation of an artifact, how do I > > >>> resolve the artifact so I end up with a local File object I can load? > > >>> > > >>> This API has seemed like total voodoo - I want to write a paper that > > >>> demystifies how to write plugins for maven3. I think I need to find > > >>> some time to sit with each of the principle author of maven3 and > > >>> publish what I learn. > > >>> > > >>> -Richard > > >>> > > >>> -Original Message- > > >>> From: Russell Gold [mailto:r...@gold-family.us] > > >>> Sent: Sunday, July 21, 2013 7:52 AM > > >>> To: Maven Users List > > >>> Subject: Re: API to resolve an artifact in Maven3 > > >>> > > >>> Hi Richard, > > >>> > > >>> Can you be more specific? What exactly is your goal? > > >>> > > >>> - Russ > > >>> > > >>> On Jul 20, 2013, at 11:02 PM, Richard Sand > > wrote: > > >>> > > >>>> Can someone please share the secret of how to do dependency > > >>>> resolution in Maven3? And specifically in 3.1? > > >>>> > > >>>> -Richard > > >>>> > > >>>> -Original Message- > > >>>> From: Richard Sand [mailto:rs...@idfconnect.com] > > >>>> Sent: Friday, July 19, 2013 3:45 PM > > >>>> To: 'Maven Users List' > > >>>> Subject: RE: API to resolve an artifact in Maven3 > > >>>> > > >>>> +1 Anthony. The question is what is the preferred 3.x way of doing > > >>>> +it, not > > >>>> how to do it the old way. Unless the official answer is "do it the > > >>>> old way because..." > > >>>> > > >>>> > > >>>> -Original Message- > > >>>> From: Anthony Dahanne [mailto:anthony.daha...@gmail.com] > > >>>> Sent: Friday, July 19, 2013 2:32 PM > > >>>> To: Maven Users List > > >>>> Subject: Re: API to resolve an artifact in Maven3 > > >>>> > > >>>> hello, I 'm slightly confused about your answer Igor. > > >>>&g
Re: API to resolve an artifact in Maven3
hello, I 'm slightly confused about your answer Igor. The other day I was wondering about how to keep a maven plugin doing artifact resolution compatible with both maven 3.0 and 3.1 and Robert answered me to use the maven dependency tree api : http://stackoverflow.com/questions/17685441/can-a-maven-mojo-relying-on-aether-be-compatible-with-maven-3-0-x-and-3-1-x#comment25769765_17686482 Now I am using something like that : Artifact enforceArtifact = defaultArtifactFactory.createArtifact(enforceGroupId,enforceArtifactId,enforceVersion,"",enforceType); MavenProject enforcePom = mavenProjectBuilder.buildFromRepository( enforceArtifact, remoteRepositories, localRepository); DependencyNode rootNode = dependencyGraphBuilder.buildDependencyGraph(enforcePom, new CumulativeScopeArtifactFilter(Arrays.asList(Artifact.SCOPE_COMPILE, Artifact.SCOPE_RUNTIME))); and that works pretty well (I used to think relying on aether directly was the best approach, until this change of package made my plugins not maven 3.1 compatible) Which approach would you consider the best then (when writing a plugin doing dependency resolution) , using the Maven 2 API with maven-compat or relying on maven-dependency-tree ? Thanks for your answer ! Anthony On Fri, Jul 19, 2013 at 1:44 PM, wrote: > Please check next post > > http://mail-archives.apache.org/mod_mbox/maven-users/201307.mbox/%3c7abc22e9-32c5-44f6-bdb3-117414907...@gmail.com%3e > It should helps you > > On Jul 19, 2013, at 9:39 PM, "Richard Sand" wrote: > > > Quick Q- what's the proper way to resolve an artifact in a Maven3 > plug-in, e.g. where the artifact isn't already a managed dependency in the > project. > > > > I found the Mojo Developer Cookbook ( > http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook) but > it gives the Maven2 technique, and the classes used are deprecated. > > > > -Richard > > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > >
Re: [ANN] Apache Tomcat Maven plugin 2.1
OK, it's much clearer now, executing the archetype and running mvn tomcat7:run and browsing to localhost:9090 Yes, the analogy between the executable war and jenkins.war is good example. Thank you Olivier and Stephen for your time, I now have a very good alternative to jetty for my dev. routine; Regards, Anthony On Mon, Feb 25, 2013 at 11:36 AM, Olivier Lamy wrote: > just test the archetype: > http://tomcat.apache.org/maven-plugin-2.1/archetype.html > > > 2013/2/25 Olivier Lamy : > > 2013/2/25 Anthony Dahanne : > >> Hello Olivier, > >> and thanks for the new release ! > >> I am used to mvn jetty:run so that I can quickly embed a war without > >> configuring a servlet container ; and, reading the documentation of > Apache > >> Tomcat Maven executable war, > >> http://tomcat.apache.org/maven-plugin-2.1/executable-war-jar.html , I > >> understand there is no equivalent of mvn jetty:run, right ? > > No, tomcat6:run or tomcat7:run do the same. ( see > > http://tomcat.apache.org/maven-plugin-2.1/run-mojo-features.html) (doh > > I see some filtered variables in the doc I will fix that :-) ) > >> I understand I have to first build the executable war and launch it with > >> java -jar to get the same behavior as mvn jetty:run ? > > This feature is just to build a runnable jar/war. The build jar will > > contain your war(s) and all tomcat needed classes. > > So you will be able to just run: java -jar yourfile.jar > > > >> Or can mvn tomcat7:run be configured to launch an embedded servlet > >> container ? > > yes it do that. > >> > >> Thanks in advance for your answers, > >> Regards, > >> Anthony > >> > >> > >> > >> > >> > >> On Mon, Feb 25, 2013 at 10:40 AM, Olivier Lamy > wrote: > >> > >>> Hi, > >>> > >>> The Apache Tomcat is pleased to announce the release of the 2.1 > >>> version. This plugin can used to run your war project inside an > >>> embeded Apache Tomcat and to deploy your project to a running Apache > >>> Tomcat instance. > >>> > >>> Documentation available: > >>> http://tomcat.apache.org/maven-plugin-2.1/index.html > >>> > >>> > >>> Release Notes - Apache Tomcat Maven Plugin - Version 2.1 > >>> > >>> > >>> ** Bug > >>> * [MTOMCAT-61] - maven tomcat:run ignores the > >>> useSeperateTomcatClassloaded when using serverXml property > >>> * [MTOMCAT-119] - tomcat7:run-war fails because it expects > >>> META-INF\context.xml > >>> * [MTOMCAT-128] - The plugin ignores and/or parses web.xml > >>> incorrectally when using tomcatWebXml option > >>> * [MTOMCAT-173] - Direct dependencies are not added to classpath > >>> * [MTOMCAT-175] - warDirectory property has wrong standard value > >>> in release version 2.0 > >>> * [MTOMCAT-179] - Null pointer dereference in RunMojo > >>> * [MTOMCAT-180] - Allow hostName and alias to be configured for > >>> tomcat6:run etc > >>> * [MTOMCAT-182] - Typo in Tomcat6 AbstractRunWarMojo MOJO > >>> * [MTOMCAT-185] - change phase for tomcat6/7:run to process-classes > >>> * [MTOMCAT-186] - Closing executable JAR does not call > >>> ServletContextListener.contextDestroyed() > >>> * [MTOMCAT-194] - Odd error message in switching from Codehaus to > >>> Maven Tomcat6 plugin > >>> * [MTOMCAT-197] - tomcat7:undeploy goal not ignoring non-war > projects > >>> * [MTOMCAT-198] - Fix base classes for redeploy and redeploy-only > goals > >>> * [MTOMCAT-206] - Runtime dependencies within multi module > >>> projects are not loaded. > >>> > >>> > >>> ** Improvement > >>> * [MTOMCAT-99] - Make redeploy goal consistent with deploy goals > >>> * [MTOMCAT-188] - Allow for the creation of a war that is both > >>> executable and deployable > >>> * [MTOMCAT-190] - Client Certificate settings for connector > >>> * [MTOMCAT-191] - Return the "redeploy" goal to the Maven plugin > >>> * [MTOMCAT-192] - Website text cleanup > >>> * [MTOMCAT-199] - Text cleanup of goal definitions > >>> * [MTOMCAT-200] - Tomcat7:redeploy > >>> * [MTOMCAT-208] - JaCoCo instrumentation errors when running > >>> StandaloneWarMojo > >>> > >>> ** New Feature > >>> * [MTOMCAT-163] - No undeploy goal > >>> > >>> ** Question > >>> * [MTOMCAT-187] - Scan resources executing run goal > >>> > >>> Have Fun, > >>> > >>> -- > >>> The Apache Tomcat Team. > >>> > >>> - > >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: users-h...@maven.apache.org > >>> > >>> > > > > > > > > -- > > Olivier Lamy > > Talend: http://coders.talend.com > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: [ANN] Apache Tomcat Maven plugin 2.1
Hello Olivier, and thanks for the new release ! I am used to mvn jetty:run so that I can quickly embed a war without configuring a servlet container ; and, reading the documentation of Apache Tomcat Maven executable war, http://tomcat.apache.org/maven-plugin-2.1/executable-war-jar.html , I understand there is no equivalent of mvn jetty:run, right ? I understand I have to first build the executable war and launch it with java -jar to get the same behavior as mvn jetty:run ? Or can mvn tomcat7:run be configured to launch an embedded servlet container ? Thanks in advance for your answers, Regards, Anthony On Mon, Feb 25, 2013 at 10:40 AM, Olivier Lamy wrote: > Hi, > > The Apache Tomcat is pleased to announce the release of the 2.1 > version. This plugin can used to run your war project inside an > embeded Apache Tomcat and to deploy your project to a running Apache > Tomcat instance. > > Documentation available: > http://tomcat.apache.org/maven-plugin-2.1/index.html > > > Release Notes - Apache Tomcat Maven Plugin - Version 2.1 > > > ** Bug > * [MTOMCAT-61] - maven tomcat:run ignores the > useSeperateTomcatClassloaded when using serverXml property > * [MTOMCAT-119] - tomcat7:run-war fails because it expects > META-INF\context.xml > * [MTOMCAT-128] - The plugin ignores and/or parses web.xml > incorrectally when using tomcatWebXml option > * [MTOMCAT-173] - Direct dependencies are not added to classpath > * [MTOMCAT-175] - warDirectory property has wrong standard value > in release version 2.0 > * [MTOMCAT-179] - Null pointer dereference in RunMojo > * [MTOMCAT-180] - Allow hostName and alias to be configured for > tomcat6:run etc > * [MTOMCAT-182] - Typo in Tomcat6 AbstractRunWarMojo MOJO > * [MTOMCAT-185] - change phase for tomcat6/7:run to process-classes > * [MTOMCAT-186] - Closing executable JAR does not call > ServletContextListener.contextDestroyed() > * [MTOMCAT-194] - Odd error message in switching from Codehaus to > Maven Tomcat6 plugin > * [MTOMCAT-197] - tomcat7:undeploy goal not ignoring non-war projects > * [MTOMCAT-198] - Fix base classes for redeploy and redeploy-only goals > * [MTOMCAT-206] - Runtime dependencies within multi module > projects are not loaded. > > > ** Improvement > * [MTOMCAT-99] - Make redeploy goal consistent with deploy goals > * [MTOMCAT-188] - Allow for the creation of a war that is both > executable and deployable > * [MTOMCAT-190] - Client Certificate settings for connector > * [MTOMCAT-191] - Return the "redeploy" goal to the Maven plugin > * [MTOMCAT-192] - Website text cleanup > * [MTOMCAT-199] - Text cleanup of goal definitions > * [MTOMCAT-200] - Tomcat7:redeploy > * [MTOMCAT-208] - JaCoCo instrumentation errors when running > StandaloneWarMojo > > ** New Feature > * [MTOMCAT-163] - No undeploy goal > > ** Question > * [MTOMCAT-187] - Scan resources executing run goal > > Have Fun, > > -- > The Apache Tomcat Team. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: snapshot versions and classpath stored in manifest
Brian, I got a tip from a colleague, to use the outputFileNameMapping : https://github.com/anthonydahanne/maven-manifest-and-assembly-bug/commit/bd946565da54be6faa1af71e894b16e6b1b0ff48 I checked with my sample project, and it renames the snapshot to a -SNAPSHOT , which will satisfy the manifest. Do you think this is a hack ? Thanks again, Anthony On Thu, Jan 10, 2013 at 12:14 AM, Anthony Dahanne wrote: > Hello Brian, > So I triple checked, and I specified : (2.4 is the latest version) > > > org.apache.maven.plugins > maven-jar-plugin > 2.4 > > > in each of my modules, but still, if I : > * in my cli project reactor : $ mvn clean deploy > * clean the local repo : $ rm -rf ~/.m2/repository/com/terracotta/ > * in the assembly module : $ mvn clean install -U > > I get : > > z:target anthony$ tar xvzf assembly-1.1.0-SNAPSHOT-bundle.tar.gz > x cli-1.1.0-20130110.023006-1.jar > x dependencyA-1.1.0-20130110.023002-1.jar > x slf4j-jdk14-1.6.6.jar > x slf4j-api-1.6.6.jar > > with the cli manifest having : > Class-Path: dependencyA-1.1.0-SNAPSHOT.jar slf4j-jdk14-1.6.6.jar slf4j > -api-1.6.6.jar > > I set up a very simple example and a nexus instance to reproduce this use > case > https://github.com/anthonydahanne/maven-manifest-and-assembly-bug > > Thanks for having a look, > Anthony > > > > > > > > > On Wed, Jan 9, 2013 at 1:40 PM, Brian Fox wrote: > >> Are you positive you are using jar plugin version 2.3? >> >> >> On Mon, Jan 7, 2013 at 11:26 AM, Anthony Dahanne >> wrote: >> >> > Hello all, >> > I am using Maven 3 with Nexus 2. >> > I am building a cli tool (let's call it cli) , which has dependencies on >> > some other libraries (let's call them dependencyA and dependencyB) >> > To make my cli tool work in every environment, I rely on the manifest >> > classpath, generated with : >> > >> > org.apache.maven.plugins >> > maven-jar-plugin >> > >> > >> > >> > true >> > >> > >> > >> > >> > >> > and then I package everything (cli and its dependencies) using an >> assembly >> > >> > my launcher script looks like : >> > java -jar cli*.jar (the * is there so that I won't need to update the >> > script for any versions) >> > >> > If I build everything locally, in version 1.1.0-SNAPSHOT, here is the >> > manifest classpath entry : >> > Class-Path: dependencyA-1.1.0-SNAPSHOT.jar dependencyB-1.1.0-S >> > NAPSHOT.jar slf4j-jdk14-1.6.6.jar slf4j-api-1.6.6.jar >> > >> > locally, everything is fine >> > >> > Now, if I download the assembly, built by a CI tool and published to >> Nexus, >> > the manifest is still the same, but look at the names of the >> dependencies : >> > ~> ls lib/ >> > cli-1.1.0-20130105.224257-7.jar dependencyA-1.1.0-20130105.224257-7.jar >> > dependencyB-1.1.0-20130105.224257-7.jar >> > >> > As you can imagine, the cli won't find it's dependencies since their >> > version does not match any more the manifest's (SNAPSHOT in the >> manifest, >> > 1.1.0-20130105.224257-7 is what we have) >> > >> > It seems like this issue was fixed some time ago : >> > http://jira.codehaus.org/browse/MJAR-28 >> > >> > Is is a regression ? >> > >> > Thanks a lot for your help! >> > Anthony >> > >> > >
Re: snapshot versions and classpath stored in manifest
Hello Brian, So I triple checked, and I specified : (2.4 is the latest version) org.apache.maven.plugins maven-jar-plugin 2.4 in each of my modules, but still, if I : * in my cli project reactor : $ mvn clean deploy * clean the local repo : $ rm -rf ~/.m2/repository/com/terracotta/ * in the assembly module : $ mvn clean install -U I get : z:target anthony$ tar xvzf assembly-1.1.0-SNAPSHOT-bundle.tar.gz x cli-1.1.0-20130110.023006-1.jar x dependencyA-1.1.0-20130110.023002-1.jar x slf4j-jdk14-1.6.6.jar x slf4j-api-1.6.6.jar with the cli manifest having : Class-Path: dependencyA-1.1.0-SNAPSHOT.jar slf4j-jdk14-1.6.6.jar slf4j -api-1.6.6.jar I set up a very simple example and a nexus instance to reproduce this use case https://github.com/anthonydahanne/maven-manifest-and-assembly-bug Thanks for having a look, Anthony On Wed, Jan 9, 2013 at 1:40 PM, Brian Fox wrote: > Are you positive you are using jar plugin version 2.3? > > > On Mon, Jan 7, 2013 at 11:26 AM, Anthony Dahanne > wrote: > > > Hello all, > > I am using Maven 3 with Nexus 2. > > I am building a cli tool (let's call it cli) , which has dependencies on > > some other libraries (let's call them dependencyA and dependencyB) > > To make my cli tool work in every environment, I rely on the manifest > > classpath, generated with : > > > > org.apache.maven.plugins > > maven-jar-plugin > > > > > > > > true > > > > > > > > > > > > and then I package everything (cli and its dependencies) using an > assembly > > > > my launcher script looks like : > > java -jar cli*.jar (the * is there so that I won't need to update the > > script for any versions) > > > > If I build everything locally, in version 1.1.0-SNAPSHOT, here is the > > manifest classpath entry : > > Class-Path: dependencyA-1.1.0-SNAPSHOT.jar dependencyB-1.1.0-S > > NAPSHOT.jar slf4j-jdk14-1.6.6.jar slf4j-api-1.6.6.jar > > > > locally, everything is fine > > > > Now, if I download the assembly, built by a CI tool and published to > Nexus, > > the manifest is still the same, but look at the names of the > dependencies : > > ~> ls lib/ > > cli-1.1.0-20130105.224257-7.jar dependencyA-1.1.0-20130105.224257-7.jar > > dependencyB-1.1.0-20130105.224257-7.jar > > > > As you can imagine, the cli won't find it's dependencies since their > > version does not match any more the manifest's (SNAPSHOT in the manifest, > > 1.1.0-20130105.224257-7 is what we have) > > > > It seems like this issue was fixed some time ago : > > http://jira.codehaus.org/browse/MJAR-28 > > > > Is is a regression ? > > > > Thanks a lot for your help! > > Anthony > > >
snapshot versions and classpath stored in manifest
Hello all, I am using Maven 3 with Nexus 2. I am building a cli tool (let's call it cli) , which has dependencies on some other libraries (let's call them dependencyA and dependencyB) To make my cli tool work in every environment, I rely on the manifest classpath, generated with : org.apache.maven.plugins maven-jar-plugin true and then I package everything (cli and its dependencies) using an assembly my launcher script looks like : java -jar cli*.jar (the * is there so that I won't need to update the script for any versions) If I build everything locally, in version 1.1.0-SNAPSHOT, here is the manifest classpath entry : Class-Path: dependencyA-1.1.0-SNAPSHOT.jar dependencyB-1.1.0-S NAPSHOT.jar slf4j-jdk14-1.6.6.jar slf4j-api-1.6.6.jar locally, everything is fine Now, if I download the assembly, built by a CI tool and published to Nexus, the manifest is still the same, but look at the names of the dependencies : ~> ls lib/ cli-1.1.0-20130105.224257-7.jar dependencyA-1.1.0-20130105.224257-7.jar dependencyB-1.1.0-20130105.224257-7.jar As you can imagine, the cli won't find it's dependencies since their version does not match any more the manifest's (SNAPSHOT in the manifest, 1.1.0-20130105.224257-7 is what we have) It seems like this issue was fixed some time ago : http://jira.codehaus.org/browse/MJAR-28 Is is a regression ? Thanks a lot for your help! Anthony
Re: specifying different dependencies according to versions
Hello Ron, Let me try to explain with other terms what we have and we want to do : we have refactored an artifact, changing his name and even its group name; * from version 1.0.0 to 2.5.0, this artifact was named my.company:my.artifact.core:version * from version 2.5.1 and up , this artifact is named my.company:my.artifact:version We have consumers of this artifact, that may depend on it directly and indirectly. Well, we were afraid of dependency clashes, and this is why we talked about version ranges (imagining a dependency chooses the right version, and other ones, using range versions, just cope with it) instead of specifying directly the right version. Now reading your email, and trying to answer your questions , I finally found out that transitive dependencies clashes can be avoided with exclusion http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html Problem solved :-) Thanks, Anthony On Fri, Oct 5, 2012 at 10:14 AM, Ron Wheeler wrote: > What are you trying to accomplish? > Why is your situation different from the normal system development process > that everyone else uses. > > What version do you want to run at run-time? > > In the pom of the artifact that you are making, set the dependency to the > version of my.artifact.core that you want to build > with. > > > It is hard to see what you are trying to tell us with this > > > "as this is internal now, we created a new module > > > my.company > my.artifact > 2.6.0-SNAPSHOT > > " > In what POM does this dependency appear? Why? How does this relate to > -core. > > If you followed last weeks discussion about version ranges, you might have > noted that they are regarded by most as inherently evil and by others as > poorly implemented. > > In general, you should pick a version of the dependency that you want to > build with and identify it with a specific version. > > A range of SNAPSHOTs makes no sense to me at all. > Ron > > > > > > On 05/10/2012 10:00 AM, Anthony Dahanne wrote: >> >> Hello all, >> We recently changed the packaging of some modules in our application : >> >>my.company >>my.artifact.core >>2.5.0-SNAPSHOT >> >> to >> >>my.company.internal >>my.artifact.core >>2.6.0-SNAPSHOT >> >> >> as this is internal now, we created a new module >> >> >>my.company >>my.artifact >>2.6.0-SNAPSHOT >> >> >> >> I have a maven module that could depend on >> my.company:my.artifact.core:2.5.0-SNAPSHOT as well as any other >> following releases, including my.company:my.artifact:2.6.0-SNAPSHOT >> I could have used a version range such as: [2.5.0,) >> if only my packaging did not change... >> >> My question is : can we tell maven to depend on >> my.company:my.artifact.core for a certain range of version and >> depend on my.company:my.artifact for another range of version? >> >> Thank you very much for your answers, >> Anthony >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
specifying different dependencies according to versions
Hello all, We recently changed the packaging of some modules in our application : my.company my.artifact.core 2.5.0-SNAPSHOT to my.company.internal my.artifact.core 2.6.0-SNAPSHOT as this is internal now, we created a new module my.company my.artifact 2.6.0-SNAPSHOT I have a maven module that could depend on my.company:my.artifact.core:2.5.0-SNAPSHOT as well as any other following releases, including my.company:my.artifact:2.6.0-SNAPSHOT I could have used a version range such as: [2.5.0,) if only my packaging did not change... My question is : can we tell maven to depend on my.company:my.artifact.core for a certain range of version and depend on my.company:my.artifact for another range of version? Thank you very much for your answers, Anthony - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: strategy for incorporating private jars into a project
you could do that...(not leveraging maven at all and writing custom svn related scripts) but you could also go the suggested "push snapshots to repo" way, keeping a large snapshots history... (btw snapshots are tagged with a timestamp) On Wed, Sep 19, 2012 at 1:30 PM, mlandman99 wrote: > The suggestion (automatically upload to local repo) sounds like a good one, > though I thought of a different solution that I'd like your opinion on: > > This project is used for running integration-level regression tests. The > project is checked into source control (SVN). > > Conceivably, I may have a need to run the project tomorrow against an older > version of code. If I were to do this, I'd want to run with the same version > of the internal jars that I had used at that date. > > If I were to tell SVN to load the project as of date/label x (might be a > release from 6 months ago..) -- and then run the project, I wouldn't want to > take the latest version of those internal jars, I'd want to use the version > that I used back at that date. > > To that end, I was thinking of creating a subdirectory within the project > inside SVN reserved for holding those internal jars. This way, whenever I > revert the project back to SVN version , I'll be assured I'm using those > same version of those same internal jars that I had originally used on that > date/label. > > To ensure I'm using the latest version (when I'm trying to run 'latest'), I > could write a script to auto-commit those jars to the subdirectory of my > project within SVN, overwriting the previous version. In reality it seems > very similar to the suggestion you had, but it's utilizing SVN to house > those artifacts instead of the local nexus repo. > > What are your thoughts on this? > > If I were to do this, what would the proper configuration be for Maven, i.e. > to treat this special subdirectory as a location for retrieving artifacts, > and to ensure that it's not cached, so that when I build, it will always use > the version in that directory? > > Thanks for your help. I'm fairly new at this and appreciate the guidance. > > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5722573.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: strategy for incorporating private jars into a project
hello, why don't you push those private jars as snapshot versions into your local nexus ? Then in your build, use something like -U to make sure maven grabs the latest snapshots. Anthony On Wed, Sep 19, 2012 at 11:04 AM, mlandman99 wrote: > Hi, > > My java project has several dependencies, both external (i.e. in the public > repo) and private (built by our own company). It's a QA project, that can be > run locally in Eclipse, and also runs on a CI server (teamcity). When it > 'builds', it runs then maven phase: "integration-test", which then runs > testNG tests within my classes. So far so good. > > Unfortunately the private jars that it uses are not under any sort of > control. They are built by a different team in my company, and are placed in > an available network-share, but that's it. They don't seem to be properly > 'versioned', and are not placed in any local (nexus) repository, unless I > manually put them there. > > For running nightly automated testing, I want to ensure I always utilize the > most recent version of those private jars. So far, I've manually placed a > version of them in a local nexus repo, and they are successfully pulled down > when teamcity runs the build. But I don't have a way of getting the nightly > builds up inside that nexus repo. Even if I did, they would always just be > "version 1.0" and probably won't be re-downloaded anyway. > > So... I'm looking for suggestions re: a strategy on how to *ensure* that > each time my project is built, that it properly grabs the new version of > those private jars, of which the only reliable way to access them is in a > network share drive. The other public jars are successfully managed by > maven. > > Is there a way to use Maven to help me pull in these private jars that exist > on a network share? If anyone has any suggestions on a strategy re: how I > can proceed, I'd appreciate it! > > Thanks! > > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524.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: [ANN] Maven Inspector for Eclipse
Hello Pascal, Thanks for contributiong this plugin, this is a very good idea, and will save users a lot of time debugging maven builds. One remark though : * do you think it would be possible to contribute this view directly into m2e ? did you contact m2e team ? I mean, that would ease adoption of the plugin, and it seems to me that it would be useful for all m2e users. Thanks again Pascal, Anthony On Fri, Jul 13, 2012 at 11:06 AM, Pascal Rapicault wrote: > As much as Maven makes it easy to deal with builds, the plethora of XML and > the varying life cycles phases can sometimes make it hard to figure out what > a build will actually do. > > To help with this, I'm happy to make available the Eclipse plugin called the > "Maven Inspector". This plugin provides a simple View called "Maven > Execution" that presents for a given POM file the phases and associated MOJOs. > > Go check it out on http://prapicault.github.com/MavenInspector/ or directly > install it from http://prapicault.github.com/MavenInspector/repository > > Hope you'll find this useful. > > Pascal > - > 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: maven dependency plugin and maven 3
Hi Wayne, you are right, running the purge corrupted my local repo in a way : $ ls ~/.m2/repository/javax/servlet/servlet-api/2.5/ _maven.repositories servlet-api-2.5.jar servlet-api-2.5.jar.lastUpdated servlet-api-2.5.jar.sha1 and if I run mvn clean install just after , everything gets back to normal. $ ls ~/.m2/repository/javax/servlet/servlet-api/2.5/ _maven.repositories servlet-api-2.5.jar.lastUpdated servlet-api-2.5.pom servlet-api-2.5.pom.sha1 servlet-api-2.5.jar servlet-api-2.5.jar.sha1 servlet-api-2.5.pom.lastUpdated updating the Jira, thanks Anthony On Mon, Jun 4, 2012 at 10:47 AM, Wayne Fay wrote: >> [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5 >> [WARNING] Missing POM for >> net.dahanne.gallery:commons-gallery:jar:2.1.0-SNAPSHOT >> even though those 2 artifacts are existing in my local repo. > > Have you looked at the content of those pom files to ensure they > aren't corrupted? > > Wayne > > - > 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: maven dependency plugin and maven 3
Update ! Creating a jira for this issue, providing the same example pom, http://jira.codehaus.org/secure/attachment/60149/pom.xml when I tried to reproduce on a linux box, with the latest maven 3.0.4 >> > 1) do a mvn package >> > 2) then do a mvn >> > org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository >> > -Dverbose=true -DresolutionFuzziness=version it actually worked as designed : ubuntu@ubuntu-server:~/maven-issue$ /opt/apache-maven-3.0.4/bin/mvn org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository -Dverbose=true -DresolutionFuzziness=version [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building pof 1.0.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-dependency-plugin:2.4:purge-local-repository (default-cli) @ pof --- [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5 [WARNING] Missing POM for net.dahanne.gallery:commons-gallery:jar:2.1.0-SNAPSHOT [INFO] Processing dependencies for project: net.dahanne:pof:jar:1.0.0-SNAPSHOT [INFO] Processing artifact: javax.servlet:servlet-api:jar:2.5 [INFO] Deleting: /home/ubuntu/.m2/repository/javax/servlet/servlet-api/2.5 [INFO] Re-resolving. Downloading: http://nexus.dahanne.net/nexus/content/repositories/snapshots/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar Downloading: http://nexus.dahanne.net/nexus/content/repositories/releases/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar Downloading: http://repo.maven.apache.org/maven2/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar Downloaded: http://repo.maven.apache.org/maven2/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar (103 KB at 15.9 KB/sec) [INFO] Processing artifact: net.dahanne.gallery:commons-gallery:jar:2.1.0-SNAPSHOT [INFO] Deleting: /home/ubuntu/.m2/repository/net/dahanne/gallery/commons-gallery/2.1.0-SNAPSHOT [INFO] Re-resolving. Downloading: http://nexus.dahanne.net/nexus/content/repositories/snapshots/net/dahanne/gallery/commons-gallery/2.1.0-SNAPSHOT/maven-metadata.xml Downloading: http://nexus.dahanne.net/nexus/content/repositories/releases/net/dahanne/gallery/commons-gallery/2.1.0-SNAPSHOT/maven-metadata.xml Downloaded: http://nexus.dahanne.net/nexus/content/repositories/snapshots/net/dahanne/gallery/commons-gallery/2.1.0-SNAPSHOT/maven-metadata.xml (998 B at 2.1 KB/sec) Downloading: http://nexus.dahanne.net/nexus/content/repositories/snapshots/net/dahanne/gallery/commons-gallery/2.1.0-SNAPSHOT/commons-gallery-2.1.0-20120525.140124-5.jar Downloaded: http://nexus.dahanne.net/nexus/content/repositories/snapshots/net/dahanne/gallery/commons-gallery/2.1.0-SNAPSHOT/commons-gallery-2.1.0-20120525.140124-5.jar (16 KB at 23.3 KB/sec) [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 17.522s [INFO] Finished at: Mon Jun 04 09:10:33 EDT 2012 [INFO] Final Memory: 6M/14M [INFO] my dependencies were deleted and re resolved ! One thing though, is that I still had those messages : [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5 [WARNING] Missing POM for net.dahanne.gallery:commons-gallery:jar:2.1.0-SNAPSHOT even though those 2 artifacts are existing in my local repo. So I created a bug in the maven dependency plugin Jira : http://jira.codehaus.org/browse/MDEP-356 to consider the use of maven 3 dependency resolver in the maven dependency plugin Thanks, Anthony On Mon, Jun 4, 2012 at 4:09 AM, Stephen Connolly wrote: > From what I recall, nobody has yet updated dependency:tree to query > aether's graph directly rather than go through the emulation of 2.x's API > for examining the dependency tree. When I last chatted on this with > Benjamin, he left me with the distinct impression that I should not rely on > the output of dependency:tree when run on m3 until it has been adapted to > query aether's graph more directly... But having said all that, I usually > find it "good enough" and it may just be some edge cases that Benjamin was > referring to, in which case I would suspect this is one of those edges. > > On Sunday, 3 June 2012, Jason van Zyl wrote: > >> You need to make a test case so we can reproduce it. It's impossible to >> tell whether it's you, your environment, the dependency plugin or Maven >> itself from looking at the textual output of the build. >> >> On Jun 3, 2012, at 11:42 AM, Anthony Dahanne wrote: >> >> > Hello all, >> > sorry to bump ... :-( >> > but I'm still having issues understanding what's wrong with the maven >> > dependency plugin and maven 3..
Fwd: maven dependency plugin and maven 3
Hello all, sorry to bump ... :-( but I'm still having issues understanding what's wrong with the maven dependency plugin and maven 3... I attached a pom to demonstrate the problem : Using maven 3, 1) do a mvn package 2) then do a mvn org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository -Dverbose=true -DresolutionFuzziness=version -U You will see the following output : [INFO] --- maven-dependency-plugin:2.4:purge-local-repository (default-cli) @ pof --- [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5 [INFO] Skipping: pof. It cannot be resolved. [INFO] Nothing to do for project: net.dahanne:pof:jar:1.0.0-SNAPSHOT But I can tell you javax.servlet:servlet-api:jar:2.5 has a pom, and is already installed in the local maven repository. Could you guys share some light on this ? I think the maven dependency plugin is not working fine with maven 3 , as opposed to what the documentation says : https://cwiki.apache.org/MAVEN/maven-3x-plugin-compatibility-matrix.html Thanks, Anthony -- Forwarded message ------ From: Anthony Dahanne Date: Thu, May 31, 2012 at 5:50 PM Subject: maven dependency plugin and maven 3 To: users@maven.apache.org Hello all, I'm only using maven 3 on my machine (be it command line or m2e). I tried to use the maven dependency plugin on a project, mvn org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository -Dverbose=true -DresolutionFuzziness=version and it printed such warnings : [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5 [WARNING] Missing POM for org.easymock:easymock:jar:3.0 [WARNING] Missing POM for junit:junit:jar:4.8.2 before telling me that the build was successful. Thing is, it did not purge anything from my repo; because of those warnings actually; launching the same command with -X, I could see : [DEBUG] Verifying availability of /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom from [] [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5: Error resolving project artifact: Could not find artifact javax.servlet:servlet-api:pom:2.5 for project javax.servlet:servlet-api:pom:2.5 [DEBUG] javax.servlet:servlet-api:jar:2.5:provided (selected for provided) and... I can tell you /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom exists and contains : 4.0.0 javax.servlet servlet-api 2.5 Debugging the code a little, I could notice that this goal was using org.apache.maven.artifact.resolver.DefaultArtifactResolver#resolveTransitively from maven-artifact-manager 2.0.9 to find the dependencies. I am wondering if this plugin failed purging my dependencies because it used a maven 2 library to scan the dependencies, and my local repo has only been built and used by mvn3 (and the repo metadata/layout could be different to what this plugin was expecting) .. Any thoughts ? thanks a lot in advance Anthony http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> 4.0.0 net.dahanne pof 1.0.0-SNAPSHOT net.dahanne.gallery commons-gallery 2.1.0-SNAPSHOT javax.servlet servlet-api 2.5 dahanne-snapshots http://nexus.dahanne.net/nexus/content/repositories/snapshots/ dahanne-releases http://nexus.dahanne.net/nexus/content/repositories/releases/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven dependency plugin and maven 3
Hello all, I'm only using maven 3 on my machine (be it command line or m2e). I tried to use the maven dependency plugin on a project, mvn org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository -Dverbose=true -DresolutionFuzziness=version and it printed such warnings : [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5 [WARNING] Missing POM for org.easymock:easymock:jar:3.0 [WARNING] Missing POM for junit:junit:jar:4.8.2 before telling me that the build was successful. Thing is, it did not purge anything from my repo; because of those warnings actually; launching the same command with -X, I could see : [DEBUG] Verifying availability of /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom from [] [WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5: Error resolving project artifact: Could not find artifact javax.servlet:servlet-api:pom:2.5 for project javax.servlet:servlet-api:pom:2.5 [DEBUG] javax.servlet:servlet-api:jar:2.5:provided (selected for provided) and... I can tell you /Users/anthony/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.pom exists and contains : 4.0.0 javax.servlet servlet-api 2.5 Debugging the code a little, I could notice that this goal was using org.apache.maven.artifact.resolver.DefaultArtifactResolver#resolveTransitively from maven-artifact-manager 2.0.9 to find the dependencies. I am wondering if this plugin failed purging my dependencies because it used a maven 2 library to scan the dependencies, and my local repo has only been built and used by mvn3 (and the repo metadata/layout could be different to what this plugin was expecting) .. Any thoughts ? thanks a lot in advance Anthony - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
