Maven release:prepare
Hi All, The maven release:prepare does the following things: release: prepare – Performs a number of operations - Checks to make sure that there are no uncommitted changes. - Ensures that there are no SNAPSHOT dependencies in the POM file, - Changes the version of the application and removes SNAPSHOT from the version. ie 1.0.3-SNAPSHOT becomes 1.0.3 - Run project tests against modified POMs - Commit the modified POM - Tag the code in Subversion - Increment the version number and append SNAPSHOT. ie 1.0.3 becomes 1.0.4-SNAPSHOT - Commit modified POM Is there way where we could skip the last 2 steps i,e increment of the version number and appending the SNAPSHOT . In a way just want to convert the snapshot to a release,no further development version. Thanks Sundeep
Re: Maven release:prepare
Is there way where we could skip the last 2 steps i,e increment of the version number and appending the SNAPSHOT . In a way just want to convert the snapshot to a release,no further development version. I am unaware of any such configuration of the plugin which would permit this. But you could simply delete the unneeded pom file(s) from SCM and you'd have the same end result, right? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: copy selected dependencies transitively
Hello Ron, very valid and good point, thank you. I will describe my scenario: I have a pipeline of processing steps. Each step is performed by a component which is packaged into a maven artifact. As the components have been developed independently of each other, some of them share some dependencies - in different and possibly incompatible versions, however. Thus, I want to cut down the pipeline to sub-pipelines with non-colliding dependencies of the used components. Then, I can run the sub-pipelines in the correct order, each in its own JVM and the exact dependencies necessary. Each sub-pipeline operates on data stored in a database, modifies the data, and stores it back. This way the original pipeline can be broken down to these sub-pipelines. Still, the project I have in mind stores all parts which are necessary to perform the complete original pipeline. I could, of course, create a maven project for each sub-pipeline. But this would come with quite some overhead in the project management (multiple POMs with similar configurations, multiple projects in SVN which must be maintained and - for running - all checked out in a single manner...). So my thought was to just create lib-folders for the component artifacts used in each sub-pipeline. And for this I thought the copy-dependencies plugin could help me if I just could tell it to copy the dependencies of each component in its own folder (or one folder for multiple components forming a sub-pipeline). I hope that was understandable :-) Any ideas how I could reach my goals without turning to a complete new technology (OSGi or something)? I don't need the sub-piplines to run in parallel (on the contrary!), I just need the dependencies of each sub-pipeline in folders of their own. Thanks a lot for reading and helping! Erik Am 04.01.2013 um 21:57 schrieb Ron Wheeler rwhee...@artifact-software.com: What are you actually trying to do? Why do you need to do this? What makes your environment different from everyone else's operation? Perhaps there are easier ways to get what you want by reformulating the problem. Ron On 04/01/2013 11:17 AM, Erik Fäßler wrote: Hi all, my issue is no new one and I found some related posts - even on this list - already. But none of them has been answered, so I try my luck. What I want: Copy one (or multiple) selected dependency of my project into a directory of its own. That is, unlike the normal copy-dependencies execution which just copies all dependencies into a directory, I want to select only some of them. I tried it with includeArtifactIds like this: plugin artifactIdmaven-dependency-plugin/artifactId version2.6/version executions execution idCopy dependencies transitive/id phasepackage/phase goals goalcopy-dependencies/goal /goals configuration excludeTransitivefalse/excludeTransitive outputDirectorylib/outputDirectory includeArtifactIdsmyartifact/includeArtifactIds /configuration /execution /executions /plugin But here, the original meaning of includeArtifactIds is copy exactly the artifacts of the given IDs, nothing else, which also means that no transitive dependencies are copied. I stated explicitly excludeTransitivefalse/excludeTransitive but this seems to be ignored. Question: Is there another way to achieve what I need (copy selected artifacts along with their transitive dependencies into a folder of their own). Feature Request: I guess it wouldn't be too difficult to take the excludeTransitivefalse/excludeTransitive command into account and just copy the transitive dependencies in this case, would it? If this could be added, it would help me and I guess some other people out there. Thanks and best regards, Erik - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- 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,
AW: Maven release:prepare
Hi Sundeep,
I doubt you can skip the last 2 steps, but you could configure the plugin to
change the development version to exactly the same version as the release
version. Haven't tried this though:
mvn release:prepare -DreleaseVersion={release-version}
-DdevelopmentVersion={release-version}
The result should be the same as if the last two steps were skipped.
As I mentioned ... haven't actually tried this :-)
Chris
-Ursprüngliche Nachricht-
Von: Sundeep Reddy [mailto:sundeep.i...@gmail.com]
Gesendet: Samstag, 5. Januar 2013 13:30
An: users@maven.apache.org
Betreff: Maven release:prepare
Hi All,
The maven release:prepare does the following things:
release: prepare - Performs a number of operations
- Checks to make sure that there are no uncommitted changes.
- Ensures that there are no SNAPSHOT dependencies in the POM file,
- Changes the version of the application and removes SNAPSHOT from the
version. ie 1.0.3-SNAPSHOT becomes 1.0.3
- Run project tests against modified POMs
- Commit the modified POM
- Tag the code in Subversion
- Increment the version number and append SNAPSHOT. ie 1.0.3 becomes
1.0.4-SNAPSHOT
- Commit modified POM
Is there way where we could skip the last 2 steps i,e increment of the version
number and appending the SNAPSHOT . In a way just want to convert the snapshot
to a release,no further development version.
Thanks
Sundeep
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: AW: Maven release:prepare
Hi,
Since version 2.4 the developmentVersion MUST be a SNAPSHOT, so that trick
will fail nowadays.
I don't see any reason why to skip these last steps.
IMHO: in the tag the version must always be a non-SNAPSHOT, in both trunk
and branches the version should always be a SNAPSHOT (expect in that
twilight-period right before tagging...)
If you don't want to continue development on the project, it should have
been a branch, so it can be removed once tagged.
Robert
Op Sat, 05 Jan 2013 17:39:33 +0100 schreef christofer.d...@c-ware.de
christofer.d...@c-ware.de:
Hi Sundeep,
I doubt you can skip the last 2 steps, but you could configure the
plugin to change the development version to exactly the same version
as the release version. Haven't tried this though:
mvn release:prepare -DreleaseVersion={release-version}
-DdevelopmentVersion={release-version}
The result should be the same as if the last two steps were skipped.
As I mentioned ... haven't actually tried this :-)
Chris
-Ursprüngliche Nachricht-
Von: Sundeep Reddy [mailto:sundeep.i...@gmail.com]
Gesendet: Samstag, 5. Januar 2013 13:30
An: users@maven.apache.org
Betreff: Maven release:prepare
Hi All,
The maven release:prepare does the following things:
release: prepare - Performs a number of operations
- Checks to make sure that there are no uncommitted changes.
- Ensures that there are no SNAPSHOT dependencies in the POM file,
- Changes the version of the application and removes SNAPSHOT from the
version. ie 1.0.3-SNAPSHOT becomes 1.0.3
- Run project tests against modified POMs
- Commit the modified POM
- Tag the code in Subversion
- Increment the version number and append SNAPSHOT. ie 1.0.3 becomes
1.0.4-SNAPSHOT
- Commit modified POM
Is there way where we could skip the last 2 steps i,e increment of the
version number and appending the SNAPSHOT . In a way just want to
convert the snapshot to a release,no further development version.
Thanks
Sundeep
-
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: AW: Maven release:prepare
Does the versions-maven-plugin happen to have a goal for you here?
On Sat, Jan 5, 2013 at 12:01 PM, Robert Scholte rfscho...@apache.orgwrote:
Hi,
Since version 2.4 the developmentVersion MUST be a SNAPSHOT, so that trick
will fail nowadays.
I don't see any reason why to skip these last steps.
IMHO: in the tag the version must always be a non-SNAPSHOT, in both trunk
and branches the version should always be a SNAPSHOT (expect in that
twilight-period right before tagging...)
If you don't want to continue development on the project, it should have
been a branch, so it can be removed once tagged.
Robert
Op Sat, 05 Jan 2013 17:39:33 +0100 schreef christofer.d...@c-ware.de
christofer.d...@c-ware.de:
Hi Sundeep,
I doubt you can skip the last 2 steps, but you could configure the plugin
to change the development version to exactly the same version as the
release version. Haven't tried this though:
mvn release:prepare -DreleaseVersion={release-**version}
-DdevelopmentVersion={release-**version}
The result should be the same as if the last two steps were skipped.
As I mentioned ... haven't actually tried this :-)
Chris
-Ursprüngliche Nachricht-
Von: Sundeep Reddy [mailto:sundeep.i...@gmail.com**]
Gesendet: Samstag, 5. Januar 2013 13:30
An: users@maven.apache.org
Betreff: Maven release:prepare
Hi All,
The maven release:prepare does the following things:
release: prepare - Performs a number of operations
- Checks to make sure that there are no uncommitted changes.
- Ensures that there are no SNAPSHOT dependencies in the POM file,
- Changes the version of the application and removes SNAPSHOT from the
version. ie 1.0.3-SNAPSHOT becomes 1.0.3
- Run project tests against modified POMs
- Commit the modified POM
- Tag the code in Subversion
- Increment the version number and append SNAPSHOT. ie 1.0.3 becomes
1.0.4-SNAPSHOT
- Commit modified POM
Is there way where we could skip the last 2 steps i,e increment of the
version number and appending the SNAPSHOT . In a way just want to convert
the snapshot to a release,no further development version.
Thanks
Sundeep
--**--**-
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-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven release:prepare
the trick for such scenarios is easy: don't use the release-plugin. Am Samstag, den 05.01.2013, 13:29 +0100 schrieb Sundeep Reddy sundeep.i...@gmail.com: Hi All, The maven release:prepare does the following things: release: prepare – Performs a number of operations - Checks to make sure that there are no uncommitted changes. - Ensures that there are no SNAPSHOT dependencies in the POM file, - Changes the version of the application and removes SNAPSHOT from the version. ie 1.0.3-SNAPSHOT becomes 1.0.3 - Run project tests against modified POMs - Commit the modified POM - Tag the code in Subversion - Increment the version number and append SNAPSHOT. ie 1.0.3 becomes 1.0.4-SNAPSHOT - Commit modified POM Is there way where we could skip the last 2 steps i,e increment of the version number and appending the SNAPSHOT . In a way just want to convert the snapshot to a release,no further development version. Thanks Sundeep - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Attached artifacts and dependencies
Is it true attached artifacts, that is artifacts with a non-empty classifier, inherit their dependencies from the main artifact? Stated otherwise - is it possible to specify different set of dependencies for an attached artifact such that when included in another project, that different set of dependencies get resolved for it, instead of the dependencies declared for the main artifact? It doesn't really matter for many of the commonly attached artifacts like sources and javadoc, or the main set of dependencies is just fine for classes (of a WAR), but here are some cases it makes sens if the dependencies for an attached artifact could be specified differently from the main one: 1. jar-with-dependencies - an assembly packaging all required dependencies in the JAR, already. In this case no dependencies should be resolved for such an artifact, I guess; 2. client - such as produced by the EJB plugin [1]. In this case resolving all dependencies from the main implementation is not desired. Adding some runtime dependencies for the attached client, not declared for the main implementation, may be desired too. So is achieving different set of dependencies possible with using attached artifacts vs. just different artifacts? [1] http://maven.apache.org/plugins/maven-ejb-plugin/examples/ejb-client-dependency.html -- Stanimir - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Attached artifacts and dependencies
If the dependencies are not applicable for this artifact (e.g. the pom is not valid for it because it is generated against Maven convention) then it should not be an artifact in the same coordinates but rather be a different module with different GAV coordinates On Sat, January 5, 2013 2:34 pm, Stanimir Stamenkov wrote: Is it true attached artifacts, that is artifacts with a non-empty classifier, inherit their dependencies from the main artifact? Stated otherwise - is it possible to specify different set of dependencies for an attached artifact such that when included in another project, that different set of dependencies get resolved for it, instead of the dependencies declared for the main artifact? It doesn't really matter for many of the commonly attached artifacts like sources and javadoc, or the main set of dependencies is just fine for classes (of a WAR), but here are some cases it makes sens if the dependencies for an attached artifact could be specified differently from the main one: 1. jar-with-dependencies - an assembly packaging all required dependencies in the JAR, already. In this case no dependencies should be resolved for such an artifact, I guess; 2. client - such as produced by the EJB plugin [1]. In this case resolving all dependencies from the main implementation is not desired. Adding some runtime dependencies for the attached client, not declared for the main implementation, may be desired too. So is achieving different set of dependencies possible with using attached artifacts vs. just different artifacts? [1] http://maven.apache.org/plugins/maven-ejb-plugin/examples/ejb-client-dependency.html -- Stanimir - 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: Attached artifacts and dependencies
Sat, 5 Jan 2013 14:38:38 -0800, /Manfred Moser/: If the dependencies are not applicable for this artifact (e.g. the pom is not valid for it because it is generated against Maven convention) then it should not be an artifact in the same coordinates but rather be a different module with different GAV coordinates All right. That's pretty much what I've thought, but then revisit the EJB plugin case I've given: http://maven.apache.org/plugins/maven-ejb-plugin/examples/ejb-client-dependency.html Seems like not the best practice - why it has been introduced, then? -- Stanimir - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Attached artifacts and dependencies
On Sat, January 5, 2013 2:43 pm, Stanimir Stamenkov wrote: Sat, 5 Jan 2013 14:38:38 -0800, /Manfred Moser/: If the dependencies are not applicable for this artifact (e.g. the pom is not valid for it because it is generated against Maven convention) then it should not be an artifact in the same coordinates but rather be a different module with different GAV coordinates All right. That's pretty much what I've thought, but then revisit the EJB plugin case I've given: http://maven.apache.org/plugins/maven-ejb-plugin/examples/ejb-client-dependency.html Seems like not the best practice - why it has been introduced, then? A mistake? I don't know. But nothing stops you from having two modules with different coordinates for the ejb and the ejb client from what I understand.. but I have not used ejb for ages so I might be completely off. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Attached artifacts and dependencies
I always argue for having the API (e.g. ejb client) as a separate module and then the impl (e.g. the ejb) as a separate module. /Anders On Sat, Jan 5, 2013 at 11:45 PM, Manfred Moser manf...@mosabuam.com wrote: On Sat, January 5, 2013 2:43 pm, Stanimir Stamenkov wrote: Sat, 5 Jan 2013 14:38:38 -0800, /Manfred Moser/: If the dependencies are not applicable for this artifact (e.g. the pom is not valid for it because it is generated against Maven convention) then it should not be an artifact in the same coordinates but rather be a different module with different GAV coordinates All right. That's pretty much what I've thought, but then revisit the EJB plugin case I've given: http://maven.apache.org/plugins/maven-ejb-plugin/examples/ejb-client-dependency.html Seems like not the best practice - why it has been introduced, then? A mistake? I don't know. But nothing stops you from having two modules with different coordinates for the ejb and the ejb client from what I understand.. but I have not used ejb for ages so I might be completely off. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Attached artifacts and dependencies
Totally agree ++ On Sat, January 5, 2013 2:52 pm, Anders Hammar wrote: I always argue for having the API (e.g. ejb client) as a separate module and then the impl (e.g. the ejb) as a separate module. /Anders On Sat, Jan 5, 2013 at 11:45 PM, Manfred Moser manf...@mosabuam.com wrote: On Sat, January 5, 2013 2:43 pm, Stanimir Stamenkov wrote: Sat, 5 Jan 2013 14:38:38 -0800, /Manfred Moser/: If the dependencies are not applicable for this artifact (e.g. the pom is not valid for it because it is generated against Maven convention) then it should not be an artifact in the same coordinates but rather be a different module with different GAV coordinates All right. That's pretty much what I've thought, but then revisit the EJB plugin case I've given: http://maven.apache.org/plugins/maven-ejb-plugin/examples/ejb-client-dependency.html Seems like not the best practice - why it has been introduced, then? A mistake? I don't know. But nothing stops you from having two modules with different coordinates for the ejb and the ejb client from what I understand.. but I have not used ejb for ages so I might be completely off. manfred - 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: Attached artifacts and dependencies
Sat, 5 Jan 2013 23:52:50 +0100, /Anders Hammar/: I always argue for having the API (e.g. ejb client) as a separate module and then the impl (e.g. the ejb) as a separate module. That's what we're using after all, but I've recently discovered this ejb-client option and started wondering if there's something I'm missing about how things are supposed to work/be used. -- Stanimir - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
