Re: Listing all attached artifacts for a specific GAV
Don't think this is possible simply because the metadata about attached artifacts doesn't exist. Please also note that all direct dependencies should be declared in the pom. So if you're going to deploy to a repo your plugin needs to update the pom-to-be-deployed and add this info. If you don't, any build declaring a dependency to your artifact will fail because the dependency info is missing. /Anders On Fri, Feb 1, 2013 at 12:10 AM, Henrik Eriksson wrote: > Hello. > > I'm writing a plugin and I'm wondering if there is any way of retrieving an > artifact's attached artifacts in a repository. I know the main artifact but > like to get the attached ones too. There are several workarounds for this, > but I would like to find out if there is a better way. I have been > searching the APIs and documentation but haven't yet found a nice way of > doing it. The reason of doing this is because I'd like to so you don't need > to declare them in a pom. > > Example: > com.acme.comp:artifact:ear:1.0 <-- main artifact > com.acme.comp:artifact:attachment1:xml <-- attachment which I'd like to get > programmatically without knowing the classifier name. > > TIA > Henrik >
Possible PluginManager interaction with Guice bug
Gentlemen
I found a consistent bug with PluginManager not able to locate @goal/** *
artifactId=modello-maven-plugin
* @author mailto:tryg...@inamo.no";>Trygve Laugstøl
* @version 1.5
* @threadSafe
*/
public abstract class AbstractModelloGeneratorMojo extends AbstractMojo notice
the lack of @goal .. because this is an abstract class which is expected to be
extend'ed by a concrete
the PluginManager backtraces classes to find who is extending AbstractMojo
and correctly identifies org.codehaus.modello.maven.AbstractModelloGeneratorMojo
org.apache.maven.plugin.MojoExecutionException: Error generating: No such
plugin: java
at
org.codehaus.modello.maven.AbstractModelloGeneratorMojo.doExecute(AbstractModelloGeneratorMojo.java:324)
abstract class AbstractModelloGeneratorMojo has no @goal .. pluginManager will
always throw MojoExecutionException
solution is to have the concrete class which contains annotated @goal extend
AbstractMojo
/*** Echos an object string to the output screen.
* @goal java
* @requiresProject false
@Mojo(name "java")
*/
public class ModelloJavaMojo extends AbstractMojo implements
org.codehaus.modello.core.ModelloCore
{ public void execute()
}
if I run mvn dependency:tree i can see the guice injector the
modello-maven-plugin is expecting
[DEBUG] org.codehaus.modello:modello-maven-plugin:maven-plugin:1.1
[DEBUG]com.google.inject:guice:jar:2.0:compile
maven-core implements guice as well
[DEBUG]org.apache.maven:maven-core:jar:3.0.2:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:2.9.1:compile
the options seem to be
1)disable guice and replace with plexus..if you find a way please let me know
2)refactor all concrete classes which already implement @goal to extend
AbstractMojo so PluginManager will
find the Mojo which contains the expected goal from plugin.xml
Thoughts?
Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
Re: [maven-release-plugin] Why does perform goal recompiles after running stage goal ?
Stephen, Really thanks very much for your quick response, really a lot helpfull !. And I love the 'poor man's staging' phrase :) thanks again tonio On Thu, Jan 31, 2013 at 5:29 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Thursday, 31 January 2013, Tonio Caputo wrote: > > > I'm using maven release for a release procedure, following this workflow > > > > 1 - release:branch create a release candidate > > using version X.X.X-000-SNAPSHOT > > (000 stands for build number) > > > > 2 - release:prepare release:stage to deploy the > > artifact to a staging repository > > > > 3 - Repeat step 2 until release candidate is ok > > > > 4 - run release:perform with the last staging data > > > > The problem I find is that in step 4 release:perform "recompiles" > > everything, while I was expecting just to deploy de already > > created binaries. > > > > So my question: > > > > - Is this an expected behaviour (perform recompilation) ? > > > Yes, the other builds are just from your workspace, and not from the tag. > > There are occasions where the workspace files can differ from the tag, so > release:perform checks out the tag and builds from that > > > > > > - Anyway you can override this (perfrom recompilation) ? > > > You can tell release:prepare to skip compilation, eg with preparationGoals > of initialize or validate > > But that is skipping a different compilation than the one you want > > > > > > - I guess is a common request to expect release deploy to contain > > the same binaries as accepted release candidate, may be I'm wrong ? > > > Well, it depends. Releases are supposed to be consistent, so it *should not > matter* that the binary is different because of time stamps, etc... But it > is expensive to re-run your QA process just because the time stamp on > META-INF/MANIFEST.MF changed and hence the sha1 signature... > > > > > > - Any other way to somehow do this you think, without relying on > > maven repository features ? > > > 1. The wagon-maven-plugin @ mojo has goals for copying from one maven repo > to another (aka poor man's staging) > > 2. If you are using the (evil) maven project type in Jenkins (freestyle + > maven build step is good though) it allows re-deploying artifacts, so you > might be able to build a staging workflow on top of that. > > 3. I have wanted to feed the mrm-maven-plugin with staging support, in > theory it is easy to add... In practice it is not very itchy for me > compared to my other itches > > > > Thanks in advance > > tonio > > >
Re: [maven-release-plugin] Why does perform goal recompiles after running stage goal ?
On Thursday, 31 January 2013, Tonio Caputo wrote: > I'm using maven release for a release procedure, following this workflow > > 1 - release:branch create a release candidate > using version X.X.X-000-SNAPSHOT > (000 stands for build number) > > 2 - release:prepare release:stage to deploy the > artifact to a staging repository > > 3 - Repeat step 2 until release candidate is ok > > 4 - run release:perform with the last staging data > > The problem I find is that in step 4 release:perform "recompiles" > everything, while I was expecting just to deploy de already > created binaries. > > So my question: > > - Is this an expected behaviour (perform recompilation) ? Yes, the other builds are just from your workspace, and not from the tag. There are occasions where the workspace files can differ from the tag, so release:perform checks out the tag and builds from that > > - Anyway you can override this (perfrom recompilation) ? You can tell release:prepare to skip compilation, eg with preparationGoals of initialize or validate But that is skipping a different compilation than the one you want > > - I guess is a common request to expect release deploy to contain > the same binaries as accepted release candidate, may be I'm wrong ? Well, it depends. Releases are supposed to be consistent, so it *should not matter* that the binary is different because of time stamps, etc... But it is expensive to re-run your QA process just because the time stamp on META-INF/MANIFEST.MF changed and hence the sha1 signature... > > - Any other way to somehow do this you think, without relying on > maven repository features ? 1. The wagon-maven-plugin @ mojo has goals for copying from one maven repo to another (aka poor man's staging) 2. If you are using the (evil) maven project type in Jenkins (freestyle + maven build step is good though) it allows re-deploying artifacts, so you might be able to build a staging workflow on top of that. 3. I have wanted to feed the mrm-maven-plugin with staging support, in theory it is easy to add... In practice it is not very itchy for me compared to my other itches > Thanks in advance > tonio >
[maven-release-plugin] Why does perform goal recompiles after running stage goal ?
I'm using maven release for a release procedure, following this workflow 1 - release:branch create a release candidate using version X.X.X-000-SNAPSHOT (000 stands for build number) 2 - release:prepare release:stage to deploy the artifact to a staging repository 3 - Repeat step 2 until release candidate is ok 4 - run release:perform with the last staging data The problem I find is that in step 4 release:perform "recompiles" everything, while I was expecting just to deploy de already created binaries. So my question: - Is this an expected behaviour (perform recompilation) ? - Anyway you can override this (perfrom recompilation) ? - I guess is a common request to expect release deploy to contain the same binaries as accepted release candidate, may be I'm wrong ? - Any other way to somehow do this you think, without relying on maven repository features ? Thanks in advance tonio
RE: Plugin to determine release order for multiple projects
Non. There is no circular dependency in this situation. Project A has a dependency on Project B, which has a dependency on Project C. I am sorry if that was unclear in my message. Thanks, Rob -Original Message- From: bmat...@gmail.com [mailto:bmat...@gmail.com] On Behalf Of Baptiste MATHUS Sent: Wednesday, January 30, 2013 10:18 AM To: Maven Users List Subject: RE: Plugin to determine release order for multiple projects Hi, I understand you have two different multimodules projects. But those projects have actually dependencies with each other. In short, "circular". If so, it won't work with Maven. The "Maven way" here is: if those projects actually have modules that are so intricate, then you somehow have the same lifecycle: those two projects should be in the same one. Cheers Le 30 janv. 2013 17:06, "Pimentel, Robert" a écrit : > When I run mvn clean, and look at the reactor order, it lists the > build order for the modules in that particular project. That list does > not include other projects for which the target project is dependent upon. > > For example: > > Project A > ---> module A > ---> module B > ---> module C > > Project B > ---> module A > ---> module B > > > Module A of project A has a dependency on module B of Project B. When > I ran mvn clean at the top level or project A, it lists the build order (e.g. > module B, C, A of project A), but there is no mention of module B in > Project B. Also, module B of project B may have a dependency on module > A of a different (project C). The goal is to have an ordered list of > the projects to be released. In this example Project C, then Project > B, and then Project A. The reactor does not seem to provide that > functionality. > Maybe I am missing something. > > Thanks, > Rob > > -Original Message- > From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com] > Sent: Friday, May 25, 2012 3:51 PM > To: Maven Users List > Subject: RE: Plugin to determine release order for multiple projects > > Can't you just look at the reactor order? That will tell you which > projects you would have to release first. > > > -Original Message- > > From: Pimentel, Robert [mailto:robert.pimen...@tgslc.org] > > Sent: Friday, May 25, 2012 4:47 PM > > To: 'users@maven.apache.org' > > Subject: Plugin to determine release order for multiple projects > > > > Hello, > > > > We currently have about 40 different multi-module projects. To date, > > we have determined an appropriate release order for the projects by > > manually parsing the POM files and making note of the dependencies. > > We keep our list in a spreadsheet, and it is re-evaluated with every > > release because (a) new projects are added (b) the list of projects > > being released changes from one release to the next (c) the project > > interdependencies change. As you can imagine this is both tedious > > and time-consuming. Do you know of a plugin, or any (preferably > > free) third-party tools that can parse a collection of project POMs > > and produce an appropriate release order? Additionally, it would be > > great if the product could check for circular dependencies. I am at > > the point where I am going to create something myself, but would > > prefer not to if something like this already exists. > > Windows Server 2003 SP2 > > Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500) Java version: > > 1.6.0_24 > > > > Thanks, > > Rob > > - > 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 > >
