Version Management
Hi Can Maven be used as a Version mangement tool? Is it possible to automate the Version management using Maven? Thanks and Regards Hemant Ved
Version management question
I recently asked the question below, but no answer.
I was wondering whether I really need to edit all pom.xml files in all
my project whenever I bump version numbers.
I'm still new at this, so if this is a trivial question, please bear
with me...
--
cg
Christian Goetze wrote:
Why can't I do this:
4.0.0
com.sensage
sensage
${sensage-version}
I do run "mvn -Dsensage-version=3.6"...
It works fine when I run from the top of the project down.
--
cg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Dependency version management
I'm thinking about moving all our version management into the parent pom in a dependencyManagement section, but I'm trying to figure out if it will really make things easier or not. Of course each version number would only be in one place instead of N places, where N is the avg # of reverse dependencies. So that is good. But when changing the version # of a component, you still have to update N places, to update them to the latest parent. That is, unless you are using a snapshot for the parent, but is that a normal/recommended practice? The problem I see with using a snapshot for the parent is it doesn't allow you to make changes in a safe way. I could update the version # of a lower component, and then a much higher component could build against that before all the middle components are built/deployed. This may not be a problem for Java or C#, but for C/C++ with headers and static libraries, it is a recipe for disaster. We're talking about things like inexplicable run-time crashes. By having version management in each pom itself, I can safely make a change to a lower component by upping the version # of its reverse dependencies at the same time I update them to use the new version of the lower component, and then follow that pattern as I go all the way up the chain of dependencies. Of course a continuous integration tool could be used to build all the reverse dependencies up the chain for you, and such a tool is much easier to set up when it doesn't have to worry about changing version #s in the pom, but that still leaves open a possible race condition. It could be only halfway through building/deploying all the components when a developer tries to build a high level component and runs into the problem I described. Some of our components take a long time to build, so there is a very real risk of this race condition. So I don't know if it is worth it. But maybe it is especially if it saves us time of building things manually (which we have to do now because I haven't found a tool that can kick off builds of reverse dependencies, and also up the version numbers along the way.) Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Version Management
Yes, Maven can be used as a Version management tool. The first time written POM file should have the version number and all other file can include a relative path for the versions later on. Thanks and Regards Vaishali G.P. | Cognizant Technology Solutions, Pune-India | PSTN: +9120 40051735 | VNet: 203735 | | "Your duty is to Be" And not to be this or that | -Original Message- From: Hemant Ved [mailto:[EMAIL PROTECTED] Sent: Thursday, August 16, 2007 4:29 PM To: [EMAIL PROTECTED] Subject: Version Management Hi Can Maven be used as a Version mangement tool? Is it possible to automate the Version management using Maven? Thanks and Regards Hemant Ved This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Version Management
Hi Hermant, No, Maven cannot be used as a Version management tool. Maven is a build tool, an advanced build tool. You can, however, interact with a version management tool (like Subversion) from within Maven, so that Maven performs checking in and checking out (commit and update) to and from Subversion for you as part of the automated build process. Regards Arne > -Original Message- > From: Hemant Ved [mailto:[EMAIL PROTECTED] > Sent: 16. august 2007 12:59 > To: [EMAIL PROTECTED] > Subject: Version Management > > Hi > > Can Maven be used as a Version mangement tool? Is it possible > to automate the Version management using Maven? > > > Thanks and Regards > Hemant Ved > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Version Management
What do you mean by "version management"? We do use maven to add specific tags at the end of project.xml with every Build something like following. 1.0.2 1.0.2 LGB_reFUEL_ServiceOrchestration_DEVGRP_dev_JAVA14_051018_2 1.1 1.1 LGB_reFUEL_ServiceOrchestration_QAGRP_test_JAVA14_051102_1 1.2 1.2 LGB_reFUEL_ServiceOrchestration_QAGRP_test_JAVA14_051115_2 1.3 1.3 LGB_reFUEL_ServiceOrchestration_QAGRP_test_JAVA14_051117_3 -Original Message- From: Hemant Ved [mailto:[EMAIL PROTECTED] Sent: Thursday, August 16, 2007 6:59 AM To: [EMAIL PROTECTED] Subject: Version Management Hi Can Maven be used as a Version mangement tool? Is it possible to automate the Version management using Maven? Thanks and Regards Hemant Ved * This message has originated from RLPTechnologies, 34405 W 12 Mile Road, Suite 343, Farmington Hills, MI 48331. If you do not wish to receive further e-mails regarding RLPTechnologies, please forward this e-mail to [EMAIL PROTECTED] with the word "remove" in the subject line. This e-mail message and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this message in error, please delete this message and notify the RLPTechnologies System Administrator at [EMAIL PROTECTED] * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version management question
This does not work.
If you think about it you can see why.
You would define 'sensage-version' in the parent pom and use it in all the
children. The problem is that as it is parsing the child pom, maven has to
find the parent. To do that, it looks in the section and has to use
the value of "sensage-version'.
Its a classic catch-22 situation. You can't find the parent without the
value of 'sensage-version' and you you can't find the value of
'sensage-versin' without the parent.
-- Lee
On 11/14/06, Christian Goetze <[EMAIL PROTECTED]> wrote:
I recently asked the question below, but no answer.
I was wondering whether I really need to edit all pom.xml files in all
my project whenever I bump version numbers.
I'm still new at this, so if this is a trivial question, please bear
with me...
--
cg
Christian Goetze wrote:
> Why can't I do this:
>
>
> 4.0.0
>
>
>
> com.sensage
> sensage
> ${sensage-version}
>
>
> I do run "mvn -Dsensage-version=3.6"...
>
> It works fine when I run from the top of the project down.
> --
> cg
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-- Lee Meador
Sent from gmail. My real email address is lee AT leemeador.com
Re: Version management question
Lee Meador wrote: This does not work. If you think about it you can see why. You would define 'sensage-version' in the parent pom and use it in all the children. The problem is that as it is parsing the child pom, maven has to find the parent. To do that, it looks in the section and has to use the value of "sensage-version'. Not really, since I pass in the value of sensage-version via a -D flag. Maven just refuses to resolve it within a ... section. Its a classic catch-22 situation. You can't find the parent without the value of 'sensage-version' and you you can't find the value of 'sensage-versin' without the parent. Yeah, I guess so... I'm wondering, though, why maven can't just go look in the parent directory for a pom.xml file and not require me to specify where the parent is - after all, maven has no qualms about imposing all sorts of directory structure conventions, so why not just go that extra step, or at least have a tag "use whatever is in the parent directory" Meanwhile, I guess I just need to live with having to manage all versions in all the pom.xml files by hand - sigh -. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Site plugin version management
Site:site says this over and over, in addition to running the javadoc over and over. INFO] Generating "Project License" report. [WARNING] Deprecated API called - not org.apache.maven.doxia.sink.Sink instance and no SinkFactory available. Please update this plugin. What should I be specifying, and where should I be specifying it (reporting versus plugin management). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency version management
On Mon, Feb 28, 2011 at 9:49 AM, Phillip Hellewell wrote: > The problem I see with using a snapshot for the parent is it doesn't > allow you to make changes in a safe way. I could update the version # > of a lower component, and then a much higher component could build > against that before all the middle components are built/deployed. > This may not be a problem for Java or C#, but for C/C++ with headers > and static libraries, it is a recipe for disaster. We're talking > about things like inexplicable run-time crashes. Actually, I just remember that with my version clash plugin in place, it will prevent this dangerous scenario. Instead, the higher components will get an error and not be able to build at all until the lower components have been built/deployed. So to prevent breaking all the builds right away, I need to update components to the latest parent from the bottom up, deploying as I go. In other words, I would end up doing pretty much the exact same thing I do now without using the parent for dependency management. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency version management
Our move to aggregation jars was our solution of this problem. We wanted central control over versions without a lot places to manage version numbers. For each application release, we decide what third versions of third party libraries will be used. If any of the libraries need changing we create the updated versions. We used to create new versions of all of the libraries but we stopped since it was a lot of work for nothing. The cost is that version 1.11.2 of the application depends on 1.9.1 of the CXF webservice libraries. We maintain a simple spreadsheet of components so that everyone knows what they are supposed call on as versions of the 5 or so dependencies that gives them their 60+ libraries required to build our application. We generally do not make or use SNAPSHOTs for these libraries so that simplifies the process. I hope that this helps. Ron On 28/02/2011 11:49 AM, Phillip Hellewell wrote: I'm thinking about moving all our version management into the parent pom in a dependencyManagement section, but I'm trying to figure out if it will really make things easier or not. Of course each version number would only be in one place instead of N places, where N is the avg # of reverse dependencies. So that is good. But when changing the version # of a component, you still have to update N places, to update them to the latest parent. That is, unless you are using a snapshot for the parent, but is that a normal/recommended practice? The problem I see with using a snapshot for the parent is it doesn't allow you to make changes in a safe way. I could update the version # of a lower component, and then a much higher component could build against that before all the middle components are built/deployed. This may not be a problem for Java or C#, but for C/C++ with headers and static libraries, it is a recipe for disaster. We're talking about things like inexplicable run-time crashes. By having version management in each pom itself, I can safely make a change to a lower component by upping the version # of its reverse dependencies at the same time I update them to use the new version of the lower component, and then follow that pattern as I go all the way up the chain of dependencies. Of course a continuous integration tool could be used to build all the reverse dependencies up the chain for you, and such a tool is much easier to set up when it doesn't have to worry about changing version #s in the pom, but that still leaves open a possible race condition. It could be only halfway through building/deploying all the components when a developer tries to build a high level component and runs into the problem I described. Some of our components take a long time to build, so there is a very real risk of this race condition. So I don't know if it is worth it. But maybe it is especially if it saves us time of building things manually (which we have to do now because I haven't found a tool that can kick off builds of reverse dependencies, and also up the version numbers along the way.) Phillip - 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: Dependency version management
Our move to aggregation jars was our solution of this problem. We wanted central control over versions without a lot places to manage version numbers. For each application release, we decide what third versions of third party libraries will be used. If any of the libraries need changing we create the updated versions. We used to create new versions of all of the libraries but we stopped since it was a lot of work for nothing. The cost is that version 1.11.2 of the application depends on 1.9.1 of our CXF webservice libraries(2.5.x I think) and 1.10.1 of our Spring, Hibernate, MySQL, Tomcat jar. We maintain a simple spreadsheet of components so that everyone knows what they are supposed call on as versions of the 5 or so dependencies that gives them their 60+ libraries required to build our application. We generally do not make or use SNAPSHOTs for these libraries so that simplifies the process. I hope that this helps. Ron On 28/02/2011 11:49 AM, Phillip Hellewell wrote: I'm thinking about moving all our version management into the parent pom in a dependencyManagement section, but I'm trying to figure out if it will really make things easier or not. Of course each version number would only be in one place instead of N places, where N is the avg # of reverse dependencies. So that is good. But when changing the version # of a component, you still have to update N places, to update them to the latest parent. That is, unless you are using a snapshot for the parent, but is that a normal/recommended practice? The problem I see with using a snapshot for the parent is it doesn't allow you to make changes in a safe way. I could update the version # of a lower component, and then a much higher component could build against that before all the middle components are built/deployed. This may not be a problem for Java or C#, but for C/C++ with headers and static libraries, it is a recipe for disaster. We're talking about things like inexplicable run-time crashes. By having version management in each pom itself, I can safely make a change to a lower component by upping the version # of its reverse dependencies at the same time I update them to use the new version of the lower component, and then follow that pattern as I go all the way up the chain of dependencies. Of course a continuous integration tool could be used to build all the reverse dependencies up the chain for you, and such a tool is much easier to set up when it doesn't have to worry about changing version #s in the pom, but that still leaves open a possible race condition. It could be only halfway through building/deploying all the components when a developer tries to build a high level component and runs into the problem I described. Some of our components take a long time to build, so there is a very real risk of this race condition. So I don't know if it is worth it. But maybe it is especially if it saves us time of building things manually (which we have to do now because I haven't found a tool that can kick off builds of reverse dependencies, and also up the version numbers along the way.) Phillip - 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: Dependency version management
Interesting ideas, thanks. By "aggregation jars" I assume you mean like intermediate components with no actual code but that serve to manage versions. I think that is a neat idea. Phillip On Mon, Feb 28, 2011 at 10:23 AM, Ron Wheeler wrote: > Our move to aggregation jars was our solution of this problem. > We wanted central control over versions without a lot places to manage > version numbers. > For each application release, we decide what third versions of third party > libraries will be used. > If any of the libraries need changing we create the updated versions. > > We used to create new versions of all of the libraries but we stopped since > it was a lot of work for nothing. > The cost is that version 1.11.2 of the application depends on 1.9.1 of the > CXF webservice libraries. > > We maintain a simple spreadsheet of components so that everyone knows what > they are supposed call on as versions of the 5 or so dependencies that gives > them their 60+ libraries required to build our application. > > We generally do not make or use SNAPSHOTs for these libraries so that > simplifies the process. > > I hope that this helps. > > Ron > > On 28/02/2011 11:49 AM, Phillip Hellewell wrote: >> >> I'm thinking about moving all our version management into the parent >> pom in a dependencyManagement section, but I'm trying to figure out if >> it will really make things easier or not. >> >> Of course each version number would only be in one place instead of N >> places, where N is the avg # of reverse dependencies. So that is >> good. But when changing the version # of a component, you still have >> to update N places, to update them to the latest parent. That is, >> unless you are using a snapshot for the parent, but is that a >> normal/recommended practice? >> >> The problem I see with using a snapshot for the parent is it doesn't >> allow you to make changes in a safe way. I could update the version # >> of a lower component, and then a much higher component could build >> against that before all the middle components are built/deployed. >> This may not be a problem for Java or C#, but for C/C++ with headers >> and static libraries, it is a recipe for disaster. We're talking >> about things like inexplicable run-time crashes. >> >> By having version management in each pom itself, I can safely make a >> change to a lower component by upping the version # of its reverse >> dependencies at the same time I update them to use the new version of >> the lower component, and then follow that pattern as I go all the way >> up the chain of dependencies. >> >> Of course a continuous integration tool could be used to build all the >> reverse dependencies up the chain for you, and such a tool is much >> easier to set up when it doesn't have to worry about changing version >> #s in the pom, but that still leaves open a possible race condition. >> It could be only halfway through building/deploying all the components >> when a developer tries to build a high level component and runs into >> the problem I described. >> >> Some of our components take a long time to build, so there is a very >> real risk of this race condition. So I don't know if it is worth it. >> But maybe it is especially if it saves us time of building things >> manually (which we have to do now because I haven't found a tool that >> can kick off builds of reverse dependencies, and also up the version >> numbers along the way.) >> >> Phillip >> >> - >> 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: Dependency version management
On 28/02/2011 2:39 PM, Phillip Hellewell wrote: Interesting ideas, thanks. By "aggregation jars" I assume you mean like intermediate components with no actual code but that serve to manage versions. I think that is a neat idea. As much I Iove being associated with a neat idea, I have to point out that we actually build jars with these 8 (6 third party code + 2 ours) POMs that we deploy as shareable libraries in Tomcat. The 34 war modules have these as "provided" dependencies which means that our war files are very small and only contain our code and resources (images can add a lot to a WAR). We have a lot of wars that are less than 50kb even with Spring, Hibernate, CXF, JSF This is really nice when dealing with something CXF which adds a huge amount of bytes to a WAR if it is not "provided". The total amount of bytes of JARS from our aggregated POMS is about 40MB in the Tomcat lib A couple of these JARs are our own utilities. I am not sure where this fits on the "neat" scale but it helps keep our dependencies under control and really speeds up builds and deploys. Ron Phillip On Mon, Feb 28, 2011 at 10:23 AM, Ron Wheeler wrote: Our move to aggregation jars was our solution of this problem. We wanted central control over versions without a lot places to manage version numbers. For each application release, we decide what third versions of third party libraries will be used. If any of the libraries need changing we create the updated versions. We used to create new versions of all of the libraries but we stopped since it was a lot of work for nothing. The cost is that version 1.11.2 of the application depends on 1.9.1 of the CXF webservice libraries. We maintain a simple spreadsheet of components so that everyone knows what they are supposed call on as versions of the 5 or so dependencies that gives them their 60+ libraries required to build our application. We generally do not make or use SNAPSHOTs for these libraries so that simplifies the process. I hope that this helps. Ron On 28/02/2011 11:49 AM, Phillip Hellewell wrote: I'm thinking about moving all our version management into the parent pom in a dependencyManagement section, but I'm trying to figure out if it will really make things easier or not. Of course each version number would only be in one place instead of N places, where N is the avg # of reverse dependencies. So that is good. But when changing the version # of a component, you still have to update N places, to update them to the latest parent. That is, unless you are using a snapshot for the parent, but is that a normal/recommended practice? The problem I see with using a snapshot for the parent is it doesn't allow you to make changes in a safe way. I could update the version # of a lower component, and then a much higher component could build against that before all the middle components are built/deployed. This may not be a problem for Java or C#, but for C/C++ with headers and static libraries, it is a recipe for disaster. We're talking about things like inexplicable run-time crashes. By having version management in each pom itself, I can safely make a change to a lower component by upping the version # of its reverse dependencies at the same time I update them to use the new version of the lower component, and then follow that pattern as I go all the way up the chain of dependencies. Of course a continuous integration tool could be used to build all the reverse dependencies up the chain for you, and such a tool is much easier to set up when it doesn't have to worry about changing version #s in the pom, but that still leaves open a possible race condition. It could be only halfway through building/deploying all the components when a developer tries to build a high level component and runs into the problem I described. Some of our components take a long time to build, so there is a very real risk of this race condition. So I don't know if it is worth it. But maybe it is especially if it saves us time of building things manually (which we have to do now because I haven't found a tool that can kick off builds of reverse dependencies, and also up the version numbers along the way.) Phillip - 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: Dependency version management
Hi Phillip, Phillip Hellewell wrote: > I'm thinking about moving all our version management into the parent > pom in a dependencyManagement section, but I'm trying to figure out if > it will really make things easier or not. > > Of course each version number would only be in one place instead of N > places, where N is the avg # of reverse dependencies. So that is > good. But when changing the version # of a component, you still have > to update N places, to update them to the latest parent. That is, > unless you are using a snapshot for the parent, but is that a > normal/recommended practice? We do this for years with a quite large project base. > The problem I see with using a snapshot for the parent is it doesn't > allow you to make changes in a safe way. I could update the version # > of a lower component, and then a much higher component could build > against that before all the middle components are built/deployed. > This may not be a problem for Java or C#, but for C/C++ with headers > and static libraries, it is a recipe for disaster. We're talking > about things like inexplicable run-time crashes. It's not as bad as it looks, because either the "higher" component is using an older released version of the parent - then it does not care about the newer stuff - or it is supposed to build against the lastest artifacts, then you need to build anything using the snapshot parent anyway. The only drawback is, that the developer that sets an own artifact to SNAPSHOT, should also do so with all the projects depending on it (at least with the ones that aggregate dependencies, i.e. ears, wars and ejbs if you use a classpath entry in the manifest). > By having version management in each pom itself, I can safely make a > change to a lower component by upping the version # of its reverse > dependencies at the same time I update them to use the new version of > the lower component, and then follow that pattern as I go all the way > up the chain of dependencies. Actually we're using a big property section in the parent for all artifacts (and plugins) managed in its dependency management. This has the nice effect, that if you are really in need of overwriting the version, you may simply redefine the version property. > Of course a continuous integration tool could be used to build all the > reverse dependencies up the chain for you, and such a tool is much > easier to set up when it doesn't have to worry about changing version > #s in the pom, but that still leaves open a possible race condition. > It could be only halfway through building/deploying all the components > when a developer tries to build a high level component and runs into > the problem I described. > > Some of our components take a long time to build, so there is a very > real risk of this race condition. So I don't know if it is worth it. > But maybe it is especially if it saves us time of building things > manually (which we have to do now because I haven't found a tool that > can kick off builds of reverse dependencies, and also up the version > numbers along the way.) The problem is that you need a CI tool that kicks those deps automatically. While most allow manual depednencies between build plans, I know currently none, that can interact with the fine grained dependency tree used by Maven. We have therefore "building blocks", e.g. all common libraries or individual projects. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Plug-in version management
Hi, I started to manage my dependency versions with and I am quite pleased on the outcome and control this configuration provides. We defined in a parent pom all dependency versions we are using in the section and in our sub-project we only define what we need to use but not the version. This has removed all questions about what version to use. Now I wonder if something similar is possible for plug-ins. Does it makes sense to define in a similar fashion the versions of plug-ins and then have the projects again just define the plug-in they need but not which version? Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven version management in ant
A while back, I stumbled across a page on the maven 2 site explaining how to use maven's nice dependency management from within ant. I can no longer find this link, has this functionality been abandoned or can someone reply with the url?
Parent, Modules and version management
Hello, I have a multimodules project (ProjectParent) with each module has a super pom's parent . See the figure: http://www.nabble.com/file/p25614127/Screen03.jpg (red : parent, blue : module) My problem is very simple. I can't manage the version of my modules from my multimodules project. I wish to have the same version in all modules and define this version in the ProjectParent. I look for this in a new plugin called versions (Codehaus), but I didn't find what I need. Has anybody a solution for this? Thank you very much, Emmanuel. -- View this message in context: http://www.nabble.com/Parent%2C-Modules-and-version-management-tp25614127p25614127.html Sent from the Maven - Users mailing list archive at Nabble.com.
Re: Site plugin version management
Did you google for it? http://jira.codehaus.org/browse/MSITE-490 Why the javadoc doesn't work I don't know... -Lukas Benson Margulies wrote: Site:site says this over and over, in addition to running the javadoc over and over. INFO] Generating "Project License" report. [WARNING] Deprecated API called - not org.apache.maven.doxia.sink.Sink instance and no SinkFactory available. Please update this plugin. What should I be specifying, and where should I be specifying it (reporting versus plugin management). - 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
Transitive dependencies and version management
Greetings, I was wondering if someone might be able to help with a Maven version management problem we've encountered. We have several interdependent, legacy Java projects, that have recently been re-cast as Maven projects. Now that we have the first iteration done, it's apparent that one salient characteristic of this particular group of projects is: there are about a half-dozen "front-end" projects that depend on an intermediate layer of several projects, which in turn depend on a rather large, "monolithic" type project at the back. For the sake of brevity, a set of projects A, depends (selectively) on a set of projects B, which in turn depend on a single project c (the monolithic one). A colleague would like to be able to increment the version number of project c, then recompile the set of projects A, without having to re-specify c's prerequisite version number occurrences in each pom.xml file of each (intermediate level) project in B each time project c's version is incremented. This would almost surely be desired only in development, and not in a test or production environment. Could anyone tell me if there is an intrinsic Maven feature that could be employed here? The present, proposed solution to the problem is to declare the of each of c's dependency declarations in each B project's pom.xml as "provided", but I am uneasy with this. For example, what if someone wanted to compile a project in B in isolation from the projects in A? Thanks very much, -- Andy Halper USGS WMA Software Engineering 520 N Park Ave Ste 221 Tucson AZ 85719
Version Management in 'mvn dependency:tree'
Hello, Recently, I attempted to use ‘mvn dependency:tree’ to retrieve the project's dependency tree. However, in the output, I noticed that for the same dependency with different scopes, its version doesn't appear to be consistent. The specific scenario is as follows: (org.checkerframework:checker-qual:jar:3.5.0:compile - scope updated from runtime; omitted for duplicate) org.checkerframework:checker-qual:jar:3.12.0:compile I made sure that these two pieces of information are present in the dependency tree of the same JAR. However, in the compilation information, I found that the first entry was hidden, and only the second entry was displayed. I'm curious about what happened here. In the actual compilation process, were both versions utilized, or was only the first version used? Additionally, I attempted to remove the existing dependency package of version 3.5.0 and recompile the project. Surprisingly, even after removing the 3.5.0 version dependency package, Maven still downloads and utilizes it. Does this indicate that the project is still using the 3.5.0 version of the dependency package? Of course, I need to add a clarification: the 3.5.0 version of the dependency package is an indirect dependency of the project, while version 3.12.0 is a direct dependency. Best regards, Yukai zhao
Re: Plug-in version management
On 9/23/06, Andreas Guther <[EMAIL PROTECTED]> wrote: Hi, I started to manage my dependency versions with and I am quite pleased on the outcome and control this configuration provides. We defined in a parent pom all dependency versions we are using in the section and in our sub-project we only define what we need to use but not the version. This has removed all questions about what version to use. Now I wonder if something similar is possible for plug-ins. Does it makes sense to define in a similar fashion the versions of plug-ins and then have the projects again just define the plug-in they need but not which version? Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plug-in version management
Cool! How could I miss that? I am deeply impressed about all those great details Maven provides. The more I use Maven the more I figure out how little I still know about Maven. Thanks for your fast response. Andreas -Original Message- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Saturday, September 23, 2006 6:30 PM To: Maven Users List Subject: Re: Plug-in version management On 9/23/06, Andreas Guther <[EMAIL PROTECTED]> wrote: > > Hi, > > I started to manage my dependency versions with > and I am quite pleased on the outcome and control this configuration > provides. > > We defined in a parent pom all dependency versions we are using in the > section and in our sub-project we only define > what we need to use but not the version. This has removed all questions > about what version to use. > > Now I wonder if something similar is possible for plug-ins. > > Does it makes sense to define in a similar fashion the versions of > plug-ins and then have the projects again just define the plug-in they > need but not which version? > > Andreas > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plug-in version management
The next question now is: Does this work for reporting as well? I looked at reporting but that does not have a pluginManagement section. Andreas -Original Message- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Saturday, September 23, 2006 6:30 PM To: Maven Users List Subject: Re: Plug-in version management On 9/23/06, Andreas Guther <[EMAIL PROTECTED]> wrote: > > Hi, > > I started to manage my dependency versions with > and I am quite pleased on the outcome and control this configuration > provides. > > We defined in a parent pom all dependency versions we are using in the > section and in our sub-project we only define > what we need to use but not the version. This has removed all questions > about what version to use. > > Now I wonder if something similar is possible for plug-ins. > > Does it makes sense to define in a similar fashion the versions of > plug-ins and then have the projects again just define the plug-in they > need but not which version? > > Andreas > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plug-in version management
http://jira.codehaus.org/browse/MNG-1931 you should have given the search a try ;) On 9/23/06, Andreas Guther <[EMAIL PROTECTED]> wrote: The next question now is: Does this work for reporting as well? I looked at reporting but that does not have a pluginManagement section. Andreas -Original Message- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Saturday, September 23, 2006 6:30 PM To: Maven Users List Subject: Re: Plug-in version management On 9/23/06, Andreas Guther <[EMAIL PROTECTED]> wrote: > > Hi, > > I started to manage my dependency versions with > and I am quite pleased on the outcome and control this configuration > provides. > > We defined in a parent pom all dependency versions we are using in the > section and in our sub-project we only define > what we need to use but not the version. This has removed all questions > about what version to use. > > Now I wonder if something similar is possible for plug-ins. > > Does it makes sense to define in a similar fashion the versions of > plug-ins and then have the projects again just define the plug-in they > need but not which version? > > Andreas > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plug-in version management
Should have :) As it turns out sometimes jira contains more helpful information than the official documentation. Thanks for your help. Andreas -Original Message- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Saturday, September 23, 2006 6:55 PM To: Maven Users List Subject: Re: Plug-in version management http://jira.codehaus.org/browse/MNG-1931 you should have given the search a try ;) On 9/23/06, Andreas Guther <[EMAIL PROTECTED]> wrote: > > The next question now is: > > Does this work for reporting as well? I looked at reporting but that > does not have a pluginManagement section. > > Andreas > > > -Original Message- > From: dan tran [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 23, 2006 6:30 PM > To: Maven Users List > Subject: Re: Plug-in version management > > > > > > > On 9/23/06, Andreas Guther <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I started to manage my dependency versions with > > and I am quite pleased on the outcome and control this configuration > > provides. > > > > We defined in a parent pom all dependency versions we are using in the > > section and in our sub-project we only define > > what we need to use but not the version. This has removed all > questions > > about what version to use. > > > > Now I wonder if something similar is possible for plug-ins. > > > > Does it makes sense to define in a similar fashion the versions of > > plug-ins and then have the projects again just define the plug-in they > > need but not which version? > > > > Andreas > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plug-in version management
actually I googled it with "reportManagement" ;-) On 9/24/06, Andreas Guther <[EMAIL PROTECTED]> wrote: Should have :) As it turns out sometimes jira contains more helpful information than the official documentation. Thanks for your help. Andreas -Original Message- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Saturday, September 23, 2006 6:55 PM To: Maven Users List Subject: Re: Plug-in version management http://jira.codehaus.org/browse/MNG-1931 you should have given the search a try ;) On 9/23/06, Andreas Guther <[EMAIL PROTECTED]> wrote: > > The next question now is: > > Does this work for reporting as well? I looked at reporting but that > does not have a pluginManagement section. > > Andreas > > > -Original Message- > From: dan tran [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 23, 2006 6:30 PM > To: Maven Users List > Subject: Re: Plug-in version management > > > > > > > On 9/23/06, Andreas Guther <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I started to manage my dependency versions with > > and I am quite pleased on the outcome and control this configuration > > provides. > > > > We defined in a parent pom all dependency versions we are using in the > > section and in our sub-project we only define > > what we need to use but not the version. This has removed all > questions > > about what version to use. > > > > Now I wonder if something similar is possible for plug-ins. > > > > Does it makes sense to define in a similar fashion the versions of > > plug-ins and then have the projects again just define the plug-in they > > need but not which version? > > > > Andreas > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven version management in ant
On 12/26/06, EJ Ciramella <[EMAIL PROTECTED]> wrote: A while back, I stumbled across a page on the maven 2 site explaining how to use maven's nice dependency management from within ant. I can no longer find this link, has this functionality been abandoned or can someone reply with the url? This? http://maven.apache.org/ant-tasks.html (It's linked from the Maven home page, at the top right under 'Maven Tasks for Ant'.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven version management in ant
That's it - thank you! -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 26, 2006 1:53 PM To: Maven Users List Subject: Re: maven version management in ant On 12/26/06, EJ Ciramella <[EMAIL PROTECTED]> wrote: > A while back, I stumbled across a page on the maven 2 site explaining > how to use maven's nice dependency management from within ant. > > I can no longer find this link, has this functionality been abandoned or > can someone reply with the url? This? http://maven.apache.org/ant-tasks.html (It's linked from the Maven home page, at the top right under 'Maven Tasks for Ant'.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven version management in ant
I'm trying this out with a VERY simple example (download one dependency), but I'm getting this: BUILD FAILED java.lang.NoSuchMethodError at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1225) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut or.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) --- Nested Exception --- java.lang.NoSuchMethodError at org.codehaus.plexus.component.configurator.ComponentConfigurationExcepti on.(ComponentConfigurationException.java:24) at org.codehaus.plexus.component.configurator.converters.basic.IntConverter .fromString(IntConverter.java:46) at org.codehaus.plexus.component.configurator.converters.basic.AbstractBasi cConverter.fromConfiguration(AbstractBasicConverter.java:61) at org.codehaus.plexus.component.configurator.converters.ComponentValueSett er.configure(ComponentValueSetter.java:207) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWi thFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:1 37) at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.co nfigureComponent(BasicComponentConfigurator.java:56) at org.codehaus.plexus.component.configurator.AbstractComponentConfigurator .configureComponent(AbstractComponentConfigurator.java:54) at org.codehaus.plexus.component.configurator.AbstractComponentConfigurator .configureComponent(AbstractComponentConfigurator.java:47) at org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhas e.execute(AutoConfigurePhase.java:39) at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLif ecycleHandler.java:101) at org.codehaus.plexus.component.manager.AbstractComponentManager.startComp onentLifecycle(AbstractComponentManager.java:105) at org.codehaus.plexus.component.manager.AbstractComponentManager.createCom ponentInstance(AbstractComponentManager.java:95) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.g etComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer .java:331) at org.codehaus.plexus.DefaultPlexusContainer.initializeLoggerManager(Defau ltPlexusContainer.java:1204) at org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusConta iner.java:642) at org.codehaus.plexus.embed.Embedder.start(Embedder.java:216) at org.codehaus.plexus.embed.Embedder.start(Embedder.java:183) at org.apache.maven.artifact.ant.AbstractArtifactTask.getEmbedder(AbstractA rtifactTask.java:312) at org.apache.maven.artifact.ant.AbstractArtifactTask.lookup(AbstractArtifa ctTask.java:276) at org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRe pository(AbstractArtifactTask.java:78) at org.apache.maven.artifact.ant.DependenciesTask.doExecute(DependenciesTas k.java:75) at org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtif actTask.java:451) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut or.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) Total time: 0 seconds Any suggestions? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 26, 2006 4:14 PM To: Maven Users List Subject: RE: maven version management in ant That's it - thank you! -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 26, 2006 1:53 PM To: Maven Users List Subject: Re: maven version management in ant On 12/26/06, EJ Ciramella <[EMAIL PROTECTED]> wrote: > A while back, I stumbled across a page on the maven 2 site explaining > how to use maven's nice dependency management from with
RE: maven version management in ant
Sorry - I'm building with jdk 1.5.1 now and this is gone. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 03, 2007 1:03 PM To: Maven Users List Subject: RE: maven version management in ant I'm trying this out with a VERY simple example (download one dependency), but I'm getting this: BUILD FAILED java.lang.NoSuchMethodError at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1225) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut or.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) --- Nested Exception --- java.lang.NoSuchMethodError at org.codehaus.plexus.component.configurator.ComponentConfigurationExcepti on.(ComponentConfigurationException.java:24) at org.codehaus.plexus.component.configurator.converters.basic.IntConverter .fromString(IntConverter.java:46) at org.codehaus.plexus.component.configurator.converters.basic.AbstractBasi cConverter.fromConfiguration(AbstractBasicConverter.java:61) at org.codehaus.plexus.component.configurator.converters.ComponentValueSett er.configure(ComponentValueSetter.java:207) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWi thFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:1 37) at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.co nfigureComponent(BasicComponentConfigurator.java:56) at org.codehaus.plexus.component.configurator.AbstractComponentConfigurator .configureComponent(AbstractComponentConfigurator.java:54) at org.codehaus.plexus.component.configurator.AbstractComponentConfigurator .configureComponent(AbstractComponentConfigurator.java:47) at org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhas e.execute(AutoConfigurePhase.java:39) at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLif ecycleHandler.java:101) at org.codehaus.plexus.component.manager.AbstractComponentManager.startComp onentLifecycle(AbstractComponentManager.java:105) at org.codehaus.plexus.component.manager.AbstractComponentManager.createCom ponentInstance(AbstractComponentManager.java:95) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.g etComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer .java:331) at org.codehaus.plexus.DefaultPlexusContainer.initializeLoggerManager(Defau ltPlexusContainer.java:1204) at org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusConta iner.java:642) at org.codehaus.plexus.embed.Embedder.start(Embedder.java:216) at org.codehaus.plexus.embed.Embedder.start(Embedder.java:183) at org.apache.maven.artifact.ant.AbstractArtifactTask.getEmbedder(AbstractA rtifactTask.java:312) at org.apache.maven.artifact.ant.AbstractArtifactTask.lookup(AbstractArtifa ctTask.java:276) at org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRe pository(AbstractArtifactTask.java:78) at org.apache.maven.artifact.ant.DependenciesTask.doExecute(DependenciesTas k.java:75) at org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtif actTask.java:451) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut or.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) Total time: 0 seconds Any suggestions? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 26, 2006 4:14 PM To: Maven Users List Subject: RE: maven version management in ant That's it - thank you! -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 26, 2006 1:53 PM To: Maven Users Lis
RE: maven version management in ant
New question, so I'm loading via a pom.xml file, how can I reference the
classpath (filled with dependencies)?
The version is ${project.version}
${project.build.directory}
???
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 3:49 PM
To: Maven Users List
Subject: RE: maven version management in ant
Sorry - I'm building with jdk 1.5.1 now and this is gone.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 1:03 PM
To: Maven Users List
Subject: RE: maven version management in ant
I'm trying this out with a VERY simple example (download one
dependency), but I'm getting this:
BUILD FAILED
java.lang.NoSuchMethodError
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1225)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut
or.java:40)
at
org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
--- Nested Exception ---
java.lang.NoSuchMethodError
at
org.codehaus.plexus.component.configurator.ComponentConfigurationExcepti
on.(ComponentConfigurationException.java:24)
at
org.codehaus.plexus.component.configurator.converters.basic.IntConverter
.fromString(IntConverter.java:46)
at
org.codehaus.plexus.component.configurator.converters.basic.AbstractBasi
cConverter.fromConfiguration(AbstractBasicConverter.java:61)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSett
er.configure(ComponentValueSetter.java:207)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWi
thFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:1
37)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.co
nfigureComponent(BasicComponentConfigurator.java:56)
at
org.codehaus.plexus.component.configurator.AbstractComponentConfigurator
.configureComponent(AbstractComponentConfigurator.java:54)
at
org.codehaus.plexus.component.configurator.AbstractComponentConfigurator
.configureComponent(AbstractComponentConfigurator.java:47)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhas
e.execute(AutoConfigurePhase.java:39)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLif
ecycleHandler.java:101)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComp
onentLifecycle(AbstractComponentManager.java:105)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createCom
ponentInstance(AbstractComponentManager.java:95)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.g
etComponent(ClassicSingletonComponentManager.java:92)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer
.java:331)
at
org.codehaus.plexus.DefaultPlexusContainer.initializeLoggerManager(Defau
ltPlexusContainer.java:1204)
at
org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusConta
iner.java:642)
at org.codehaus.plexus.embed.Embedder.start(Embedder.java:216)
at org.codehaus.plexus.embed.Embedder.start(Embedder.java:183)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.getEmbedder(AbstractA
rtifactTask.java:312)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.lookup(AbstractArtifa
ctTask.java:276)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRe
pository(AbstractArtifactTask.java:78)
at
org.apache.maven.artifact.ant.DependenciesTask.doExecute(DependenciesTas
k.java:75)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtif
actTask.java:451)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut
or.java:40)
at
org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.
RE: maven version management in ant
I made it a bit further:
The version is ${project.version}
${project.build.directory}
${project.name}
${project.dependencies}
Is the actual classpath used for compiling unavailable to ant as a
property?
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 2:07 PM
To: Maven Users List
Subject: RE: maven version management in ant
New question, so I'm loading via a pom.xml file, how can I reference the
classpath (filled with dependencies)?
The version is ${project.version}
${project.build.directory}
???
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 3:49 PM
To: Maven Users List
Subject: RE: maven version management in ant
Sorry - I'm building with jdk 1.5.1 now and this is gone.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 1:03 PM
To: Maven Users List
Subject: RE: maven version management in ant
I'm trying this out with a VERY simple example (download one
dependency), but I'm getting this:
BUILD FAILED
java.lang.NoSuchMethodError
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1225)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut
or.java:40)
at
org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
--- Nested Exception ---
java.lang.NoSuchMethodError
at
org.codehaus.plexus.component.configurator.ComponentConfigurationExcepti
on.(ComponentConfigurationException.java:24)
at
org.codehaus.plexus.component.configurator.converters.basic.IntConverter
.fromString(IntConverter.java:46)
at
org.codehaus.plexus.component.configurator.converters.basic.AbstractBasi
cConverter.fromConfiguration(AbstractBasicConverter.java:61)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSett
er.configure(ComponentValueSetter.java:207)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWi
thFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:1
37)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.co
nfigureComponent(BasicComponentConfigurator.java:56)
at
org.codehaus.plexus.component.configurator.AbstractComponentConfigurator
.configureComponent(AbstractComponentConfigurator.java:54)
at
org.codehaus.plexus.component.configurator.AbstractComponentConfigurator
.configureComponent(AbstractComponentConfigurator.java:47)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhas
e.execute(AutoConfigurePhase.java:39)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLif
ecycleHandler.java:101)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComp
onentLifecycle(AbstractComponentManager.java:105)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createCom
ponentInstance(AbstractComponentManager.java:95)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.g
etComponent(ClassicSingletonComponentManager.java:92)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer
.java:331)
at
org.codehaus.plexus.DefaultPlexusContainer.initializeLoggerManager(Defau
ltPlexusContainer.java:1204)
at
org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusConta
iner.java:642)
at org.codehaus.plexus.embed.Embedder.start(Embedder.java:216)
at org.codehaus.plexus.embed.Embedder.start(Embedder.java:183)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.getEmbedder(AbstractA
rtifactTask.java:312)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.lookup(AbstractArtifa
ctTask.java:276)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRe
pository(AbstractArtifactTask.java:78)
at
org.apache.maven.artifact.ant.DependenciesTask.doExecute(DependenciesTas
k.java:75)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtif
actTask.java:451)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at
org.apache.tools.ant.Project.
RE: maven version management in ant
Bump - I could really use some feed back here people, this has me
completely wedged...
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 3:56 PM
To: Maven Users List
Subject: RE: maven version management in ant
I made it a bit further:
The version is ${project.version}
${project.build.directory}
${project.name}
${project.dependencies}
Is the actual classpath used for compiling unavailable to ant as a
property?
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 2:07 PM
To: Maven Users List
Subject: RE: maven version management in ant
New question, so I'm loading via a pom.xml file, how can I reference the
classpath (filled with dependencies)?
The version is ${project.version}
${project.build.directory}
???
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 3:49 PM
To: Maven Users List
Subject: RE: maven version management in ant
Sorry - I'm building with jdk 1.5.1 now and this is gone.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 1:03 PM
To: Maven Users List
Subject: RE: maven version management in ant
I'm trying this out with a VERY simple example (download one
dependency), but I'm getting this:
BUILD FAILED
java.lang.NoSuchMethodError
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1225)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut
or.java:40)
at
org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
--- Nested Exception ---
java.lang.NoSuchMethodError
at
org.codehaus.plexus.component.configurator.ComponentConfigurationExcepti
on.(ComponentConfigurationException.java:24)
at
org.codehaus.plexus.component.configurator.converters.basic.IntConverter
.fromString(IntConverter.java:46)
at
org.codehaus.plexus.component.configurator.converters.basic.AbstractBasi
cConverter.fromConfiguration(AbstractBasicConverter.java:61)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSett
er.configure(ComponentValueSetter.java:207)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWi
thFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:1
37)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.co
nfigureComponent(BasicComponentConfigurator.java:56)
at
org.codehaus.plexus.component.configurator.AbstractComponentConfigurator
.configureComponent(AbstractComponentConfigurator.java:54)
at
org.codehaus.plexus.component.configurator.AbstractComponentConfigurator
.configureComponent(AbstractComponentConfigurator.java:47)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhas
e.execute(AutoConfigurePhase.java:39)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLif
ecycleHandler.java:101)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComp
onentLifecycle(AbstractComponentManager.java:105)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createCom
ponentInstance(AbstractComponentManager.java:95)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.g
etComponent(ClassicSingletonComponentManager.java:92)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer
.java:331)
at
org.codehaus.plexus.DefaultPlexusContainer.initializeLoggerManager(Defau
ltPlexusContainer.java:1204)
at
org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusConta
iner.java:642)
at org.codehaus.plexus.embed.Embedder.start(Embedder.java:216)
at org.codehaus.plexus.embed.Embedder.start(Embedder.java:183)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.getEmbedder(AbstractA
rtifactTask.java:312)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.lookup(AbstractArtifa
ctTask.java:276)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRe
pository(AbstractArtifactTask.java:78)
at
org.apache.maven.artifact.ant.DependenciesTask.doExecute(DependenciesTas
k.java:75)
at
org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtif
actTask.java:451)
at
org.apache.tools.ant.Un
RE: maven version management in ant
EJ:
Unsure if it's the same in maven2, but "maven.dependency.classpath" contained
dependencies in m1.
I have a feeling you'll have to splice maven.compile.classpath in with it,
though.
http://wiki.astrogrid.org/bin/view/Astrogrid/UsefulMavenNotes#How_to_find_out_what_is_actually
HTH
Barrett
::
Barrett Nuzum
Consultant, Skill Development
Direct: 918.640.4414
Fax: 972.789.1340
Valtech Technologies, Inc.
5080 Spectrum Drive
Suite 700 West
Addison, Texas 75001
www.valtech.com <http://www.valtech.com>
making IT business friendly
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Mon 1/8/2007 8:19 AM
To: Maven Users List
Subject: RE: maven version management in ant
Bump - I could really use some feed back here people, this has me
completely wedged...
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 3:56 PM
To: Maven Users List
Subject: RE: maven version management in ant
I made it a bit further:
The version is ${project.version}
${project.build.directory}
${project.name}
${project.dependencies}
Is the actual classpath used for compiling unavailable to ant as a
property?
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 2:07 PM
To: Maven Users List
Subject: RE: maven version management in ant
New question, so I'm loading via a pom.xml file, how can I reference the
classpath (filled with dependencies)?
The version is ${project.version}
${project.build.directory}
???
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 3:49 PM
To: Maven Users List
Subject: RE: maven version management in ant
Sorry - I'm building with jdk 1.5.1 now and this is gone.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 1:03 PM
To: Maven Users List
Subject: RE: maven version management in ant
I'm trying this out with a VERY simple example (download one
dependency), but I'm getting this:
BUILD FAILED
java.lang.NoSuchMethodError
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1225)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut
or.java:40)
at
org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
--- Nested Exception ---
java.lang.NoSuchMethodError
at
org.codehaus.plexus.component.configurator.ComponentConfigurationExcepti
on.(ComponentConfigurationException.java:24)
at
org.codehaus.plexus.component.configurator.converters.basic.IntConverter
.fromString(IntConverter.java:46)
at
org.codehaus.plexus.component.configurator.converters.basic.AbstractBasi
cConverter.fromConfiguration(AbstractBasicConverter.java:61)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSett
er.configure(ComponentValueSetter.java:207)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWi
thFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:1
37)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.co
nfigureComponent(BasicComponentConfigurator.java:56)
at
org.codehaus.plexus.component.configurator.AbstractComponentConfigurator
.configureComponent(AbstractComponentConfigurator.java:54)
at
org.codehaus.plexus.component.configurator.AbstractComponentConfigurator
.configureComponent(AbstractComponentConfigurator.java:47)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhas
e.execute(AutoConfigurePhase.java:39)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLif
ecycleHandler.java:101)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComp
onentLifecycle(AbstractComponentManager.java:105)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createCom
ponentInstance(AbstractComponentManager.java:95)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.g
etComponent(ClassicSingletonComponentManager.java:92)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer
.java:331)
at
org.codehaus.plexus.DefaultPlexusContainer.initializeLoggerManager(Defau
ltPlexusContainer.java:1204)
at
org.codehaus.plexus.DefaultPlexusContainer.initializ
RE: maven version management in ant
FWIW
snippet of working maven pom.xml and ant build.xml
# pom.xml partial
[snip]
maven-antrun-plugin
pre-site
pom.xml: timestamp ${TODAY_UK}
run
[snip]
# build.xml
[snip]
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Monday, January 08, 2007 6:19 AM
To: Maven Users List
Subject: RE: maven version management in ant
Bump - I could really use some feed back here people, this has me
completely wedged...
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 3:56 PM
To: Maven Users List
Subject: RE: maven version management in ant
I made it a bit further:
The version is ${project.version}
${project.build.directory}
${project.name}
${project.dependencies}
Is the actual classpath used for compiling unavailable to ant as a
property?
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 2:07 PM
To: Maven Users List
Subject: RE: maven version management in ant
New question, so I'm loading via a pom.xml file, how can I reference the
classpath (filled with dependencies)?
The version is ${project.version}
${project.build.directory}
???
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 3:49 PM
To: Maven Users List
Subject: RE: maven version management in ant
Sorry - I'm building with jdk 1.5.1 now and this is gone.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 1:03 PM
To: Maven Users List
Subject: RE: maven version management in ant
I'm trying this out with a VERY simple example (download one
dependency), but I'm getting this:
BUILD FAILED
java.lang.NoSuchMethodError
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1225)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut
or.java:40)
at
org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
--- Nested Exception ---
java.lang.NoSuchMethodError
at
org.codehaus.plexus.component.configurator.ComponentConfigurationExcepti
on.(ComponentConfigurationException.java:24)
at
org.codehaus.plexus.component.configurator.converters.basic.IntConverter
.fromString(IntConverter.java:46)
at
org.codehaus.plexus.component.configurator.converters.basic.AbstractBasi
cConverter.fromConfiguration(AbstractBasicConverter.java:61)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSett
er.configure(ComponentValueSetter.java:207)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWi
thFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:1
37)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.co
nfigureComponent(BasicComponentConfigurator.java:56)
at
org.codehaus.plexus.component.configurator.AbstractComponentConfigurator
.configureComponent(AbstractComponentConfigurator.java:54)
at
org.codehaus.plexus.component.configurator.AbstractComponentConfigurator
.configureComponent(AbstractComponentConfigurator.java:47)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhas
e.execute(AutoConfigurePhase.java:39)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLif
ecycleHandler.java:101)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComp
onentLifecycle(AbstractComponentManager.java:105)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createCom
ponentInstance(AbstractComponentManager.java:95)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.g
etComponent(ClassicSingletonComponentManager.java:92)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer
.java:331)
at
org.codehaus.plexus.DefaultPlexusContainer.initializeLoggerManager(Defau
ltPlexusContainer.j
RE: maven version management in ant
This is a bit backward, I'm using ant to build and maven to manage
dependencies.
See:
http://maven.apache.org/ant-tasks.html
-Original Message-
From: Sean Hennessy [mailto:[EMAIL PROTECTED]
Sent: Monday, January 08, 2007 1:30 PM
To: Maven Users List
Subject: RE: maven version management in ant
FWIW
snippet of working maven pom.xml and ant build.xml
# pom.xml partial
[snip]
maven-antrun-plugin
pre-site
pom.xml: timestamp ${TODAY_UK}
run
[snip]
# build.xml
[snip]
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Monday, January 08, 2007 6:19 AM
To: Maven Users List
Subject: RE: maven version management in ant
Bump - I could really use some feed back here people, this has me
completely wedged...
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 3:56 PM
To: Maven Users List
Subject: RE: maven version management in ant
I made it a bit further:
The version is ${project.version}
${project.build.directory}
${project.name}
${project.dependencies}
Is the actual classpath used for compiling unavailable to ant as a
property?
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 2:07 PM
To: Maven Users List
Subject: RE: maven version management in ant
New question, so I'm loading via a pom.xml file, how can I reference the
classpath (filled with dependencies)?
The version is ${project.version}
${project.build.directory}
???
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 3:49 PM
To: Maven Users List
Subject: RE: maven version management in ant
Sorry - I'm building with jdk 1.5.1 now and this is gone.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 1:03 PM
To: Maven Users List
Subject: RE: maven version management in ant
I'm trying this out with a VERY simple example (download one
dependency), but I'm getting this:
BUILD FAILED
java.lang.NoSuchMethodError
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1225)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut
or.java:40)
at
org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
--- Nested Exception ---
java.lang.NoSuchMethodError
at
org.codehaus.plexus.component.configurator.ComponentConfigurationExcepti
on.(ComponentConfigurationException.java:24)
at
org.codehaus.plexus.component.configurator.converters.basic.IntConverter
.fromString(IntConverter.java:46)
at
org.codehaus.plexus.component.configurator.converters.basic.AbstractBasi
cConverter.fromConfiguration(AbstractBasicConverter.java:61)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSett
er.configure(ComponentValueSetter.java:207)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWi
thFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:1
37)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.co
nfigureComponent(BasicComponentConfigurator.java:56)
at
org.codehaus.plexus.component.configurator.AbstractComponentConfigurator
.configureComponent(AbstractComponentConfigurator.java:54)
at
org.codehaus.plexus.component.configurator.AbstractComponentConfigurator
.configureComponent(AbstractComponentConfigurator.java:47)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhas
e.execute(AutoConfigurePhase.java:39)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLif
ecycleHandler.java:101)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComp
onentLifecycle(AbstractComponentManager.java:105)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createCom
ponentInstance(AbstractComponentManager.java:95)
at
org.codehaus.plexus.component.manager.ClassicSingletonCompo
RE: maven version management in ant
All of these are blank:
${maven.dependency.classpath}
${maven.compile.classpath}
${maven.runtime.classpath}
${maven.test.classpath}
${maven.plugin.classpath}
Here is my full target:
The version is ${project.version}
${project.build.directory}
${project.name}
${project.dependencies}
${maven.dependency.classpath}
${maven.compile.classpath}
${maven.runtime.classpath}
${maven.test.classpath}
${maven.plugin.classpath}
As a crappy hack, from:
I can use that as a fileset to copy from the m2 repository to some local
folder for building (and then I'll just include anything in that
folder).
But this stinks as when we have 10 projects, these dependent jars will
be all over the place.
This feels like a bug and limited functionality when using the following
technique to build with ant and manage dependencies with maven2:
-Original Message-
From: Barrett Nuzum [mailto:[EMAIL PROTECTED]
Sent: Monday, January 08, 2007 11:10 AM
To: Maven Users List
Subject: RE: maven version management in ant
EJ:
Unsure if it's the same in maven2, but "maven.dependency.classpath"
contained dependencies in m1.
I have a feeling you'll have to splice maven.compile.classpath in with
it, though.
http://wiki.astrogrid.org/bin/view/Astrogrid/UsefulMavenNotes#How_to_fin
d_out_what_is_actually
HTH
Barrett
::
Barrett Nuzum
Consultant, Skill Development
Direct: 918.640.4414
Fax: 972.789.1340
Valtech Technologies, Inc.
5080 Spectrum Drive
Suite 700 West
Addison, Texas 75001
www.valtech.com <http://www.valtech.com>
making IT business friendly
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Mon 1/8/2007 8:19 AM
To: Maven Users List
Subject: RE: maven version management in ant
Bump - I could really use some feed back here people, this has me
completely wedged...
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 3:56 PM
To: Maven Users List
Subject: RE: maven version management in ant
I made it a bit further:
The version is ${project.version}
${project.build.directory}
${project.name}
${project.dependencies}
Is the actual classpath used for compiling unavailable to ant as a
property?
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 2:07 PM
To: Maven Users List
Subject: RE: maven version management in ant
New question, so I'm loading via a pom.xml file, how can I reference the
classpath (filled with dependencies)?
The version is ${project.version}
${project.build.directory}
???
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 3:49 PM
To: Maven Users List
Subject: RE: maven version management in ant
Sorry - I'm building with jdk 1.5.1 now and this is gone.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 03, 2007 1:03 PM
To: Maven Users List
Subject: RE: maven version management in ant
I'm trying this out with a VERY simple example (download one
dependency), but I'm getting this:
BUILD FAILED
java.lang.NoSuchMethodError
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1225)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut
or.java:40)
at
org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
--- Nested Exception ---
java.lang.NoSuchMethodError
at
org.codehaus.plexus.component.configurator.ComponentConfigurationExcepti
on.(ComponentConfigurationException.java:24)
at
org.codehaus.plexus.component.configurator.converters.basic.IntConverter
.fromString(IntConverter.java:46)
at
org.codehaus.plexus.component.configurator.converters.basic.AbstractBasi
cConverter.fromConfiguration(AbstractBasicConverter.java:61)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSett
er.configure(ComponentValueSetter.java:207)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWi
thFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:1
37)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.co
nfigureComponent(BasicComponentConfigurator.java:56)
at
org.codehaus.plexus.c
RE: maven version management in ant
Perhaps I'm not following, but how is the my.compile.dependency.fileset
different from what you want? Unless you really wanted a path reference,
in which case you replace filesetId with pathId. Or you want that in a
property? Then add:
Am I missing something here?
Chris
> -Original Message-
> From: EJ Ciramella [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 09 January, 2007 09:24
> To: Maven Users List
> Subject: RE: maven version management in ant
>
> All of these are blank:
> ${maven.dependency.classpath}
> ${maven.compile.classpath}
> ${maven.runtime.classpath}
> ${maven.test.classpath}
> ${maven.plugin.classpath}
>
> Here is my full target:
>
>
>
> filesetId="my.compile.dependency.fileset"
> usescope="compile" verbose="true">
>
>
> The version is ${project.version}
> ${project.build.directory}
> ${project.name}
> ${project.dependencies}
> ${maven.dependency.classpath}
> ${maven.compile.classpath}
> ${maven.runtime.classpath}
> ${maven.test.classpath}
> ${maven.plugin.classpath}
>
>
>
> As a crappy hack, from:
>
> filesetId="my.compile.dependency.fileset"
> usescope="compile" verbose="true">
>
>
>
> I can use that as a fileset to copy from the m2 repository to
> some local folder for building (and then I'll just include
> anything in that folder).
>
> But this stinks as when we have 10 projects, these dependent
> jars will be all over the place.
>
> This feels like a bug and limited functionality when using
> the following technique to build with ant and manage
> dependencies with maven2:
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
> -Original Message-
> From: Barrett Nuzum [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 08, 2007 11:10 AM
> To: Maven Users List
> Subject: RE: maven version management in ant
>
> EJ:
>
> Unsure if it's the same in maven2, but "maven.dependency.classpath"
> contained dependencies in m1.
> I have a feeling you'll have to splice
> maven.compile.classpath in with it, though.
>
> http://wiki.astrogrid.org/bin/view/Astrogrid/UsefulMavenNotes#
> How_to_fin
> d_out_what_is_actually
>
> HTH
>
> Barrett
>
> ::
> Barrett Nuzum
> Consultant, Skill Development
> Direct: 918.640.4414
> Fax: 972.789.1340
>
> Valtech Technologies, Inc.
> 5080 Spectrum Drive
> Suite 700 West
> Addison, Texas 75001
> www.valtech.com <http://www.valtech.com>
> making IT business friendly
>
>
>
>
> From: EJ Ciramella [mailto:[EMAIL PROTECTED]
> Sent: Mon 1/8/2007 8:19 AM
> To: Maven Users List
> Subject: RE: maven version management in ant
>
>
>
> Bump - I could really use some feed back here people, this
> has me completely wedged...
>
> -Original Message-
> From: EJ Ciramella [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 05, 2007 3:56 PM
> To: Maven Users List
> Subject: RE: maven version management in ant
>
> I made it a bit further:
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
>
>
> The version is ${project.version}
> ${project.build.directory}
> ${project.name}
> ${project.dependencies}
>
>
>
>
>
> destdir="target/classes"
> includes="**/*.java"
> classpathref="maven.project.classpath"
> debug="on"
> />
>
>
> Is the actual classpath used for compiling unavailable to ant
> as a property?
>
> -Original Message-
> From: EJ Ciramella [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 05, 2007 2:07 PM
> To: Maven Users List
> Subject: RE: maven version management in ant
>
> New question, so I'm loading via a pom.xml file, how can I
> reference the classpath (filled with dependencies)?
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
>
>
> The version is ${project.version}
> ${project.build.directory}
>
>
>
>
>
> destdir="target/classes"
> includes="**/*.java"
> classpathref="maven.project.classpath"
> debug="on"
> />
RE: maven version management in ant
That seems to be working!
Thank you so much for this!
How was one to know that pathId existed?
-Original Message-
From: Chris Hilton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 09, 2007 11:16 AM
To: Maven Users List
Subject: RE: maven version management in ant
Perhaps I'm not following, but how is the my.compile.dependency.fileset
different from what you want? Unless you really wanted a path reference,
in which case you replace filesetId with pathId. Or you want that in a
property? Then add:
Am I missing something here?
Chris
> -Original Message-
> From: EJ Ciramella [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 09 January, 2007 09:24
> To: Maven Users List
> Subject: RE: maven version management in ant
>
> All of these are blank:
> ${maven.dependency.classpath}
> ${maven.compile.classpath}
> ${maven.runtime.classpath}
> ${maven.test.classpath}
> ${maven.plugin.classpath}
>
> Here is my full target:
>
>
>
> filesetId="my.compile.dependency.fileset"
> usescope="compile" verbose="true">
>
>
> The version is ${project.version}
> ${project.build.directory}
> ${project.name}
> ${project.dependencies}
> ${maven.dependency.classpath}
> ${maven.compile.classpath}
> ${maven.runtime.classpath}
> ${maven.test.classpath}
> ${maven.plugin.classpath}
>
>
>
> As a crappy hack, from:
>
> filesetId="my.compile.dependency.fileset"
> usescope="compile" verbose="true">
>
>
>
> I can use that as a fileset to copy from the m2 repository to
> some local folder for building (and then I'll just include
> anything in that folder).
>
> But this stinks as when we have 10 projects, these dependent
> jars will be all over the place.
>
> This feels like a bug and limited functionality when using
> the following technique to build with ant and manage
> dependencies with maven2:
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
> -Original Message-
> From: Barrett Nuzum [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 08, 2007 11:10 AM
> To: Maven Users List
> Subject: RE: maven version management in ant
>
> EJ:
>
> Unsure if it's the same in maven2, but "maven.dependency.classpath"
> contained dependencies in m1.
> I have a feeling you'll have to splice
> maven.compile.classpath in with it, though.
>
> http://wiki.astrogrid.org/bin/view/Astrogrid/UsefulMavenNotes#
> How_to_fin
> d_out_what_is_actually
>
> HTH
>
> Barrett
>
> ::
> Barrett Nuzum
> Consultant, Skill Development
> Direct: 918.640.4414
> Fax: 972.789.1340
>
> Valtech Technologies, Inc.
> 5080 Spectrum Drive
> Suite 700 West
> Addison, Texas 75001
> www.valtech.com <http://www.valtech.com>
> making IT business friendly
>
>
>
>
> From: EJ Ciramella [mailto:[EMAIL PROTECTED]
> Sent: Mon 1/8/2007 8:19 AM
> To: Maven Users List
> Subject: RE: maven version management in ant
>
>
>
> Bump - I could really use some feed back here people, this
> has me completely wedged...
>
> -Original Message-
> From: EJ Ciramella [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 05, 2007 3:56 PM
> To: Maven Users List
> Subject: RE: maven version management in ant
>
> I made it a bit further:
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
>
>
> The version is ${project.version}
> ${project.build.directory}
> ${project.name}
> ${project.dependencies}
>
>
>
>
>
> destdir="target/classes"
> includes="**/*.java"
> classpathref="maven.project.classpath"
> debug="on"
> />
>
>
> Is the actual classpath used for compiling unavailable to ant
> as a property?
>
> -Original Message-
> From: EJ Ciramella [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 05, 2007 2:07 PM
> To: Maven Users List
> Subject: RE: maven version management in ant
>
> New question, so I'm loading via a pom.xml file, how can I
> reference the classpath (filled with dependencies)?
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
>
>
> The version is ${project.version}
> ${project.build.directory}
>
RE: maven version management in ant
It is in the docs, but a second set of eyes never hurt.
http://maven.apache.org/ant-tasks.html
Glad I could help.
Chris
> -Original Message-
> From: EJ Ciramella [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 09 January, 2007 12:26
> To: Maven Users List
> Subject: RE: maven version management in ant
>
> That seems to be working!
>
> Thank you so much for this!
>
> How was one to know that pathId existed?
>
> -Original Message-
> From: Chris Hilton [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 09, 2007 11:16 AM
> To: Maven Users List
> Subject: RE: maven version management in ant
>
> Perhaps I'm not following, but how is the
> my.compile.dependency.fileset different from what you want?
> Unless you really wanted a path reference, in which case you
> replace filesetId with pathId. Or you want that in a
> property? Then add:
>
> refid="my.compile.dependency.fileset"/>
>
> Am I missing something here?
>
> Chris
>
> > -Original Message-
> > From: EJ Ciramella [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, 09 January, 2007 09:24
> > To: Maven Users List
> > Subject: RE: maven version management in ant
> >
> > All of these are blank:
> > ${maven.dependency.classpath}
> > ${maven.compile.classpath}
> > ${maven.runtime.classpath}
> > ${maven.test.classpath}
> > ${maven.plugin.classpath}
> >
> > Here is my full target:
> >
> >
> >
> > > filesetId="my.compile.dependency.fileset"
> > usescope="compile" verbose="true">
> >
> >
> > The version is ${project.version}
> > ${project.build.directory}
> > ${project.name}
> > ${project.dependencies}
> > ${maven.dependency.classpath}
> > ${maven.compile.classpath}
> > ${maven.runtime.classpath}
> > ${maven.test.classpath}
> > ${maven.plugin.classpath}
> >
> >
> >
> > As a crappy hack, from:
> >
> > > filesetId="my.compile.dependency.fileset"
> > usescope="compile" verbose="true">
> >
> >
> >
> > I can use that as a fileset to copy from the m2 repository to some
> > local folder for building (and then I'll just include
> anything in that
> > folder).
> >
> > But this stinks as when we have 10 projects, these
> dependent jars will
> > be all over the place.
> >
> > This feels like a bug and limited functionality when using the
> > following technique to build with ant and manage dependencies with
> > maven2:
> >
> > > xmlns:artifact="antlib:org.apache.maven.artifact.ant">
> >
> > -Original Message-
> > From: Barrett Nuzum [mailto:[EMAIL PROTECTED]
> > Sent: Monday, January 08, 2007 11:10 AM
> > To: Maven Users List
> > Subject: RE: maven version management in ant
> >
> > EJ:
> >
> > Unsure if it's the same in maven2, but "maven.dependency.classpath"
> > contained dependencies in m1.
> > I have a feeling you'll have to splice
> maven.compile.classpath in with
> > it, though.
> >
> > http://wiki.astrogrid.org/bin/view/Astrogrid/UsefulMavenNotes#
> > How_to_fin
> > d_out_what_is_actually
> >
> > HTH
> >
> > Barrett
> >
> > ::
> > Barrett Nuzum
> > Consultant, Skill Development
> > Direct: 918.640.4414
> > Fax: 972.789.1340
> >
> > Valtech Technologies, Inc.
> > 5080 Spectrum Drive
> > Suite 700 West
> > Addison, Texas 75001
> > www.valtech.com <http://www.valtech.com>
> > making IT business friendly
> >
> >
> >
> >
> > From: EJ Ciramella [mailto:[EMAIL PROTECTED]
> > Sent: Mon 1/8/2007 8:19 AM
> > To: Maven Users List
> > Subject: RE: maven version management in ant
> >
> >
> >
> > Bump - I could really use some feed back here people, this has me
> > completely wedged...
> >
> > -Original Message-
> > From: EJ Ciramella [mailto:[EMAIL PROTECTED]
> > Sent: Friday, January 05, 2007 3:56 PM
> > To: Maven Users List
> > Subject: RE: maven version management in ant
> >
> > I made it a bit further:
> >
> > > xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
Re: Parent, Modules and version management
Hi Jeff, Thank you for your answer. The problem is that I can't change parent poms because it's enterprise poms. My poms inherit from them to respect enterprise archictecture choices. Emmanuel. Jeff MAURY wrote: > > From my experience with Maven, I discourage using properties for > defining pom version, Maven does handle it correctly on some cases, > even if the properties are defined on the parent pom > > I recommand using version herited from the parent and updating the > parent version with the version plugin > Jeff MAURY > > -- View this message in context: http://www.nabble.com/Parent%2C-Modules-and-version-management-tp25614127p25625561.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: Parent, Modules and version management
In that case, I don't understand where the versions of your projects are defined because if the parents are enterprise pom, you are not allowed to modify them !!! Jeff On Sat, Sep 26, 2009 at 4:06 PM, Emmanuel24 wrote: > > Hi Jeff, > > Thank you for your answer. The problem is that I can't change parent poms > because it's enterprise poms. My poms inherit from them to respect > enterprise archictecture choices. > > Emmanuel. > > > > Jeff MAURY wrote: > > > > From my experience with Maven, I discourage using properties for > > defining pom version, Maven does handle it correctly on some cases, > > even if the properties are defined on the parent pom > > > > I recommand using version herited from the parent and updating the > > parent version with the version plugin > > Jeff MAURY > > > > > > -- > View this message in context: > http://www.nabble.com/Parent%2C-Modules-and-version-management-tp25614127p25625561.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 > > -- La mélancolie c’est communiste Tout le monde y a droit de temps en temps La mélancolie n’est pas capitaliste C’est même gratuit pour les perdants La mélancolie c’est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c’est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal
Re: Parent, Modules and version management
>From my experience with Maven, I discourage using properties for defining pom version, Maven does handle it correctly on some cases, even if the properties are defined on the parent pom I recommand using version herited from the parent and updating the parent version with the version plugin Jeff MAURY On Friday, September 25, 2009, Emmanuel24 wrote: > > Hello, > > > I have a multimodules project (ProjectParent) with each module has a super > pom's parent . > > See the figure: > > > http://www.nabble.com/file/p25614127/Screen03.jpg > > (red : parent, blue : module) > > > My problem is very simple. I can't manage the version of my modules from my > multimodules project. I wish to have the same version in all modules and > define this version in the ProjectParent. > > > I look for this in a new plugin called versions (Codehaus), but I didn't > find what I need. > > > > Has anybody a solution for this? > > > Thank you very much, > > Emmanuel. > -- > View this message in context: > http://www.nabble.com/Parent%2C-Modules-and-version-management-tp25614127p25614127.html > Sent from the Maven - Users mailing list archive at Nabble.com. > -- La mélancolie c’est communiste Tout le monde y a droit de temps en temps La mélancolie n’est pas capitaliste C’est même gratuit pour les perdants La mélancolie c’est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c’est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Parent, Modules and version management
As I said, I define the version in ProjectParent and in this project, I defined my modules as the figure shows it. But my modules don't inherit from this project. That is the problem. Emmanuel. jeffma...@jeffmaury.com wrote: > > In that case, I don't understand where the versions of your projects are > defined because if the parents are enterprise pom, you are not allowed to > modify them !!! > > Jeff > > -- View this message in context: http://www.nabble.com/Parent%2C-Modules-and-version-management-tp25614127p25627113.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: Parent, Modules and version management
In that case, you're stuck and the release plugin will do the job but don't use properties to define versions. I think a certain version of Maven allows to import a pom into another. Regards Jeff On Sat, Sep 26, 2009 at 7:09 PM, Emmanuel24 wrote: > > As I said, I define the version in ProjectParent and in this project, I > defined my modules as the figure shows it. > But my modules don't inherit from this project. That is the problem. > > Emmanuel. > > > > jeffma...@jeffmaury.com wrote: > > > > In that case, I don't understand where the versions of your projects are > > defined because if the parents are enterprise pom, you are not allowed to > > modify them !!! > > > > Jeff > > > > > > -- > View this message in context: > http://www.nabble.com/Parent%2C-Modules-and-version-management-tp25614127p25627113.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 > > -- La mélancolie c’est communiste Tout le monde y a droit de temps en temps La mélancolie n’est pas capitaliste C’est même gratuit pour les perdants La mélancolie c’est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c’est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal
LATEST and RELEASE release version management
We use Maven in an enterprise environment and internally we are required to execute "release" builds whenever we want to install to our testing environment. We have found that executing many release builds can be tedious when we have in-development snapshot dependencies that also have to be released. We don't mind doing the releases, but the manual version update -- release -- revert version cycle is a chore. I was hoping that Maven could simplify this by allowing a project to declare a dependency on LATEST or 1.0-LATEST and have the maven release plugin resolve this to the actual latest released version available in the repository. The subsequent fully resolved pom would then be uploaded to the internal repository and the pom left in source control still references LATEST. Does maven already support something like this or would others find this useful? Peter Hayes Architecture & Shared Technology Services | Fidelity Investments Management Technology
Re: Transitive dependencies and version management
Have you considered using snapshot versions for C? If both A and B depend on a snapshot, they will automatically take the latest version in the repository. https://stackoverflow.com/questions/5901378/what-exactly-is-a-maven-snapshot-and-why-do-we-need-it#5901460 > On Aug 17, 2017, at 8:34 PM, Halper, Andrew wrote: > > Greetings, > > I was wondering if someone might be able to help with a Maven version > management problem we've encountered. > > We have several interdependent, legacy Java projects, that have recently > been re-cast as Maven projects. Now that we have the first iteration done, > it's apparent that one salient characteristic of this particular group of > projects is: there are about a half-dozen "front-end" projects that depend > on an intermediate layer of several projects, which in turn depend on a > rather large, "monolithic" type project at the back. For the sake of > brevity, a set of projects A, depends (selectively) on a set of projects B, > which in turn depend on a single project c (the monolithic one). > > A colleague would like to be able to increment the version number of > project c, then recompile the set of projects A, without having to > re-specify c's prerequisite version number occurrences in each pom.xml file > of each (intermediate level) project in B each time project c's version is > incremented. This would almost surely be desired only in development, and > not in a test or production environment. > > Could anyone tell me if there is an intrinsic Maven feature that could be > employed here? The present, proposed solution to the problem is to declare > the of each of c's dependency declarations in each B project's > pom.xml as "provided", but I am uneasy with this. For example, what if > someone wanted to compile a project in B in isolation from the projects in > A? > > Thanks very much, > -- > Andy Halper > USGS WMA Software Engineering > 520 N Park Ave Ste 221 > Tucson AZ 85719 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Transitive dependencies and version management
What you would do is that you specify the version of C in dependencyManagement of A. When you then build A, the specified version of C will be used regardless of what version is specified in B. However, for thsi to work in runtime this requires the specified version of C to be compatible with the version that B was compiled with. I very often, when talking to developers, run into the thinking that (using your naming) B needs to be re-release whenever there is a new version of C. You don't have to do that but you could handle that in A using dependencyManagement. Also, if you utilize api modules and impl modules you could do this even more beautifully by having B depend on an API artifact which doesn't change that often. /Anders On Fri, Aug 18, 2017 at 2:34 AM, Halper, Andrew wrote: > Greetings, > > I was wondering if someone might be able to help with a Maven version > management problem we've encountered. > > We have several interdependent, legacy Java projects, that have recently > been re-cast as Maven projects. Now that we have the first iteration done, > it's apparent that one salient characteristic of this particular group of > projects is: there are about a half-dozen "front-end" projects that depend > on an intermediate layer of several projects, which in turn depend on a > rather large, "monolithic" type project at the back. For the sake of > brevity, a set of projects A, depends (selectively) on a set of projects B, > which in turn depend on a single project c (the monolithic one). > > A colleague would like to be able to increment the version number of > project c, then recompile the set of projects A, without having to > re-specify c's prerequisite version number occurrences in each pom.xml file > of each (intermediate level) project in B each time project c's version is > incremented. This would almost surely be desired only in development, and > not in a test or production environment. > > Could anyone tell me if there is an intrinsic Maven feature that could be > employed here? The present, proposed solution to the problem is to declare > the of each of c's dependency declarations in each B project's > pom.xml as "provided", but I am uneasy with this. For example, what if > someone wanted to compile a project in B in isolation from the projects in > A? > > Thanks very much, > -- > Andy Halper > USGS WMA Software Engineering > 520 N Park Ave Ste 221 > Tucson AZ 85719 >
RE: Version Management in 'mvn dependency:tree'
Can't quite make sense of all this; given that you got no replies, maybe no one else understood either. Could you explain a bit better? -Original Message- From: yukai zhao Sent: Monday, October 30, 2023 9:10 PM To: users@maven.apache.org Subject: Version Management in 'mvn dependency:tree' CAUTION: This email originated from outside our organisation - yukz...@163.com Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. Hello, Recently, I attempted to use 'mvn dependency:tree' to retrieve the project's dependency tree. However, in the output, I noticed that for the same dependency with different scopes, its version doesn't appear to be consistent. The specific scenario is as follows: (org.checkerframework:checker-qual:jar:3.5.0:compile - scope updated from runtime; omitted for duplicate) org.checkerframework:checker-qual:jar:3.12.0:compile I made sure that these two pieces of information are present in the dependency tree of the same JAR. However, in the compilation information, I found that the first entry was hidden, and only the second entry was displayed. I'm curious about what happened here. In the actual compilation process, were both versions utilized, or was only the first version used? Additionally, I attempted to remove the existing dependency package of version 3.5.0 and recompile the project. Surprisingly, even after removing the 3.5.0 version dependency package, Maven still downloads and utilizes it. Does this indicate that the project is still using the 3.5.0 version of the dependency package? Of course, I need to add a clarification: the 3.5.0 version of the dependency package is an indirect dependency of the project, while version 3.12.0 is a direct dependency. Best regards, Yukai zhao This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com. __ If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. __ For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. __ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version Management in 'mvn dependency:tree'
On Tue, Oct 31, 2023 at 11:27 AM wrote: > Can't quite make sense of all this; given that you got no replies, maybe > no one else understood either. I second this sentiment. All I could tell is it seems like there's some confusion about interpreting the dependency:tree output, and perhaps confusion on how dependency convergence works, or how a project should specify dependency versions. See https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html for an overview.
Re: Version Management in 'mvn dependency:tree'
On Wednesday, 1. November 2023, 06:37:31 CET yukai zhao wrote: > Thank you for your response! > Additionally, I've noticed that in this situation, if I delete 3.12.0 from > my local repository and then recompile the project, Maven still downloads > 3.12.0. Is this behavior normal? In this case, yes, because the core of Maven 3.9.4 is actually *using* this version when you run it. This has nothing to do with the classpath of a project where you're using maven-core as dependency. Regards, Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: LATEST and RELEASE release version management
Hayes, Peter wrote: > We use Maven in an enterprise environment and internally we are required > to execute "release" builds whenever we want to install to our testing > environment. We have found that executing many release builds can be > tedious when we have in-development snapshot dependencies that also have > to be released. We don't mind doing the releases, but the manual > version update -- release -- revert version cycle is a chore. > > I was hoping that Maven could simplify this by allowing a project to > declare a dependency on LATEST or 1.0-LATEST and have the maven release > plugin resolve this to the actual latest released version available in > the repository. The subsequent fully resolved pom would then be > uploaded to the internal repository and the pom left in source control > still references LATEST. > > Does maven already support something like this or would others find this > useful? Having a LATEST concept would be very useful for something like continuous integration builds, where the desire is for a project to depend on the latest version of another project (release or snapshot), rather than a specific version of another project, so that you can see what errors have been introduced or that should be allowed for. Having said that, it makes no sense to have the release plugin care about LATEST, because by definition, building against LATEST isn't repeatable, and in order for there to be a release, you need the build to be repeatable. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: LATEST and RELEASE release version management
rtf1uqccPrltQ.rtf Description: RTF file smime.p7s Description: S/MIME cryptographic signature
Re: LATEST and RELEASE release version management
If you are prepared to run maven multiple times as part of your CI build you could achieve some of what you are looking for with the versions-maven-plugin. step 1. use versions-maven-plugin to update the pom to the latest releases of all dependencies step 2. use maven-scm-plugin to commit the modified poms back to scm step 3. use maven-release-plugin to release the ci build (the following 2 steps are optional) step 4. use versions-maven-plugin to update the pom to the next snapshots of all dependencies step 5 . use maven-scm-plugin to commit the modified poms back to scm ok, so you're ci build will auto-generate tags... but if you root ci generated tags in a special ci-tags directory and only do these 3/5 step builds nightlly it should be less of an SCM churn -Stephen 2009/4/6 Hayes, Peter > Graham Leggett wrote: > > >Having said that, it makes no sense to have the release plugin care > >about LATEST, because by definition, building against LATEST isn't > >repeatable, and in order for there to be a release, you need the build > >to be repeatable. > > I think this does impact the release plugin as it could offer the ability > to resolve the LATEST version at release time. These builds would be > reproducible because the release plugin tags the poms during the release > process. > > I think what you're saying is that the build prior to the release build is > not guaranteed to have the same dependent artifacts as the release build. I > care about the release build being reproducible. > > Pete >
RE: LATEST and RELEASE release version management
Having the release plugin translate these values at release time _before_ the validation build and tag is the only sane way to use them. I currently have never use them because they aren't repeatable. From: Hayes, Peter [mailto:peter.ha...@fmr.com] Sent: Monday, April 06, 2009 12:12 PM To: Maven Users List Subject: RE: LATEST and RELEASE release version management Graham Leggett wrote: >Having said that, it makes no sense to have the release plugin care >about LATEST, because by definition, building against LATEST isn't >repeatable, and in order for there to be a release, you need the build >to be repeatable. I think this does impact the release plugin as it could offer the ability to resolve the LATEST version at release time. These builds would be reproducible because the release plugin tags the poms during the release process. I think what you're saying is that the build prior to the release build is not guaranteed to have the same dependent artifacts as the release build. I care about the release build being reproducible. Pete
Re: LATEST and RELEASE release version management
http://jira.codehaus.org/browse/MNG-4089 I need to read over the bug that was linked as a duplicate more closely but I don't think it's the same thing. What I asked for was the same as what you said with 1.0-LATEST. Doing something like that or 1.0-RELEASE would actually be very beneficial to people that know that minor releases won't break backwards compatibility but will allow for more features without having to keep changing versions. On Mon, Apr 6, 2009 at 6:29 PM, Brian E. Fox wrote: > Having the release plugin translate these values at release time > _before_ the validation build and tag is the only sane way to use them. > I currently have never use them because they aren't repeatable. > > > > From: Hayes, Peter [mailto:peter.ha...@fmr.com] > Sent: Monday, April 06, 2009 12:12 PM > To: Maven Users List > Subject: RE: LATEST and RELEASE release version management > > > > Graham Leggett wrote: > > >Having said that, it makes no sense to have the release plugin care > >about LATEST, because by definition, building against LATEST isn't > >repeatable, and in order for there to be a release, you need the build > >to be repeatable. > > I think this does impact the release plugin as it could offer the > ability to resolve the LATEST version at release time. These builds > would be reproducible because the release plugin tags the poms during > the release process. > > I think what you're saying is that the build prior to the release build > is not guaranteed to have the same dependent artifacts as the release > build. I care about the release build being reproducible. > > Pete > > -- Emo Philips <http://www.brainyquote.com/quotes/authors/e/emo_philips.html> - "A computer once beat me at chess, but it was no match for me at kick boxing."
Re: LATEST and RELEASE release version management
sounds like you want version ranges [1.0,2.0-!) Sent from my [rhymes with myPod] ;-) On 8 Apr 2009, at 01:39, Tim wrote: http://jira.codehaus.org/browse/MNG-4089 I need to read over the bug that was linked as a duplicate more closely but I don't think it's the same thing. What I asked for was the same as what you said with 1.0-LATEST. Doing something like that or 1.0-RELEASE would actually be very beneficial to people that know that minor releases won't break backwards compatibility but will allow for more features without having to keep changing versions. On Mon, Apr 6, 2009 at 6:29 PM, Brian E. Fox wrote: Having the release plugin translate these values at release time _before_ the validation build and tag is the only sane way to use them. I currently have never use them because they aren't repeatable. From: Hayes, Peter [mailto:peter.ha...@fmr.com] Sent: Monday, April 06, 2009 12:12 PM To: Maven Users List Subject: RE: LATEST and RELEASE release version management Graham Leggett wrote: Having said that, it makes no sense to have the release plugin care about LATEST, because by definition, building against LATEST isn't repeatable, and in order for there to be a release, you need the build to be repeatable. I think this does impact the release plugin as it could offer the ability to resolve the LATEST version at release time. These builds would be reproducible because the release plugin tags the poms during the release process. I think what you're saying is that the build prior to the release build is not guaranteed to have the same dependent artifacts as the release build. I care about the release build being reproducible. Pete -- Emo Philips <http://www.brainyquote.com/quotes/authors/e/emo_philips.html > - "A computer once beat me at chess, but it was no match for me at kick boxing." - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: LATEST and RELEASE release version management
Version ranges seem to totally break reproducibility of released builds. Personally, I'd like to see these eliminated from Maven altogether and replaced with a separate version compatibility field that indicates which versions of a dependency you are compatible with but still have a specific version that you declare: ... org.springframework spring-core 2.5.5 [2.5,3.0-!) ... This would ensure reproducibility while providing higher value version information that could then be used within metadata and leveraged by containers such as OSGI. Pete -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Wednesday, April 08, 2009 3:16 AM To: Maven Users List Cc: Maven Users List Subject: Re: LATEST and RELEASE release version management sounds like you want version ranges [1.0,2.0-!) Sent from my [rhymes with myPod] ;-) On 8 Apr 2009, at 01:39, Tim wrote: > http://jira.codehaus.org/browse/MNG-4089 > I need to read over the bug that was linked as a duplicate more > closely but > I don't think it's the same thing. > What I asked for was the same as what you said with 1.0-LATEST. > Doing something like that or 1.0-RELEASE would actually be very > beneficial > to people that know that minor releases won't break backwards > compatibility > but will allow for more features without having to keep changing > versions. > > On Mon, Apr 6, 2009 at 6:29 PM, Brian E. Fox > wrote: > >> Having the release plugin translate these values at release time >> _before_ the validation build and tag is the only sane way to use >> them. >> I currently have never use them because they aren't repeatable. >> >> >> >> From: Hayes, Peter [mailto:peter.ha...@fmr.com] >> Sent: Monday, April 06, 2009 12:12 PM >> To: Maven Users List >> Subject: RE: LATEST and RELEASE release version management >> >> >> >> Graham Leggett wrote: >> >>> Having said that, it makes no sense to have the release plugin care >>> about LATEST, because by definition, building against LATEST isn't >>> repeatable, and in order for there to be a release, you need the >>> build >>> to be repeatable. >> >> I think this does impact the release plugin as it could offer the >> ability to resolve the LATEST version at release time. These builds >> would be reproducible because the release plugin tags the poms during >> the release process. >> >> I think what you're saying is that the build prior to the release >> build >> is not guaranteed to have the same dependent artifacts as the release >> build. I care about the release build being reproducible. >> >> Pete >> >> > > > -- > > Emo Philips <http://www.brainyquote.com/quotes/authors/e/emo_philips.html > > > - "A computer once beat me at chess, but it was no match for me at > kick > boxing." - 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: LATEST and RELEASE release version management
It does but that actually includes all SNAPSHOT versions. If you aren't interested in snapshot versions as well that that will break. On Wed, Apr 8, 2009 at 2:16 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > sounds like you want version ranges > > [1.0,2.0-!) > > Sent from my [rhymes with myPod] ;-) > > > On 8 Apr 2009, at 01:39, Tim wrote: > > http://jira.codehaus.org/browse/MNG-4089 >> I need to read over the bug that was linked as a duplicate more closely >> but >> I don't think it's the same thing. >> What I asked for was the same as what you said with 1.0-LATEST. >> Doing something like that or 1.0-RELEASE would actually be very beneficial >> to people that know that minor releases won't break backwards >> compatibility >> but will allow for more features without having to keep changing versions. >> >> On Mon, Apr 6, 2009 at 6:29 PM, Brian E. Fox > >wrote: >> >> Having the release plugin translate these values at release time >>> _before_ the validation build and tag is the only sane way to use them. >>> I currently have never use them because they aren't repeatable. >>> >>> >>> >>> From: Hayes, Peter [mailto:peter.ha...@fmr.com] >>> Sent: Monday, April 06, 2009 12:12 PM >>> To: Maven Users List >>> Subject: RE: LATEST and RELEASE release version management >>> >>> >>> >>> Graham Leggett wrote: >>> >>> Having said that, it makes no sense to have the release plugin care >>>> about LATEST, because by definition, building against LATEST isn't >>>> repeatable, and in order for there to be a release, you need the build >>>> to be repeatable. >>>> >>> >>> I think this does impact the release plugin as it could offer the >>> ability to resolve the LATEST version at release time. These builds >>> would be reproducible because the release plugin tags the poms during >>> the release process. >>> >>> I think what you're saying is that the build prior to the release build >>> is not guaranteed to have the same dependent artifacts as the release >>> build. I care about the release build being reproducible. >>> >>> Pete >>> >>> >>> >> >> -- >> >> Emo Philips <http://www.brainyquote.com/quotes/authors/e/emo_philips.html >> > >> - "A computer once beat me at chess, but it was no match for me at >> kick >> boxing." >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Fred Allen <http://www.brainyquote.com/quotes/authors/f/fred_allen.html> - "Washington is no place for a good actor. The competition from bad actors is too great."
Version management in a Maven CI environment
My organization has been using Maven and CI for a few years now. Although we have a process in place that works for us, it has always been difficult to come up with a successful approach to dependency version management in Maven at release-time. We use the release plugin extensively, are familiar with the version plugin and use them both in an attempt to automate the process as much as possible but I feel that our approach may not be a "best-practice". The Sonatype CI best practices blog post was very helpful but I think it was light on details regarding dependency version handling. The two areas I feel we have the clunkiest processes are: 1. When a component is released, we don't have a good way to automatically update dependent projects that need a corresponding snapshot version reference update. What is the recommended Maven best practice for synchronizing snapshot dependencies in a complex dependency tree? For us this requires an awareness of the dependencies and manual notification and maintenance. 2. Just prior to release time, we have snapshot dependencies. What is the recommended Maven best practice for transitioning those references to released versions while still maintaining proper continuous integration of trunk source changes to the dependencies? In other words where does CI go when we fix our dependency references around release time? We want to avoid any concept of code-freeze around these times. -- View this message in context: http://maven.40175.n5.nabble.com/Version-management-in-a-Maven-CI-environment-tp4694136p4694136.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: Re: Version Management in 'mvn dependency:tree'
I apologize for my unclear description! Allow me to explain my problem
specifically. You are right; it is indeed a confusion.
Firstly, I compiled a project using Maven. This step was completed with the
command mvn clean install. Below is part of the output (I have omitted some
information for brevity).
[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=316672,
ConflictMarker.markTime=152305, ConflictMarker.nodeCount=135,
ConflictIdSorter.graphTime=146303, ConflictIdSorter.topsortTime=42955,
ConflictIdSorter.conflictIdCount=59, ConflictIdSorter.conflictIdCycleCount=0,
ConflictResolver.totalTime=4445286, ConflictResolver.conflictItemCount=131,
DefaultDependencyCollector.collectTime=204337663,
DefaultDependencyCollector.transformTime=5194486}
[DEBUG]
com.akathist.maven.plugins.launch4j:launch4j-maven-plugin:maven-plugin:2.4.2-SNAPSHOT
...
[DEBUG] org.apache.maven:maven-core:jar:3.9.4:provided
...
[DEBUG] org.codehaus.plexus:plexus-interpolation:jar:1.26:provided
[DEBUG]
org.codehaus.plexus:plexus-component-annotations:jar:2.1.0:provided
[DEBUG] org.slf4j:slf4j-api:jar:1.7.36:provided
[DEBUG]
org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.9.0:provided
[DEBUG] org.apache.commons:commons-lang3:jar:3.13.0:compile
[DEBUG] junit:junit:jar:4.13.2:test
...
>From this portion of the information, we can see that the version of the
>dependency package org.apache.commons:commons-lang3 is 3.13.0. However,
>because the compilation output hides duplicate dependency information, I tried
>mvn dependency:tree -Dverbose=true to get more detailed information. Here is
>the output:
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @
launch4j-maven-plugin ---
[INFO]
com.akathist.maven.plugins.launch4j:launch4j-maven-plugin:maven-plugin:2.4.2-SNAPSHOT
...
[INFO] +- org.apache.maven:maven-core:jar:3.9.4:provided
...
[INFO] | +- org.codehaus.plexus:plexus-interpolation:jar:1.26:provided
[INFO] | +- org.codehaus.plexus:plexus-component-annotations:jar:2.1.0:provided
[INFO] | +- (org.apache.commons:commons-lang3:jar:3.12.0:provided - omitted for
duplicate)
[INFO] | \- org.slf4j:slf4j-api:jar:1.7.36:provided
[INFO] +-
org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.9.0:provided
[INFO] +- org.apache.commons:commons-lang3:jar:3.13.0:compile
[INFO] +- junit:junit:jar:4.13.2:test
...
>From this, we can still find the dependency package
>org.apache.commons:commons-lang3 at its original location, and the version
>matches the one mentioned in the compilation output, which is 3.13.0. However,
>within the dependency of org.apache.maven:maven-core, there is another
>occurrence of org.apache.commons:commons-lang3. It's worth noting that this
>dependency package does not have the version 3.13.0.
My confusion is: based on the above situation, has the project actually
introduced the org.apache.commons:commons-lang3 with version 3.12.0 during the
actual compilation process?
I hope this clarifies my confusion.
On 2023/10/31 19:14:08 Greg Chabala wrote:
> On Tue, Oct 31, 2023 at 11:27 AM
> wrote:
>
> > Can't quite make sense of all this; given that you got no replies, maybe
> > no one else understood either.
>
>
> I second this sentiment. All I could tell is it seems like there's some
> confusion about interpreting the dependency:tree output, and perhaps
> confusion on how dependency convergence works, or how a project should
> specify dependency versions.
>
> See
> https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html
> for an overview.
>
Re: Re: Version Management in 'mvn dependency:tree'
On Tue, Oct 31, 2023 at 10:27 PM yukai zhao wrote: > has the project actually introduced the org.apache.commons:commons-lang3 > with version 3.12.0 during the actual compilation process? > Well, no. It says 3.12.0 was omitted, due to being a duplicate, hence why it was not even mentioned without turning on verbose output. This is basically the core purpose of Maven, choosing what version of an artifact to include in the classpath.
Best practices for release and version management?
Hi there, How do you use to manage your project version among releases? I mean... what do you exactly put in currentVersion in your pom and how do you change it among releases? I'm currently using the following approach: 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT 2. V0.1 release: commit all pending changes, change currentVersion to 0.1, commit pom, tag/branch repository, make release. 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, commit pom, update and continue developing What do you think about this? This approach has one annoying thing: maven tries to download SNAPSHOT versions from remote repositories, although they're only locally installed in the developer repository. After some timeout maven uses the local version, but in case of large projects the sum of the timeouts may be big. Do you use any other approach? Thanks in advance, best regards Jose - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version management in a Maven CI environment
On Fri, August 12, 2011 10:34 am, leonfranzen wrote: > My organization has been using Maven and CI for a few years now. Although > we > have a process in place that works for us, it has always been difficult to > come up with a successful approach to dependency version management in > Maven > at release-time. We use the release plugin extensively, are familiar with > the version plugin and use them both in an attempt to automate the process > as much as possible but I feel that our approach may not be a > "best-practice". The Sonatype CI best practices blog post was very > helpful > but I think it was light on details regarding dependency version handling. > The two areas I feel we have the clunkiest processes are: > 1. When a component is released, we don't have a good way to automatically > update dependent projects that need a corresponding snapshot version > reference update. What is the recommended Maven best practice for > synchronizing snapshot dependencies in a complex dependency tree? For us > this requires an awareness of the dependencies and manual notification and > maintenance. What about using dependency management in a parent pom? > 2. Just prior to release time, we have snapshot dependencies. What is the > recommended Maven best practice for transitioning those references to > released versions while still maintaining proper continuous integration of > trunk source changes to the dependencies? In other words where does CI go > when we fix our dependency references around release time? We want to > avoid > any concept of code-freeze around these times. Depending on your scm strategy e.g. trunk moves straight to the next snapshot, release branch gets separate CI setup.. Of course depending on your CI server and SCM things around this idea might vary.. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version management in a Maven CI environment
Manfred Moser wrote: > > What about using dependency management in a parent pom? > I'm not sure I understand what you're suggesting. Do you mean all dependency versions are provided by a common parent POM? Doesn't that present the problem of needing to constantly release the parent POM which would in turn force all projects to update their referenced parent version? This would be compounded if you have deep POM inheritance. Manfred Moser wrote: > > Depending on your scm strategy e.g. trunk moves straight to the next > snapshot, release branch gets separate CI setup.. > > Of course depending on your CI server and SCM things around this idea > might vary.. > We have tried a few approaches here, including branch and then release from branch, while trunk maintains Snapshot. While this works, it still requires updating of the snapshot dependency versions. I was hoping to find the "Maven-way" documented somewhere. One of the main strengths of Maven is its predictable process but it's lighter on details than I would like when it comes to fitting it into a typical CI release cycle. In other words, it's not as simple as "mvn release:prepare", "mvn release:perform". Since it's not that simple, documentation of a real SCM-integrated, CI process seems to be necessary. -- View this message in context: http://maven.40175.n5.nabble.com/Version-management-in-a-Maven-CI-environment-tp4694136p4702766.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: Re: Re: Version Management in 'mvn dependency:tree'
Thank you for your response! Additionally, I've noticed that in this situation, if I delete 3.12.0 from my local repository and then recompile the project, Maven still downloads 3.12.0. Is this behavior normal? On 2023/11/01 03:45:49 Greg Chabala wrote: > On Tue, Oct 31, 2023 at 10:27 PM yukai zhao wrote: > > > has the project actually introduced the org.apache.commons:commons-lang3 > > with version 3.12.0 during the actual compilation process? > > > > Well, no. It says 3.12.0 was omitted, due to being a duplicate, hence why > it was not even mentioned without turning on verbose output. > > This is basically the core purpose of Maven, choosing what version of an > artifact to include in the classpath. >
Re: Re: Re: Version Management in 'mvn dependency:tree'
Howdy, "I delete 3.12.0" -- you deleted the "3.12.0" directory? "still downloads 3.12.0" -- means you got again the "3.12.0" directory? As it _will_ download the POM during collection, but not the JAR (or at least should not) T On Wed, Nov 1, 2023 at 6:37 AM yukai zhao wrote: > Thank you for your response! > Additionally, I've noticed that in this situation, if I delete 3.12.0 from > my local repository and then recompile the project, Maven still downloads > 3.12.0. Is this behavior normal? > > On 2023/11/01 03:45:49 Greg Chabala wrote: > > On Tue, Oct 31, 2023 at 10:27 PM yukai zhao wrote: > > > > > has the project actually introduced the > org.apache.commons:commons-lang3 > > > with version 3.12.0 during the actual compilation process? > > > > > > > Well, no. It says 3.12.0 was omitted, due to being a duplicate, hence why > > it was not even mentioned without turning on verbose output. > > > > This is basically the core purpose of Maven, choosing what version of an > > artifact to include in the classpath. > > >
Re: Best practices for release and version management?
2005/9/2, Jose Gonzalez Gomez <[EMAIL PROTECTED]>: > Hi there, > > How do you use to manage your project version among releases? I > mean... what do you exactly put in currentVersion in your pom and how > do you change it among releases? > > I'm currently using the following approach: > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT > 2. V0.1 release: commit all pending changes, change currentVersion to > 0.1, commit pom, tag/branch repository, make release. > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > commit pom, update and continue developing > > What do you think about this? This approach has one annoying thing: > maven tries to download SNAPSHOT versions from remote repositories, > although they're only locally installed in the developer repository. > After some timeout maven uses the local version, but in case of large > projects the sum of the timeouts may be big. Do you use any other > approach? > > Thanks in advance, best regards > Jose > After re-reading some of the maven documentation it seems I'm following the suggested approach (although manually, instead of using the scm plugin)... anyway, is there any way to force maven to use the local repository version of my own SNAPSHOT artifacts while still downloading external dependencies? Thanks in advance, best regards Jose - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for release and version management?
On Fri, Sep 02, 2005 at 11:46:49AM +0200, Jose Gonzalez Gomez wrote: > Hi there, > > How do you use to manage your project version among releases? I > mean... what do you exactly put in currentVersion in your pom and how > do you change it among releases? > > I'm currently using the following approach: > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT > 2. V0.1 release: commit all pending changes, change currentVersion to > 0.1, commit pom, tag/branch repository, make release. > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > commit pom, update and continue developing This is the way that we're recomending and using ourselfs. > What do you think about this? This approach has one annoying thing: > maven tries to download SNAPSHOT versions from remote repositories, > although they're only locally installed in the developer repository. > After some timeout maven uses the local version, but in case of large > projects the sum of the timeouts may be big. Do you use any other > approach? The easiest solution to this problem is to either configure a proxy so it doesn't time out (but rather get a 404 response from the HTTP server) or just run Maven in off-line mode (by using the -o switch) -- Trygve signature.asc Description: Digital signature
RE: Best practices for release and version management?
We're pretty much doing what Jose is doing, but we don't see these timeouts. I think it's because the Maven properties are set up to look in our internal repository first and then go global from there. Just about everything is in the internal repository (certainly the artifacts for our projects are there), so the download time isn't much at all. My maven.repo.remote property lists the internal repository first, and ibiblio second. As far as the approach to take when releasing and incrementing versions, the process you describe is essentially what we're doing. In fact, I just wrote up a document outlining our internal process for releasing projects for our developers (since we're about to release the big project soon), so I know the details very well. ..David.. -Original Message- From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] Sent: Friday, September 02, 2005 4:14 AM To: Maven Users List Subject: Re: Best practices for release and version management? On Fri, Sep 02, 2005 at 11:46:49AM +0200, Jose Gonzalez Gomez wrote: > Hi there, > > How do you use to manage your project version among releases? I > mean... what do you exactly put in currentVersion in your pom and how > do you change it among releases? > > I'm currently using the following approach: > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT 2. V0.1 > release: commit all pending changes, change currentVersion to 0.1, > commit pom, tag/branch repository, make release. > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > commit pom, update and continue developing This is the way that we're recomending and using ourselfs. > What do you think about this? This approach has one annoying thing: > maven tries to download SNAPSHOT versions from remote repositories, > although they're only locally installed in the developer repository. > After some timeout maven uses the local version, but in case of large > projects the sum of the timeouts may be big. Do you use any other > approach? The easiest solution to this problem is to either configure a proxy so it doesn't time out (but rather get a 404 response from the HTTP server) or just run Maven in off-line mode (by using the -o switch) -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practices for release and version management?
How does one do it for m2? I am new to maven and I have decided to skip maven 1.x and start with m2 directly. -Moiz -Original Message- From: David Jackman [mailto:[EMAIL PROTECTED] Sent: Friday, September 02, 2005 7:00 AM To: Maven Users List Subject: RE: Best practices for release and version management? We're pretty much doing what Jose is doing, but we don't see these timeouts. I think it's because the Maven properties are set up to look in our internal repository first and then go global from there. Just about everything is in the internal repository (certainly the artifacts for our projects are there), so the download time isn't much at all. My maven.repo.remote property lists the internal repository first, and ibiblio second. As far as the approach to take when releasing and incrementing versions, the process you describe is essentially what we're doing. In fact, I just wrote up a document outlining our internal process for releasing projects for our developers (since we're about to release the big project soon), so I know the details very well. ..David.. -Original Message- From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] Sent: Friday, September 02, 2005 4:14 AM To: Maven Users List Subject: Re: Best practices for release and version management? On Fri, Sep 02, 2005 at 11:46:49AM +0200, Jose Gonzalez Gomez wrote: > Hi there, > > How do you use to manage your project version among releases? I > mean... what do you exactly put in currentVersion in your pom and how > do you change it among releases? > > I'm currently using the following approach: > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT 2. V0.1 > release: commit all pending changes, change currentVersion to 0.1, > commit pom, tag/branch repository, make release. > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > commit pom, update and continue developing This is the way that we're recomending and using ourselfs. > What do you think about this? This approach has one annoying thing: > maven tries to download SNAPSHOT versions from remote repositories, > although they're only locally installed in the developer repository. > After some timeout maven uses the local version, but in case of large > projects the sum of the timeouts may be big. Do you use any other > approach? The easiest solution to this problem is to either configure a proxy so it doesn't time out (but rather get a 404 response from the HTTP server) or just run Maven in off-line mode (by using the -o switch) -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for release and version management?
On Fri, Sep 02, 2005 at 10:54:37AM -0400, dohadwala, moiz wrote: > How does one do it for m2? > > I am new to maven and I have decided to skip maven 1.x and start with m2 > directly. In Maven 2 there is the same off-line option as in Maven 1 but you can also say that repositories can contain snapshots or not so by default Maven won't go to Ibiblio to look for snapshots. -- Trygve signature.asc Description: Digital signature
Re: Best practices for release and version management?
Hi David, Is it possible for you to share the "internal process" document with us? It will help a lot. -Sanjay On 9/2/05, David Jackman <[EMAIL PROTECTED]> wrote: > > We're pretty much doing what Jose is doing, but we don't see these > timeouts. I think it's because the Maven properties are set up to look in > our internal repository first and then go global from there. Just about > everything is in the internal repository (certainly the artifacts for our > projects are there), so the download time isn't much at all. > > My maven.repo.remote property lists the internal repository first, and > ibiblio second. > > As far as the approach to take when releasing and incrementing versions, > the process you describe is essentially what we're doing. In fact, I just > wrote up a document outlining our internal process for releasing projects > for our developers (since we're about to release the big project soon), so I > know the details very well. > > ..David.. > > > -Original Message- > From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] > Sent: Friday, September 02, 2005 4:14 AM > To: Maven Users List > Subject: Re: Best practices for release and version management? > > On Fri, Sep 02, 2005 at 11:46:49AM +0200, Jose Gonzalez Gomez wrote: > > Hi there, > > > > How do you use to manage your project version among releases? I > > mean... what do you exactly put in currentVersion in your pom and how > > do you change it among releases? > > > > I'm currently using the following approach: > > > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT 2. V0.1 > > release: commit all pending changes, change currentVersion to 0.1, > > commit pom, tag/branch repository, make release. > > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > > commit pom, update and continue developing > > This is the way that we're recomending and using ourselfs. > > > What do you think about this? This approach has one annoying thing: > > maven tries to download SNAPSHOT versions from remote repositories, > > although they're only locally installed in the developer repository. > > After some timeout maven uses the local version, but in case of large > > projects the sum of the timeouts may be big. Do you use any other > > approach? > > The easiest solution to this problem is to either configure a proxy so it > doesn't time out (but rather get a 404 response from the HTTP server) or > just run Maven in off-line mode (by using the -o switch) > > -- > Trygve > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Best practices for release and version management?
2005/9/2, Trygve Laugstøl <[EMAIL PROTECTED]>: > On Fri, Sep 02, 2005 at 10:54:37AM -0400, dohadwala, moiz wrote: > > How does one do it for m2? > > > > I am new to maven and I have decided to skip maven 1.x and start with m2 > > directly. > > In Maven 2 there is the same off-line option as in Maven 1 but you can > also say that repositories can contain snapshots or not so by default > Maven won't go to Ibiblio to look for snapshots. > I think that's what I was looking for... so if I explicitly list the default repositories and add a false to them, Maven won't look for snapshots there and directly get snapshots from the developer local repository... I'll give it a try. Thanks, best regards Jose - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for release and version management?
David, I understand that you're deploying your snapshot versions for your projects in your internal repository, but I don't fully understand your environment (or maybe Maven's way of working)... let me explain: I understand that you can publish snapshot versions of artifacts under development that are used across projects using a checked out source tree of those artifacts. The problem comes when you have several developers working on a project and using artifacts that are private to that project, and where several developers may be changing the same artifact (think of two different developers working on two different EJBs in the same artifact, or two different parts of a web interface). In this case you cannot publish that artifact until changes are comitted, and every developer must use her own snapshot copy of the artifact with her local changes that must be taken from her local repository. It's in this case that I don't want those artifacts to be taken from any other repository. How do you handle this, or how do you configure Maven to tell that those artifacts should only be taken from the developer local repository? Best regards Jose 2005/9/2, David Jackman <[EMAIL PROTECTED]>: > We're pretty much doing what Jose is doing, but we don't see these timeouts. > I think it's because the Maven properties are set up to look in our internal > repository first and then go global from there. Just about everything is in > the internal repository (certainly the artifacts for our projects are there), > so the download time isn't much at all. > > My maven.repo.remote property lists the internal repository first, and > ibiblio second. > > As far as the approach to take when releasing and incrementing versions, the > process you describe is essentially what we're doing. In fact, I just wrote > up a document outlining our internal process for releasing projects for our > developers (since we're about to release the big project soon), so I know the > details very well. > > ..David.. > > > -Original Message- > From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] > Sent: Friday, September 02, 2005 4:14 AM > To: Maven Users List > Subject: Re: Best practices for release and version management? > > On Fri, Sep 02, 2005 at 11:46:49AM +0200, Jose Gonzalez Gomez wrote: > > Hi there, > > > > How do you use to manage your project version among releases? I > > mean... what do you exactly put in currentVersion in your pom and how > > do you change it among releases? > > > > I'm currently using the following approach: > > > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT 2. V0.1 > > release: commit all pending changes, change currentVersion to 0.1, > > commit pom, tag/branch repository, make release. > > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > > commit pom, update and continue developing > > This is the way that we're recomending and using ourselfs. > > > What do you think about this? This approach has one annoying thing: > > maven tries to download SNAPSHOT versions from remote repositories, > > although they're only locally installed in the developer repository. > > After some timeout maven uses the local version, but in case of large > > projects the sum of the timeouts may be big. Do you use any other > > approach? > > The easiest solution to this problem is to either configure a proxy so it > doesn't time out (but rather get a 404 response from the HTTP server) or just > run Maven in off-line mode (by using the -o switch) > > -- > Trygve > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practices for release and version management?
I don't know of a way to configure Maven this way, other than the -o option to tell Maven to run in offline mode, where nothing ever gets downloaded. We haven't really had this problem come up. The un-committed changes for any given developer is usually limited to one or two projects. Plus, most of our developers use an IDE for doing their own builds of projects while developing instead of using Maven. When they are ready to commit their changes, they'll do a Maven build to make sure that build still works. ..David.. -Original Message- From: Jose Gonzalez Gomez [mailto:[EMAIL PROTECTED] Sent: Saturday, September 03, 2005 3:16 AM To: Maven Users List Subject: Re: Best practices for release and version management? David, I understand that you're deploying your snapshot versions for your projects in your internal repository, but I don't fully understand your environment (or maybe Maven's way of working)... let me explain: I understand that you can publish snapshot versions of artifacts under development that are used across projects using a checked out source tree of those artifacts. The problem comes when you have several developers working on a project and using artifacts that are private to that project, and where several developers may be changing the same artifact (think of two different developers working on two different EJBs in the same artifact, or two different parts of a web interface). In this case you cannot publish that artifact until changes are comitted, and every developer must use her own snapshot copy of the artifact with her local changes that must be taken from her local repository. It's in this case that I don't want those artifacts to be taken from any other repository. How do you handle this, or how do you configure Maven to tell that those artifacts should only be taken from the developer local repository? Best regards Jose 2005/9/2, David Jackman <[EMAIL PROTECTED]>: > We're pretty much doing what Jose is doing, but we don't see these timeouts. > I think it's because the Maven properties are set up to look in our internal > repository first and then go global from there. Just about everything is in > the internal repository (certainly the artifacts for our projects are there), > so the download time isn't much at all. > > My maven.repo.remote property lists the internal repository first, and > ibiblio second. > > As far as the approach to take when releasing and incrementing versions, the > process you describe is essentially what we're doing. In fact, I just wrote > up a document outlining our internal process for releasing projects for our > developers (since we're about to release the big project soon), so I know the > details very well. > > ..David.. > > > -Original Message- > From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] > Sent: Friday, September 02, 2005 4:14 AM > To: Maven Users List > Subject: Re: Best practices for release and version management? > > On Fri, Sep 02, 2005 at 11:46:49AM +0200, Jose Gonzalez Gomez wrote: > > Hi there, > > > > How do you use to manage your project version among releases? I > > mean... what do you exactly put in currentVersion in your pom and > > how do you change it among releases? > > > > I'm currently using the following approach: > > > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT 2. V0.1 > > release: commit all pending changes, change currentVersion to 0.1, > > commit pom, tag/branch repository, make release. > > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > > commit pom, update and continue developing > > This is the way that we're recomending and using ourselfs. > > > What do you think about this? This approach has one annoying thing: > > maven tries to download SNAPSHOT versions from remote repositories, > > although they're only locally installed in the developer repository. > > After some timeout maven uses the local version, but in case of > > large projects the sum of the timeouts may be big. Do you use any > > other approach? > > The easiest solution to this problem is to either configure a proxy so > it doesn't time out (but rather get a 404 response from the HTTP > server) or just run Maven in off-line mode (by using the -o switch) > > -- > Trygve > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for release and version management?
Jose Gonzalez Gomez wrote: I understand that you're deploying your snapshot versions for your projects in your internal repository, but I don't fully understand your environment (or maybe Maven's way of working)... let me explain: I understand that you can publish snapshot versions of artifacts under development that are used across projects using a checked out source tree of those artifacts. The problem comes when you have several developers working on a project and using artifacts that are private to that project, and where several developers may be changing the same artifact (think of two different developers working on two different EJBs in the same artifact, or two different parts of a web interface). In this case you cannot publish that artifact until changes are comitted, and every developer must use her own snapshot copy of the artifact with her local changes that must be taken from her local repository. It's in this case that I don't want those artifacts to be taken from any other repository. How do you handle this, or how do you configure Maven to tell that those artifacts should only be taken from the developer local repository? Jose, I think that one way to solve the problem that you have posed would be to expand the namespace used by individuals/teams for the development artifacts. If you and I are each making mutually exclusive changes to an artifact that we each call artifact-dev-SNAPSHOT.jar, then there is a serious problem, which you identified. If on the other hand, you call your artifact artifact-j-dev-SNAPSHOT.jar and I call my artifact artifact-a-dev-SNAPSHOT.jar, then each SNAPSHOT is qualified by owner. As long as each owner uses a unique name then there can be no problems. This naming convention allows the various teams to roll their changes stepwise into an artifact-dev-SNAPSHOT.jar at integration time, if that is desirable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
