Site thread saftey?
Hi all, The site:site and site:deply goals are not marked as threadsafe which is pretty reasonable as it relies on the underlying reporters and wagons to be threadsafe before it can make that contract (and not all reporters and wagons are threadsafe - esp the default scp wagon - so it can't be marked as threadsafe). If the underlying wagon and reporters are known to be threadsafe are there any known issues with the site goals themselves that would cause issues with a parallel build? Regards, /James
cannot resolve POM with classifier?
Hi all, I am in the scenario where a POM is generated and attached in the main project, then will be deployed on the repo; that POM contains all required dependencies my users need when developing custom applications. The issue comes when I would like to resolve the generated prom in an external project, becauee IIUC there is no way to: * inherit from a parent pom with a classifier; * declare its dependency in `dependencyManagement` with scope `import`. Does that mean that POM cannot have classifiers? Do you have any alternative solution? TIA! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: cannot resolve POM with classifier?
Deploy at a different GAV. Used do this at a former employers. Internally we'd use one GA and the publish externally at a different GA (same V) On Thursday, 2 May 2013, Simone Tripodi wrote: Hi all, I am in the scenario where a POM is generated and attached in the main project, then will be deployed on the repo; that POM contains all required dependencies my users need when developing custom applications. The issue comes when I would like to resolve the generated prom in an external project, becauee IIUC there is no way to: * inherit from a parent pom with a classifier; * declare its dependency in `dependencyManagement` with scope `import`. Does that mean that POM cannot have classifiers? Do you have any alternative solution? TIA! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ -- Sent from my phone
Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
- when speaking about SNAPSHOTs we should distinguish between
dependencies and what we produce. With a build we produce an artifact which
is either a SNAPSHOT or release according to the version in the pom.xml. A
dependency resolves either to a SNAPSHOT or a released version of another
library. The dependency might be internal (modules built within the same
reactor) or external.
- an external dependency should never be a SNAPSHOT (it makes life easier
anyway ;-), should only be allowed temporarily.
- all modules in our multi module project always have the same version
(e.g. 0.1.0-SNAPSHOT) and dependencies are defined with ${project.version}
When produce artifacts we deploy them to our target environment (e.g.
war-file to app-server, db scripts to database...) and make some tests. All
this stuff is done during the night in an automated way. We have other
stages where we have to deploy a build which has passed this first tests
but normally, this happens some days later. That's why a SNAPSHOT is not
enough as it's hard to track down which SNAPSHOT we can deliver.
In other words: It's important what we produce and less important what's in
it (e.g. SNAPSHOT or not) as we test if it works or not. Don't get me
wrong: we avoid having SNAPSHOT deps and when it goes to production we
don't have SNAPSHOT libs anymore! But during development this is ok.
And that's what we do all the time: during the day we do continuous builds
(mvn clean install) in the night we create an ad-hoc release with mvn
clean install -Dversion.override=x.y-n which is virtually changing the
${project.version} in all our pom.xml but not changing anything in our
version control. And if something fails we don't repeat we start a new one.
By the way: The version.override feature has options to let a build fail or
issue a warning when it detects SNAPSHOT deps. This is not documented but
it's there.
Cheers,
Rotsch
2013/5/2 Mirko Friedenhagen mfriedenha...@gmail.com
Hello there,
I. find prepare and perform quite heavyweight my self. After prepare did
build everything successfully, it throws away everything, just tags the
source and starts over again during perform.
prepare already checks with scm means, that there are no modifications and
in my experience tagging is the most harmless operation in the whole
process (well, would I still use CVS that could be different).
So running prepare with prepareGoals set to -DperformRelease=true clean
deploy does what *I* want.
- checks I have everything in SCM
- does modify POMs for release.
- deploys to staging
- only on success of this tags the sources
- go back to SNAPSHOT.
git and svn (when not doing the strange remoteTagging) are capable of
tagging always.
Worst thing that might happen: bad stuff in staging for a short time.
Regards Mirko
--
Sent from my mobile
On May 1, 2013 9:15 PM, Robert Scholte rfscho...@apache.org wrote:
Graham, well said.
Although the pom.xml is the easiest way to discover the version, it is
not
the best location, since it would require a commit.
The solution must be found in a generated file which will be added to the
artifact during packaging. Here you could add a timestamp or revision.
Robert
Op Wed, 01 May 2013 12:44:19 +0200 schreef Graham Leggett
minf...@sharp.fm:
On 30 Apr 2013, at 11:21 PM, Roger Brechbühl rotscher...@gmail.com
wrote:
Maybe somebody is interested in how a release could be built in a more
lightweight and safe way than with the maven-release-plugin. Especially
recommended for nightly releases.
It's not yet released, but basically fully working:
*mvn clean install -Dversion.override=1.2.3-S-5*
https://github.com/rotscher/**emerging/tree/version.**
override-with_maven_install-2.**4
https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4
Maven has a very clear definition of a release, being an artefact that
can traced back to the precise code via a tag, and a build that can be
repeated. This is as opposed to a snapshot, which has no well defined
origin.
You might approach this two ways, you might create nightly snapshots
and have them deployed somewhere suitable, using mvn deploy.
Alternatively if you want to create proper nightly releases (in the
maven sense), you could feed a custom version number into the release
plugin to represent your release, but this starts to smell like that's
what a snapshot is for.
Regards,
Graham
--
--**--**-
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
Hello, if interested: the topic of lightweight maven releases is discussed in DevOps for Developers, Apress, Chapter 8. Cheers, Michael Hello there, I. find prepare and perform quite heavyweight my self. After prepare did build everything successfully, it throws away everything, just tags the source and starts over again during perform. prepare already checks with scm means, that there are no modifications and in my experience tagging is the most harmless operation in the whole process (well, would I still use CVS that could be different). So running prepare with prepareGoals set to -DperformRelease=true clean deploy does what *I* want. - checks I have everything in SCM - does modify POMs for release. - deploys to staging - only on success of this tags the sources - go back to SNAPSHOT. git and svn (when not doing the strange remoteTagging) are capable of tagging always. Worst thing that might happen: bad stuff in staging for a short time. Regards Mirko -- Sent from my mobile On May 1, 2013 9:15 PM, Robert Scholte rfscho...@apache.org wrote: Graham, well said. Although the pom.xml is the easiest way to discover the version, it is not the best location, since it would require a commit. The solution must be found in a generated file which will be added to the artifact during packaging. Here you could add a timestamp or revision. Robert Op Wed, 01 May 2013 12:44:19 +0200 schreef Graham Leggett minf...@sharp.fm: On 30 Apr 2013, at 11:21 PM, Roger Brechbühl rotscher...@gmail.com wrote: Maybe somebody is interested in how a release could be built in a more lightweight and safe way than with the maven-release-plugin. Especially recommended for nightly releases. It's not yet released, but basically fully working: *mvn clean install -Dversion.override=1.2.3-S-5* https://github.com/rotscher/**emerging/tree/version.** override-with_maven_install-2.**4https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 Maven has a very clear definition of a release, being an artefact that can traced back to the precise code via a tag, and a build that can be repeated. This is as opposed to a snapshot, which has no well defined origin. You might approach this two ways, you might create nightly snapshots and have them deployed somewhere suitable, using mvn deploy. Alternatively if you want to create proper nightly releases (in the maven sense), you could feed a custom version number into the release plugin to represent your release, but this starts to smell like that's what a snapshot is for. Regards, Graham -- --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-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: cannot resolve POM with classifier?
Hi Simone, per GAV there's exactly 1 pom.xml, there's no such thing as a classified pom.xml. You are probably looking for mixins, still somthingon the wishlist of Maven. Robert Op Thu, 02 May 2013 13:51:59 +0200 schreef Simone Tripodi simonetrip...@apache.org: Hi all, I am in the scenario where a POM is generated and attached in the main project, then will be deployed on the repo; that POM contains all required dependencies my users need when developing custom applications. The issue comes when I would like to resolve the generated prom in an external project, becauee IIUC there is no way to: * inherit from a parent pom with a classifier; * declare its dependency in `dependencyManagement` with scope `import`. Does that mean that POM cannot have classifiers? Do you have any alternative solution? TIA! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Executing tests in a newer JVM version than the one used to build project.
Hi, I have a bit of a complicated setup. I need to build my jar file using java 1.6, but I need to execute my tests using Java 1.7, as my library need to connect to other libraries built for Java V1.7. How can I do that? I currently set my pom.xml with the following entries: properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding maven.compiler.target1.6/maven.compiler.target maven.compiler.source1.6/maven.compiler.source /properties Unfortunately when my test is executed it is also running using v1.6 but I would like to use version 1.7. Is there a way to tell sure fire (I guess this is the plugin I should look at) to use v1.7 when executing the tests? What is exactly choosing the target version of the Java being used for testing? I develop my project library using eclipse. I have set this project to use java 1.6 for this eclipse project. If I tell eclipse to use V1.7 my tests are executed in Maven using V1.7 and then my test are all fine. The problem is then that when I build my jar files there are conflicts between the java used by eclipse and the java used by Maven, and it can happen that suddenly the jar file is built with java classes being 1.7 instead of 1.6. Does anyone have an idea what I should do here? Thanks for your help. Jean
Re: Executing tests in a newer JVM version than the one used to build project.
On Thursday, 2 May 2013, Jean Tremblay wrote: Hi, I have a bit of a complicated setup. I need to build my jar file using java 1.6, but I need to execute my tests using Java 1.7, as my library need to connect to other libraries built for Java V1.7. How can I do that? I currently set my pom.xml with the following entries: properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding maven.compiler.target1.6/maven.compiler.target maven.compiler.source1.6/maven.compiler.source /properties Unfortunately when my test is executed it is also running using v1.6 but I would like to use version 1.7. Is there a way to tell sure fire (I guess this is the plugin I should look at) to use v1.7 when executing the tests? What is exactly choosing the target version of the Java being used for testing? I develop my project library using eclipse. I have set this project to use java 1.6 for this eclipse project. If I tell eclipse to use V1.7 my tests are executed in Maven using V1.7 and then my test are all fine. The problem is then that when I build my jar files there are conflicts between the java used by eclipse and the java used by Maven, and it can happen that suddenly the jar file is built with java classes being 1.7 instead of 1.6. Does anyone have an idea what I should do here? See my answer here: http://stackoverflow.com/questions/12414209/compile-maven-module-with-different-java-version/12419643#12419643 IIRC you then need to bind a second execution of tool chains after the compile phase but before the test phase to switch to 1.7 Thanks for your help. Jean -- Sent from my phone
Re: Building selected projects with nested aggregators
Sorry to bump my own thread, but I've got a another use-case and I'm hoping there's a similarly blindingly obvious solution :) What if I want to build all the sub-modules of, say, web-apps and their dependencies across the whole tree? I know I can go in to the web-apps aggregator and do a mvn install, but then this won't build any of the dependencies from sibling/parent aggregators. Any way to do this without having to call out all the sub-modules explicitly? -- View this message in context: http://maven.40175.n5.nabble.com/Building-selected-projects-with-nested-aggregators-tp5753572p5754822.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Building selected projects with nested aggregators
Oops, just realised this scenario doesn't quite reflect my situation. Please also imagine in the attached image that there is no parent/child relationship between webapps and it's sub-modules, i.e. it's purely an aggregator POM -- View this message in context: http://maven.40175.n5.nabble.com/Building-selected-projects-with-nested-aggregators-tp5753572p5754823.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
