Re: [ANN] Apache Maven Shared Jarsigner 1.3.2 Released
Hi all, I believe the groupId should be org.apache.maven.plugins, not org.apache.maven.shared. Regards, Christian Schlichtherle Am 24.03.2014 um 08:45 schrieb Tony Chemit tche...@apache.org: The Maven team is pleased to announce the release of the Apache Maven Jarsigner, version 1.3.2 This component provides some utilities to sign/verify jars/files in your Mojos. http://maven.apache.org/shared/maven-jarsigner/ To use the Maven Jarsigner, add the following dependency to your project: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-jarsigner/artifactId version1.3.2/version /dependency Release Notes - Maven Shared Components - Version maven-jarsigner-1.3.2 ** Bug * [MSHARED-316] - Can not pass storetype nor storepass to a verify request ** Improvement * [MSHARED-321] - Mask passwords in logs ** Task * [MSHARED-322] - Use maven-shared-utils 0.6 Enjoy, -The Maven team tony. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: properties that are not being resolved
The File vs String types note is the relevant part IIRC... It's not just
file vs string though
On Tuesday, 25 March 2014, Henrik Østerlund Gram henrik.g...@gmail.com
wrote:
Thanks for the link. It was quite informative, but I'm again a little
confused because it is stated in your explanation,
the configuration sections will have mojo-injected properties evaluated,
but that isn't the case in my example. I was trying to have such
properties evaluated in a envEntries element inside a configuration
element for the ear plugin, but it would not work until I modified the
plugin to do an extra substitution itself.
Regards,
Henrik Gram
On Mon, Mar 24, 2014 at 10:38 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Please read my answer to a similar question on Stack Overflow:
http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
On 23 March 2014 21:36, Henrik Østerlund Gram henrik.g...@gmail.com
wrote:
I stumbled over some rather strange behaviour regarding properties. It
seems properties generated by one plugin are not always resolved for
other
plugins and I can't figure out why.
I use a plugin to make info about the git branch available in the
properties so it can be passed to other plugins. The particular plugin
does not seem important, but I've included it here for sake of
completeness:
plugin
groupIdcom.code54.mojo/groupId
artifactIdbuildversion-plugin/artifactId
version1.0.3/version
configuration
tstamp_format.MM.dd HH:mm/tstamp_format
/configuration
executions
execution
goals
goalset-properties/goal
/goals
/execution
/executions
/plugin
But when I referenced the properties set by the plugin in an env entry
for
the maven ear plugin, the properties were not resolved at all:
envEntries
env-entry
descriptionMiddleware build information/description
env-entry-namejava:app/env/sw-version/env-entry-name
env-entry-typejava.lang.String/env-entry-type
env-entry-value${build-commit} @ ${build-tstamp} built on
${maven.build.timestamp}/env-entry-value
/env-entry
/envEntries
Just to be sure, I used the latest maven and tried both version 2.9 of
the
plugin and the latest from the repo with the same result.
The only way I managed to fix this was to patch the maven-ear-plugin
itself, adding the following code in
GenerateApplicationXmlMojo.execute():
// Fix env variable substitutions
Properties props = project.getProperties();
PlexusConfiguration[] entries = envEntries.getChildren();
if (entries != null) {
for (PlexusConfiguration entry : entries) {
if (env-entry.equals(entry.getName())) {
PlexusConfiguration[] envEntryChildren =
entry.getChildren();
if (envEntryChildren != null) {
for (PlexusConfiguration envEntryChild :
envEntryChildren)
{
envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
props));
}
}
}
}
}
Then it worked just fine, but I don't understand why this is necessary.
I
thought whatever called the plugin was supposed to have done the
variable
substitution already. So clearly the properties were present at the
time
of executing the plugin, but they werent being automaticly substituted.
To add to the confusion, using ${project.version} in the
env-entry-value
was resolved just fine, but just not the properties coming from another
plugin despite the plugins being run in the correct order.
To further add to th
--
Sent from my phone
Re: [ANN] Apache Maven Shared Jarsigner 1.3.2 Released
No, the specified groupId is correct. There is a plugin as well but this announcement is for the shared component, not the plugin. /Anders On Tue, Mar 25, 2014 at 8:25 AM, Christian Schlichtherle christ...@schlichtherle.de wrote: Hi all, I believe the groupId should be org.apache.maven.plugins, not org.apache.maven.shared. Regards, Christian Schlichtherle Am 24.03.2014 um 08:45 schrieb Tony Chemit tche...@apache.org: The Maven team is pleased to announce the release of the Apache Maven Jarsigner, version 1.3.2 This component provides some utilities to sign/verify jars/files in your Mojos. http://maven.apache.org/shared/maven-jarsigner/ To use the Maven Jarsigner, add the following dependency to your project: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-jarsigner/artifactId version1.3.2/version /dependency Release Notes - Maven Shared Components - Version maven-jarsigner-1.3.2 ** Bug * [MSHARED-316] - Can not pass storetype nor storepass to a verify request ** Improvement * [MSHARED-321] - Mask passwords in logs ** Task * [MSHARED-322] - Use maven-shared-utils 0.6 Enjoy, -The Maven team tony.
[ANN] Animal Sniffer version 1.11 Released
Hi, The Mojo team is pleased to announce the release of Animal Sniffer version 1.11. This release permits the use of custom annotations in lieu of @IgnoreJRERequirement Animal Sniffer provides tools to assist verifying that classes compiled with a newer JDK/API are compatible with an older JDK/API. The following tools are provided by animal sniffer: * A command line tool to dump the class file version number (http://mojo.codehaus.org/animal-sniffer/animal-sniffer/index.html). This helps you track down the offending jar file when you see UnsupportedClassVersionError. * A set of ANT tasks (http://mojo.codehaus.org/animal-sniffer/animal-sniffer-ant-tasks/index.html) for verifying that your classes comply with an API signature as well as tasks for creating API signatures from a JDK, or a collection or jar and class files, or a collection of other API signature files, or combination of these elements. * A rule for use in the maven-enforcer-plugin (http://mojo.codehaus.org/animal-sniffer/animal-sniffer-enforcer-rule/index.html) for verifying that your classes comply with an API signature . * A maven plugin (http://mojo.codehaus.org/animal-sniffer-maven-plugin/index.html) for verifying that your classes comply with an API signature as well as for creating API signatures from a JDK, or the current module's classes, or the current module's dependencies, or a collection of other API signature files, or combination of these elements. The artifacts are available from the Maven Central repository. Release Notes - Mojo Animal Sniffer - Version 1.11 ** Improvement * [MANIMALSNIFFER-41] - Define a custom annotation instead of relying on @IgnoreJRERequirement Enjoy, The Mojo Team.
Incremental build API
Hi, For those who are interested in incremental builds we, at Takari, have released a general purpose incremental build API with an initial focus on Maven. We've created a short, high-level description of the framework[1] and we've opened up our Git repository with the code[2]. We also have a some demos that people can look at[3]. We are, and have been, running this code in production for a few months but it is still a work in progress. We have implemented a Maven lifecycle that integrates this API but we've just started using it ourselves. We will open this lifecycle up shortly for people to try but for now, if you're interested in incremental builds take a look and let us know what you think! A note to those interested that the use of the API in Maven requires 3.2.1+. [1]: http://takari.io/2014/03/25/incremental-build.html [2]: https://github.com/takari/io.takari.incrementalbuild [3]: https://github.com/takari/io.takari.incrementalbuild/tree/master/incrementalbuild/src/test/java/io/takari/incremental/demo Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon
Re: Forcing Integration Tests Before a Release
I have tried to get this working, but it does not seem to work. When I do mvn release:prepare I get [INFO] Executing: cmd.exe /X /C D:\bin\Apache\apache-maven-3.1.1\bin\mvn -s C:\Users\Eric\AppData\Local\Temp\release-settings2652114304406041143.xml clean verify site --no-plugin-updates -Psonatype-oss-release -P user,local-repository In the output I can see the 'clean' and the 'site' happen, but the failsafe integration tests do not run. If I do mvn verify -P run-it then the integration tests run as normal. Cheers, Eric build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.17/version executions execution iddefault-integration-test/id goals goalintegration-test/goal /goals /execution execution iddefault-verify/id goals goalverify/goal /goals /execution /executions /plugin plugin artifactIdmaven-release-plugin/artifactId version2.5/version /plugin /plugins /pluginManagement plugins plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean verify site/preparationGoals /configuration /plugin . . . profiles profile idrun-it/id activation property nameperformRelease/name valuetrue/value /property /activation build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId executions execution goals goalintegration-test/goal goalverify/goal /goals /execution /executions /plugin /plugins /build /profile /profiles On 3/21/2014 1:10 PM, Eric Kolotyluk wrote: Cool, that is what I am looking for. Thanks so much. Cheers, Eric On 2014-03-20, 1:50 PM, Mirko Friedenhagen wrote: Eric, when you use the maven-release-plugin a property performRelease is set during release:perform. So define in the pluginManagement section a definition for the maven-failsafe-plugin in your build section: build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.17/version executions execution iddefault-integration-test/id goals goalintegration-test/goal /goals /execution execution iddefault-verify/id goals goalverify/goal /goals /execution /executions /plugin /plugins /pluginManagement /build and later on in your pom profile idrelease-run-failsafe/id activation property nameperformRelease/name valuetrue/value /property /activation build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId /plugin /plugins /build profile So only during release:perform your integration tests will be executed and success is verified. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 20, 2014 at 8:32 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: I am looking for some way to force my integration tests before a release, without explicitly using a profile. For example, plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean verify site/preparationGoals /configuration /plugin But that doesn't work because unless the failsafe plugin is defined, it won't run the tests. I thought of doing something like profiles profile idrun-it/id activation file missingtarget/failsafe-reports/missing /file /activation build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.17/version executions execution goals goalintegration-test/goal goalverify/goal /goals
Re: Incremental build API
Thanks, I’ll take a look One of these days I was going to attempt a port of an incremental build system we developed to Maven. Some concepts include a post compile artifact byte code analyzer and comparator that classifies the nature of change to help optimize away (in some cases) the dependent transient rebuilds Of course using mvn clean would defeat this, we have a smarter clean that executes its goal only if the scm system has detected deletes… Anyway, I’ll use your announcement to try to engage. Thanks! From: Jason van Zyl ja...@takari.iomailto:ja...@takari.io Reply-To: Maven Users List users@maven.apache.orgmailto:users@maven.apache.org Date: Tuesday, March 25, 2014 at 10:44 AM To: Maven Users List users@maven.apache.orgmailto:users@maven.apache.org Subject: Incremental build API Hi, For those who are interested in incremental builds we, at Takari, have released a general purpose incremental build API with an initial focus on Maven. We've created a short, high-level description of the framework[1] and we've opened up our Git repository with the code[2]. We also have a some demos that people can look at[3]. We are, and have been, running this code in production for a few months but it is still a work in progress. We have implemented a Maven lifecycle that integrates this API but we've just started using it ourselves. We will open this lifecycle up shortly for people to try but for now, if you're interested in incremental builds take a look and let us know what you think! A note to those interested that the use of the API in Maven requires 3.2.1+. [1]: http://takari.io/2014/03/25/incremental-build.html [2]: https://github.com/takari/io.takari.incrementalbuild [3]: https://github.com/takari/io.takari.incrementalbuild/tree/master/incrementalbuild/src/test/java/io/takari/incremental/demo Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon
Re: Incremental build API
Looking interesting - will definitely take a look at this for my various language plugins ( coffee script, clojure, frege ). On 26 Mar 2014, at 6:44, Jason van Zyl wrote: A note to those interested that the use of the API in Maven requires 3.2.1+. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Incremental build API
On Mar 25, 2014, at 2:36 PM, Mauri, Richard richard.ma...@sap.com wrote: Thanks, I’ll take a look One of these days I was going to attempt a port of an incremental build system we developed to Maven. Some concepts include a post compile artifact byte code analyzer and comparator that classifies the nature of change to help optimize away (in some cases) the dependent transient rebuilds Of course using mvn clean would defeat this, we have a smarter clean that executes its goal only if the scm system has detected deletes… Yes, clean becomes unnecessary unless we detect state changes we can't account for (configuration changes or the plugins change from the previous run). We handle the case of detecting stale outputs as well, where you need to delete the outputs of inputs that have been deleted. We also have a more fine-grained model underneath that allows us to model compilation units which is what we use in our incremental compilers (JDT and Javac implementations). Anyway, I’ll use your announcement to try to engage. Thanks! From: Jason van Zyl ja...@takari.iomailto:ja...@takari.io Reply-To: Maven Users List users@maven.apache.orgmailto:users@maven.apache.org Date: Tuesday, March 25, 2014 at 10:44 AM To: Maven Users List users@maven.apache.orgmailto:users@maven.apache.org Subject: Incremental build API Hi, For those who are interested in incremental builds we, at Takari, have released a general purpose incremental build API with an initial focus on Maven. We've created a short, high-level description of the framework[1] and we've opened up our Git repository with the code[2]. We also have a some demos that people can look at[3]. We are, and have been, running this code in production for a few months but it is still a work in progress. We have implemented a Maven lifecycle that integrates this API but we've just started using it ourselves. We will open this lifecycle up shortly for people to try but for now, if you're interested in incremental builds take a look and let us know what you think! A note to those interested that the use of the API in Maven requires 3.2.1+. [1]: http://takari.io/2014/03/25/incremental-build.html [2]: https://github.com/takari/io.takari.incrementalbuild [3]: https://github.com/takari/io.takari.incrementalbuild/tree/master/incrementalbuild/src/test/java/io/takari/incremental/demo Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: Incremental build API
Should work for any kind of plugins. We have integrated this into 20 or so mojos thus far ranging from source generation, resource processing, resource generation, compilation and class file processing. It's intended to be general purpose but we're looking for feedback to help flesh out the APIs and make them more friendly where/if they are not. On Mar 25, 2014, at 3:09 PM, Mark Derricutt m...@talios.com wrote: Looking interesting - will definitely take a look at this for my various language plugins ( coffee script, clojure, frege ). On 26 Mar 2014, at 6:44, Jason van Zyl wrote: A note to those interested that the use of the API in Maven requires 3.2.1+. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - To think is easy. To act is hard. But the hardest thing in the world is to act in accordance with your thinking. -- Johann von Goethe
Re: Forcing Integration Tests Before a Release
performRelease is only set during release:perform :-) Regards Mirko -- Sent from my mobile On Mar 25, 2014 10:05 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: I have tried to get this working, but it does not seem to work. When I do mvn release:prepare I get [INFO] Executing: cmd.exe /X /C D:\bin\Apache\apache-maven-3.1.1\bin\mvn -s C:\Users\Eric\AppData\Local\Temp\release-settings2652114304406041143.xml clean verify site --no-plugin-updates -Psonatype-oss-release -P user,local-repository In the output I can see the 'clean' and the 'site' happen, but the failsafe integration tests do not run. If I do mvn verify -P run-it then the integration tests run as normal. Cheers, Eric build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.17/version executions execution iddefault-integration-test/id goals goalintegration-test/goal /goals /execution execution iddefault-verify/id goals goalverify/goal /goals /execution /executions /plugin plugin artifactIdmaven-release-plugin/artifactId version2.5/version /plugin /plugins /pluginManagement plugins plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean verify site/preparationGoals /configuration /plugin . . . profiles profile idrun-it/id activation property nameperformRelease/name valuetrue/value /property /activation build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId executions execution goals goalintegration-test/goal goalverify/goal /goals /execution /executions /plugin /plugins /build /profile /profiles On 3/21/2014 1:10 PM, Eric Kolotyluk wrote: Cool, that is what I am looking for. Thanks so much. Cheers, Eric On 2014-03-20, 1:50 PM, Mirko Friedenhagen wrote: Eric, when you use the maven-release-plugin a property performRelease is set during release:perform. So define in the pluginManagement section a definition for the maven-failsafe-plugin in your build section: build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.17/version executions execution iddefault-integration-test/id goals goalintegration-test/goal /goals /execution execution iddefault-verify/id goals goalverify/goal /goals /execution /executions /plugin /plugins /pluginManagement /build and later on in your pom profile idrelease-run-failsafe/id activation property nameperformRelease/name valuetrue/value /property /activation build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId /plugin /plugins /build profile So only during release:perform your integration tests will be executed and success is verified. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 20, 2014 at 8:32 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: I am looking for some way to force my integration tests before a release, without explicitly using a profile. For example, plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean verify site/preparationGoals /configuration /plugin But that doesn't work because unless the failsafe plugin is defined, it won't run the tests. I thought of doing something like profiles profile idrun-it/id activation file missingtarget/failsafe-reports/missing /file /activation build
Re: Forcing Integration Tests Before a Release
Eric, you might modify the preparationGoals parameter to include -DperformRelease=true. Regards Mirko -- Sent from my mobile On Mar 25, 2014 10:05 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: I have tried to get this working, but it does not seem to work. When I do mvn release:prepare I get [INFO] Executing: cmd.exe /X /C D:\bin\Apache\apache-maven-3.1.1\bin\mvn -s C:\Users\Eric\AppData\Local\Temp\release-settings2652114304406041143.xml clean verify site --no-plugin-updates -Psonatype-oss-release -P user,local-repository In the output I can see the 'clean' and the 'site' happen, but the failsafe integration tests do not run. If I do mvn verify -P run-it then the integration tests run as normal. Cheers, Eric build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.17/version executions execution iddefault-integration-test/id goals goalintegration-test/goal /goals /execution execution iddefault-verify/id goals goalverify/goal /goals /execution /executions /plugin plugin artifactIdmaven-release-plugin/artifactId version2.5/version /plugin /plugins /pluginManagement plugins plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean verify site/preparationGoals /configuration /plugin . . . profiles profile idrun-it/id activation property nameperformRelease/name valuetrue/value /property /activation build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId executions execution goals goalintegration-test/goal goalverify/goal /goals /execution /executions /plugin /plugins /build /profile /profiles On 3/21/2014 1:10 PM, Eric Kolotyluk wrote: Cool, that is what I am looking for. Thanks so much. Cheers, Eric On 2014-03-20, 1:50 PM, Mirko Friedenhagen wrote: Eric, when you use the maven-release-plugin a property performRelease is set during release:perform. So define in the pluginManagement section a definition for the maven-failsafe-plugin in your build section: build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.17/version executions execution iddefault-integration-test/id goals goalintegration-test/goal /goals /execution execution iddefault-verify/id goals goalverify/goal /goals /execution /executions /plugin /plugins /pluginManagement /build and later on in your pom profile idrelease-run-failsafe/id activation property nameperformRelease/name valuetrue/value /property /activation build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId /plugin /plugins /build profile So only during release:perform your integration tests will be executed and success is verified. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 20, 2014 at 8:32 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: I am looking for some way to force my integration tests before a release, without explicitly using a profile. For example, plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean verify site/preparationGoals /configuration /plugin But that doesn't work because unless the failsafe plugin is defined, it won't run the tests. I thought of doing something like profiles profile idrun-it/id activation file missingtarget/failsafe-reports/missing /file
Re: Forcing Integration Tests Before a Release
Eric, I do only use release:prepare, see https://github.com/1and1/foss-parent/blob/master/release line 47ff. Regards Mirko -- Sent from my mobile On Mar 25, 2014 10:05 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: I have tried to get this working, but it does not seem to work. When I do mvn release:prepare I get [INFO] Executing: cmd.exe /X /C D:\bin\Apache\apache-maven-3.1.1\bin\mvn -s C:\Users\Eric\AppData\Local\Temp\release-settings2652114304406041143.xml clean verify site --no-plugin-updates -Psonatype-oss-release -P user,local-repository In the output I can see the 'clean' and the 'site' happen, but the failsafe integration tests do not run. If I do mvn verify -P run-it then the integration tests run as normal. Cheers, Eric build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.17/version executions execution iddefault-integration-test/id goals goalintegration-test/goal /goals /execution execution iddefault-verify/id goals goalverify/goal /goals /execution /executions /plugin plugin artifactIdmaven-release-plugin/artifactId version2.5/version /plugin /plugins /pluginManagement plugins plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean verify site/preparationGoals /configuration /plugin . . . profiles profile idrun-it/id activation property nameperformRelease/name valuetrue/value /property /activation build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId executions execution goals goalintegration-test/goal goalverify/goal /goals /execution /executions /plugin /plugins /build /profile /profiles On 3/21/2014 1:10 PM, Eric Kolotyluk wrote: Cool, that is what I am looking for. Thanks so much. Cheers, Eric On 2014-03-20, 1:50 PM, Mirko Friedenhagen wrote: Eric, when you use the maven-release-plugin a property performRelease is set during release:perform. So define in the pluginManagement section a definition for the maven-failsafe-plugin in your build section: build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.17/version executions execution iddefault-integration-test/id goals goalintegration-test/goal /goals /execution execution iddefault-verify/id goals goalverify/goal /goals /execution /executions /plugin /plugins /pluginManagement /build and later on in your pom profile idrelease-run-failsafe/id activation property nameperformRelease/name valuetrue/value /property /activation build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId /plugin /plugins /build profile So only during release:perform your integration tests will be executed and success is verified. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 20, 2014 at 8:32 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: I am looking for some way to force my integration tests before a release, without explicitly using a profile. For example, plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean verify site/preparationGoals /configuration /plugin But that doesn't work because unless the failsafe plugin is defined, it won't run the tests. I thought of doing something like profiles profile idrun-it/id activation file missingtarget/failsafe-reports/missing
Updated documentation for Central Repository
Hello everyone! We have updated the documentation for publishing artifacts to the Central Repository via the free Sonatype Open Source Repository Hosting (OSSRH) and added more documents about status, getting help and more and put it all together on a brand new website. Please look at the announcement blog post at http://blog.sonatype.com/2014/03/a-home-for-the-central-repository/ and the actual new website at http://central.sonatype.org/ Specifically the instructions for Apache Maven are at http://central.sonatype.org/pages/apache-maven.html but I would like to encourage you all to have a look at the rest of the site as well. The Maven docs details usage of things like the Nexus Staging Maven Plugin for command line based release (no more logging into the UI) and a whole lot of other things. We are hoping you find this all useful and get some great feedback and recommendations for improvements from you. Looking forward to continue to improve the site going forward. Jason, Joel, Manfred and others Sonatype Ops Team - @sonatype_ops - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Forcing Integration Tests Before a Release
On 26 March 2014 07:34, Eric Kolotyluk eric.koloty...@gmail.com wrote: I have tried to get this working, but it does not seem to work. When I do mvn release:prepare I get [INFO] Executing: cmd.exe /X /C D:\bin\Apache\apache-maven-3.1.1\bin\mvn -s C:\Users\Eric\AppData\Local\Temp\release-settings2652114304406041143.xml clean verify site --no-plugin-updates -Psonatype-oss-release -P user,local-repository In the output I can see the 'clean' and the 'site' happen, but the failsafe integration tests do not run. If I do mvn verify -P run-it then the integration tests run as normal. What is -X telling you? Is the variable performRelease actually set? Looking at org.apache:apache:10 the release-plugin is configured different to the docs. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.1/version configuration useReleaseProfilefalse/useReleaseProfile goalsdeploy/goals arguments-Papache-release/arguments /configuration /plugin i.e. it disables useReleaseProfile and forces the apache-release profile to be used. I've had a quick look at the code, and I dont think this variable will be set on prepare. The performRelease variable looks like it is only set on perform not prepare. http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile You can use http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#argumentsto provide additional arguments to the release plugin. The code in AbstractReleaseMojo.createReleaseDescriptor() builds a list of active profiles and so you can just configure the release plugin to include -P run-its (which is the profile name used in org.apache.maven.plugins:maven-plugins:22 so I assume its the preferred name) Since it is the same plugin, I dont think you are going to be able to separate out running the integration tests only in prepare. They are going to be run again in perform. This is probably not a bad thing.
Re: Forcing Integration Tests Before a Release
Ahhh, actually adding -P run-it to the preparationGoals parameter does exactly what I want, and I can dispense with all the other complexities. I did not realize I could add other arguments to the preparationGoals parameter. Sometimes getting what you want from Maven is not obvious, until you get it working :-) Thanks so much for the key Mirko Cheers, Eric On 3/25/2014 3:26 PM, Mirko Friedenhagen wrote: Eric, you might modify the preparationGoals parameter to include -DperformRelease=true. Regards Mirko - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Updated documentation for Central Repository
On 3/25/2014 4:42 PM, Manfred Moser wrote: Hello everyone! We have updated the documentation for publishing artifacts to the Central Repository via the free Sonatype Open Source Repository Hosting (OSSRH) and added more documents about status, getting help and more and put it all together on a brand new website. Please look at the announcement blog post at http://blog.sonatype.com/2014/03/a-home-for-the-central-repository/ and the actual new website at http://central.sonatype.org/ Specifically the instructions for Apache Maven are at http://central.sonatype.org/pages/apache-maven.html but I would like to encourage you all to have a look at the rest of the site as well. The Maven docs details usage of things like the Nexus Staging Maven Plugin for command line based release (no more logging into the UI) and a whole lot of other things. We are hoping you find this all useful and get some great feedback and recommendations for improvements from you. Looking forward to continue to improve the site going forward. Jason, Joel, Manfred and others Sonatype Ops Team - @sonatype_ops - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org In the Maven section, I was hoping to see some discussion like... *Local Repository Manager vs Sonatype OSS* You may be in a situation that you have a local or corporate Repository Manager that you use as part of your daily software development process, and you only want to use the Sonatype OSS Repository Manager on occasion. You can can configure this in your settings.xml like this: profile idlocal-repository/id properties altReleaseDeploymentRepositorylocal-nexus::default::http://localhost:8081/nexus/content/repositories/releases//altReleaseDeploymentRepository altSnapshotDeploymentRepositorylocal-nexus::default::http://localhost:8081/nexus/content/repositories/snapshots//altSnapshotDeploymentRepository /properties /profile activeProfiles activeProfilelocal-repository/activeProfile /activeProfiles servers server idlocal-nexus/id usernamedeployment/username password/secret//password /server server idsonatype-nexus-snapshots/id username/username//username password/secret//password /server server idsonatype-nexus-staging/id username/username//username password/secret//password /server /servers Normally when you run deploy, your artifacts will go to 'local-nexus' (or whatever you configure), but when you want to use the Sonatype OSS repository, you can just use mvn deploy -P!local-repository and Maven will deploy according to the distributionManagement defined in parent groupIdorg.sonatype.oss/groupId artifactIdoss-parent/artifactId version7/version /parent The benefit of this method is that you do not have to put any local or unnecessary corporate information in the pom.xml you are distributing with your project. Warning: some older versions of the maven-deploy-plugin do not support this properly, so use the latest version, for example, in your pom.xml: build pluginManagement plugins plugin !-- Bugs in older versions prevent altReleaseDeploymentRepository and altSnapshotDeploymentRepository from working correctly https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html -- artifactIdmaven-deploy-plugin/artifactId version2.8.1/version /plugin /pluginManagement . . . /build
