Option fork=true
What does this option mean in various contexts? Where do I find meaning of all options? Thanks in advance, Madhav -- View this message in context: http://maven.40175.n5.nabble.com/Option-fork-true-tp5723762.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: Versioning with release plugin - support for qualifier
On Wed, September 26, 2012 2:46 pm, Manfred Moser wrote: > Hi! > > I have done some testing with version numbers using classifiers and found > that e.g. the release plugin does not correctly increase the version > number. > > With e.g. 2.1.1-RC.1-SNAPSHOT or 2.1.1-RC1-SNAPSHOT the release plugin > prepare goal suggests 2.1.2-RC.1-SNAPSHOT as next version but I would > expect it to suggest 2.1.1-RC.2-SNAPSHOT > > Is this a known bug or intended behaviour? Should I file a bug? > > manfred Btw. the reason I am asking is that this scheme is suggested as good practice by http://semver.org/ and it should imho work.. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Versioning with release plugin - support for qualifier
Hi Manfred, I have been struggling with the same thing here, and would love to know how to control this. Under my scenario though, the dependency version (with the classifier) is just ignored and not updated to the next dev iteration.. -Ken -Original Message- From: Manfred Moser [mailto:manf...@mosabuam.com] Sent: Wednesday, September 26, 2012 5:47 PM To: users@maven.apache.org Subject: Versioning with release plugin - support for qualifier Hi! I have done some testing with version numbers using classifiers and found that e.g. the release plugin does not correctly increase the version number. With e.g. 2.1.1-RC.1-SNAPSHOT or 2.1.1-RC1-SNAPSHOT the release plugin prepare goal suggests 2.1.2-RC.1-SNAPSHOT as next version but I would expect it to suggest 2.1.1-RC.2-SNAPSHOT Is this a known bug or intended behaviour? Should I file a bug? manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within including any attachments is only for the recipient(s) to which it is intended and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of; or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please send the e-mail back by replying to the sender and permanently delete the entire message and its attachments from all computers and network systems involved in its receipt. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: strategy for incorporating private jars into a project
On Wed, September 26, 2012 2:44 pm, mlandman99 wrote: > Done! Was easier than I thought. I've stored the logic in a java class > within "project 1". On the CI server, I'll have a separate maven build > step > that only runs that one class as a testNG test, which will get those 4-5 > jars to the repo. Then, my next maven build step in the same project (but > with a -U) should enforce that it rebuilds with those guaranteed-to-be-new > internal jars. > > Thanks for the help, all! haha.. interesting hack. You better document that well so that whoever else has to pick up on that will not be investigating forever.. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Versioning with release plugin - support for qualifier
Hi! I have done some testing with version numbers using classifiers and found that e.g. the release plugin does not correctly increase the version number. With e.g. 2.1.1-RC.1-SNAPSHOT or 2.1.1-RC1-SNAPSHOT the release plugin prepare goal suggests 2.1.2-RC.1-SNAPSHOT as next version but I would expect it to suggest 2.1.1-RC.2-SNAPSHOT Is this a known bug or intended behaviour? Should I file a bug? manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: strategy for incorporating private jars into a project
Manfred Moser wrote > Write a script that invokes the the mvn deploy plugin with the deploy goal > and invoke that as separate freestyle build step before your other build > > e.g. > > mvn deploy:deploy-file -D ... > > More info on parameters and stuff at > > http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html > > manfred Done! Was easier than I thought. I've stored the logic in a java class within "project 1". On the CI server, I'll have a separate maven build step that only runs that one class as a testNG test, which will get those 4-5 jars to the repo. Then, my next maven build step in the same project (but with a -U) should enforce that it rebuilds with those guaranteed-to-be-new internal jars. Thanks for the help, all! -- View this message in context: http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5723825.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: strategy for incorporating private jars into a project
On Wed, September 26, 2012 1:04 pm, mlandman99 wrote: > Baptiste MATHUS wrote >> +1. >> There's many possibilities to do that. But are you aware that mvn deploy >> is >> already going to timestamp SNAPSHOTs? Isn't that sufficient?> > > Just found that out yesterday, and am using it, awesome! > > My project is dependent on another maven project that I have control over, > as well as 4-5 internally built jars that I don't have control over. All > of > these dependencies might change daily and I'd like them in the repo as > snapshots. > > Let's call "my" project "project 1" and the project it's dependent on, > "project 2". > > For project 2, I have control over building it, and so I have configured > the > nexus repo info in the POM file for that project. On my CI server, I build > that project first, and I have the maven goal "deploy" defined, and it is > properly deploying the snapshot (with timestamp) to the nexus repo. And > when > Project 1 builds later with the -U parameter, it is always downloading the > most recent snapshot of Project 2 from the repo. Cool! > > My problem lies with the 4-5 jars (that are built nightly) that Project 1 > is > dependent on, that are NOT built by maven projects. Specifically, all I > have > a mounted drive to a network share and know that the (new) .jars will be > there, but that's about it. I'd like to automate the process of getting > those to the repo (as an updated SNAPSHOT version) immediately prior to my > project building, so that I'll pull down the latest version. But unless > I'm > missing something, I don't see any easy way to use maven plugins to deploy > those files, since they're not artifacts of a project I'm building. > > What is the easiest way to do that? I suppose I could write a script that > runs some kind of nexus-related command line or maven command line that > will > somehow deploy these 4-5 files as -SNAPSHOT to the repo. But how? Write a script that invokes the the mvn deploy plugin with the deploy goal and invoke that as separate freestyle build step before your other build e.g. mvn deploy:deploy-file -D ... More info on parameters and stuff at http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Doxia Integration Tools 1.5 Released
The Maven team is pleased to announce the release of the Maven Doxia Integration Tools, version 1.5 This shared component has some utilities that are useful when integrating Doxia in Maven, mainly for site generation and report creation. The main entry point is the SiteTool Plexus component. http://maven.apache.org/doxia/doxia-tools/doxia-integration-tools/ You should specify the version in your project's plugin configuration: org.apache.maven.doxia doxia-integration-tools 1.5 Release Notes - Maven Doxia Tools 1.5 ** Bug * [DOXIATOOLS-16] - NullPointerException when site URL is being generated ** Improvement * [DOXIATOOLS-35] - [PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata ** Task * [DOXIATOOLS-37] - use plexus java 5 annotations instead of old-style javadoc annotations * [DOXIATOOLS-41] - Update to Doxia base 1.3 * [DOXIATOOLS-42] - Upgrade to doxia-sitetools-1.3 Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: strategy for incorporating private jars into a project
Baptiste MATHUS wrote > +1. > There's many possibilities to do that. But are you aware that mvn deploy > is > already going to timestamp SNAPSHOTs? Isn't that sufficient?> Just found that out yesterday, and am using it, awesome! My project is dependent on another maven project that I have control over, as well as 4-5 internally built jars that I don't have control over. All of these dependencies might change daily and I'd like them in the repo as snapshots. Let's call "my" project "project 1" and the project it's dependent on, "project 2". For project 2, I have control over building it, and so I have configured the nexus repo info in the POM file for that project. On my CI server, I build that project first, and I have the maven goal "deploy" defined, and it is properly deploying the snapshot (with timestamp) to the nexus repo. And when Project 1 builds later with the -U parameter, it is always downloading the most recent snapshot of Project 2 from the repo. Cool! My problem lies with the 4-5 jars (that are built nightly) that Project 1 is dependent on, that are NOT built by maven projects. Specifically, all I have a mounted drive to a network share and know that the (new) .jars will be there, but that's about it. I'd like to automate the process of getting those to the repo (as an updated SNAPSHOT version) immediately prior to my project building, so that I'll pull down the latest version. But unless I'm missing something, I don't see any easy way to use maven plugins to deploy those files, since they're not artifacts of a project I'm building. What is the easiest way to do that? I suppose I could write a script that runs some kind of nexus-related command line or maven command line that will somehow deploy these 4-5 files as -SNAPSHOT to the repo. But how? I think some of my confusion is probably due to never using maven at the command line. I use it via m2e, or the CI server has been invoking it for me. If there is a way to get an external file into a repo via a command line, I'm not sure how to do it. :) -- View this message in context: http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5723813.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: How to put a dependency in the classpath BEFORE jre.jar?
> If there is a real interest in my participation I would be glad to join. But ... > a consensus. So do you actually see any chances of a solution for the > described problem? See, if not, it makes no sense that I add another thread > on the dev list. I think there is genuine interest in pursuing POM5 which would help to solve this issue you're talking about (and perhaps add the notion of Platforms etc) but it is going to be a while before it becomes a reality. Right now Maven Dev is working to move from SVN to Git but once that is done, I think the POM5 conversation can be entertained more seriously. Did you ever try the configuration in that blog post you were linked to earlier in this thread? I think it would solve your problem in the short term. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to put a dependency in the classpath BEFORE jre.jar?
If there is a real interest in my participation I would be glad to join. But to tell it frankly, I enjoyed lots of forums and lists where people talked and talked and talked (I am an EG member and know how long companies can talk just to not being forced to change one code line) and did never come to a consensus. So do you actually see any chances of a solution for the described problem? See, if not, it makes no sense that I add another thread on the dev list. > -Original Message- > From: Benson Margulies [mailto:bimargul...@gmail.com] > Sent: Dienstag, 25. September 2012 20:09 > To: Maven Users List > Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? > > Markus, > > If you want to join in on the fun of the development community, please > join us on the dev list. As you've heard on this thread, your > particular concern smacks into a messy conundrum about our desire to > avoid breaking other people's tools that read poms -- no matter how > poorly coded. However, there is a design in progress, it needs more > refinement, and mostly it will need people to actually code it. > > --benson > > - > 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: How to put a dependency in the classpath BEFORE jre.jar?
Strub, thank you for your comments. Unfortunately (as I already wrote two times before) this thread started by the exact problem of overloading a JRE class (Resource annotation) by javaee6.jar... so it just don't work (otherwise I wouldn't have started this thread). Anyway, thanks for chiming in! :-) Regards Markus > -Original Message- > From: Mark Struberg [mailto:strub...@yahoo.de] > Sent: Dienstag, 25. September 2012 21:48 > To: Maven Users List > Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? > > I did not read through the whole thread, so maybe I missed (sorry for > that). > > Afaik maven plugins use a different ClassLoader hierarchy than you > might expect. > Most frameworks use ParentClassLoaderFirst, but maven afaik uses > ClientClassLoaderFirst. > > Which means it's perfectly fine to to put a javax.* dependency in your > plugin classpath. The only thing which is not allowed is to overwrite > native SE stuff. > > LieGrue, > strub > > > > > - Original Message - > > From: Benson Margulies > > To: Maven Users List > > Cc: > > Sent: Tuesday, September 25, 2012 8:08 PM > > Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? > > > > Markus, > > > > If you want to join in on the fun of the development community, > please > > join us on the dev list. As you've heard on this thread, your > > particular concern smacks into a messy conundrum about our desire to > > avoid breaking other people's tools that read poms -- no matter how > > poorly coded. However, there is a design in progress, it needs more > > refinement, and mostly it will need people to actually code it. > > > > --benson > > > > - > > 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: strategy for incorporating private jars into a project
+1. There's many possibilities to do that. But are you aware that mvn deploy is already going to timestamp SNAPSHOTs? Isn't that sufficient? 2012/9/25 Wayne Fay > > Is there a way to automate incrementing the version number and deploy to > > nexus? > > versions plugin @ codehaus mojo > deploy plugin @ apache maven (deploy-file mojo) > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! > nbsp;! > >
