Re: [VOTE] Retire Maven One Plugin
+1 S. On Sat, Jul 20, 2013 at 11:13 AM, Dennis Lundberg denn...@apache.orgwrote: Hi, Now that we have Maven 1 at End-Of-Life, I think it's time to retire Maven One Plugin as well. It has been almost six years since the last release. I therefor propose that we retire maven-one-plugin. http://maven.apache.org/plugins/maven-one-plugin/ If this vote is successful I will make one final release of the plugin, making it clear on the plugin site that it has been retired. After that the source code will be moved into the retired area in Subversion. The process for retiring a plugin is described here, and is being improved: http://maven.apache.org/developers/retirement-plan-plugins.html The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
mvn release:prepare does not update parent version
I'm driving nuts with mvn release:prepare...: When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Thanks! -Markus
Antwort: mvn release:prepare does not update parent version
Hi Markus using mvn release:prepare -DautoVersionSubmodules=true should solve your problem. Greetz, Sandra Von:Markus Karg k...@quipsy.de An: users@maven.apache.org, Datum: 22.07.2013 09:47 Betreff:mvn release:prepare does not update parent version I'm driving nuts with mvn release:prepare...: When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Thanks! -Markus
Installing/deploying effective rather than original POM
I have a POM file that contains a profile used specifically during development, and another (default) used for release builds. In the POM that gets installed and deployed when building a release build, I do not want to expose any traced of the development profile, as these should not be seen by users of the library being built. Is there a way I can get Maven to generate and install/deploy the effective POM resulting after profiles have been replied, i.e. one where properties have been replaced with their effective values, only the dependencies listed in active profiles show up etc? Cheers, Kristian
Re: Validate html encoding with maven in webapp project
Hi, Validating an encoding is actually more complex than it seems. Basically, it's about validating some bytes (or bytes sequences in utf-8). It's not feasible apart from using some heuristics (meaning, ok you're using a brasil locale, so I'm gonna look for weird byte combinations, but no 100% sure I'm not gonna trigger false positives). I don't know of a tool that would do that in maven. But if you find any tool or lib that satisfies you then I suppose that one could be integrated as an enforcer rule. Hth. Cheers Le 22 juil. 2013 07:42, Maximiliano Milicich maximilianomilic...@gmail.com a écrit : Let me put it this way: If I take one java Class of my project, I add some latin characters like á é í ó ú ñ (we use it a lot in spanish writing), and I save this *.java file choosing in IDE editor options ANSI encoding instead of UTF8 encoding, then when I invoke maven compiling: $ mvn clean package I get this BUILD FAILURE message: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project xyz: Com pilation failure: Compilation failure: [ERROR] /usr/home/xyz/src/main/java/ar/com/xyz/pdf/SeamPdfDocument.java:[35,95] unmappable character for encoding UTF-8 This is, as far as i know, because of having this setting project.build.sourceEncodingUTF-8/project.build.sourceEncoding in my POM's properties. Could I achieve the same validation but with my *.html files content? I mean, If I open xyz.html and I add the following line pthese are latin problematic characters: á é í ó ú ñ Ñ /p I save file with ANSI encoding instead of UTF-8 Could I get Maven give me some warning about this? Thanks againg Max from Buenos Aires, Argentina On Mon, Jul 22, 2013 at 2:08 AM, Russell Gold r...@gold-family.us wrote: What would validation consist of? How would you determine that interpreting the file as UTF-8 would produce the correct view? It seems to me that if you can actually decide what the rules are that you could write a test for it. But I cannot imagine any general automatic way to do it, as a matter of principle. - Russ On Jul 22, 2013, at 12:56 AM, Maximiliano Milicich maximilianomilic...@gmail.com wrote: Hello: Is it posible to get Maven validate html encoding in a webapp project at compile time? Sometimes developers make mistakes and save files with wrong encoding, and this error appears only when the webapp is deployed onto the web server. I've tried so far with maven-resource-plugin with this section: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version2.6/version configuration encodingUTF-8/encoding /configuration /plugin /plugins /build But it makes nothing...it packages my webapp project even with html with wrong encoding. I'm using Maven 3.0.5 Thanx in advance Max from Buenos Aires, Argentina - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html!
Re: Installing/deploying effective rather than original POM
Hi, IIRC, I don't think this is possible. My 2 cents. Le 22 juil. 2013 11:20, Kristian Freed kristian.fr...@gmail.com a écrit : I have a POM file that contains a profile used specifically during development, and another (default) used for release builds. In the POM that gets installed and deployed when building a release build, I do not want to expose any traced of the development profile, as these should not be seen by users of the library being built. Is there a way I can get Maven to generate and install/deploy the effective POM resulting after profiles have been replied, i.e. one where properties have been replaced with their effective values, only the dependencies listed in active profiles show up etc? Cheers, Kristian
Re: Installing/deploying effective rather than original POM
You could do something with maven-invoker-plugin and have something else generate the filtered pom file for you... you'd have to do some dancing games though. I would suspect, though, that you have some anti-patterns in your pom in the first place. Perhaps you should re-evaluate how and why you think you need these different profiles. On 22 July 2013 10:59, Baptiste MATHUS m...@batmat.net wrote: Hi, IIRC, I don't think this is possible. My 2 cents. Le 22 juil. 2013 11:20, Kristian Freed kristian.fr...@gmail.com a écrit : I have a POM file that contains a profile used specifically during development, and another (default) used for release builds. In the POM that gets installed and deployed when building a release build, I do not want to expose any traced of the development profile, as these should not be seen by users of the library being built. Is there a way I can get Maven to generate and install/deploy the effective POM resulting after profiles have been replied, i.e. one where properties have been replaced with their effective values, only the dependencies listed in active profiles show up etc? Cheers, Kristian
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 rs...@idfconnect.com 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 rs...@idfconnect.com 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. 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-o n-aeth er-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 ,enfor ceVersion,,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, igor.zaplet...@gmail.com wrote: Please check next post http://mail-archives.apache.org/mod_mbox/maven-users/201307.mbox/%3c7 A bc22e9-32c5-44f6-bdb3-117414907...@gmail.com%3e It should helps you On Jul 19, 2013, at 9:39 PM, Richard Sand rs...@idfconnect.com 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 - 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 - Come read my webnovel, Take a Lemon
Re: how to properly propagate plugin results into subsequent phases
Hi Richard,
I would probably use a multi-module project, here, with the war module
depending on the others it needs to include.
- Russ
On Jul 22, 2013, at 1:55 AM, Richard Sand rs...@idfconnect.com wrote:
Hoping someone in the know will work with me to get this answered. Its an
important use case for how plugins affect the project and further downstream
activity. Please reach out to me if you can spare 30 minutes to chat with me
about this subject. Thanks!
-Original Message-
From: Richard Sand [mailto:rs...@idfconnect.com]
Sent: Thursday, July 18, 2013 2:02 AM
To: 'Maven Users List'
Subject: RE: how to properly propagate plugin results into subsequent phases
Hi all,
Can someone please help me with the proper technique when manipulating the
dependent artifacts within a custom plugin.
To put it simply, my plug-in may take in multiple source, say
/target/classes plus for example 3 dependent compile-time artifacts. It'll
take these in - classes, plus 3 dependent libraries, and run them through
the processor. It'll save the results as a jar file called
${projectname}-small.jar
Sometimes, we're now done. But more often than not, there are more stages to
be processed. For example, maven-war-plugin needs to make a war package with
the input artifacts. So, what I want to do is include the obfuscated jar as
a library in the WEB-INF/lib of the war, but I want to skip the classes and
other 3 dependent artifacts that went into the optimizer. What is the best
way to do this, in keeping with maven architecture?
Appreciate any help!
-Richard
-Original Message-
From: Richard Sand [mailto:rs...@idfconnect.com]
Sent: Saturday, July 13, 2013 11:36 AM
To: 'Maven Users List'
Subject: how to properly propagate plugin results into subsequent phases
Hi all,
I'm having trouble getting the output jar from this obfuscation plug-in I'm
writing to be processed properly by subsequent plugins (e.g.
maven-war-plugin and maven-install-plugin). Can someone with more savvy with
the Maven 3.0 API give some advice on where I'm going wrong?
The obfuscator takes the class files from ${project.build.outputDirectory}
(e.g. ./target/classes), plus optionally some other jars from the project
dependencies, and creates an obfuscated jar file such as
${project.build.directory}/${project.build.finalName}-obfuscated.jar.
What I want to do is add this new jar, e.g.
myproject-1.0.0-obfuscated.jar, into subsequent phases such as
maven-war-plugin (to be included in the output artifact's WEB-INF/lib
folder) while excluding the input (e.g. ignore the ./target/classes and the
dependent jars which were included in the obfuscation).
To add the obfuscated jar into subsequent phases, I tried to include it by
using mavenProjectHelper.attachArtifact - but this gave me a very strange
behavior - when the install-plugin executed, it took the war file created by
maven-war-plugin and installed that over top of my last dependent jar! In
other words, it took myapp-1.0.0.war and myapp-1.0.0.pom and put them into
the repository as somedependency.jar and somedependency.pom. Very strange -
and although I'm sure I'm doing something wrong, that outcome feels like a
bug to me anyway. At least something that isn't idiot-proof! But this is
where I am least confident in my approach - can someone advise if I'm doing
this with the wrong technique?
To prevent the dependent jars which were obfuscated from being included in
subsequent phases, I'm finding each dependency from the project artifact
map, and then doing artifact.setScope(Artifact.SCOPE_PROVIDED) and
mavenProject.setArtifact(artifact) to put it back into the project. Any
comment on this technique?
Lastly, I'm not sure how to exclude the primary output from the compile
phase - e.g. if I compile ./target/classes, or if my plugin is running after
the packaging phase and I've got ./target/myproject-1.0.0.jar, how do I
exclude these after I successfully include
./target/myproject-1.0.0-obfuscated.jar?
Appreciate any help here. Thanks!
-Richard
-
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
-
Come read my webnovel, Take a Lemon http://www.takealemon.com,
and listen to the Misfile radio play
http://www.gold-family.us/audio/misfile.html!
mvn release:prepare does not update parent version
I'm driving nuts with mvn release:prepare...: When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Thanks! -Markus - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: ForkedBooter in 2.2.1 does not honor MAVEN_OPTS
Thanks for the help. I considered using the argLine param. Reading the docs it seemed like that would mean setting it globally for all users in the pom.xml. I ended up just doing #!/bin/bash (export _JAVA_OPTIONS=-Djava.awt.headless=true /usr/local/apache-maven/bin/mvn $@) to set it for all java processes started in that sub shell. Again, thanks for the help! On Mon, Jul 22, 2013 at 1:57 AM, Vincent Latombe vincent.lato...@gmail.comwrote: Hello, This is the JVM forked to execute unit tests (through maven-surefire-plugin). Check [1] to set options for that jvm. [1] http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#argLine Vincent 2013/7/20 Ben Siemon ben.sie...@opower.com Specifically I have -Djava.awt.headless=true set in my maven options. Other surefire booters seem to honor the headless mode and not steal focus but the ForkedBooter still steals focus even when headless is set to true in MAVEN_OPTS. Running jps -v yields this view of the two maven jvms started: Parent Maven with the correct MAVNE_OPTS 29028 Launcher -Xms2048m -Xmx4096m -XX:PermSize=1024m -XX:MaxPermSize=2048m -Djava.awt.headless=true -Dclassworlds.conf=/usr/local/apache-maven//bin/m2.conf -Dmaven.home=/usr/local/apache-maven/ ForkedBooter without the maven opts. This process steals my screen each time it runs. 29033 surefirebooter3016997434240550753.jar -XX:+HeapDumpOnOutOfMemoryError -Xmx512M -XX:MaxPermSize=128M maven version: Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) Java version: 1.6.0_51 Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x version: 10.8.4 arch: x86_64 Family: mac Upgrading from this version is not currently possible. I am not sure why mvn is now using this forked booter in place of the earlier one that honored MAVEN_OPTS. It might be that upstream changes in parent artifacts are forcing me to run the ForkedBooter instead. Thanks for any help you can offer. -- *Ben Siemon* Senior Software Engineer, Engineering *Opower* http://www.opower.com We’re hiring! See jobs here http://www.opower.com/careers. -- *Ben Siemon* Senior Software Engineer, Engineering *Opower* http://www.opower.com We’re hiring! See jobs here http://www.opower.com/careers.
Re: mvn release:prepare does not update parent version
Hi, which version of Maven and Maven-Release-Plugin are you using? On Mon, Jul 22, 2013 at 9:25 AM, Markus Karg k...@quipsy.de wrote: I'm driving nuts with mvn release:prepare...: When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Thanks! -Markus - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn release:prepare does not update parent version
Greetings, On Mon, Jul 22, 2013 at 8:25 AM, Markus Karg k...@quipsy.de wrote: When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I don't think the language says that at all. I ran a quick build and I'm not seeing where it says it will update every single SNAPSHOT version referenced in the POM. Can you please paste it? I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. And it should not. It will rewrite the versions for the artifacts in its build plan, and the parent is not part of the build plan in this way. It would be horrifying, frankly, if running a release in a project would go update the parent project also. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. I don't think it should obviously do that. Perhaps you actually intended to run the release from the parent, if that is true, then you should do it from there. Not from within some submodule. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Run the release from the proper location. Or if the parent really does not have a submodule of the project you're errantly trying to run the release from right now, then you should release it (parent) first and then make the updates in the unlinked child projects to the latest release number. The m-versions-p is quite adept at automating this process. -Jesse - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: API to resolve an artifact in Maven3
Hey Russell - DependencyGraphBuilder seems to be for resolving the dependencies that the project already has, i.e. in the projectdependencies element. What I'm trying to do now is 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 rs...@idfconnect.com 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 rs...@idfconnect.com 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. 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- o n-aeth er-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,enforceArtifactI d ,enfor ceVersion,,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, igor.zaplet...@gmail.com wrote: Please check next post http://mail-archives.apache.org/mod_mbox/maven-users/201307.mbox/%3c 7 A bc22e9-32c5-44f6-bdb3-117414907...@gmail.com%3e It should helps you On Jul 19, 2013, at 9:39 PM, Richard Sand rs...@idfconnect.com 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 (
Re: API to resolve an artifact in Maven3
You are not using Maven; you are developing a custom plug-in. That is a development activity so you should expect that it will be more difficult than what other users need to do and you will need information that is of no use to anyone else. It appears that you are trying to extend Maven in a way that is outside what Maven likes to do so you can expect that some information will be hard to find outside the code. Ron On 22/07/2013 2:54 PM, Richard Sand wrote: Hey Russell - DependencyGraphBuilder seems to be for resolving the dependencies that the project already has, i.e. in the projectdependencies element. What I'm trying to do now is 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 rs...@idfconnect.com 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 rs...@idfconnect.com 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. 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- o n-aeth er-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,enforceArtifactI d ,enfor ceVersion,,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, igor.zaplet...@gmail.com wrote: Please check next post
RE: mvn release:prepare does not update parent version
Thanks for picking up this thread! I am using: Maven 3.0.4 and maven-release-plugin 2.4.1 -Markus Hi, which version of Maven and Maven-Release-Plugin are you using? On Mon, Jul 22, 2013 at 9:25 AM, Markus Karg k...@quipsy.de wrote: I'm driving nuts with mvn release:prepare...: When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Thanks! -Markus - 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: API to resolve an artifact in Maven3
Hi Ron - I'm not sure what you're telling me. I thought that the capability to easily write custom plug-ins was part of the goal of Maven. If Maven doesn't want people outside of Maven writing plug-ins, then you're right the information I'm looking for isn't useful. But the javadocs are published - they just aren't filled in. Examples are published, but they're for Maven 2 and either don't work or are deprecated. Basic tasks that *seem* to be within the scope of what Maven wants to do are surprisingly difficult. That's frustrating. The questions I've asked on this this have been as specific and technical as I could make them. I'm not trying to waste anyone's time or not respect the work that others have volunteered. -Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 3:11 PM To: users@maven.apache.org Subject: Re: API to resolve an artifact in Maven3 You are not using Maven; you are developing a custom plug-in. That is a development activity so you should expect that it will be more difficult than what other users need to do and you will need information that is of no use to anyone else. It appears that you are trying to extend Maven in a way that is outside what Maven likes to do so you can expect that some information will be hard to find outside the code. Ron On 22/07/2013 2:54 PM, Richard Sand wrote: Hey Russell - DependencyGraphBuilder seems to be for resolving the dependencies that the project already has, i.e. in the projectdependencies element. What I'm trying to do now is 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 rs...@idfconnect.com 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 rs...@idfconnect.com 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. 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 - o n-aeth
RE: mvn release:prepare does not update parent version
Thanks for picking this up. Please find answers inlined. :-) When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I don't think the language says that at all. I ran a quick build and I'm not seeing where it says it will update every single SNAPSHOT version referenced in the POM. Can you please paste it? [INFO] Checking dependencies and plugins for snapshots ... There are still some remaining snapshot dependencies.: Do you want to resolve them now? (yes/no) no: : yes Dependency type to resolve,: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : 1 Resolve Project Dependency Snapshots.: 'de.foo:my-company-pom' set to release? (yes/no) yes: : yes What is the next development version? (4.34.5-SNAPSHOT) 4.34.5-SNAPSHOT: : 4.34.5-SNAPSHOT 'de.foo:my-library' set to release? (yes/no) yes: : ... As you see, it asks whether I want to set the reference to the parent (my-company-pom) to release, and I say: yes. Then it suggests to reference the latest company pom, which actually is 4.34.5-SNAPSHOT, which I confirmed. (in reality I just press [Enter], but I added the value here for better readability) I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. And it should not. It will rewrite the versions for the artifacts in its build plan, and the parent is not part of the build plan in this way. It would be horrifying, frankly, if running a release in a project would go update the parent project also. I do not want to update the parent project itself. I want to replace the reference to the SNAPSHOT parent by a reference to the RELEASE parent. Which is not horrible, but certainly what everybody wants when doing a release and having just released the parent one minute before. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. I don't think it should obviously do that. Perhaps you actually intended to run the release from the parent, if that is true, then you should do it from there. Not from within some submodule. This is not a submodule. I do not talk about a multi-module project at all. This is a simple standalone project, which references a company POM. The company POM was released a minute ago, and now I want to release this project. So I cannot run the release from the parent, obviously. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Run the release from the proper location. Or if the parent really does not have a submodule of the project you're errantly trying to run the release from right now, then you should release it (parent) first and then make the updates in the unlinked child projects to the latest release number. The m-versions-p is quite adept at automating this process. Please read above lines. As it is a standalone project, I DO run the release from the proper location. I actually HAVE released the parent bevore. All I want to get is that the release plugin doeas what it actually announced to do. It asked me what parent version I want, and it just discards the information. That's what I complain about. Regards -Markus - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: API to resolve an artifact in Maven3
My point is that most of the people here are users and not interested in plug-in development or knowledgeable about plug-in development. Custom plug-ins are not required for development of standalone or web applications in Java most of the time. Most appear to be developed to support specific specific non-java activities. I use one developed as a front-end for DITA document production to simplify the use of the DITA-OT. I use another to simplify the packaging of applications into an installer using IzPack. These are pretty simple Maven plug-ins and likely do not include very much coordination with or use of Maven internal methods. I am not sure if there is a better forum for you to get the kind of help that you need. The kind of information that you seem to need is probably known by the people who frequent the dev list but they are going to be pretty focused on Maven development and may not welcome third-party development questions. You might get some help by offering to add documentation to the code in the dev list in return for specific questions. Certainly you are doing a level of research into the examples, docs and code that could lead to useful updates to the docs or examples. Ron On 22/07/2013 4:30 PM, Richard Sand wrote: Hi Ron - I'm not sure what you're telling me. I thought that the capability to easily write custom plug-ins was part of the goal of Maven. If Maven doesn't want people outside of Maven writing plug-ins, then you're right the information I'm looking for isn't useful. But the javadocs are published - they just aren't filled in. Examples are published, but they're for Maven 2 and either don't work or are deprecated. Basic tasks that *seem* to be within the scope of what Maven wants to do are surprisingly difficult. That's frustrating. The questions I've asked on this this have been as specific and technical as I could make them. I'm not trying to waste anyone's time or not respect the work that others have volunteered. -Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 3:11 PM To: users@maven.apache.org Subject: Re: API to resolve an artifact in Maven3 You are not using Maven; you are developing a custom plug-in. That is a development activity so you should expect that it will be more difficult than what other users need to do and you will need information that is of no use to anyone else. It appears that you are trying to extend Maven in a way that is outside what Maven likes to do so you can expect that some information will be hard to find outside the code. Ron On 22/07/2013 2:54 PM, Richard Sand wrote: Hey Russell - DependencyGraphBuilder seems to be for resolving the dependencies that the project already has, i.e. in the projectdependencies element. What I'm trying to do now is 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 rs...@idfconnect.com 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
RE: API to resolve an artifact in Maven3
Ok good points, thanks Ron. I'll try what you suggested, and see if I can get some assistance on the developers list. I'm happy to volunteer to update some documentation around what I've learned writing this plugin. Best regards, Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 5:06 PM To: Richard Sand Cc: 'Maven Users List' Subject: Re: API to resolve an artifact in Maven3 My point is that most of the people here are users and not interested in plug-in development or knowledgeable about plug-in development. Custom plug-ins are not required for development of standalone or web applications in Java most of the time. Most appear to be developed to support specific specific non-java activities. I use one developed as a front-end for DITA document production to simplify the use of the DITA-OT. I use another to simplify the packaging of applications into an installer using IzPack. These are pretty simple Maven plug-ins and likely do not include very much coordination with or use of Maven internal methods. I am not sure if there is a better forum for you to get the kind of help that you need. The kind of information that you seem to need is probably known by the people who frequent the dev list but they are going to be pretty focused on Maven development and may not welcome third-party development questions. You might get some help by offering to add documentation to the code in the dev list in return for specific questions. Certainly you are doing a level of research into the examples, docs and code that could lead to useful updates to the docs or examples. Ron On 22/07/2013 4:30 PM, Richard Sand wrote: Hi Ron - I'm not sure what you're telling me. I thought that the capability to easily write custom plug-ins was part of the goal of Maven. If Maven doesn't want people outside of Maven writing plug-ins, then you're right the information I'm looking for isn't useful. But the javadocs are published - they just aren't filled in. Examples are published, but they're for Maven 2 and either don't work or are deprecated. Basic tasks that *seem* to be within the scope of what Maven wants to do are surprisingly difficult. That's frustrating. The questions I've asked on this this have been as specific and technical as I could make them. I'm not trying to waste anyone's time or not respect the work that others have volunteered. -Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 3:11 PM To: users@maven.apache.org Subject: Re: API to resolve an artifact in Maven3 You are not using Maven; you are developing a custom plug-in. That is a development activity so you should expect that it will be more difficult than what other users need to do and you will need information that is of no use to anyone else. It appears that you are trying to extend Maven in a way that is outside what Maven likes to do so you can expect that some information will be hard to find outside the code. Ron On 22/07/2013 2:54 PM, Richard Sand wrote: Hey Russell - DependencyGraphBuilder seems to be for resolving the dependencies that the project already has, i.e. in the projectdependencies element. What I'm trying to do now is 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 rs...@idfconnect.com 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
Re: Installing/deploying effective rather than original POM
The shade plugin is perhaps relevant here. On Mon, Jul 22, 2013 at 6:02 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: You could do something with maven-invoker-plugin and have something else generate the filtered pom file for you... you'd have to do some dancing games though. I would suspect, though, that you have some anti-patterns in your pom in the first place. Perhaps you should re-evaluate how and why you think you need these different profiles. On 22 July 2013 10:59, Baptiste MATHUS m...@batmat.net wrote: Hi, IIRC, I don't think this is possible. My 2 cents. Le 22 juil. 2013 11:20, Kristian Freed kristian.fr...@gmail.com a écrit : I have a POM file that contains a profile used specifically during development, and another (default) used for release builds. In the POM that gets installed and deployed when building a release build, I do not want to expose any traced of the development profile, as these should not be seen by users of the library being built. Is there a way I can get Maven to generate and install/deploy the effective POM resulting after profiles have been replied, i.e. one where properties have been replaced with their effective values, only the dependencies listed in active profiles show up etc? Cheers, Kristian
Re: API to resolve an artifact in Maven3
Eclipse aether is the api you need resolve your artifact for maven 3.1. I think there are plenty of examples for you to base on. If you have question, you can post it here at user group, there are plenty of dev folks here always trying to help out -D On Mon, Jul 22, 2013 at 2:55 PM, Richard Sand rs...@idfconnect.com wrote: Ok good points, thanks Ron. I'll try what you suggested, and see if I can get some assistance on the developers list. I'm happy to volunteer to update some documentation around what I've learned writing this plugin. Best regards, Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 5:06 PM To: Richard Sand Cc: 'Maven Users List' Subject: Re: API to resolve an artifact in Maven3 My point is that most of the people here are users and not interested in plug-in development or knowledgeable about plug-in development. Custom plug-ins are not required for development of standalone or web applications in Java most of the time. Most appear to be developed to support specific specific non-java activities. I use one developed as a front-end for DITA document production to simplify the use of the DITA-OT. I use another to simplify the packaging of applications into an installer using IzPack. These are pretty simple Maven plug-ins and likely do not include very much coordination with or use of Maven internal methods. I am not sure if there is a better forum for you to get the kind of help that you need. The kind of information that you seem to need is probably known by the people who frequent the dev list but they are going to be pretty focused on Maven development and may not welcome third-party development questions. You might get some help by offering to add documentation to the code in the dev list in return for specific questions. Certainly you are doing a level of research into the examples, docs and code that could lead to useful updates to the docs or examples. Ron On 22/07/2013 4:30 PM, Richard Sand wrote: Hi Ron - I'm not sure what you're telling me. I thought that the capability to easily write custom plug-ins was part of the goal of Maven. If Maven doesn't want people outside of Maven writing plug-ins, then you're right the information I'm looking for isn't useful. But the javadocs are published - they just aren't filled in. Examples are published, but they're for Maven 2 and either don't work or are deprecated. Basic tasks that *seem* to be within the scope of what Maven wants to do are surprisingly difficult. That's frustrating. The questions I've asked on this this have been as specific and technical as I could make them. I'm not trying to waste anyone's time or not respect the work that others have volunteered. -Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 3:11 PM To: users@maven.apache.org Subject: Re: API to resolve an artifact in Maven3 You are not using Maven; you are developing a custom plug-in. That is a development activity so you should expect that it will be more difficult than what other users need to do and you will need information that is of no use to anyone else. It appears that you are trying to extend Maven in a way that is outside what Maven likes to do so you can expect that some information will be hard to find outside the code. Ron On 22/07/2013 2:54 PM, Richard Sand wrote: Hey Russell - DependencyGraphBuilder seems to be for resolving the dependencies that the project already has, i.e. in the projectdependencies element. What I'm trying to do now is 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
Re: API to resolve an artifact in Maven3
On Mon, Jul 22, 2013 at 6:59 PM, Dan Tran dant...@gmail.com wrote: Eclipse aether is the api you need resolve your artifact for maven 3.1. Yeah, and that would mean bye bye maven 2 and maven 3.0 support ! I think there are plenty of examples for you to base on. If you have question, you can post it here at user group, there are plenty of dev folks here always trying to help out -D On Mon, Jul 22, 2013 at 2:55 PM, Richard Sand rs...@idfconnect.com wrote: Ok good points, thanks Ron. I'll try what you suggested, and see if I can get some assistance on the developers list. I'm happy to volunteer to update some documentation around what I've learned writing this plugin. Best regards, Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 5:06 PM To: Richard Sand Cc: 'Maven Users List' Subject: Re: API to resolve an artifact in Maven3 My point is that most of the people here are users and not interested in plug-in development or knowledgeable about plug-in development. Custom plug-ins are not required for development of standalone or web applications in Java most of the time. Most appear to be developed to support specific specific non-java activities. I use one developed as a front-end for DITA document production to simplify the use of the DITA-OT. I use another to simplify the packaging of applications into an installer using IzPack. These are pretty simple Maven plug-ins and likely do not include very much coordination with or use of Maven internal methods. I am not sure if there is a better forum for you to get the kind of help that you need. The kind of information that you seem to need is probably known by the people who frequent the dev list but they are going to be pretty focused on Maven development and may not welcome third-party development questions. You might get some help by offering to add documentation to the code in the dev list in return for specific questions. Certainly you are doing a level of research into the examples, docs and code that could lead to useful updates to the docs or examples. Ron On 22/07/2013 4:30 PM, Richard Sand wrote: Hi Ron - I'm not sure what you're telling me. I thought that the capability to easily write custom plug-ins was part of the goal of Maven. If Maven doesn't want people outside of Maven writing plug-ins, then you're right the information I'm looking for isn't useful. But the javadocs are published - they just aren't filled in. Examples are published, but they're for Maven 2 and either don't work or are deprecated. Basic tasks that *seem* to be within the scope of what Maven wants to do are surprisingly difficult. That's frustrating. The questions I've asked on this this have been as specific and technical as I could make them. I'm not trying to waste anyone's time or not respect the work that others have volunteered. -Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 3:11 PM To: users@maven.apache.org Subject: Re: API to resolve an artifact in Maven3 You are not using Maven; you are developing a custom plug-in. That is a development activity so you should expect that it will be more difficult than what other users need to do and you will need information that is of no use to anyone else. It appears that you are trying to extend Maven in a way that is outside what Maven likes to do so you can expect that some information will be hard to find outside the code. Ron On 22/07/2013 2:54 PM, Richard Sand wrote: Hey Russell - DependencyGraphBuilder seems to be for resolving the dependencies that the project already has, i.e. in the projectdependencies element. What I'm trying to do now is 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 -
Re: API to resolve an artifact in Maven3
Yes, I am also at a odd situation whether I need to have my custom plugin to support both maven 3 and 3.1 at the same time. Btw, maven 2 api should support most of the requirement, do you have specific needs for maven 3 artifact api? -D On Mon, Jul 22, 2013 at 4:57 PM, Anthony Dahanne anthony.daha...@gmail.comwrote: On Mon, Jul 22, 2013 at 6:59 PM, Dan Tran dant...@gmail.com wrote: Eclipse aether is the api you need resolve your artifact for maven 3.1. Yeah, and that would mean bye bye maven 2 and maven 3.0 support ! I think there are plenty of examples for you to base on. If you have question, you can post it here at user group, there are plenty of dev folks here always trying to help out -D On Mon, Jul 22, 2013 at 2:55 PM, Richard Sand rs...@idfconnect.com wrote: Ok good points, thanks Ron. I'll try what you suggested, and see if I can get some assistance on the developers list. I'm happy to volunteer to update some documentation around what I've learned writing this plugin. Best regards, Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 5:06 PM To: Richard Sand Cc: 'Maven Users List' Subject: Re: API to resolve an artifact in Maven3 My point is that most of the people here are users and not interested in plug-in development or knowledgeable about plug-in development. Custom plug-ins are not required for development of standalone or web applications in Java most of the time. Most appear to be developed to support specific specific non-java activities. I use one developed as a front-end for DITA document production to simplify the use of the DITA-OT. I use another to simplify the packaging of applications into an installer using IzPack. These are pretty simple Maven plug-ins and likely do not include very much coordination with or use of Maven internal methods. I am not sure if there is a better forum for you to get the kind of help that you need. The kind of information that you seem to need is probably known by the people who frequent the dev list but they are going to be pretty focused on Maven development and may not welcome third-party development questions. You might get some help by offering to add documentation to the code in the dev list in return for specific questions. Certainly you are doing a level of research into the examples, docs and code that could lead to useful updates to the docs or examples. Ron On 22/07/2013 4:30 PM, Richard Sand wrote: Hi Ron - I'm not sure what you're telling me. I thought that the capability to easily write custom plug-ins was part of the goal of Maven. If Maven doesn't want people outside of Maven writing plug-ins, then you're right the information I'm looking for isn't useful. But the javadocs are published - they just aren't filled in. Examples are published, but they're for Maven 2 and either don't work or are deprecated. Basic tasks that *seem* to be within the scope of what Maven wants to do are surprisingly difficult. That's frustrating. The questions I've asked on this this have been as specific and technical as I could make them. I'm not trying to waste anyone's time or not respect the work that others have volunteered. -Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 3:11 PM To: users@maven.apache.org Subject: Re: API to resolve an artifact in Maven3 You are not using Maven; you are developing a custom plug-in. That is a development activity so you should expect that it will be more difficult than what other users need to do and you will need information that is of no use to anyone else. It appears that you are trying to extend Maven in a way that is outside what Maven likes to do so you can expect that some information will be hard to find outside the code. Ron On 22/07/2013 2:54 PM, Richard Sand wrote: Hey Russell - DependencyGraphBuilder seems to be for resolving the dependencies that the project already has, i.e. in the projectdependencies element. What I'm trying to do now is 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:
RE: API to resolve an artifact in Maven3
Hi Dan - no I really don't specifically need the maven3 API. In fact, I only started asking when I got the compiler warnings that ArtifactFactory was deprecated, thus the conversation about what the proper technique was. It sounds like the 3.1 API should expose more of the aether API through an interface and factory pattern if it wants to support these plug-ins while still moving off of the maven 2 approach. What do you think? -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Monday, July 22, 2013 8:38 PM To: Maven Users List Subject: Re: API to resolve an artifact in Maven3 Yes, I am also at a odd situation whether I need to have my custom plugin to support both maven 3 and 3.1 at the same time. Btw, maven 2 api should support most of the requirement, do you have specific needs for maven 3 artifact api? -D On Mon, Jul 22, 2013 at 4:57 PM, Anthony Dahanne anthony.daha...@gmail.comwrote: On Mon, Jul 22, 2013 at 6:59 PM, Dan Tran dant...@gmail.com wrote: Eclipse aether is the api you need resolve your artifact for maven 3.1. Yeah, and that would mean bye bye maven 2 and maven 3.0 support ! I think there are plenty of examples for you to base on. If you have question, you can post it here at user group, there are plenty of dev folks here always trying to help out -D On Mon, Jul 22, 2013 at 2:55 PM, Richard Sand rs...@idfconnect.com wrote: Ok good points, thanks Ron. I'll try what you suggested, and see if I can get some assistance on the developers list. I'm happy to volunteer to update some documentation around what I've learned writing this plugin. Best regards, Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 5:06 PM To: Richard Sand Cc: 'Maven Users List' Subject: Re: API to resolve an artifact in Maven3 My point is that most of the people here are users and not interested in plug-in development or knowledgeable about plug-in development. Custom plug-ins are not required for development of standalone or web applications in Java most of the time. Most appear to be developed to support specific specific non-java activities. I use one developed as a front-end for DITA document production to simplify the use of the DITA-OT. I use another to simplify the packaging of applications into an installer using IzPack. These are pretty simple Maven plug-ins and likely do not include very much coordination with or use of Maven internal methods. I am not sure if there is a better forum for you to get the kind of help that you need. The kind of information that you seem to need is probably known by the people who frequent the dev list but they are going to be pretty focused on Maven development and may not welcome third-party development questions. You might get some help by offering to add documentation to the code in the dev list in return for specific questions. Certainly you are doing a level of research into the examples, docs and code that could lead to useful updates to the docs or examples. Ron On 22/07/2013 4:30 PM, Richard Sand wrote: Hi Ron - I'm not sure what you're telling me. I thought that the capability to easily write custom plug-ins was part of the goal of Maven. If Maven doesn't want people outside of Maven writing plug-ins, then you're right the information I'm looking for isn't useful. But the javadocs are published - they just aren't filled in. Examples are published, but they're for Maven 2 and either don't work or are deprecated. Basic tasks that *seem* to be within the scope of what Maven wants to do are surprisingly difficult. That's frustrating. The questions I've asked on this this have been as specific and technical as I could make them. I'm not trying to waste anyone's time or not respect the work that others have volunteered. -Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 3:11 PM To: users@maven.apache.org Subject: Re: API to resolve an artifact in Maven3 You are not using Maven; you are developing a custom plug-in. That is a development activity so you should expect that it will be more difficult than what other users need to do and you will need information that is of no use to anyone else. It appears that you are trying to extend Maven in a way that is outside what Maven likes to do so you can expect that some information will be hard to find outside the code. Ron On 22/07/2013 2:54 PM, Richard Sand wrote: Hey Russell - DependencyGraphBuilder seems to be for resolving the dependencies that the
Re: API to resolve an artifact in Maven3
I hope some maven dev folks seeing this discussion and provide guidance for you case. For my case, very likely i will move directly mvn 3.1.x and stop support for 3.0 completely ( i have no need for maven 2 support ) -D On Mon, Jul 22, 2013 at 6:11 PM, Richard Sand rs...@idfconnect.com wrote: Hi Dan - no I really don't specifically need the maven3 API. In fact, I only started asking when I got the compiler warnings that ArtifactFactory was deprecated, thus the conversation about what the proper technique was. It sounds like the 3.1 API should expose more of the aether API through an interface and factory pattern if it wants to support these plug-ins while still moving off of the maven 2 approach. What do you think? -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Monday, July 22, 2013 8:38 PM To: Maven Users List Subject: Re: API to resolve an artifact in Maven3 Yes, I am also at a odd situation whether I need to have my custom plugin to support both maven 3 and 3.1 at the same time. Btw, maven 2 api should support most of the requirement, do you have specific needs for maven 3 artifact api? -D On Mon, Jul 22, 2013 at 4:57 PM, Anthony Dahanne anthony.daha...@gmail.comwrote: On Mon, Jul 22, 2013 at 6:59 PM, Dan Tran dant...@gmail.com wrote: Eclipse aether is the api you need resolve your artifact for maven 3.1. Yeah, and that would mean bye bye maven 2 and maven 3.0 support ! I think there are plenty of examples for you to base on. If you have question, you can post it here at user group, there are plenty of dev folks here always trying to help out -D On Mon, Jul 22, 2013 at 2:55 PM, Richard Sand rs...@idfconnect.com wrote: Ok good points, thanks Ron. I'll try what you suggested, and see if I can get some assistance on the developers list. I'm happy to volunteer to update some documentation around what I've learned writing this plugin. Best regards, Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 5:06 PM To: Richard Sand Cc: 'Maven Users List' Subject: Re: API to resolve an artifact in Maven3 My point is that most of the people here are users and not interested in plug-in development or knowledgeable about plug-in development. Custom plug-ins are not required for development of standalone or web applications in Java most of the time. Most appear to be developed to support specific specific non-java activities. I use one developed as a front-end for DITA document production to simplify the use of the DITA-OT. I use another to simplify the packaging of applications into an installer using IzPack. These are pretty simple Maven plug-ins and likely do not include very much coordination with or use of Maven internal methods. I am not sure if there is a better forum for you to get the kind of help that you need. The kind of information that you seem to need is probably known by the people who frequent the dev list but they are going to be pretty focused on Maven development and may not welcome third-party development questions. You might get some help by offering to add documentation to the code in the dev list in return for specific questions. Certainly you are doing a level of research into the examples, docs and code that could lead to useful updates to the docs or examples. Ron On 22/07/2013 4:30 PM, Richard Sand wrote: Hi Ron - I'm not sure what you're telling me. I thought that the capability to easily write custom plug-ins was part of the goal of Maven. If Maven doesn't want people outside of Maven writing plug-ins, then you're right the information I'm looking for isn't useful. But the javadocs are published - they just aren't filled in. Examples are published, but they're for Maven 2 and either don't work or are deprecated. Basic tasks that *seem* to be within the scope of what Maven wants to do are surprisingly difficult. That's frustrating. The questions I've asked on this this have been as specific and technical as I could make them. I'm not trying to waste anyone's time or not respect the work that others have volunteered. -Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 3:11 PM To: users@maven.apache.org Subject: Re: API to resolve an artifact in Maven3 You are not using Maven; you are developing a custom plug-in. That is a development activity so you should expect that it will be more difficult than what other users need to do and you will need
Re: API to resolve an artifact in Maven3
Thats what we plan to do for the android maven plugin as well. I hope some maven dev folks seeing this discussion and provide guidance for you case. For my case, very likely i will move directly mvn 3.1.x and stop support for 3.0 completely ( i have no need for maven 2 support ) -D On Mon, Jul 22, 2013 at 6:11 PM, Richard Sand rs...@idfconnect.com wrote: Hi Dan - no I really don't specifically need the maven3 API. In fact, I only started asking when I got the compiler warnings that ArtifactFactory was deprecated, thus the conversation about what the proper technique was. It sounds like the 3.1 API should expose more of the aether API through an interface and factory pattern if it wants to support these plug-ins while still moving off of the maven 2 approach. What do you think? -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Monday, July 22, 2013 8:38 PM To: Maven Users List Subject: Re: API to resolve an artifact in Maven3 Yes, I am also at a odd situation whether I need to have my custom plugin to support both maven 3 and 3.1 at the same time. Btw, maven 2 api should support most of the requirement, do you have specific needs for maven 3 artifact api? -D On Mon, Jul 22, 2013 at 4:57 PM, Anthony Dahanne anthony.daha...@gmail.comwrote: On Mon, Jul 22, 2013 at 6:59 PM, Dan Tran dant...@gmail.com wrote: Eclipse aether is the api you need resolve your artifact for maven 3.1. Yeah, and that would mean bye bye maven 2 and maven 3.0 support ! I think there are plenty of examples for you to base on. If you have question, you can post it here at user group, there are plenty of dev folks here always trying to help out -D On Mon, Jul 22, 2013 at 2:55 PM, Richard Sand rs...@idfconnect.com wrote: Ok good points, thanks Ron. I'll try what you suggested, and see if I can get some assistance on the developers list. I'm happy to volunteer to update some documentation around what I've learned writing this plugin. Best regards, Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 5:06 PM To: Richard Sand Cc: 'Maven Users List' Subject: Re: API to resolve an artifact in Maven3 My point is that most of the people here are users and not interested in plug-in development or knowledgeable about plug-in development. Custom plug-ins are not required for development of standalone or web applications in Java most of the time. Most appear to be developed to support specific specific non-java activities. I use one developed as a front-end for DITA document production to simplify the use of the DITA-OT. I use another to simplify the packaging of applications into an installer using IzPack. These are pretty simple Maven plug-ins and likely do not include very much coordination with or use of Maven internal methods. I am not sure if there is a better forum for you to get the kind of help that you need. The kind of information that you seem to need is probably known by the people who frequent the dev list but they are going to be pretty focused on Maven development and may not welcome third-party development questions. You might get some help by offering to add documentation to the code in the dev list in return for specific questions. Certainly you are doing a level of research into the examples, docs and code that could lead to useful updates to the docs or examples. Ron On 22/07/2013 4:30 PM, Richard Sand wrote: Hi Ron - I'm not sure what you're telling me. I thought that the capability to easily write custom plug-ins was part of the goal of Maven. If Maven doesn't want people outside of Maven writing plug-ins, then you're right the information I'm looking for isn't useful. But the javadocs are published - they just aren't filled in. Examples are published, but they're for Maven 2 and either don't work or are deprecated. Basic tasks that *seem* to be within the scope of what Maven wants to do are surprisingly difficult. That's frustrating. The questions I've asked on this this have been as specific and technical as I could make them. I'm not trying to waste anyone's time or not respect the work that others have volunteered. -Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 3:11 PM To: users@maven.apache.org Subject: Re: API to resolve an artifact in Maven3 You are not using Maven; you are developing a custom plug-in. That is a development activity so you should expect that it will
RE: API to resolve an artifact in Maven3
Just closing the loop, the eclipse aether project has a maven example showing how to do exactly what I need to do... So many hours spent searching for this...!!! http://git.eclipse.org/c/aether/aether-demo.git/tree/aether-demo-maven-plugin/src/main/java/org/eclipse/aether/examples/maven/ResolveArtifactMojo.java -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Monday, July 22, 2013 6:59 PM To: Maven Users List Subject: Re: API to resolve an artifact in Maven3 Eclipse aether is the api you need resolve your artifact for maven 3.1. I think there are plenty of examples for you to base on. If you have question, you can post it here at user group, there are plenty of dev folks here always trying to help out -D On Mon, Jul 22, 2013 at 2:55 PM, Richard Sand rs...@idfconnect.com wrote: Ok good points, thanks Ron. I'll try what you suggested, and see if I can get some assistance on the developers list. I'm happy to volunteer to update some documentation around what I've learned writing this plugin. Best regards, Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 5:06 PM To: Richard Sand Cc: 'Maven Users List' Subject: Re: API to resolve an artifact in Maven3 My point is that most of the people here are users and not interested in plug-in development or knowledgeable about plug-in development. Custom plug-ins are not required for development of standalone or web applications in Java most of the time. Most appear to be developed to support specific specific non-java activities. I use one developed as a front-end for DITA document production to simplify the use of the DITA-OT. I use another to simplify the packaging of applications into an installer using IzPack. These are pretty simple Maven plug-ins and likely do not include very much coordination with or use of Maven internal methods. I am not sure if there is a better forum for you to get the kind of help that you need. The kind of information that you seem to need is probably known by the people who frequent the dev list but they are going to be pretty focused on Maven development and may not welcome third-party development questions. You might get some help by offering to add documentation to the code in the dev list in return for specific questions. Certainly you are doing a level of research into the examples, docs and code that could lead to useful updates to the docs or examples. Ron On 22/07/2013 4:30 PM, Richard Sand wrote: Hi Ron - I'm not sure what you're telling me. I thought that the capability to easily write custom plug-ins was part of the goal of Maven. If Maven doesn't want people outside of Maven writing plug-ins, then you're right the information I'm looking for isn't useful. But the javadocs are published - they just aren't filled in. Examples are published, but they're for Maven 2 and either don't work or are deprecated. Basic tasks that *seem* to be within the scope of what Maven wants to do are surprisingly difficult. That's frustrating. The questions I've asked on this this have been as specific and technical as I could make them. I'm not trying to waste anyone's time or not respect the work that others have volunteered. -Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 3:11 PM To: users@maven.apache.org Subject: Re: API to resolve an artifact in Maven3 You are not using Maven; you are developing a custom plug-in. That is a development activity so you should expect that it will be more difficult than what other users need to do and you will need information that is of no use to anyone else. It appears that you are trying to extend Maven in a way that is outside what Maven likes to do so you can expect that some information will be hard to find outside the code. Ron On 22/07/2013 2:54 PM, Richard Sand wrote: Hey Russell - DependencyGraphBuilder seems to be for resolving the dependencies that the project already has, i.e. in the projectdependencies element. What I'm trying to do now is 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
Re: API to resolve an artifact in Maven3
if all you need is from that example, then i think maven 2 artifact resolver should work just fine and it is compatible with maven 2 and 3 -Dan On Mon, Jul 22, 2013 at 7:44 PM, Richard Sand rs...@idfconnect.com wrote: Just closing the loop, the eclipse aether project has a maven example showing how to do exactly what I need to do... So many hours spent searching for this...!!! http://git.eclipse.org/c/aether/aether-demo.git/tree/aether-demo-maven-plugin/src/main/java/org/eclipse/aether/examples/maven/ResolveArtifactMojo.java -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Monday, July 22, 2013 6:59 PM To: Maven Users List Subject: Re: API to resolve an artifact in Maven3 Eclipse aether is the api you need resolve your artifact for maven 3.1. I think there are plenty of examples for you to base on. If you have question, you can post it here at user group, there are plenty of dev folks here always trying to help out -D On Mon, Jul 22, 2013 at 2:55 PM, Richard Sand rs...@idfconnect.com wrote: Ok good points, thanks Ron. I'll try what you suggested, and see if I can get some assistance on the developers list. I'm happy to volunteer to update some documentation around what I've learned writing this plugin. Best regards, Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 5:06 PM To: Richard Sand Cc: 'Maven Users List' Subject: Re: API to resolve an artifact in Maven3 My point is that most of the people here are users and not interested in plug-in development or knowledgeable about plug-in development. Custom plug-ins are not required for development of standalone or web applications in Java most of the time. Most appear to be developed to support specific specific non-java activities. I use one developed as a front-end for DITA document production to simplify the use of the DITA-OT. I use another to simplify the packaging of applications into an installer using IzPack. These are pretty simple Maven plug-ins and likely do not include very much coordination with or use of Maven internal methods. I am not sure if there is a better forum for you to get the kind of help that you need. The kind of information that you seem to need is probably known by the people who frequent the dev list but they are going to be pretty focused on Maven development and may not welcome third-party development questions. You might get some help by offering to add documentation to the code in the dev list in return for specific questions. Certainly you are doing a level of research into the examples, docs and code that could lead to useful updates to the docs or examples. Ron On 22/07/2013 4:30 PM, Richard Sand wrote: Hi Ron - I'm not sure what you're telling me. I thought that the capability to easily write custom plug-ins was part of the goal of Maven. If Maven doesn't want people outside of Maven writing plug-ins, then you're right the information I'm looking for isn't useful. But the javadocs are published - they just aren't filled in. Examples are published, but they're for Maven 2 and either don't work or are deprecated. Basic tasks that *seem* to be within the scope of what Maven wants to do are surprisingly difficult. That's frustrating. The questions I've asked on this this have been as specific and technical as I could make them. I'm not trying to waste anyone's time or not respect the work that others have volunteered. -Richard -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, July 22, 2013 3:11 PM To: users@maven.apache.org Subject: Re: API to resolve an artifact in Maven3 You are not using Maven; you are developing a custom plug-in. That is a development activity so you should expect that it will be more difficult than what other users need to do and you will need information that is of no use to anyone else. It appears that you are trying to extend Maven in a way that is outside what Maven likes to do so you can expect that some information will be hard to find outside the code. Ron On 22/07/2013 2:54 PM, Richard Sand wrote: Hey Russell - DependencyGraphBuilder seems to be for resolving the dependencies that the project already has, i.e. in the projectdependencies element. What I'm trying to do now is 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
Re: API to resolve an artifact in Maven3
On 23 July 2013 06:00, Richard Sand rs...@idfconnect.com wrote: Hi Ron - I'm not sure what you're telling me. I thought that the capability to easily write custom plug-ins was part of the goal of Maven. If Maven doesn't want people outside of Maven writing plug-ins, then you're right the information I'm looking for isn't useful. But the javadocs are published - they just aren't filled in. Examples are published, but they're for Maven 2 and either don't work or are deprecated. Basic tasks that *seem* to be within the scope of what Maven wants to do are surprisingly difficult. That's frustrating. The questions I've asked on this this have been as specific and technical as I could make them. I'm not trying to waste anyone's time or not respect the work that others have volunteered. Ron is essentially saying roughtly... Number of Maven Committers = O(X) Number of Maven Developers = O(10 * X) Number of Maven Users = O(100+ * X) So as you travel up the scope there are less and less people who understand what is going on, and since there is less of them there is also less time to actually do stuff. And they spend that time getting stuff working rather than explaining what is going on. For most people that are writing a plugin they do not need dependency resolution, in fact most Maven plugins themselves don't need it - they can rely on Maven to have done that already for them. The general documentation for writing a non-dependency plugin is ok enough, but this could also be improved. You are definitely right, and you are not alone in feeling frustrated, that the documentation on how to do dependency resolution could be improved - a lot. Any improvement you would be willing to submit back would be most grateful. Part of the problem is that once you have grokked this stuff you then forget what the pain points were so that writing documentation to illuminate the next person coming along is difficult; unless you remembered to make a map as you were going along. And there aren't enough people like that. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
