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
RE: generating plugin project index page via site plugin
That is not generated, but manually added text. /Anders (mobile) Den 18 jul 2013 07:30 skrev Richard Sand rs...@idfconnect.com: Hi Anders- thanks, I definitely needed that plugin report to get the goal usage reports I needed. But I still don't know how to get the goal summary onto the index page the way the maven plugins are documented. Compare my page http://mavenproguard.sourceforge.net/index.html with another plugin page such as maven compiler plugin: http://maven.apache.org/plugins/maven-compiler-plugin/ Note they have the goals summary right on the index page. How are they generating that? Do they have a special index.apt or such to generate that content? -Richard -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Wednesday, July 17, 2013 1:58 PM To: Maven Users List Subject: Re: generating plugin project index page via site plugin This is done by the maven-plugin-plugin [1]. How to get the very specific report you're asking about, read [2]. [1] http://maven.apache.org/plugin-tools/maven-plugin-plugin/ [2] http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/generate-r eport.html /Anders On Wed, Jul 17, 2013 at 5:50 AM, Richard Sand rs...@idfconnect.com wrote: Hi all - on the Apache Maven website, the index pages for the various plugin projects have the Goals Overview section, and each goal has a link to a goal-mojo.html file. How do I get the site plugin to generate this for my plugin project? The index page for the obfuscator plugin is missing this and I can't see any options on the maven-project-info-reports-plugin:2.7:index goal to control this. -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
Re: executing release:prepare with release-sign-artifacts
I have the following profile in my ~/.m2/settings.xml profile idsonatype-oss-release/id properties gpg.passphrase!-- I am not going top copy paste this bit--/gpg.passphrase gpg.keynamesteph...@apache.org/gpg.keyname /properties /profile That means that any time I make a release which has the sonatype-oss-parent as its parent, then it gets signed with my personal key. For other projects which need a different key, I get them to use a different profile for releasing and I then have that different key get selected. I do worry about the passphrase being in clear text... but as my GPG keys for signing are on a USB stick and not permanently connected to the machine it seems an acceptable trade-off from my PoV On 17 July 2013 23:02, Richard Sand rs...@idfconnect.com wrote: Hi all, Trying to move this obfuscation plugin along. I have the snapshot in the OSS Sonatype snapshot repository now: https://oss.sonatype.org/content/repositories/snapshots/com/idfconnect/devto ols/idfc-proguard-maven-plugin/0.8.0-SNAPSHOT/ Now I'm trying to release 0.8.0, however when I run maven release:prepare, I'm getting an exception when it gets to the sign artifacts goal. The problem seems to be caused by the fact that release:prepare forks a separate maven invocation, but isn't passing along the command-line java properties into that forked invocation. When I call maven deploy, I am passing in the password to my pgp. Maven deploy works perfect, and puts the result SNAPSHOT artifact onto OSS: mvn -DperformRelease=true -Dgpg.passphrase=* -B -X -e -U -Dmaven.test.skip=true -s C:\Documents and Settings\rsand\.m2\settings.xml clean deploy But when I call maven release:prepare with the same arguments, the forked maven execution fails because it cannot prompt for the gpg passphrase: mvn -DperformRelease=true -Dgpg.passphrase=* -B -X -e -U -Dmaven.test.skip=true -s C:\Documents and Settings\rsand\.m2\settings.xml release:prepare You can see the regular output below. The debug mode output is much larger and shows all of the invocation properties. [INFO] --- maven-release-plugin:2.0:prepare (default-cli) @ idfc-proguard-maven-plugin --- [INFO] Resuming release from phase 'run-preparation-goals' [INFO] Executing goals 'clean verify'... [INFO] [INFO] Scanning for projects... [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] Building IDFC ProGuard Maven Plugin 0.8.0-SNAPSHOT [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ idfc-proguard-maven-plugin --- [INFO] [INFO] Deleting D:\dev\workspace\IDFC ProGuard Maven Plugin\target [INFO] [INFO] [INFO] [INFO] --- maven-plugin-plugin:3.2:helpmojo (help-goal) @ idfc-proguard-maven-plugin --- [INFO] [INFO] Using 'UTF-8' encoding to read mojo metadata. [INFO] [INFO] Applying mojo extractor for language: java-annotations [INFO] [INFO] Mojo extractor for language: java-annotations found 0 mojo descriptors. [INFO] [INFO] Applying mojo extractor for language: java [INFO] [INFO] Mojo extractor for language: java found 0 mojo descriptors. [INFO] [INFO] Applying mojo extractor for language: bsh [INFO] [INFO] Mojo extractor for language: bsh found 0 mojo descriptors. [INFO] [INFO] [INFO] [INFO] --- maven-plugin-plugin:3.2:descriptor (default-descriptor) @ idfc-proguard-maven-plugin --- [INFO] [INFO] Using 'UTF-8' encoding to read mojo metadata. [INFO] [INFO] Applying mojo extractor for language: java-annotations [INFO] [INFO] Mojo extractor for language: java-annotations found 0 mojo descriptors. [INFO] [INFO] Applying mojo extractor for language: java [INFO] [INFO] Mojo extractor for language: java found 0 mojo descriptors. [INFO] [INFO] Applying mojo extractor for language: bsh [INFO] [INFO] Mojo extractor for language: bsh found 0 mojo descriptors. [INFO] [INFO] [INFO] [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ idfc-proguard-maven-plugin --- [INFO] [debug] execute contextualize [INFO] [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] [INFO] skip non existing resourceDirectory D:\dev\workspace\IDFC ProGuard Maven Plugin\src\main\resources [INFO] [INFO] [INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ idfc-proguard-maven-plugin --- [INFO] [INFO] Compiling 2 source files to D:\dev\workspace\IDFC ProGuard Maven Plugin\target\classes [INFO] [INFO] [INFO] [INFO] --- maven-plugin-plugin:3.2:descriptor (mojo-descriptor) @ idfc-proguard-maven-plugin --- [INFO] [INFO] Using 'UTF-8' encoding to read mojo metadata. [INFO] [INFO] Applying mojo extractor for language: java-annotations [INFO] [INFO] Mojo extractor for language: java-annotations found 2 mojo descriptors. [INFO] [INFO] Applying mojo extractor for
Re: Maven deploy goal using ROLE account on Linux/Unix
We have used it for about 5 years now and it has been no trouble from a system administration point of view. Your system administrator doing the install should be warned to read and follow the instructions carefully. Ron On 17/07/2013 9:52 PM, rahulvd84 wrote: Thanks Niranjan, Barrie and Ron. The use of sudo account is needed pretty much due to policies and security restrictions. Though today finally my manager showed some willingness to try out some repository manager and we will begin with the open source edition of nexus. Ron, good to hear that you have used and are happy with that version, it is should serve our purpose. On Wed, Jul 17, 2013 at 9:23 PM, Ron Wheeler [via Maven] ml-node+s40175n5763716...@n5.nabble.com wrote: There has been many discussions about trying to use Maven without a proper Maven repo. Barrie is one of the experienced Maven users and his advice is worth following. We use the community version of Nexus and are very happy but other repos exist and are well regarded. There are a lot of advantages besides the problem you are currently trying to solve. Ron On 17/07/2013 9:15 PM, Barrie Treloar wrote: The other short answer is: Don't share your local m2 cache (~/.m2/repository) between developers. That is a bad idea because one developers install of snapshots will pollute the cache for everyone and give you something you dont expect. Local disk is cheap - dont worry about the waste. The correct way is to install a Maven Repository Manager (see http://maven.apache.org/repository-management.html) which will isolate your from external repository failures and also reduce your internet usage. - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=5763716i=0 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=5763716i=1 -- Ron Wheeler President Artifact Software Inc email: [hidden email]http://user/SendEmail.jtp?type=nodenode=5763716i=2 skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=5763716i=3 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=5763716i=4 -- If you reply to this email, your message will be added to the discussion below: http://maven.40175.n5.nabble.com/Maven-deploy-goal-using-ROLE-account-on-Linux-Unix-tp5762445p5763716.html To unsubscribe from Maven deploy goal using ROLE account on Linux/Unix, click herehttp://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5762445code=cmFodWx2ZDg0QGdtYWlsLmNvbXw1NzYyNDQ1fC0yMTI2NTI3ODM= . NAMLhttp://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: generating plugin project index page via site plugin
And I thought I was going crazy. Or senile... thanks Anders! -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Thursday, July 18, 2013 5:15 AM To: Maven Users List Subject: RE: generating plugin project index page via site plugin That is not generated, but manually added text. /Anders (mobile) Den 18 jul 2013 07:30 skrev Richard Sand rs...@idfconnect.com: Hi Anders- thanks, I definitely needed that plugin report to get the goal usage reports I needed. But I still don't know how to get the goal summary onto the index page the way the maven plugins are documented. Compare my page http://mavenproguard.sourceforge.net/index.html with another plugin page such as maven compiler plugin: http://maven.apache.org/plugins/maven-compiler-plugin/ Note they have the goals summary right on the index page. How are they generating that? Do they have a special index.apt or such to generate that content? -Richard -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Wednesday, July 17, 2013 1:58 PM To: Maven Users List Subject: Re: generating plugin project index page via site plugin This is done by the maven-plugin-plugin [1]. How to get the very specific report you're asking about, read [2]. [1] http://maven.apache.org/plugin-tools/maven-plugin-plugin/ [2] http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/gene rate-r eport.html /Anders On Wed, Jul 17, 2013 at 5:50 AM, Richard Sand rs...@idfconnect.com wrote: Hi all - on the Apache Maven website, the index pages for the various plugin projects have the Goals Overview section, and each goal has a link to a goal-mojo.html file. How do I get the site plugin to generate this for my plugin project? The index page for the obfuscator plugin is missing this and I can't see any options on the maven-project-info-reports-plugin:2.7:index goal to control this. -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
RE: executing release:prepare with release-sign-artifacts
Thanks Stephen, I'll give that a try. It'll at least get me unstuck. Would you agree that when plug-ins spawn a separate maven execution they should pass along any command-line java properties? Seems like this would be a good static utility method to include in the plugin api. -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Thursday, July 18, 2013 7:10 AM To: Maven Users List Subject: Re: executing release:prepare with release-sign-artifacts I have the following profile in my ~/.m2/settings.xml profile idsonatype-oss-release/id properties gpg.passphrase!-- I am not going top copy paste this bit--/gpg.passphrase gpg.keynamesteph...@apache.org/gpg.keyname /properties /profile That means that any time I make a release which has the sonatype-oss-parent as its parent, then it gets signed with my personal key. For other projects which need a different key, I get them to use a different profile for releasing and I then have that different key get selected. I do worry about the passphrase being in clear text... but as my GPG keys for signing are on a USB stick and not permanently connected to the machine it seems an acceptable trade-off from my PoV On 17 July 2013 23:02, Richard Sand rs...@idfconnect.com wrote: Hi all, Trying to move this obfuscation plugin along. I have the snapshot in the OSS Sonatype snapshot repository now: https://oss.sonatype.org/content/repositories/snapshots/com/idfconnect /devto ols/idfc-proguard-maven-plugin/0.8.0-SNAPSHOT/ Now I'm trying to release 0.8.0, however when I run maven release:prepare, I'm getting an exception when it gets to the sign artifacts goal. The problem seems to be caused by the fact that release:prepare forks a separate maven invocation, but isn't passing along the command-line java properties into that forked invocation. When I call maven deploy, I am passing in the password to my pgp. Maven deploy works perfect, and puts the result SNAPSHOT artifact onto OSS: mvn -DperformRelease=true -Dgpg.passphrase=* -B -X -e -U -Dmaven.test.skip=true -s C:\Documents and Settings\rsand\.m2\settings.xml clean deploy But when I call maven release:prepare with the same arguments, the forked maven execution fails because it cannot prompt for the gpg passphrase: mvn -DperformRelease=true -Dgpg.passphrase=* -B -X -e -U -Dmaven.test.skip=true -s C:\Documents and Settings\rsand\.m2\settings.xml release:prepare You can see the regular output below. The debug mode output is much larger and shows all of the invocation properties. [INFO] --- maven-release-plugin:2.0:prepare (default-cli) @ idfc-proguard-maven-plugin --- [INFO] Resuming release from phase 'run-preparation-goals' [INFO] Executing goals 'clean verify'... [INFO] [INFO] Scanning for projects... [INFO] [INFO] [INFO] [INFO] -- -- [INFO] [INFO] Building IDFC ProGuard Maven Plugin 0.8.0-SNAPSHOT [INFO] [INFO] -- -- [INFO] [INFO] [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ idfc-proguard-maven-plugin --- [INFO] [INFO] Deleting D:\dev\workspace\IDFC ProGuard Maven Plugin\target [INFO] [INFO] [INFO] [INFO] --- maven-plugin-plugin:3.2:helpmojo (help-goal) @ idfc-proguard-maven-plugin --- [INFO] [INFO] Using 'UTF-8' encoding to read mojo metadata. [INFO] [INFO] Applying mojo extractor for language: java-annotations [INFO] [INFO] Mojo extractor for language: java-annotations found 0 mojo descriptors. [INFO] [INFO] Applying mojo extractor for language: java [INFO] [INFO] Mojo extractor for language: java found 0 mojo descriptors. [INFO] [INFO] Applying mojo extractor for language: bsh [INFO] [INFO] Mojo extractor for language: bsh found 0 mojo descriptors. [INFO] [INFO] [INFO] [INFO] --- maven-plugin-plugin:3.2:descriptor (default-descriptor) @ idfc-proguard-maven-plugin --- [INFO] [INFO] Using 'UTF-8' encoding to read mojo metadata. [INFO] [INFO] Applying mojo extractor for language: java-annotations [INFO] [INFO] Mojo extractor for language: java-annotations found 0 mojo descriptors. [INFO] [INFO] Applying mojo extractor for language: java [INFO] [INFO] Mojo extractor for language: java found 0 mojo descriptors. [INFO] [INFO] Applying mojo extractor for language: bsh [INFO] [INFO] Mojo extractor for language: bsh found 0 mojo descriptors. [INFO] [INFO] [INFO] [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ idfc-proguard-maven-plugin --- [INFO] [debug] execute contextualize [INFO] [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] [INFO] skip non existing resourceDirectory D:\dev\workspace\IDFC ProGuard Maven Plugin\src\main\resources [INFO] [INFO] [INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile
Re: executing release:prepare with release-sign-artifacts
Well actually that can be a bit of an anti-pattern... it might make sense for the release plugin to allow defining properties that get passed through. But normally you want to have the release:perform fork be clean and pure. On 18 July 2013 13:36, Richard Sand rs...@idfconnect.com wrote: Thanks Stephen, I'll give that a try. It'll at least get me unstuck. Would you agree that when plug-ins spawn a separate maven execution they should pass along any command-line java properties? Seems like this would be a good static utility method to include in the plugin api. -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Thursday, July 18, 2013 7:10 AM To: Maven Users List Subject: Re: executing release:prepare with release-sign-artifacts I have the following profile in my ~/.m2/settings.xml profile idsonatype-oss-release/id properties gpg.passphrase!-- I am not going top copy paste this bit--/gpg.passphrase gpg.keynamesteph...@apache.org/gpg.keyname /properties /profile That means that any time I make a release which has the sonatype-oss-parent as its parent, then it gets signed with my personal key. For other projects which need a different key, I get them to use a different profile for releasing and I then have that different key get selected. I do worry about the passphrase being in clear text... but as my GPG keys for signing are on a USB stick and not permanently connected to the machine it seems an acceptable trade-off from my PoV On 17 July 2013 23:02, Richard Sand rs...@idfconnect.com wrote: Hi all, Trying to move this obfuscation plugin along. I have the snapshot in the OSS Sonatype snapshot repository now: https://oss.sonatype.org/content/repositories/snapshots/com/idfconnect /devto ols/idfc-proguard-maven-plugin/0.8.0-SNAPSHOT/ Now I'm trying to release 0.8.0, however when I run maven release:prepare, I'm getting an exception when it gets to the sign artifacts goal. The problem seems to be caused by the fact that release:prepare forks a separate maven invocation, but isn't passing along the command-line java properties into that forked invocation. When I call maven deploy, I am passing in the password to my pgp. Maven deploy works perfect, and puts the result SNAPSHOT artifact onto OSS: mvn -DperformRelease=true -Dgpg.passphrase=* -B -X -e -U -Dmaven.test.skip=true -s C:\Documents and Settings\rsand\.m2\settings.xml clean deploy But when I call maven release:prepare with the same arguments, the forked maven execution fails because it cannot prompt for the gpg passphrase: mvn -DperformRelease=true -Dgpg.passphrase=* -B -X -e -U -Dmaven.test.skip=true -s C:\Documents and Settings\rsand\.m2\settings.xml release:prepare You can see the regular output below. The debug mode output is much larger and shows all of the invocation properties. [INFO] --- maven-release-plugin:2.0:prepare (default-cli) @ idfc-proguard-maven-plugin --- [INFO] Resuming release from phase 'run-preparation-goals' [INFO] Executing goals 'clean verify'... [INFO] [INFO] Scanning for projects... [INFO] [INFO] [INFO] [INFO] -- -- [INFO] [INFO] Building IDFC ProGuard Maven Plugin 0.8.0-SNAPSHOT [INFO] [INFO] -- -- [INFO] [INFO] [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ idfc-proguard-maven-plugin --- [INFO] [INFO] Deleting D:\dev\workspace\IDFC ProGuard Maven Plugin\target [INFO] [INFO] [INFO] [INFO] --- maven-plugin-plugin:3.2:helpmojo (help-goal) @ idfc-proguard-maven-plugin --- [INFO] [INFO] Using 'UTF-8' encoding to read mojo metadata. [INFO] [INFO] Applying mojo extractor for language: java-annotations [INFO] [INFO] Mojo extractor for language: java-annotations found 0 mojo descriptors. [INFO] [INFO] Applying mojo extractor for language: java [INFO] [INFO] Mojo extractor for language: java found 0 mojo descriptors. [INFO] [INFO] Applying mojo extractor for language: bsh [INFO] [INFO] Mojo extractor for language: bsh found 0 mojo descriptors. [INFO] [INFO] [INFO] [INFO] --- maven-plugin-plugin:3.2:descriptor (default-descriptor) @ idfc-proguard-maven-plugin --- [INFO] [INFO] Using 'UTF-8' encoding to read mojo metadata. [INFO] [INFO] Applying mojo extractor for language: java-annotations [INFO] [INFO] Mojo extractor for language: java-annotations found 0 mojo descriptors. [INFO] [INFO] Applying mojo extractor for language: java [INFO] [INFO] Mojo extractor for language: java found 0 mojo descriptors. [INFO] [INFO] Applying mojo extractor for language: bsh [INFO] [INFO] Mojo extractor for language: bsh found 0 mojo descriptors. [INFO] [INFO] [INFO] [INFO] ---
RE: executing release:prepare with release-sign-artifacts
Thanks Stephen, that got me past the gpg signing problem. I still think the cmd-line properties should be propagated though :-) Now I'm getting a 400-Bad Request error when maven tries to download something from the Sonatype parent when I do the release. Has anyone seen this error? Since all of the reports/site plugin ran successfully on the snapshot, does it matter if I just disable them for the release goal? [INFO] maven-plugin-plugin:3.2:report (report:report) @ idfc-proguard-maven-plugin [INFO] Parent project loaded from repository: org.sonatype.oss:oss-parent:pom:7 Downloading: https://oss.sonatype.org/service/local/staging/deploy/maven2/org/sonatype/os s/oss-parent/7/oss-parent-7-site_en.xml [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 31.175s [INFO] Finished at: Thu Jul 18 10:16:19 EDT 2013 [INFO] Final Memory: 31M/75M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project idfc-proguard-maven-plugin: SiteToolException: The site descriptor cannot be resolved from the repository: ArtifactResolutionException: Unable to locate site descriptor: Could not transfer artifact org.sonatype.oss:oss-parent:xml:site_en:7 from/to oss.sonatype.org (https://oss.sonatype.org/service/local/staging/deploy/maven2/): Failed to transfer file: https://oss.sonatype.org/service/local/staging/deploy/maven2/org/sonatype/os s/oss-parent/7/oss-parent-7-site_en.xml. Return code is: 400 , ReasonPhrase:Bad Request. [ERROR] org.sonatype.oss:oss-parent:xml:7 [ERROR] [ERROR] from the specified remote repositories: [ERROR] oss.sonatype.org (https://oss.sonatype.org/service/local/staging/deploy/maven2/, releases=true, snapshots=true), [ERROR] sonatype-nexus-snapshots (https://oss.sonatype.org/content/repositories/snapshots, releases=false, snapshots=true), [ERROR] central (http://repo.maven.apache.org/maven2, releases=true, snapshots=false) [ERROR] - [Help 1] -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Thursday, July 18, 2013 7:10 AM To: Maven Users List Subject: Re: executing release:prepare with release-sign-artifacts I have the following profile in my ~/.m2/settings.xml profile idsonatype-oss-release/id properties gpg.passphrase!-- I am not going top copy paste this bit--/gpg.passphrase gpg.keynamesteph...@apache.org/gpg.keyname /properties /profile That means that any time I make a release which has the sonatype-oss-parent as its parent, then it gets signed with my personal key. For other projects which need a different key, I get them to use a different profile for releasing and I then have that different key get selected. I do worry about the passphrase being in clear text... but as my GPG keys for signing are on a USB stick and not permanently connected to the machine it seems an acceptable trade-off from my PoV On 17 July 2013 23:02, Richard Sand rs...@idfconnect.com wrote: Hi all, Trying to move this obfuscation plugin along. I have the snapshot in the OSS Sonatype snapshot repository now: https://oss.sonatype.org/content/repositories/snapshots/com/idfconnect /devto ols/idfc-proguard-maven-plugin/0.8.0-SNAPSHOT/ Now I'm trying to release 0.8.0, however when I run maven release:prepare, I'm getting an exception when it gets to the sign artifacts goal. The problem seems to be caused by the fact that release:prepare forks a separate maven invocation, but isn't passing along the command-line java properties into that forked invocation. When I call maven deploy, I am passing in the password to my pgp. Maven deploy works perfect, and puts the result SNAPSHOT artifact onto OSS: mvn -DperformRelease=true -Dgpg.passphrase=* -B -X -e -U -Dmaven.test.skip=true -s C:\Documents and Settings\rsand\.m2\settings.xml clean deploy But when I call maven release:prepare with the same arguments, the forked maven execution fails because it cannot prompt for the gpg passphrase: mvn -DperformRelease=true -Dgpg.passphrase=* -B -X -e -U -Dmaven.test.skip=true -s C:\Documents and Settings\rsand\.m2\settings.xml release:prepare You can see the regular output below. The debug mode output is much larger and shows all of the invocation properties. [INFO] --- maven-release-plugin:2.0:prepare (default-cli) @ idfc-proguard-maven-plugin --- [INFO] Resuming release from phase 'run-preparation-goals' [INFO] Executing goals 'clean verify'... [INFO] [INFO] Scanning for projects... [INFO] [INFO] [INFO] [INFO] -- -- [INFO] [INFO] Building IDFC ProGuard Maven
Maven Deploy Plugin and Nexus Meta Data update of LATEST failing
Hi all, I've upgraded to the latest maven deploy plugin and hte latest nexus OSS version. I hoped that between the two that the updating of the LATEST meta-data would work when doing a relase (See http://stackoverflow.com/questions/4878808/maven-metadata-xml-is-not-updated-when-deploying-to-nexusas a reference). This doesn't appear to be the case, does anyone else know of another mail thread / JIRA issue tracking this? Cheers, Martijn
chaining release:prepare release:perform for multi-module [I]
Classification: For internal use only Hi all, I appreciate the normal approach to executing a maven release is to execute release:prepare, followed by release:perform I am attempting to set up a release job within our build server (TeamCity) which will atomically create a release. Assuming successful execution. mvn release:prepare release:perform My concern is that this will execute prepare followed by perform upon each module in the reactor build order. Where what is needed is for release:prepare to be executed in full, followed by release perform in full. Is there any way to configure this in a single chained command? Or will I have to configure multiple build jobs and link the jobs? Regards, Nathan --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: chaining release:prepare release:perform for multi-module [I]
Nathan, Strategy working for me is to have two jobs, one doing mvn clean install on every commit and another for release. The release job would do mvn release:prepare release:perform --batch-mode on my multi module project's parent pom. With TeamCity and svn it works great, and the install job gives me a safety net that trunk is green. Regards, Ziga On 18. jul. 2013, at 17:23, Nathan Coast nathan.co...@db.com wrote: Classification: For internal use only Hi all, I appreciate the normal approach to executing a maven release is to execute release:prepare, followed by release:perform I am attempting to set up a release job within our build server (TeamCity) which will atomically create a release. Assuming successful execution. mvn release:prepare release:perform My concern is that this will execute prepare followed by perform upon each module in the reactor build order. Where what is needed is for release:prepare to be executed in full, followed by release perform in full. Is there any way to configure this in a single chained command? Or will I have to configure multiple build jobs and link the jobs? Regards, Nathan --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - 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
[ANN] Apache Maven Enforcer Plugin 1.3.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Enforcer Plugin, version 1.3.1 This plugin provides goals to control certain environmental constraints such as Maven version, JDK version and OS family along with many more standard rules and user created rules. http://maven.apache.org/plugins/maven-enforcer-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version1.3.1/version /plugin Release Notes - Maven 2.x Enforcer Plugin - Version 1.3.1 ** Bug * [MENFORCER-156] - Upgrading maven-enforcer-plugin from 1.2 to 1.3 breaks maven-assembly-plugin * [MENFORCER-157] - NOTICE file bad indentation references software which is not actually included * [MENFORCER-158] - LICENSE file contains duplicated copy Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
