Re: dependency management with ant quick question
Hi Chris Thanks for replying. We like to use ant as our main build process, not maven so the maven-antrun wouldnt apply here. On Wed, May 13, 2015 at 8:14 PM, Christopher ctubb...@apache.org wrote: One maven plugin which might help is the https://maven.apache.org/plugins/maven-antrun-plugin/ , which allows you to execute ant tasks within maven. I've seen some projects do this to mavenize an ant project a bit (though, usually they end up transitioning completely... eventually). Another option is to have a small maven project inside your project which has all your dependencies, and which executes the copy-dependencies goal of the maven-dependency-plugin to copy all your dependencies to a specified directory ( https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html ) to make them available for ant. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, May 13, 2015 at 11:00 PM, Zk W mpc8...@gmail.com wrote: Hi All We are new to Maven and we are an ant shop. We like to use Maven's dependency management feature, not ivy. 1- Can we just use Maven's dependency management feature to work with our ant build script ? 2- Since .m2 is the default folder for all the jars, do we use ant copy task to copy jars from .m2 folder to different project folders to compile properly ? 3. Are there examples out there that use ant for build purpose in conjunction with maven's dependency management ? Thank you. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency management with ant quick question
One maven plugin which might help is the https://maven.apache.org/plugins/maven-antrun-plugin/ , which allows you to execute ant tasks within maven. I've seen some projects do this to mavenize an ant project a bit (though, usually they end up transitioning completely... eventually). Another option is to have a small maven project inside your project which has all your dependencies, and which executes the copy-dependencies goal of the maven-dependency-plugin to copy all your dependencies to a specified directory (https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html) to make them available for ant. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, May 13, 2015 at 11:00 PM, Zk W mpc8...@gmail.com wrote: Hi All We are new to Maven and we are an ant shop. We like to use Maven's dependency management feature, not ivy. 1- Can we just use Maven's dependency management feature to work with our ant build script ? 2- Since .m2 is the default folder for all the jars, do we use ant copy task to copy jars from .m2 folder to different project folders to compile properly ? 3. Are there examples out there that use ant for build purpose in conjunction with maven's dependency management ? Thank you. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency Management versus Dependencies
dependencyManagement does not create dependencies like the dependencies section does. Rather what dependencyManagement does is specify the version and/or other configuration of actual dependencies specified in dependencies sections or transitive dependencies. -Dave On Sun, Feb 22, 2015 at 12:17 PM, Dishant Anand dishant.an...@techblue.co.uk wrote: Hi Team, Can somebody please explain me what is the difference between using a dependency in dependency management and dependency in dependencies .? We have one project where some dependencies in parent pom are defined under the dependency management while other are defined under the dependencies. Thanks for your answer in advance. Regards, Dishant Anand - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency Management versus Dependencies
That was really very helpful.Thanks Dave On 22/02/2015 19:56, David Hoffer wrote: dependencyManagement does not create dependencies like the dependencies section does. Rather what dependencyManagement does is specify the version and/or other configuration of actual dependencies specified in dependencies sections or transitive dependencies. -Dave On Sun, Feb 22, 2015 at 12:17 PM, Dishant Anand dishant.an...@techblue.co.uk wrote: Hi Team, Can somebody please explain me what is the difference between using a dependency in dependency management and dependency in dependencies .? We have one project where some dependencies in parent pom are defined under the dependency management while other are defined under the dependencies. Thanks for your answer in advance. Regards, Dishant Anand - 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 management across projects
Hi Jörg, What do you mean with irreproducible builds? I mean that you may build the same source code today, and then again next week, and the two build results may differ. With our projects we wanted the certainty that if you checked out *any* revision from the SCM history, you would still be able to build it in, say, 5 years... at least as long as you use the same versions of the tooling (Java version etc.). With a SNAPSHOT parent, that is not guaranteed. You may introduce a change in the parent that causes a build to fail when it used to succeed, which makes bisect style debugging no longer feasible. That is, if old SCM revisions no longer build properly due to changes in the parent, you will no longer be able to perform a binary search through the SCM history to determine the exact commit which introduced a bug. This scheme works well for us now for several years. Sure, and I'm not dissing it, just pointing out the pros and cons. We wanted fully reproducible builds, which meant that even our SNAPSHOT revisions have only release dependencies, including the parent POM reference. This indeed has some negative consequences, such as needing that script to bump things for us, rather than everything Just Working with no changes. And you're right that *release* version builds are still reproducible either way. Regards, Curtis On Wed, Feb 5, 2014 at 1:54 AM, Jörg Schaible joerg.schai...@swisspost.comwrote: Hi Curtis, Curtis Rueden wrote: Hi Jörg, We use simply x-SNAPSHOT for the parent version. That way no unreleased project has to be touched, it simply uses the lastest SNAPSHOT of the parent. No script required. Yeah, that is very convenient, if you are willing to accept the two-edged sword of irreproducible builds. What do you mean with irreproducible builds? Definitely, if you project relies on a SNAPSHOT parent, it does not matter if you call it 1-SNAPSHOT or x-SNAPSHOT. A breaking change in the parent will break all builds that consume it... but can be fixed just as easily too without touching the downstream projects. Well, somebody obviously made the choice for the SNAPSHOT parent ... with all consequences. Of course, it's a decision every project has to make for themselves. My projects opted for build reproducibility by using only release linkages (for parent POMs, dependencies and plugins). This has many advantages: e.g., git bisect fully works as one might hope, allowing you to resurrect the state of the code even from years prior and still build successfully. The downside is that you must make releases in order to be able to pin to them. Once a project is released, you also have a released parent. No surprises anymore. And the project can then make its own decision if it creates also a branch for the parent and rely on e.g. 254.x-SNAPSHOT either for maintenance releases or further development. This scheme works well for us now for several years. Cheers, Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency management across projects
On Mon, Feb 3, 2014 at 8:21 AM, Anders Hammar and...@hammar.net wrote: I believe so, yes. The key thing in my solution is the BOM. And the BOM will keep the appropriate version of the the sub-products together. Right! There is no automatic solution for this that I know of. I suppose that tolls could be created, but keep in mind that in the end, for backward compatibility reason SP2 has to use 1.8.0 is normally a human decision. It is. The tool I aim to create is more report-based. Something that would gather the dependencies on each sub-projects and report inconsistencies: a dependency unknown to the product has been added or removed, etc. Thanks for brainstorming this with me. It feels that we're indeed lacking for a standard solution for this in the Maven land. Will look into that and report here my progress S. /Anders Creating manually the first BOM for P v1.0.0 isn't a problem: i've created a set of tools that I am happy to share once they are fully ready. But maintaining that BOM in the long run is more of a challenge (because we can't force the sub-projects to use those versions so we have to monitor what happens in each sub-project to take the appropriate version at the product level). Thanks again for the feedback! S. /Anders There is also the possibility of creating a grouping pom, which lists all artifacts as dependencies. You would then declare a dependency to that grouping pom and get all deps magically sucked in. However, this is not really the Maven way in my opinion as you wouldn't specify your direct deps bu sort of relly on transitive deps. There are some fans of this approach though here on this list. 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose Maybe some enforcer rule? Like I said, this is to be used alongside the regular build job. So my SP4 1.2.0-SNAPSHOT is building with a set of dependencies on its own and I want to validate that with the dependencies of the target release for P, it is also working just fine. It may just be the same ideally or slightly different (or not slightly at all which requires an explicit validation). So I need to be able to swap those versions for validation purposes and run the build with that. S. /Anders I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade or not, etc). For the second part, it's not easy to force a dependency change in Maven, especially if the version has been specified at the project level. Thanks for reading that far. If you have any idea or know any organisation that tried to implement that, I'd be interested Thanks! S.
Re: dependency management across projects
Thanks for the feedback. This looks like something that the versions-maven-plugin could do. There's something similar that is advertised by the plugin documentation but it's not implemented. I'll have a look to that too. Thanks! S. On Mon, Feb 3, 2014 at 6:39 PM, Curtis Rueden ctrue...@wisc.edu wrote: Hi everyone, The very point I am trying to make here is how do you manage that manual BOM on a daily basis. There is no automatic solution for this that I know of. Maybe not exactly what you are looking for, but sort of similar: My group uses a script [1] to automatically bump the version of our parent POM [2]. In that parent POM, we declare many version properties, plugin configuration in pluginManagement, etc., and we like to keep all our projects across various Git repositories using the newest available version of the parent, to minimize version clashes when mixing and matching libraries. We set up a parameterized Jenkins job [3] to run the parent bump for us, which provides checkboxes for all the downstream projects so the bump can be controlled individually. It's not perfect but it does save a lot of manual maintenance. Regards, Curtis [1] https://github.com/scijava/scijava-scripts/blob/a0fc8006741e0216c74c82866fd1bb1a7d364d55/bump-pom-scijava.sh [2] https://github.com/scijava/pom-scijava/blob/0de0676f7731b98baa89379dc8b92f8b26a5d086/pom.xml [3] http://jenkins.imagej.net/view/SciJava/job/Bump-POM-SciJava/ On Mon, Feb 3, 2014 at 1:21 AM, Anders Hammar and...@hammar.net wrote: The release of the BOM would be that release of a single coherent unit then. It would specify the (marketing) version of the platform P. For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1), v1.4.3 of SP2, etc. Isn't it what I just write in my original post? (without mentioning the BOM) I believe so, yes. The key thing in my solution is the BOM. And the BOM will keep the appropriate version of the the sub-products together. The very point I am trying to make here is how do you manage that manual BOM on a daily basis. Each sub-project has its own release cycle and we cannot force the versions it has to use for a specific branch. For instance, the product might state that the dependency D should be 2.2.0 (because that's the latest or the one that people generally use) but for backward compatibility reason SP2 has to use 1.8.0. There is no automatic solution for this that I know of. I suppose that tolls could be created, but keep in mind that in the end, for backward compatibility reason SP2 has to use 1.8.0 is normally a human decision. /Anders Creating manually the first BOM for P v1.0.0 isn't a problem: i've created a set of tools that I am happy to share once they are fully ready. But maintaining that BOM in the long run is more of a challenge (because we can't force the sub-projects to use those versions so we have to monitor what happens in each sub-project to take the appropriate version at the product level). Thanks again for the feedback! S. /Anders There is also the possibility of creating a grouping pom, which lists all artifacts as dependencies. You would then declare a dependency to that grouping pom and get all deps magically sucked in. However, this is not really the Maven way in my opinion as you wouldn't specify your direct deps bu sort of relly on transitive deps. There are some fans of this approach though here on this list. 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose Maybe some enforcer rule? Like I said, this is to be used alongside the regular build job. So my SP4 1.2.0-SNAPSHOT is building with a set of dependencies on its own and I want to validate that with the dependencies of the target release for P, it is also working just fine. It may just be the same ideally or slightly different (or not slightly at all which requires an explicit validation). So I need to be able to swap those versions for validation purposes and run the build with that. S. /Anders I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade
Re: dependency management across projects
Curtis Rueden wrote: Hi everyone, The very point I am trying to make here is how do you manage that manual BOM on a daily basis. There is no automatic solution for this that I know of. Maybe not exactly what you are looking for, but sort of similar: My group uses a script [1] to automatically bump the version of our parent POM [2]. We use simply x-SNAPSHOT for the parent version. That way no unreleased project has to be touched, it simply uses the lastest SNAPSHOT of the parent. No script required. [snip] - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency management across projects
Hi Jörg, We use simply x-SNAPSHOT for the parent version. That way no unreleased project has to be touched, it simply uses the lastest SNAPSHOT of the parent. No script required. Yeah, that is very convenient, if you are willing to accept the two-edged sword of irreproducible builds. A breaking change in the parent will break all builds that consume it... but can be fixed just as easily too without touching the downstream projects. Of course, it's a decision every project has to make for themselves. My projects opted for build reproducibility by using only release linkages (for parent POMs, dependencies and plugins). This has many advantages: e.g., git bisect fully works as one might hope, allowing you to resurrect the state of the code even from years prior and still build successfully. The downside is that you must make releases in order to be able to pin to them. Regards, Curtis On Tue, Feb 4, 2014 at 4:38 AM, Jörg Schaible joerg.schai...@swisspost.comwrote: Curtis Rueden wrote: Hi everyone, The very point I am trying to make here is how do you manage that manual BOM on a daily basis. There is no automatic solution for this that I know of. Maybe not exactly what you are looking for, but sort of similar: My group uses a script [1] to automatically bump the version of our parent POM [2]. We use simply x-SNAPSHOT for the parent version. That way no unreleased project has to be touched, it simply uses the lastest SNAPSHOT of the parent. No script required. [snip] - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency management across projects
Hi Curtis, Curtis Rueden wrote: Hi Jörg, We use simply x-SNAPSHOT for the parent version. That way no unreleased project has to be touched, it simply uses the lastest SNAPSHOT of the parent. No script required. Yeah, that is very convenient, if you are willing to accept the two-edged sword of irreproducible builds. What do you mean with irreproducible builds? Definitely, if you project relies on a SNAPSHOT parent, it does not matter if you call it 1-SNAPSHOT or x-SNAPSHOT. A breaking change in the parent will break all builds that consume it... but can be fixed just as easily too without touching the downstream projects. Well, somebody obviously made the choice for the SNAPSHOT parent ... with all consequences. Of course, it's a decision every project has to make for themselves. My projects opted for build reproducibility by using only release linkages (for parent POMs, dependencies and plugins). This has many advantages: e.g., git bisect fully works as one might hope, allowing you to resurrect the state of the code even from years prior and still build successfully. The downside is that you must make releases in order to be able to pin to them. Once a project is released, you also have a released parent. No surprises anymore. And the project can then make its own decision if it creates also a branch for the parent and rely on e.g. 254.x-SNAPSHOT either for maintenance releases or further development. This scheme works well for us now for several years. Cheers, Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency management across projects
Hi everyone, The very point I am trying to make here is how do you manage that manual BOM on a daily basis. There is no automatic solution for this that I know of. Maybe not exactly what you are looking for, but sort of similar: My group uses a script [1] to automatically bump the version of our parent POM [2]. In that parent POM, we declare many version properties, plugin configuration in pluginManagement, etc., and we like to keep all our projects across various Git repositories using the newest available version of the parent, to minimize version clashes when mixing and matching libraries. We set up a parameterized Jenkins job [3] to run the parent bump for us, which provides checkboxes for all the downstream projects so the bump can be controlled individually. It's not perfect but it does save a lot of manual maintenance. Regards, Curtis [1] https://github.com/scijava/scijava-scripts/blob/a0fc8006741e0216c74c82866fd1bb1a7d364d55/bump-pom-scijava.sh [2] https://github.com/scijava/pom-scijava/blob/0de0676f7731b98baa89379dc8b92f8b26a5d086/pom.xml [3] http://jenkins.imagej.net/view/SciJava/job/Bump-POM-SciJava/ On Mon, Feb 3, 2014 at 1:21 AM, Anders Hammar and...@hammar.net wrote: The release of the BOM would be that release of a single coherent unit then. It would specify the (marketing) version of the platform P. For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1), v1.4.3 of SP2, etc. Isn't it what I just write in my original post? (without mentioning the BOM) I believe so, yes. The key thing in my solution is the BOM. And the BOM will keep the appropriate version of the the sub-products together. The very point I am trying to make here is how do you manage that manual BOM on a daily basis. Each sub-project has its own release cycle and we cannot force the versions it has to use for a specific branch. For instance, the product might state that the dependency D should be 2.2.0 (because that's the latest or the one that people generally use) but for backward compatibility reason SP2 has to use 1.8.0. There is no automatic solution for this that I know of. I suppose that tolls could be created, but keep in mind that in the end, for backward compatibility reason SP2 has to use 1.8.0 is normally a human decision. /Anders Creating manually the first BOM for P v1.0.0 isn't a problem: i've created a set of tools that I am happy to share once they are fully ready. But maintaining that BOM in the long run is more of a challenge (because we can't force the sub-projects to use those versions so we have to monitor what happens in each sub-project to take the appropriate version at the product level). Thanks again for the feedback! S. /Anders There is also the possibility of creating a grouping pom, which lists all artifacts as dependencies. You would then declare a dependency to that grouping pom and get all deps magically sucked in. However, this is not really the Maven way in my opinion as you wouldn't specify your direct deps bu sort of relly on transitive deps. There are some fans of this approach though here on this list. 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose Maybe some enforcer rule? Like I said, this is to be used alongside the regular build job. So my SP4 1.2.0-SNAPSHOT is building with a set of dependencies on its own and I want to validate that with the dependencies of the target release for P, it is also working just fine. It may just be the same ideally or slightly different (or not slightly at all which requires an explicit validation). So I need to be able to swap those versions for validation purposes and run the build with that. S. /Anders I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade or not, etc). For the second part, it's not easy to force a dependency change in Maven, especially if the version has been specified at the project level. Thanks for reading that far. If you have any idea or know any organisation that tried to implement that, I'd be interested Thanks! S.
Re: dependency management across projects
On Fri, Jan 31, 2014 at 1:16 PM, Anders Hammar and...@hammar.net wrote: The release of the BOM would be that release of a single coherent unit then. It would specify the (marketing) version of the platform P. For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1), v1.4.3 of SP2, etc. Isn't it what I just write in my original post? (without mentioning the BOM) Creating the BOM would be a manual work I think, as you want to make sure that exactly the correct versions are included (might not be the latest releases). Yes, this is already what I do. The very point I am trying to make here is how do you manage that manual BOM on a daily basis. Each sub-project has its own release cycle and we cannot force the versions it has to use for a specific branch. For instance, the product might state that the dependency D should be 2.2.0 (because that's the latest or the one that people generally use) but for backward compatibility reason SP2 has to use 1.8.0. Creating manually the first BOM for P v1.0.0 isn't a problem: i've created a set of tools that I am happy to share once they are fully ready. But maintaining that BOM in the long run is more of a challenge (because we can't force the sub-projects to use those versions so we have to monitor what happens in each sub-project to take the appropriate version at the product level). Thanks again for the feedback! S. /Anders There is also the possibility of creating a grouping pom, which lists all artifacts as dependencies. You would then declare a dependency to that grouping pom and get all deps magically sucked in. However, this is not really the Maven way in my opinion as you wouldn't specify your direct deps bu sort of relly on transitive deps. There are some fans of this approach though here on this list. 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose Maybe some enforcer rule? Like I said, this is to be used alongside the regular build job. So my SP4 1.2.0-SNAPSHOT is building with a set of dependencies on its own and I want to validate that with the dependencies of the target release for P, it is also working just fine. It may just be the same ideally or slightly different (or not slightly at all which requires an explicit validation). So I need to be able to swap those versions for validation purposes and run the build with that. S. /Anders I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade or not, etc). For the second part, it's not easy to force a dependency change in Maven, especially if the version has been specified at the project level. Thanks for reading that far. If you have any idea or know any organisation that tried to implement that, I'd be interested Thanks! S.
Re: dependency management across projects
The release of the BOM would be that release of a single coherent unit then. It would specify the (marketing) version of the platform P. For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1), v1.4.3 of SP2, etc. Isn't it what I just write in my original post? (without mentioning the BOM) I believe so, yes. The key thing in my solution is the BOM. And the BOM will keep the appropriate version of the the sub-products together. The very point I am trying to make here is how do you manage that manual BOM on a daily basis. Each sub-project has its own release cycle and we cannot force the versions it has to use for a specific branch. For instance, the product might state that the dependency D should be 2.2.0 (because that's the latest or the one that people generally use) but for backward compatibility reason SP2 has to use 1.8.0. There is no automatic solution for this that I know of. I suppose that tolls could be created, but keep in mind that in the end, for backward compatibility reason SP2 has to use 1.8.0 is normally a human decision. /Anders Creating manually the first BOM for P v1.0.0 isn't a problem: i've created a set of tools that I am happy to share once they are fully ready. But maintaining that BOM in the long run is more of a challenge (because we can't force the sub-projects to use those versions so we have to monitor what happens in each sub-project to take the appropriate version at the product level). Thanks again for the feedback! S. /Anders There is also the possibility of creating a grouping pom, which lists all artifacts as dependencies. You would then declare a dependency to that grouping pom and get all deps magically sucked in. However, this is not really the Maven way in my opinion as you wouldn't specify your direct deps bu sort of relly on transitive deps. There are some fans of this approach though here on this list. 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose Maybe some enforcer rule? Like I said, this is to be used alongside the regular build job. So my SP4 1.2.0-SNAPSHOT is building with a set of dependencies on its own and I want to validate that with the dependencies of the target release for P, it is also working just fine. It may just be the same ideally or slightly different (or not slightly at all which requires an explicit validation). So I need to be able to swap those versions for validation purposes and run the build with that. S. /Anders I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade or not, etc). For the second part, it's not easy to force a dependency change in Maven, especially if the version has been specified at the project level. Thanks for reading that far. If you have any idea or know any organisation that tried to implement that, I'd be interested Thanks! S.
Re: dependency management across projects
1. Provide a single/coherent dependencyManagement section so that users using P do not have to care about the different versions of the sub-projects: they use P and all the required dependencies are pulled automatically Some confusion here. You're talking about depMgmt and then say that the required deps should be pulled in autoamtically. That will not happen. You still need to specify the deps you have. In any case, this is ok if you want to stay on the Maven way. This depMgmt could be handled/provided in a separate pom which is then included in those projects that want to use the platform/product. Sometimes this is called a BOM (Bill of Material). JBoss provides such a BOM for their app server for example. A quick Google gave this page talking about that: http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms There is also the possibility of creating a grouping pom, which lists all artifacts as dependencies. You would then declare a dependency to that grouping pom and get all deps magically sucked in. However, this is not really the Maven way in my opinion as you wouldn't specify your direct deps bu sort of relly on transitive deps. There are some fans of this approach though here on this list. 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose Maybe some enforcer rule? /Anders I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade or not, etc). For the second part, it's not easy to force a dependency change in Maven, especially if the version has been specified at the project level. Thanks for reading that far. If you have any idea or know any organisation that tried to implement that, I'd be interested Thanks! S.
Re: dependency management across projects
Thanks for the response. On Fri, Jan 31, 2014 at 11:33 AM, Anders Hammar and...@hammar.net wrote: 1. Provide a single/coherent dependencyManagement section so that users using P do not have to care about the different versions of the sub-projects: they use P and all the required dependencies are pulled automatically Some confusion here. You're talking about depMgmt and then say that the required deps should be pulled in autoamtically. That will not happen. You still need to specify the deps you have. Yes, but not the versions. The users will have to add the dependency they want to use, yes. The point here is that they don't have to care about the versions (but I do, which is why I need some tooling) In any case, this is ok if you want to stay on the Maven way. This depMgmt could be handled/provided in a separate pom which is then included in those projects that want to use the platform/product. Sometimes this is called a BOM (Bill of Material). JBoss provides such a BOM for their app server for example. A quick Google gave this page talking about that: http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms BOM is exactly what I want to do, yes. What may not be clear in my original post is that I am looking at this problem as the release manager of P who wants to release P 1.0.0 with SP1 1.2.3, SP2 1.4.3, SP3 4.3.0, etc. I want to have an overview of where the different sub-projects stands with regards to the target for P. Assume that each sub-project has its own release cycle (and is released as a project on its own actually) and at some point those different projects have to be released as a single coherent unit. There is also the possibility of creating a grouping pom, which lists all artifacts as dependencies. You would then declare a dependency to that grouping pom and get all deps magically sucked in. However, this is not really the Maven way in my opinion as you wouldn't specify your direct deps bu sort of relly on transitive deps. There are some fans of this approach though here on this list. 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose Maybe some enforcer rule? Like I said, this is to be used alongside the regular build job. So my SP4 1.2.0-SNAPSHOT is building with a set of dependencies on its own and I want to validate that with the dependencies of the target release for P, it is also working just fine. It may just be the same ideally or slightly different (or not slightly at all which requires an explicit validation). So I need to be able to swap those versions for validation purposes and run the build with that. S. /Anders I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade or not, etc). For the second part, it's not easy to force a dependency change in Maven, especially if the version has been specified at the project level. Thanks for reading that far. If you have any idea or know any organisation that tried to implement that, I'd be interested Thanks! S.
Re: dependency management across projects
Some confusion here. You're talking about depMgmt and then say that the required deps should be pulled in autoamtically. That will not happen. You still need to specify the deps you have. Yes, but not the versions. The users will have to add the dependency they want to use, yes. The point here is that they don't have to care about the versions (but I do, which is why I need some tooling) In any case, this is ok if you want to stay on the Maven way. This depMgmt could be handled/provided in a separate pom which is then included in those projects that want to use the platform/product. Sometimes this is called a BOM (Bill of Material). JBoss provides such a BOM for their app server for example. A quick Google gave this page talking about that: http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms BOM is exactly what I want to do, yes. What may not be clear in my original post is that I am looking at this problem as the release manager of P who wants to release P 1.0.0 with SP1 1.2.3, SP2 1.4.3, SP3 4.3.0, etc. I want to have an overview of where the different sub-projects stands with regards to the target for P. Assume that each sub-project has its own release cycle (and is released as a project on its own actually) and at some point those different projects have to be released as a single coherent unit. The release of the BOM would be that release of a single coherent unit then. It would specify the (marketing) version of the platform P. For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1), v1.4.3 of SP2, etc. Creating the BOM would be a manual work I think, as you want to make sure that exactly the correct versions are included (might not be the latest releases). /Anders There is also the possibility of creating a grouping pom, which lists all artifacts as dependencies. You would then declare a dependency to that grouping pom and get all deps magically sucked in. However, this is not really the Maven way in my opinion as you wouldn't specify your direct deps bu sort of relly on transitive deps. There are some fans of this approach though here on this list. 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose Maybe some enforcer rule? Like I said, this is to be used alongside the regular build job. So my SP4 1.2.0-SNAPSHOT is building with a set of dependencies on its own and I want to validate that with the dependencies of the target release for P, it is also working just fine. It may just be the same ideally or slightly different (or not slightly at all which requires an explicit validation). So I need to be able to swap those versions for validation purposes and run the build with that. S. /Anders I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade or not, etc). For the second part, it's not easy to force a dependency change in Maven, especially if the version has been specified at the project level. Thanks for reading that far. If you have any idea or know any organisation that tried to implement that, I'd be interested Thanks! S.
Re: dependency management across projects
As one of the fans of a non-Maven way to deal with this, I will point you to some documentation on the approach. http://blog.artifact-software.com/tech/?tag=maven This should get you 4 articles that discuss our approach to Maven. http://blog.artifact-software.com/tech/?p=121 Specifically addresses the problem that you are working through. It works well for us. Our big project had over 30 independent modules that depended on more than 70 third party modules - Tomcat, Jetspeed, Apache Commons, Spring, Hibernate, Mysql JSF, CXF, Jasper Reports, etc. We are currently actively developing 2 projects each with about 10 modules (Maven Projects) with the same technology stack (Jackrabbit replacing MySQL and adding Spring-Data) and have continued the same approach. It works well and makes the war files very small and cuts the build time dramatically. It relieves the developer from dealing with versions and dependency configurations. The individual shared libraries have the right versions with the required exclusions already fixed up so inter-library conflicts are resolved. The developer just have to make sure that their code works. If they want to add a third party library that is not included in the corporate utility libraries, this is supposed to be discussed at the project level to see if it should be shared or not. We don't make a big deal about this now that we have a really good core stack settled. At the beginning of each release cycle we review the approved versions and upgrade as appropriate. This lets us review and test dependency changes as a team. We use the STS version of Eclipse so we have full support for Maven and can easily see where dependencies are coming from and where potential dependency conflicts occur between third party software so exclusions can be adjusted. Ron On 31/01/2014 5:33 AM, Anders Hammar wrote: 1. Provide a single/coherent dependencyManagement section so that users using P do not have to care about the different versions of the sub-projects: they use P and all the required dependencies are pulled automatically Some confusion here. You're talking about depMgmt and then say that the required deps should be pulled in autoamtically. That will not happen. You still need to specify the deps you have. In any case, this is ok if you want to stay on the Maven way. This depMgmt could be handled/provided in a separate pom which is then included in those projects that want to use the platform/product. Sometimes this is called a BOM (Bill of Material). JBoss provides such a BOM for their app server for example. A quick Google gave this page talking about that: http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms There is also the possibility of creating a grouping pom, which lists all artifacts as dependencies. You would then declare a dependency to that grouping pom and get all deps magically sucked in. However, this is not really the Maven way in my opinion as you wouldn't specify your direct deps bu sort of relly on transitive deps. There are some fans of this approach though here on this list. 2. Build configs that *force* each sub-project to run with the list of dependencies for the project (to ensure all tests pass, etc). This is to be used alongside the regular build job for validation purpose Maybe some enforcer rule? /Anders I started to look at this and my first trial was to generate a report with all the dependencies of each project and build a consolidated report that I can match against the candidates. This would help manage the first goal as if a dependency gets added, removed or updated, the global dependencyManagement has to be impacted manually (do we upgrade or not, etc). For the second part, it's not easy to force a dependency change in Maven, especially if the version has been specified at the project level. Thanks for reading that far. If you have any idea or know any organisation that tried to implement that, I'd be interested Thanks! S. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency management multi-module
Nevermind, what i described does in fact work :) The error was I receiving was unrelated to having dependencymanagement in the two pom projects. On Sun, Jan 16, 2011 at 11:08 AM, CassUser CassUser cassu...@gmail.comwrote: Hey all, I have a parent module with dependencies listed under the dependencymanagement section. I now have two modules under this parent, which are both pom packaging maven projects. both the sub parent projects have common dependencies along with some specific. If i put a dependencymanagement section under each of the sub parents, then the modules under each isn't able to import those specific dependencies. Is there any way to do this elegantly, or do i have to put all dependencies in the parent (which is not the end of the world). Thanks.
Re: Dependency Management +
We use a plugin called deptools to automatically fail the build if a maven chooses a dependency that is older than the version some other dependency requires it to be.. Have a look at it here: http://github.com/mbknor/deptools -Morten On Mon, Apr 26, 2010 at 6:12 PM, Nick Stolwijk nick.stolw...@gmail.com wrote: To enforce that all plugins are versioned use the enforcer plugin [1] with the rule requirePluginVersions [2]. For the dependencymanagement enforcement take a look at the Maven Dependency Plugin [3] with the goals analyze-only [4] and anaylyze-dep-mgt [5]. [1] http://maven.apache.org/plugins/maven-enforcer-plugin/ [2] http://maven.apache.org/enforcer/enforcer-rules/requirePluginVersions.html [3] http://maven.apache.org/plugins/maven-dependency-plugin/ [4] http://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html [5] http://maven.apache.org/plugins/maven-dependency-plugin/analyze-dep-mgt-mojo.html Hth, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Mon, Apr 26, 2010 at 5:59 PM, solo1970 sonia.lodoviche...@ericsson.com wrote: Hello, For my project, I need to identify plugins/dependencies that don't have explicit versions specified (i.e. that would use the latest version) Also, I would need a plugin to fail my build if the aggregated modules don't use the same version of inter-project dependencies. (would check for project dependency inconsistency) Any ideas? Sonia -- View this message in context: http://old.nabble.com/Dependency-Management-%2B-tp28366761p28366761.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 - 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 Management +
To enforce that all plugins are versioned use the enforcer plugin [1] with the rule requirePluginVersions [2]. For the dependencymanagement enforcement take a look at the Maven Dependency Plugin [3] with the goals analyze-only [4] and anaylyze-dep-mgt [5]. [1] http://maven.apache.org/plugins/maven-enforcer-plugin/ [2] http://maven.apache.org/enforcer/enforcer-rules/requirePluginVersions.html [3] http://maven.apache.org/plugins/maven-dependency-plugin/ [4] http://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html [5] http://maven.apache.org/plugins/maven-dependency-plugin/analyze-dep-mgt-mojo.html Hth, Nick Stolwijk ~Java Developer~ IPROFS BV. Claus Sluterweg 125 2012 WS Haarlem http://www.iprofs.nl On Mon, Apr 26, 2010 at 5:59 PM, solo1970 sonia.lodoviche...@ericsson.com wrote: Hello, For my project, I need to identify plugins/dependencies that don't have explicit versions specified (i.e. that would use the latest version) Also, I would need a plugin to fail my build if the aggregated modules don't use the same version of inter-project dependencies. (would check for project dependency inconsistency) Any ideas? Sonia -- View this message in context: http://old.nabble.com/Dependency-Management-%2B-tp28366761p28366761.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency management question
I just ran into a problem with the import scope feature. It does not resolve properly. I.e. Project B uses import scope feature on Project A. Project C uses import scope feature on Project B. Project C cannot build because it says that A does not exist. I'm using maven 2.1.0, has this been fixed in later versions? Is there a way to make this work? -Dave On Sat, Nov 7, 2009 at 11:13 AM, Anders Hammar and...@hammar.net wrote: Regarding the feature the assimilate plugin gives you, I would do like this instead: http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/ /Anders On Sat, Nov 7, 2009 at 19:07, Anders Hammar and...@hammar.net wrote: Yes, it exists in Maven 2.0.9+. Sorry, if the link wasn't clear enough. Have a look here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies The import support is different that what the assimilate gives you. The one described above is for dep management, while the assimilate plugin are for actual dependencies. /Anders On Sat, Nov 7, 2009 at 17:41, David Hoffer dhoff...@gmail.com wrote: That looks good. Just to be clear, in that link it seemed to be a discussion of what to possibly add to maven...are you saying that is in maven now? Btw I use 2.1.0. Also what do you think about http://code.google.com/p/assimilate/mentioned in the bottom of this link? -Dave On Sat, Nov 7, 2009 at 9:10 AM, Anders Hammar and...@hammar.net wrote: Yes, you could use the import scope at the top level to import dependency management defined in another pom (which could be the ones in D). http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies /Anders On Sat, Nov 7, 2009 at 15:42, David Hoffer dhoff...@gmail.com wrote: We have a large maven project where each component (or group of artifacts) each uses dependencyManagement to control what versions are used and to specify exclusions, etc. At an individual component level this works well. You can think of our project as being lots of new maven/components (A, B, C) that act as a facade around a legacy component D...so D is at the bottom of the dependency graph. However we really need D's dependency management to be at the top level too. That is, lots of changes happen at the legacy component D and we don't want to have to manually track dependency changes there and copy to the top level. Is there a way in maven to say, at the top-level, use D's dependencies for me too? If not, how hard would it be to write a plugin that does this?
Re: Dependency management question
I assume that project B builds just fine? Never had import dependency in two levels like you have, so I don't know if it's a known bug being fixed. Try Maven 2.2.1 and see, or search jira! /Anders On Mon, Nov 9, 2009 at 20:15, David Hoffer dhoff...@gmail.com wrote: I just ran into a problem with the import scope feature. It does not resolve properly. I.e. Project B uses import scope feature on Project A. Project C uses import scope feature on Project B. Project C cannot build because it says that A does not exist. I'm using maven 2.1.0, has this been fixed in later versions? Is there a way to make this work? -Dave On Sat, Nov 7, 2009 at 11:13 AM, Anders Hammar and...@hammar.net wrote: Regarding the feature the assimilate plugin gives you, I would do like this instead: http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/ /Anders On Sat, Nov 7, 2009 at 19:07, Anders Hammar and...@hammar.net wrote: Yes, it exists in Maven 2.0.9+. Sorry, if the link wasn't clear enough. Have a look here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies The import support is different that what the assimilate gives you. The one described above is for dep management, while the assimilate plugin are for actual dependencies. /Anders On Sat, Nov 7, 2009 at 17:41, David Hoffer dhoff...@gmail.com wrote: That looks good. Just to be clear, in that link it seemed to be a discussion of what to possibly add to maven...are you saying that is in maven now? Btw I use 2.1.0. Also what do you think about http://code.google.com/p/assimilate/mentioned in the bottom of this link? -Dave On Sat, Nov 7, 2009 at 9:10 AM, Anders Hammar and...@hammar.net wrote: Yes, you could use the import scope at the top level to import dependency management defined in another pom (which could be the ones in D). http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies /Anders On Sat, Nov 7, 2009 at 15:42, David Hoffer dhoff...@gmail.com wrote: We have a large maven project where each component (or group of artifacts) each uses dependencyManagement to control what versions are used and to specify exclusions, etc. At an individual component level this works well. You can think of our project as being lots of new maven/components (A, B, C) that act as a facade around a legacy component D...so D is at the bottom of the dependency graph. However we really need D's dependency management to be at the top level too. That is, lots of changes happen at the legacy component D and we don't want to have to manually track dependency changes there and copy to the top level. Is there a way in maven to say, at the top-level, use D's dependencies for me too? If not, how hard would it be to write a plugin that does this?
Re: Dependency management question
Yes, building project B is just fine...I thought I had a working solution using import scope. Then other developers in our company tried building C and reported the failure. What I note in the console error is: Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository com.issinc.webtas:webtas-parent:pom:4.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) (Where webtas-parent is A.) If I am to believe this report...its looking in the wrong repo. We have our own corporate repo, our settings.xml points all requests to our internal URL so it should not look at http://repo1.maven.org/maven2 directly. Any thoughts? -Dave On Mon, Nov 9, 2009 at 12:19 PM, Anders Hammar and...@hammar.net wrote: I assume that project B builds just fine? Never had import dependency in two levels like you have, so I don't know if it's a known bug being fixed. Try Maven 2.2.1 and see, or search jira! /Anders On Mon, Nov 9, 2009 at 20:15, David Hoffer dhoff...@gmail.com wrote: I just ran into a problem with the import scope feature. It does not resolve properly. I.e. Project B uses import scope feature on Project A. Project C uses import scope feature on Project B. Project C cannot build because it says that A does not exist. I'm using maven 2.1.0, has this been fixed in later versions? Is there a way to make this work? -Dave On Sat, Nov 7, 2009 at 11:13 AM, Anders Hammar and...@hammar.net wrote: Regarding the feature the assimilate plugin gives you, I would do like this instead: http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/ /Anders On Sat, Nov 7, 2009 at 19:07, Anders Hammar and...@hammar.net wrote: Yes, it exists in Maven 2.0.9+. Sorry, if the link wasn't clear enough. Have a look here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies The import support is different that what the assimilate gives you. The one described above is for dep management, while the assimilate plugin are for actual dependencies. /Anders On Sat, Nov 7, 2009 at 17:41, David Hoffer dhoff...@gmail.com wrote: That looks good. Just to be clear, in that link it seemed to be a discussion of what to possibly add to maven...are you saying that is in maven now? Btw I use 2.1.0. Also what do you think about http://code.google.com/p/assimilate/mentioned in the bottom of this link? -Dave On Sat, Nov 7, 2009 at 9:10 AM, Anders Hammar and...@hammar.net wrote: Yes, you could use the import scope at the top level to import dependency management defined in another pom (which could be the ones in D). http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies /Anders On Sat, Nov 7, 2009 at 15:42, David Hoffer dhoff...@gmail.com wrote: We have a large maven project where each component (or group of artifacts) each uses dependencyManagement to control what versions are used and to specify exclusions, etc. At an individual component level this works well. You can think of our project as being lots of new maven/components (A, B, C) that act as a facade around a legacy component D...so D is at the bottom of the dependency graph. However we really need D's dependency management to be at the top level too. That is, lots of changes happen at the legacy component D and we don't want to have to manually track dependency changes there and copy to the top level. Is there a way in maven to say, at the top-level, use D's dependencies for me too? If not, how hard would it be to write a plugin that does this?
Re: Dependency management question
Sorry, no. I would investigate why it's looking in central first of all though. /Anders On Mon, Nov 9, 2009 at 20:25, David Hoffer dhoff...@gmail.com wrote: Yes, building project B is just fine...I thought I had a working solution using import scope. Then other developers in our company tried building C and reported the failure. What I note in the console error is: Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository com.issinc.webtas:webtas-parent:pom:4.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) (Where webtas-parent is A.) If I am to believe this report...its looking in the wrong repo. We have our own corporate repo, our settings.xml points all requests to our internal URL so it should not look at http://repo1.maven.org/maven2 directly. Any thoughts? -Dave On Mon, Nov 9, 2009 at 12:19 PM, Anders Hammar and...@hammar.net wrote: I assume that project B builds just fine? Never had import dependency in two levels like you have, so I don't know if it's a known bug being fixed. Try Maven 2.2.1 and see, or search jira! /Anders On Mon, Nov 9, 2009 at 20:15, David Hoffer dhoff...@gmail.com wrote: I just ran into a problem with the import scope feature. It does not resolve properly. I.e. Project B uses import scope feature on Project A. Project C uses import scope feature on Project B. Project C cannot build because it says that A does not exist. I'm using maven 2.1.0, has this been fixed in later versions? Is there a way to make this work? -Dave On Sat, Nov 7, 2009 at 11:13 AM, Anders Hammar and...@hammar.net wrote: Regarding the feature the assimilate plugin gives you, I would do like this instead: http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/ /Anders On Sat, Nov 7, 2009 at 19:07, Anders Hammar and...@hammar.net wrote: Yes, it exists in Maven 2.0.9+. Sorry, if the link wasn't clear enough. Have a look here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies The import support is different that what the assimilate gives you. The one described above is for dep management, while the assimilate plugin are for actual dependencies. /Anders On Sat, Nov 7, 2009 at 17:41, David Hoffer dhoff...@gmail.com wrote: That looks good. Just to be clear, in that link it seemed to be a discussion of what to possibly add to maven...are you saying that is in maven now? Btw I use 2.1.0. Also what do you think about http://code.google.com/p/assimilate/mentioned in the bottom of this link? -Dave On Sat, Nov 7, 2009 at 9:10 AM, Anders Hammar and...@hammar.net wrote: Yes, you could use the import scope at the top level to import dependency management defined in another pom (which could be the ones in D). http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies /Anders On Sat, Nov 7, 2009 at 15:42, David Hoffer dhoff...@gmail.com wrote: We have a large maven project where each component (or group of artifacts) each uses dependencyManagement to control what versions are used and to specify exclusions, etc. At an individual component level this works well. You can think of our project as being lots of new maven/components (A, B, C) that act as a facade around a legacy component D...so D is at the bottom of the dependency graph. However we really need D's dependency management to be at the top level too. That is, lots of changes happen at the legacy component D and we don't want to have to manually track dependency changes there and copy to the top level. Is there a way in maven to say, at the top-level, use D's dependencies for me too? If not, how hard would it be to write a plugin that does this?
Re: Dependency management question
Ah, and as always. It might help building a very simple project to reproduce this. Removing all unimportant parts. If it then works, you know it's not a Maven bug. If it still doesn't work, you have an example that reproduces the issue that you can attach to the jira. That increases the likelihood to get it fixed. /Anders On Mon, Nov 9, 2009 at 20:37, Anders Hammar and...@hammar.net wrote: Sorry, no. I would investigate why it's looking in central first of all though. /Anders On Mon, Nov 9, 2009 at 20:25, David Hoffer dhoff...@gmail.com wrote: Yes, building project B is just fine...I thought I had a working solution using import scope. Then other developers in our company tried building C and reported the failure. What I note in the console error is: Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository com.issinc.webtas:webtas-parent:pom:4.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) (Where webtas-parent is A.) If I am to believe this report...its looking in the wrong repo. We have our own corporate repo, our settings.xml points all requests to our internal URL so it should not look at http://repo1.maven.org/maven2 directly. Any thoughts? -Dave On Mon, Nov 9, 2009 at 12:19 PM, Anders Hammar and...@hammar.net wrote: I assume that project B builds just fine? Never had import dependency in two levels like you have, so I don't know if it's a known bug being fixed. Try Maven 2.2.1 and see, or search jira! /Anders On Mon, Nov 9, 2009 at 20:15, David Hoffer dhoff...@gmail.com wrote: I just ran into a problem with the import scope feature. It does not resolve properly. I.e. Project B uses import scope feature on Project A. Project C uses import scope feature on Project B. Project C cannot build because it says that A does not exist. I'm using maven 2.1.0, has this been fixed in later versions? Is there a way to make this work? -Dave On Sat, Nov 7, 2009 at 11:13 AM, Anders Hammar and...@hammar.net wrote: Regarding the feature the assimilate plugin gives you, I would do like this instead: http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/ /Anders On Sat, Nov 7, 2009 at 19:07, Anders Hammar and...@hammar.net wrote: Yes, it exists in Maven 2.0.9+. Sorry, if the link wasn't clear enough. Have a look here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies The import support is different that what the assimilate gives you. The one described above is for dep management, while the assimilate plugin are for actual dependencies. /Anders On Sat, Nov 7, 2009 at 17:41, David Hoffer dhoff...@gmail.com wrote: That looks good. Just to be clear, in that link it seemed to be a discussion of what to possibly add to maven...are you saying that is in maven now? Btw I use 2.1.0. Also what do you think about http://code.google.com/p/assimilate/mentioned in the bottom of this link? -Dave On Sat, Nov 7, 2009 at 9:10 AM, Anders Hammar and...@hammar.net wrote: Yes, you could use the import scope at the top level to import dependency management defined in another pom (which could be the ones in D). http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies /Anders On Sat, Nov 7, 2009 at 15:42, David Hoffer dhoff...@gmail.com wrote: We have a large maven project where each component (or group of artifacts) each uses dependencyManagement to control what versions are used and to specify exclusions, etc. At an individual component level this works well. You can think of our project as being lots of new maven/components (A, B, C) that act as a facade around a legacy component D...so D is at the bottom of the dependency graph. However we really need D's dependency management to be at the top level too. That is, lots of changes happen at the legacy component D and we don't want to have to manually track dependency changes there and copy to the top level. Is there a way in maven to say, at the top-level, use D's dependencies for me too? If not, how hard would it be to write a plugin that does this?
Re: Dependency management question
Good idea for sure. I tried maven v2.2.1 and it had the same problem. I'm going to try to use A as my parent for now. A is more than I want/need as my parent but should work. -Dave On Mon, Nov 9, 2009 at 12:39 PM, Anders Hammar and...@hammar.net wrote: Ah, and as always. It might help building a very simple project to reproduce this. Removing all unimportant parts. If it then works, you know it's not a Maven bug. If it still doesn't work, you have an example that reproduces the issue that you can attach to the jira. That increases the likelihood to get it fixed. /Anders On Mon, Nov 9, 2009 at 20:37, Anders Hammar and...@hammar.net wrote: Sorry, no. I would investigate why it's looking in central first of all though. /Anders On Mon, Nov 9, 2009 at 20:25, David Hoffer dhoff...@gmail.com wrote: Yes, building project B is just fine...I thought I had a working solution using import scope. Then other developers in our company tried building C and reported the failure. What I note in the console error is: Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository com.issinc.webtas:webtas-parent:pom:4.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) (Where webtas-parent is A.) If I am to believe this report...its looking in the wrong repo. We have our own corporate repo, our settings.xml points all requests to our internal URL so it should not look at http://repo1.maven.org/maven2 directly. Any thoughts? -Dave On Mon, Nov 9, 2009 at 12:19 PM, Anders Hammar and...@hammar.net wrote: I assume that project B builds just fine? Never had import dependency in two levels like you have, so I don't know if it's a known bug being fixed. Try Maven 2.2.1 and see, or search jira! /Anders On Mon, Nov 9, 2009 at 20:15, David Hoffer dhoff...@gmail.com wrote: I just ran into a problem with the import scope feature. It does not resolve properly. I.e. Project B uses import scope feature on Project A. Project C uses import scope feature on Project B. Project C cannot build because it says that A does not exist. I'm using maven 2.1.0, has this been fixed in later versions? Is there a way to make this work? -Dave On Sat, Nov 7, 2009 at 11:13 AM, Anders Hammar and...@hammar.net wrote: Regarding the feature the assimilate plugin gives you, I would do like this instead: http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/ /Anders On Sat, Nov 7, 2009 at 19:07, Anders Hammar and...@hammar.net wrote: Yes, it exists in Maven 2.0.9+. Sorry, if the link wasn't clear enough. Have a look here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies The import support is different that what the assimilate gives you. The one described above is for dep management, while the assimilate plugin are for actual dependencies. /Anders On Sat, Nov 7, 2009 at 17:41, David Hoffer dhoff...@gmail.com wrote: That looks good. Just to be clear, in that link it seemed to be a discussion of what to possibly add to maven...are you saying that is in maven now? Btw I use 2.1.0. Also what do you think about http://code.google.com/p/assimilate/mentioned in the bottom of this link? -Dave On Sat, Nov 7, 2009 at 9:10 AM, Anders Hammar and...@hammar.net wrote: Yes, you could use the import scope at the top level to import dependency management defined in another pom (which could be the ones in D). http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies /Anders On Sat, Nov 7, 2009 at 15:42, David Hoffer dhoff...@gmail.com wrote: We have a large maven project where each component (or group of artifacts) each uses dependencyManagement to control what versions are used and to specify exclusions, etc. At an individual component level this works well. You can think of our project as being lots of new maven/components (A, B, C) that act as a facade around a legacy component D...so D is at the bottom of the dependency graph. However we really need D's dependency management to be at the top level too. That is, lots of changes happen at the legacy component D and we don't want to have to manually track dependency changes there and
Re: Dependency management question
Yes, you could use the import scope at the top level to import dependency management defined in another pom (which could be the ones in D). http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies /Anders On Sat, Nov 7, 2009 at 15:42, David Hoffer dhoff...@gmail.com wrote: We have a large maven project where each component (or group of artifacts) each uses dependencyManagement to control what versions are used and to specify exclusions, etc. At an individual component level this works well. You can think of our project as being lots of new maven/components (A, B, C) that act as a facade around a legacy component D...so D is at the bottom of the dependency graph. However we really need D's dependency management to be at the top level too. That is, lots of changes happen at the legacy component D and we don't want to have to manually track dependency changes there and copy to the top level. Is there a way in maven to say, at the top-level, use D's dependencies for me too? If not, how hard would it be to write a plugin that does this?
Re: Dependency management question
That looks good. Just to be clear, in that link it seemed to be a discussion of what to possibly add to maven...are you saying that is in maven now? Btw I use 2.1.0. Also what do you think about http://code.google.com/p/assimilate/ mentioned in the bottom of this link? -Dave On Sat, Nov 7, 2009 at 9:10 AM, Anders Hammar and...@hammar.net wrote: Yes, you could use the import scope at the top level to import dependency management defined in another pom (which could be the ones in D). http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies /Anders On Sat, Nov 7, 2009 at 15:42, David Hoffer dhoff...@gmail.com wrote: We have a large maven project where each component (or group of artifacts) each uses dependencyManagement to control what versions are used and to specify exclusions, etc. At an individual component level this works well. You can think of our project as being lots of new maven/components (A, B, C) that act as a facade around a legacy component D...so D is at the bottom of the dependency graph. However we really need D's dependency management to be at the top level too. That is, lots of changes happen at the legacy component D and we don't want to have to manually track dependency changes there and copy to the top level. Is there a way in maven to say, at the top-level, use D's dependencies for me too? If not, how hard would it be to write a plugin that does this?
Re: Dependency management question
Yes, it exists in Maven 2.0.9+. Sorry, if the link wasn't clear enough. Have a look here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies The import support is different that what the assimilate gives you. The one described above is for dep management, while the assimilate plugin are for actual dependencies. /Anders On Sat, Nov 7, 2009 at 17:41, David Hoffer dhoff...@gmail.com wrote: That looks good. Just to be clear, in that link it seemed to be a discussion of what to possibly add to maven...are you saying that is in maven now? Btw I use 2.1.0. Also what do you think about http://code.google.com/p/assimilate/mentioned in the bottom of this link? -Dave On Sat, Nov 7, 2009 at 9:10 AM, Anders Hammar and...@hammar.net wrote: Yes, you could use the import scope at the top level to import dependency management defined in another pom (which could be the ones in D). http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies /Anders On Sat, Nov 7, 2009 at 15:42, David Hoffer dhoff...@gmail.com wrote: We have a large maven project where each component (or group of artifacts) each uses dependencyManagement to control what versions are used and to specify exclusions, etc. At an individual component level this works well. You can think of our project as being lots of new maven/components (A, B, C) that act as a facade around a legacy component D...so D is at the bottom of the dependency graph. However we really need D's dependency management to be at the top level too. That is, lots of changes happen at the legacy component D and we don't want to have to manually track dependency changes there and copy to the top level. Is there a way in maven to say, at the top-level, use D's dependencies for me too? If not, how hard would it be to write a plugin that does this?
Re: Dependency management question
Regarding the feature the assimilate plugin gives you, I would do like this instead: http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/ /Anders On Sat, Nov 7, 2009 at 19:07, Anders Hammar and...@hammar.net wrote: Yes, it exists in Maven 2.0.9+. Sorry, if the link wasn't clear enough. Have a look here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies The import support is different that what the assimilate gives you. The one described above is for dep management, while the assimilate plugin are for actual dependencies. /Anders On Sat, Nov 7, 2009 at 17:41, David Hoffer dhoff...@gmail.com wrote: That looks good. Just to be clear, in that link it seemed to be a discussion of what to possibly add to maven...are you saying that is in maven now? Btw I use 2.1.0. Also what do you think about http://code.google.com/p/assimilate/mentioned in the bottom of this link? -Dave On Sat, Nov 7, 2009 at 9:10 AM, Anders Hammar and...@hammar.net wrote: Yes, you could use the import scope at the top level to import dependency management defined in another pom (which could be the ones in D). http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies /Anders On Sat, Nov 7, 2009 at 15:42, David Hoffer dhoff...@gmail.com wrote: We have a large maven project where each component (or group of artifacts) each uses dependencyManagement to control what versions are used and to specify exclusions, etc. At an individual component level this works well. You can think of our project as being lots of new maven/components (A, B, C) that act as a facade around a legacy component D...so D is at the bottom of the dependency graph. However we really need D's dependency management to be at the top level too. That is, lots of changes happen at the legacy component D and we don't want to have to manually track dependency changes there and copy to the top level. Is there a way in maven to say, at the top-level, use D's dependencies for me too? If not, how hard would it be to write a plugin that does this?
Re: Dependency Management
thx! That thread Told me all I needed to know! :-) Peter
Re: Dependency Management
Hi! On Thursday 25 June 2009 Peter Horlock wrote: Hi, I've got a question regarding dependency management - I've got a project with a default tree layout - it uses subprojects, which again are using subprojects which again... Now, one of these subprojects defined a dependency scope as compile. It's grand-grand-parent project or the root project defined the same dependency as scope test. Now the dependency was set to test and as a result was not added to the war when deployed. The error how ever was only found on runtime and the entire project failed on production! :-( Why is that so? Shouldn't dependency, if it is needed, stay there? This problem was discussed just about a month ago. Here is the link to the thread: http://www.nabble.com/Transitive-and-inherited-dependencies---potential-bug,-or-my--misunderstanding-of-the-mechanism-to23403092.html#a23436523 hth, - martin signature.asc Description: This is a digitally signed message part.
Re: dependency management in sub-sub-module
I'm new to Maven so take this with a grain of salt, but I don't see why you can't just do: ...snip... modules modulemodule1/module modulemodule2/module moduleclient1/module moduleclient2/module /modules ...snip... From: Markus Jostock markus.jost...@softwareag.com To: Maven Users List users@maven.apache.org Sent: Thursday, June 11, 2009 8:17:01 AM Subject: dependency management in sub-sub-module Dear all I have module structure with two levels of sub-modules. The root level pom defines a dependency managment section which is working fine for sub-modules. But for a deeper level, the dependency management section of the root pom apparently is not available any more ... root +- module1 -- working fine +- module2 -- working fine +- clients +- client1 -- compile errors ... +- client2 -- compile errors ... During build, the system does not complain about unsatisfied dependencies, but in the compile phase the compiler cannot find the symbols. Would anyone have an idea what I could be doing wrong here? Any advice would be gratefully appreciated ... Many, many thanks! Markus root-pom: === project modelVersion4.0.0/modelVersion groupIdmy.groupid/groupId artifactIdroot/artifactId packagingpom/packaging version1.0-SNAPSHOT/version nameMy Project/name modules modulemodule1/module modulemodule2/module moduleclients/module /modules dependencyManagement dependency groupIdcommons-beanutils/groupId artifactIdcommons-beanutils/artifactId version1.8.0/version scopecompile/scope /dependency ... /dependencyManagement /project clients-pom: project modelVersion4.0.0/modelVersion parent artifactIdroot/artifactId groupIdmy.groupid/groupId version1.0-SNAPSHOT/version /parent artifactIdclients/artifactId nameMy Clients/name packagingpom/packaging modules moduleclient1/module moduleclient2/module /modules /project client1-pom: project modelVersion4.0.0/modelVersion parent artifactIdclients/artifactId groupIdmy.groupId/groupId version1.0-SNAPSHOT/version /parent artifactIdclient1/artifactId nameMy Client 1/name dependencies dependency groupIdcommons-beanutils/groupId artifactIdcommons-beanutils/artifactId scopecompile/scope /dependency ... /dependencies /project - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency management management
You could use the dependency management[1] report for that. Hth, [1] http://maven.apache.org/plugins/maven-project-info-reports-plugin/dependency-management-mojo.html Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Tue, Apr 21, 2009 at 8:15 PM, Jon Strayer j...@strayer.org wrote: Our project has about 65 dependencies listed. I just discovered that one was listed twice. Is there a tool that will detect that for me? Or, perhaps one that will sort the dependencies to make it easier to scan for duplicates? -- All religions are Scientology complete - 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 management management
I like to use: mvn dependency:tree mvn dependency:analyze On Tue, 21 Apr 2009 20:19:54 +0200, Nick Stolwijk nick.stolw...@gmail.com wrote: You could use the dependency management[1] report for that. Hth, [1] http://maven.apache.org/plugins/maven-project-info-reports-plugin/dependency-management-mojo.html Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Tue, Apr 21, 2009 at 8:15 PM, Jon Strayer j...@strayer.org wrote: Our project has about 65 dependencies listed. I just discovered that one was listed twice. Is there a tool that will detect that for me? Or, perhaps one that will sort the dependencies to make it easier to scan for duplicates? -- All religions are Scientology complete - 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 -- Nayan Hajratwala http://agileshrugged.com 734.658.6032 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency management
On 14/11/2007, Brian De Pradine [EMAIL PROTECTED] wrote: Hello all, Is there a way to configure maven2 so that it loads classes from a dependency that I specify rather than from the JVM? could you explain which classes you'd want to load from a dependency rather than the JVM - and also explain why you want to do this? (there may be a better solution) I guess that I need to configure the class path so that my library is located in front of the libraries from the JVM. the core JVM libraries are supplied from the boot classloader, which all classloaders delegate to in the normal parent delegation model, so if you want to make sure you override the JVM libraries you'd normally use -Xbootclasspath/p:... (JVM libraries are separate from application libraries, which use the normal classpath) Cheers Brian DePradine Web Services Development IBM Hursley External +44 (0) 1962 816319 Internal 246319 If you can't find the time to do it right the first time, where will you find the time to do it again? Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- Cheers, Stuart
Re: Dependency management
On 8/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I have a question that I hope isn't too basic. I've been trying to reconcile the behavior of dependency management with my expectations. I'll state in advance that I'm more than willing to admit that my expectations might be unrealistic. We've got a home grown dependency mechanism that works as follows: If artifact A requires artifact B and artifact B does not exist it builds artifact B before building artifact A. That isn't really a dependency mechanism in Maven - that is a module hierarchy. As long as module B exists in the set of modules along with A, and A depends on B, then B will be built first. To further clarify what I'd like to do, I had originally started with the modules element but quickly ran into this screnario: artifacts A and B are built in the same POM (packagingpom/packaging), and both require artifact C. This does not make it past the reactor engine, which will not allow artifact C to appear more than once. True - why would you want the same artifact built more than once? Is this behavior possible with the dependencyManagement tags? So far it doesn't seem likely, but perhaps I'm not understanding dependency management, which brings us back to that start of this message. I'm not understanding what you want to do. Is what behavior possible? Making the reactor build a project twice? If that is your question, then no. To clarify: all dependencyManagement does is pre-configure a set of dependencies for use by inheriting projects. For example, if project P is the parent with a depMan containing junit:junit:4.0, then an inheriting child project C can add a dependency junit:junit, and junit will be automatically configured to be version 4.0... the child need not specify anything. This gives you a single point of management for dependency configurations like versions, or exclusions. -- Eric Redmond http://blog.propellors.net Thanks Robert Egan This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
Re: Dependency management
Eric Redmond [EMAIL PROTECTED] wrote on 08/21/2007 12:12:55 PM: On 8/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I have a question that I hope isn't too basic. I've been trying to reconcile the behavior of dependency management with my expectations. I'll state in advance that I'm more than willing to admit that my expectations might be unrealistic. We've got a home grown dependency mechanism that works as follows: If artifact A requires artifact B and artifact B does not exist it builds artifact B before building artifact A. That isn't really a dependency mechanism in Maven - that is a module hierarchy. As long as module B exists in the set of modules along with A, and A depends on B, then B will be built first. Essentially, yes. If the reactor allowed it I would use module hierarchies. To further clarify what I'd like to do, I had originally started with the modules element but quickly ran into this screnario: artifacts A and B are built in the same POM (packagingpom/packaging), and both require artifact C. This does not make it past the reactor engine, which will not allow artifact C to appear more than once. True - why would you want the same artifact built more than once? You wouldn't. Our home grown system remembers that you've already visited the module during this phase and skips it for visits 2 through N. Is this behavior possible with the dependencyManagement tags? So far it doesn't seem likely, but perhaps I'm not understanding dependency management, which brings us back to that start of this message. I'm not understanding what you want to do. Is what behavior possible? Making the reactor build a project twice? If that is your question, then no. Thanks for the explanation. I didn't think dependency management was the answer either. I'll have to port our home grown system to a plugin at some point, or convince management to re-engineer the build process. Thanks again, Robert Egan This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
Re: Dependency management
[EMAIL PROTECTED] schrieb: Eric Redmond [EMAIL PROTECTED] wrote on 08/21/2007 12:12:55 PM: On 8/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I have a question that I hope isn't too basic. I've been trying to reconcile the behavior of dependency management with my expectations. I'll state in advance that I'm more than willing to admit that my expectations might be unrealistic. We've got a home grown dependency mechanism that works as follows: If artifact A requires artifact B and artifact B does not exist it builds artifact B before building artifact A. That isn't really a dependency mechanism in Maven - that is a module hierarchy. As long as module B exists in the set of modules along with A, and A depends on B, then B will be built first. Essentially, yes. If the reactor allowed it I would use module hierarchies. Can you give a somewhat more specific example what the reactor does not allow? The scenario you describe above is a fairly standard use-case I would say. Perhaps a set of minimal example poms and a short description of what you expect them to do would be helpful. To further clarify what I'd like to do, I had originally started with the modules element but quickly ran into this screnario: artifacts A and B are built in the same POM (packagingpom/packaging), and both require artifact C. This does not make it past the reactor engine, which will not allow artifact C to appear more than once. True - why would you want the same artifact built more than once? You wouldn't. Our home grown system remembers that you've already visited the module during this phase and skips it for visits 2 through N. Maven calculates the dependency tree for the set of reactor projects and then orders the builds of the projects (modules) in such an order that all dependencies of a module are available when the module is build. So what you want to do should be entirely possible with maven out of the box... Or I totally misunderstand what you want to do. Is this behavior possible with the dependencyManagement tags? So far it doesn't seem likely, but perhaps I'm not understanding dependency management, which brings us back to that start of this message. I'm not understanding what you want to do. Is what behavior possible? Making the reactor build a project twice? If that is your question, then no. Thanks for the explanation. I didn't think dependency management was the answer either. I'll have to port our home grown system to a plugin at some point, or convince management to re-engineer the build process. Thanks again, Robert Egan -Tim This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency management
On 8/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Eric Redmond [EMAIL PROTECTED] wrote on 08/21/2007 12:12:55 PM: On 8/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I have a question that I hope isn't too basic. I've been trying to reconcile the behavior of dependency management with my expectations. I'll state in advance that I'm more than willing to admit that my expectations might be unrealistic. We've got a home grown dependency mechanism that works as follows: If artifact A requires artifact B and artifact B does not exist it builds artifact B before building artifact A. That isn't really a dependency mechanism in Maven - that is a module hierarchy. As long as module B exists in the set of modules along with A, and A depends on B, then B will be built first. Essentially, yes. If the reactor allowed it I would use module hierarchies. Again, I am confused. What use-case do you have where you cannot just create a multi-module project that contains project A and B as modules? To further clarify what I'd like to do, I had originally started with the modules element but quickly ran into this screnario: artifacts A and B are built in the same POM (packagingpom/packaging), and both require artifact C. This does not make it past the reactor engine, which will not allow artifact C to appear more than once. True - why would you want the same artifact built more than once? You wouldn't. Our home grown system remembers that you've already visited the module during this phase and skips it for visits 2 through N. So does Maven. I just don't understand what you want. Maven already satisfies the use-cases you put forth. Is this behavior possible with the dependencyManagement tags? So far it doesn't seem likely, but perhaps I'm not understanding dependency management, which brings us back to that start of this message. I'm not understanding what you want to do. Is what behavior possible? Making the reactor build a project twice? If that is your question, then no. Thanks for the explanation. I didn't think dependency management was the answer either. I'll have to port our home grown system to a plugin at some point, or convince management to re-engineer the build process. Thanks again, Robert Egan This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally. -- Eric Redmond http://blog.propellors.net
Re: Dependency management
I'd like to thank you again for taking time to work with me on this. I have been asked to address a production problem for now but I will attempt to post a concrete example from home this evening or no later than tomorrow morning (my TZ is GMT +5). Robert Egan Tim Kettler [EMAIL PROTECTED] wrote on 08/21/2007 01:03:05 PM: Can you give a somewhat more specific example what the reactor does not allow? The scenario you describe above is a fairly standard use-case I would say. Perhaps a set of minimal example poms and a short description of what you expect them to do would be helpful. Maven calculates the dependency tree for the set of reactor projects and then orders the builds of the projects (modules) in such an order that all dependencies of a module are available when the module is build. So what you want to do should be entirely possible with maven out of the box... Or I totally misunderstand what you want to do. Eric Redmond [EMAIL PROTECTED] wrote on 08/21/2007 01:17:35 PM: Again, I am confused. What use-case do you have where you cannot just create a multi-module project that contains project A and B as modules? This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
Re: Dependency management
As promised: I wrote on 08/21/2007 03:13:21 PM: I'd like to thank you again for taking time to work with me on this. I have been asked to address a production problem for now but I will attempt to post a concrete example from home this evening or no later than tomorrow morning (my TZ is GMT +5). Consider the following directory structure /base /artifact1 /artifact2 /artifact3 /artifact3a The relevant sections of /base/pom.xml look like this: packagingpom/packaging modules moduleartifact1/module moduleartifact2/module moduleartifact3/module /modules /base/artifact1/pom.xml and /base/artifact2/pom.xml are simple jars, so you can call mvn clean install from either folder. The relevant sections of /base/artifact3/pom.xml look like this: packagingpom/packaging modules module../artifact1/module module../artifact2/module moduleartifact3a/module /modules While you can do mvn clean install from /base/artifact3/ you will not be allowed to do it from /base, because the reactor won't let you visit artifact1 and artifact2 twice. This is a very simplified example. Our build contains several dozen artifacts with numerous dependencies similar to the above. Also, I am willing to live with the fact that this may not be the best design and that it may be easier to re-engineer the build, if that is your recommendation. Thanks again Robert Egan This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
Re: Dependency management
I think what you really want is simply a dependency on artifact1 and artifact2 in your artifact3 pom, not module../artifact1/module. I'm a little surprised that ../ notation is even allowed in the module node, to be honest. Then, when you build from the top, all of your projects will be built in the proper order assuming your dependencies are declared properly, and all modules will use the most recent bits of code in each module as the various artifacts are produced. If you build from a3, Maven will use the most recently built (and installed into your local repo) files from a1 and a2. It will not go into a1 and a2 to rebuild those files, however. Wayne On 8/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: As promised: I wrote on 08/21/2007 03:13:21 PM: I'd like to thank you again for taking time to work with me on this. I have been asked to address a production problem for now but I will attempt to post a concrete example from home this evening or no later than tomorrow morning (my TZ is GMT +5). Consider the following directory structure /base /artifact1 /artifact2 /artifact3 /artifact3a The relevant sections of /base/pom.xml look like this: packagingpom/packaging modules moduleartifact1/module moduleartifact2/module moduleartifact3/module /modules /base/artifact1/pom.xml and /base/artifact2/pom.xml are simple jars, so you can call mvn clean install from either folder. The relevant sections of /base/artifact3/pom.xml look like this: packagingpom/packaging modules module../artifact1/module module../artifact2/module moduleartifact3a/module /modules While you can do mvn clean install from /base/artifact3/ you will not be allowed to do it from /base, because the reactor won't let you visit artifact1 and artifact2 twice. This is a very simplified example. Our build contains several dozen artifacts with numerous dependencies similar to the above. Also, I am willing to live with the fact that this may not be the best design and that it may be easier to re-engineer the build, if that is your recommendation. Thanks again Robert Egan This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency management
Wayne Fay [EMAIL PROTECTED] wrote on 08/21/2007 08:52:31 PM: I think what you really want is simply a dependency on artifact1 and artifact2 in your artifact3 pom, not module../artifact1/module. I'm a little surprised that ../ notation is even allowed in the module node, to be honest. Then, when you build from the top, all of your projects will be built in the proper order assuming your dependencies are declared properly, and all modules will use the most recent bits of code in each module as the various artifacts are produced. If you build from a3, Maven will use the most recently built (and installed into your local repo) files from a1 and a2. It will not go into a1 and a2 to rebuild those files, however. Wayne I have also come to this conclusion. It is the correct approach to dependency management, although I am concerned that the developers will consider it a loss of functionality because they have become used to the home grown system, which pretty much lets you build any part of the product at any time. Perhaps I'll offer to write a plugin as part of phase 2 of the rollout. On 8/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Consider the following directory structure /base /artifact1 /artifact2 /artifact3 /artifact3a The relevant sections of /base/pom.xml look like this: packagingpom/packaging modules moduleartifact1/module moduleartifact2/module moduleartifact3/module /modules /base/artifact1/pom.xml and /base/artifact2/pom.xml are simple jars, so you can call mvn clean install from either folder. The relevant sections of /base/artifact3/pom.xml look like this: packagingpom/packaging modules module../artifact1/module module../artifact2/module moduleartifact3a/module /modules While you can do mvn clean install from /base/artifact3/ you will not be allowed to do it from /base, because the reactor won't let you visit artifact1 and artifact2 twice. This is a very simplified example. Our build contains several dozen artifacts with numerous dependencies similar to the above. Also, I am willing to live with the fact that this may not be the best design and that it may be easier to re-engineer the build, if that is your recommendation. Thanks again Robert Egan This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
Re: dependency management problems...
So essentially you'd break up and move the monolithic validate phase into a series of mini-validates that fire immediately before every other lifecycle phase, to validate the artifacts necessary for (only) that phase are available. I think it would complicate things a bit, but it doesn't sound unreasonable. Wayne On 5/2/07, William Ferguson [EMAIL PROTECTED] wrote: Interesting point. Aren't dependencies just compile time dependencies? So there is no need to resolve them unless your build includes the compile:compile goal. Plugin dependencies are only resolved if that plugin is required as part of the current build. So why do the (compile) dependencies need to be resolved if compilation is not part of the build? William -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, 2 May 2007 1:24 PM To: Maven Users List Subject: Re: dependency management problems... As far as I know, you can't. Maven resolves all dependencies etc at the beginning of the lifecycle, so it can find all transitive artifacts etc and make sure EVERYTHING is available in the local cache before proceeding with the build. Wayne On 5/1/07, EJ Ciramella [EMAIL PROTECTED] wrote: Here's another way of phrasing this question - if a module has a dependency on another one, how do you stop it from attempting to download until absolutely necessary (say at compile time, NOT at process-resources time)? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 3:11 PM To: Maven Users List Subject: dependency management problems... We're having problems building modules like this from scratch. If we run process resources from the top most level, submodule.B complains about not being able to find module1's artifacts (why would submodule.B need module 1's jar artifact just to process resources?). parent - version 1.0-SNAPSHOT | |---module1 - version 1.0-SNAPSHOT | |---module2 - version 1.0-SNAPSHOT |---submodule.A- version 1.0-SNAPSHOT |---submodule.B- version 1.0-SNAPSHOT I'm really at the end of my rope on this one. The only way to successfully get this to go through is to run a mvn install from the top most level first. What's crazy is submodule.A has the same dependency and goes through just fine. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependency management problems...
I was actually thinking that the validate phase would only compile a list of dependencies up to the furthermost lifecycle phase required by the list of goals specified. But I guess it amounts to the same thing. William -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, 4 May 2007 2:00 AM To: Maven Users List Subject: Re: dependency management problems... So essentially you'd break up and move the monolithic validate phase into a series of mini-validates that fire immediately before every other lifecycle phase, to validate the artifacts necessary for (only) that phase are available. I think it would complicate things a bit, but it doesn't sound unreasonable. Wayne On 5/2/07, William Ferguson [EMAIL PROTECTED] wrote: Interesting point. Aren't dependencies just compile time dependencies? So there is no need to resolve them unless your build includes the compile:compile goal. Plugin dependencies are only resolved if that plugin is required as part of the current build. So why do the (compile) dependencies need to be resolved if compilation is not part of the build? William -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, 2 May 2007 1:24 PM To: Maven Users List Subject: Re: dependency management problems... As far as I know, you can't. Maven resolves all dependencies etc at the beginning of the lifecycle, so it can find all transitive artifacts etc and make sure EVERYTHING is available in the local cache before proceeding with the build. Wayne On 5/1/07, EJ Ciramella [EMAIL PROTECTED] wrote: Here's another way of phrasing this question - if a module has a dependency on another one, how do you stop it from attempting to download until absolutely necessary (say at compile time, NOT at process-resources time)? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 3:11 PM To: Maven Users List Subject: dependency management problems... We're having problems building modules like this from scratch. If we run process resources from the top most level, submodule.B complains about not being able to find module1's artifacts (why would submodule.B need module 1's jar artifact just to process resources?). parent - version 1.0-SNAPSHOT | |---module1 - version 1.0-SNAPSHOT | |---module2 - version 1.0-SNAPSHOT |---submodule.A- version 1.0-SNAPSHOT |---submodule.B- version 1.0-SNAPSHOT I'm really at the end of my rope on this one. The only way to successfully get this to go through is to run a mvn install from the top most level first. What's crazy is submodule.A has the same dependency and goes through just fine. - 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] - 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: dependency management problems...
If anyone actually wants this to happen, you probably need to file a JIRA issue so this can be considered in 2.0.x (or 2.1). William, your idea could perhaps even be implemented in 2.0.x. Discussions like this, esp on the Users list, generally do not result in new functionality as there are simply too many things to keep track of... Wayne On 5/3/07, William Ferguson [EMAIL PROTECTED] wrote: I was actually thinking that the validate phase would only compile a list of dependencies up to the furthermost lifecycle phase required by the list of goals specified. But I guess it amounts to the same thing. William -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, 4 May 2007 2:00 AM To: Maven Users List Subject: Re: dependency management problems... So essentially you'd break up and move the monolithic validate phase into a series of mini-validates that fire immediately before every other lifecycle phase, to validate the artifacts necessary for (only) that phase are available. I think it would complicate things a bit, but it doesn't sound unreasonable. Wayne On 5/2/07, William Ferguson [EMAIL PROTECTED] wrote: Interesting point. Aren't dependencies just compile time dependencies? So there is no need to resolve them unless your build includes the compile:compile goal. Plugin dependencies are only resolved if that plugin is required as part of the current build. So why do the (compile) dependencies need to be resolved if compilation is not part of the build? William -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, 2 May 2007 1:24 PM To: Maven Users List Subject: Re: dependency management problems... As far as I know, you can't. Maven resolves all dependencies etc at the beginning of the lifecycle, so it can find all transitive artifacts etc and make sure EVERYTHING is available in the local cache before proceeding with the build. Wayne On 5/1/07, EJ Ciramella [EMAIL PROTECTED] wrote: Here's another way of phrasing this question - if a module has a dependency on another one, how do you stop it from attempting to download until absolutely necessary (say at compile time, NOT at process-resources time)? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 3:11 PM To: Maven Users List Subject: dependency management problems... We're having problems building modules like this from scratch. If we run process resources from the top most level, submodule.B complains about not being able to find module1's artifacts (why would submodule.B need module 1's jar artifact just to process resources?). parent - version 1.0-SNAPSHOT | |---module1 - version 1.0-SNAPSHOT | |---module2 - version 1.0-SNAPSHOT |---submodule.A- version 1.0-SNAPSHOT |---submodule.B- version 1.0-SNAPSHOT I'm really at the end of my rope on this one. The only way to successfully get this to go through is to run a mvn install from the top most level first. What's crazy is submodule.A has the same dependency and goes through just fine. - 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] - 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: dependency management problems...
Here's another way of phrasing this question - if a module has a dependency on another one, how do you stop it from attempting to download until absolutely necessary (say at compile time, NOT at process-resources time)? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 3:11 PM To: Maven Users List Subject: dependency management problems... We're having problems building modules like this from scratch. If we run process resources from the top most level, submodule.B complains about not being able to find module1's artifacts (why would submodule.B need module 1's jar artifact just to process resources?). parent - version 1.0-SNAPSHOT | |---module1 - version 1.0-SNAPSHOT | |---module2 - version 1.0-SNAPSHOT |---submodule.A- version 1.0-SNAPSHOT |---submodule.B- version 1.0-SNAPSHOT I'm really at the end of my rope on this one. The only way to successfully get this to go through is to run a mvn install from the top most level first. What's crazy is submodule.A has the same dependency and goes through just fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency management problems...
As far as I know, you can't. Maven resolves all dependencies etc at the beginning of the lifecycle, so it can find all transitive artifacts etc and make sure EVERYTHING is available in the local cache before proceeding with the build. Wayne On 5/1/07, EJ Ciramella [EMAIL PROTECTED] wrote: Here's another way of phrasing this question - if a module has a dependency on another one, how do you stop it from attempting to download until absolutely necessary (say at compile time, NOT at process-resources time)? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 3:11 PM To: Maven Users List Subject: dependency management problems... We're having problems building modules like this from scratch. If we run process resources from the top most level, submodule.B complains about not being able to find module1's artifacts (why would submodule.B need module 1's jar artifact just to process resources?). parent - version 1.0-SNAPSHOT | |---module1 - version 1.0-SNAPSHOT | |---module2 - version 1.0-SNAPSHOT |---submodule.A- version 1.0-SNAPSHOT |---submodule.B- version 1.0-SNAPSHOT I'm really at the end of my rope on this one. The only way to successfully get this to go through is to run a mvn install from the top most level first. What's crazy is submodule.A has the same dependency and goes through just fine. - 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: Dependency management
Hi Alexander, Hi, I have a few questions about modules and dependencies. Does the order of modules listed in the parent pom.xml matter? As said by others it does NOT matter for the dependency management. It only matters for the ordering when the modules are rendered to the menu of the generated site. I maintain a very big project with maven that has up to 4 level deepth modules and very complex situations like P/B/B1 depends on P/A/A1 P/B/B2 depends on P/B/B1 and P/A/A2 P/A/A2 depends on P/B/B1 Where P is the main project, A and B are modules that both have to sub modules. So it is NOT possible to build A or B completely independent of each other. My situations are sometimes even more complex and I never had trouble with this. For example, if C depends on A and B depends on C, then the correct order would be:A, C B moduleA/module moduleC/module moduleB/module If I specify instead moduleA/module moduleB/module moduleC/module, will Maven pick up the right dependency order and build as if I had written A,C,B? As for my second question, if I declare a dependency in a project, will that artifact be automatically built and deployed to maven repo so that it would be picked up for build? For example, if I declare: dependency groupIdb/groupId artifactIda/artifactId version1.0/version /dependency Will Maven go and build a for me or do I need to include a as a submodule? Thanks. Regards Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency management within plugin dependencies
Hi, dependencyManagement is inherited by children POMs. It is useful to define a dependency within dependencyManagement tag expliciting the version there. Then in the children POMs you can just declare your dependecy without having the version tag have a look here: http://maven.apache.org/pom.html#Dependency%20Management bye, Federico Gregory Kick-2 wrote: I have a question about the behavior of the dependencyManagement portion of a POM as it relates to plugin dependencies. Say I have: ... dependencyManagement dependencies dependency groupIdGROUP/groupId artifactIdARTIFACT/artifactId /dependency /dependencies /dependencyManagement ... And in some project that inherits from this pom, plugin ... dependencies dependency groupIdGROUP/groupId artifactIdARTIFACT/artifactId /dependency delendencies ... /plugin will fail with a missing version. Is this the expected behavior or is this a bug? -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/dependency-management-within-plugin-dependencies-tf2772190s177.html#a7735149 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: dependency management within plugin dependencies
Federico, I'm aware of what it does... The question was regarding dependencies listed relative to a plugin. Wayne, The problem with pluginManagement is that I don't necessarily want a dependency for every invocation of the pluign. For example, say that have a plugin that uses the jaxb api and I want to use jaxb in some situations and jaxme in others. They have the same api so it might be reasonable to want a plugin to execute using one implementation in some instances and the other implementation in another. Additionally, I'd like to standardize the versions in the same way as I would with a typical dependency, so that I always use jaxb whatever-jaxb-version and jaxme whatever-jaxme-version. My first thought is that a dependency that is listed under a plugin should also utilize dependencyManagement, but that seems to not be the case. And, since there's no dependencyManagement under pluginManagement I wondered whether this was intentional or an oversight. Thoughts? On 12/7/06, Federico Yankelevich [EMAIL PROTECTED] wrote: Hi, dependencyManagement is inherited by children POMs. It is useful to define a dependency within dependencyManagement tag expliciting the version there. Then in the children POMs you can just declare your dependecy without having the version tag have a look here: http://maven.apache.org/pom.html#Dependency%20Management bye, Federico Gregory Kick-2 wrote: I have a question about the behavior of the dependencyManagement portion of a POM as it relates to plugin dependencies. Say I have: ... dependencyManagement dependencies dependency groupIdGROUP/groupId artifactIdARTIFACT/artifactId /dependency /dependencies /dependencyManagement ... And in some project that inherits from this pom, plugin ... dependencies dependency groupIdGROUP/groupId artifactIdARTIFACT/artifactId /dependency delendencies ... /plugin will fail with a missing version. Is this the expected behavior or is this a bug? -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/dependency-management-within-plugin-dependencies-tf2772190s177.html#a7735149 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: dependency management within plugin dependencies
Sounds like a job for a profile. Wayne On 12/7/06, Gregory Kick [EMAIL PROTECTED] wrote: Federico, I'm aware of what it does... The question was regarding dependencies listed relative to a plugin. Wayne, The problem with pluginManagement is that I don't necessarily want a dependency for every invocation of the pluign. For example, say that have a plugin that uses the jaxb api and I want to use jaxb in some situations and jaxme in others. They have the same api so it might be reasonable to want a plugin to execute using one implementation in some instances and the other implementation in another. Additionally, I'd like to standardize the versions in the same way as I would with a typical dependency, so that I always use jaxb whatever-jaxb-version and jaxme whatever-jaxme-version. My first thought is that a dependency that is listed under a plugin should also utilize dependencyManagement, but that seems to not be the case. And, since there's no dependencyManagement under pluginManagement I wondered whether this was intentional or an oversight. Thoughts? On 12/7/06, Federico Yankelevich [EMAIL PROTECTED] wrote: Hi, dependencyManagement is inherited by children POMs. It is useful to define a dependency within dependencyManagement tag expliciting the version there. Then in the children POMs you can just declare your dependecy without having the version tag have a look here: http://maven.apache.org/pom.html#Dependency%20Management bye, Federico Gregory Kick-2 wrote: I have a question about the behavior of the dependencyManagement portion of a POM as it relates to plugin dependencies. Say I have: ... dependencyManagement dependencies dependency groupIdGROUP/groupId artifactIdARTIFACT/artifactId /dependency /dependencies /dependencyManagement ... And in some project that inherits from this pom, plugin ... dependencies dependency groupIdGROUP/groupId artifactIdARTIFACT/artifactId /dependency delendencies ... /plugin will fail with a missing version. Is this the expected behavior or is this a bug? -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/dependency-management-within-plugin-dependencies-tf2772190s177.html#a7735149 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [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: dependency management within plugin dependencies
You're looking for pluginManagement I believe... Wayne On 12/6/06, Gregory Kick [EMAIL PROTECTED] wrote: I have a question about the behavior of the dependencyManagement portion of a POM as it relates to plugin dependencies. Say I have: ... dependencyManagement dependencies dependency groupIdGROUP/groupId artifactIdARTIFACT/artifactId /dependency /dependencies /dependencyManagement ... And in some project that inherits from this pom, plugin ... dependencies dependency groupIdGROUP/groupId artifactIdARTIFACT/artifactId /dependency delendencies ... /plugin will fail with a missing version. Is this the expected behavior or is this a bug? -- Gregory Kick [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: Dependency management
Hi Alexander, 2006/9/27, Morgovsky, Alexander (US - Glen Mills) [EMAIL PROTECTED]: Hi, I have a few questions about modules and dependencies. Does the order of modules listed in the parent pom.xml matter? For example, if C depends on A and B depends on C, then the correct order would be:A, C B moduleA/module moduleC/module moduleB/module If I specify instead moduleA/module moduleB/module moduleC/module, will Maven pick up the right dependency order and build as if I had written A,C,B? Order doesn't matter, Maven does well. But you could simply try. ^_^ As for my second question, if I declare a dependency in a project, will that artifact be automatically built and deployed to maven repo so that it would be picked up for build? For example, if I declare: dependency groupIdb/groupId artifactIda/artifactId version1.0/version /dependency Will Maven go and build a for me or do I need to include a as a submodule? Thanks. Maven won't build it - if your dependency was Spring, Maven wouldn't build Spring. So, yes, you need to include a as a submodule. HTH, - Yann This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1]
RE: Dependency management
Hi Alexander Yann I believe if you declare a dependency and don't have it specified as a module, maven will try and download it from the repository. Thanks Lakshman -Original Message- From: Yann Le Du [mailto:[EMAIL PROTECTED] Sent: Thursday, 28 September 2006 3:05 AM To: Maven Users List Subject: Re: Dependency management Hi Alexander, 2006/9/27, Morgovsky, Alexander (US - Glen Mills) [EMAIL PROTECTED]: Hi, I have a few questions about modules and dependencies. Does the order of modules listed in the parent pom.xml matter? For example, if C depends on A and B depends on C, then the correct order would be:A, C B moduleA/module moduleC/module moduleB/module If I specify instead moduleA/module moduleB/module moduleC/module, will Maven pick up the right dependency order and build as if I had written A,C,B? Order doesn't matter, Maven does well. But you could simply try. ^_^ As for my second question, if I declare a dependency in a project, will that artifact be automatically built and deployed to maven repo so that it would be picked up for build? For example, if I declare: dependency groupIdb/groupId artifactIda/artifactId version1.0/version /dependency Will Maven go and build a for me or do I need to include a as a submodule? Thanks. Maven won't build it - if your dependency was Spring, Maven wouldn't build Spring. So, yes, you need to include a as a submodule. HTH, - Yann This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependency management
I think that's exactly what Yann said :) if it is only a dependency but not a module, maven will NOT build it. It will download from repository (either local or remote) instead. Adrian Shum -Original Message- From: Lakshman Srilakshmanan [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 11:13 AM To: Maven Users List Subject: RE: Dependency management Hi Alexander Yann I believe if you declare a dependency and don't have it specified as a module, maven will try and download it from the repository. Thanks Lakshman -Original Message- From: Yann Le Du [mailto:[EMAIL PROTECTED] Sent: Thursday, 28 September 2006 3:05 AM To: Maven Users List Subject: Re: Dependency management Hi Alexander, 2006/9/27, Morgovsky, Alexander (US - Glen Mills) [EMAIL PROTECTED]: Hi, I have a few questions about modules and dependencies. Does the order of modules listed in the parent pom.xml matter? For example, if C depends on A and B depends on C, then the correct order would be:A, C B moduleA/module moduleC/module moduleB/module If I specify instead moduleA/module moduleB/module moduleC/module, will Maven pick up the right dependency order and build as if I had written A,C,B? Order doesn't matter, Maven does well. But you could simply try. ^_^ As for my second question, if I declare a dependency in a project, will that artifact be automatically built and deployed to maven repo so that it would be picked up for build? For example, if I declare: dependency groupIdb/groupId artifactIda/artifactId version1.0/version /dependency Will Maven go and build a for me or do I need to include a as a submodule? Thanks. Maven won't build it - if your dependency was Spring, Maven wouldn't build Spring. So, yes, you need to include a as a submodule. HTH, - Yann This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This email is confidential. If you are not the intended recipient, please delete it from your system and notify the sender immediately. Any unauthorized use, disclosure, dissemination or copying of this email is prohibited. Taifook Securities Group, its group companies and their content providers (Parties) shall not be responsible for the accuracy or completeness of this email or its attachment, if any, which could contain virus, be corrupted, destroyed, incomplete, intercepted, lost or arrive late. The Parites do not accept liability for any damage caused by this email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency management problem with classifier tag - bug?
I understand from your words that if you have a classifier the dependency is identified not only with groupId and artifactId but also with classifier, so if you have two dependencies with different classifiers you should include both dependencies in the dependency management section, each with its corresponding classifier, and then you would identify the dependency in the child pom using groupId, artifactId and classifier, am I right? 2006/6/20, Carlos Sanchez [EMAIL PROTECTED]: because you may have two dependencies with different classifiers On 6/20/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Ok, now it's working... may I ask what is the logic behind this? I mean, why must classifier be included in the child pom? Thanks a lot, best regards Jose 2006/6/20, Carlos Sanchez [EMAIL PROTECTED]: no, classifier in both On 6/20/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Do you mean this? parent pom: dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version4.7/version scopetest/scope /dependency child pom: dependency groupIdorg.testng/groupId artifactIdtestng/artifactId classifierjdk15/classifier /dependency I tried it, and it also fails 2006/6/20, Carlos Sanchez [EMAIL PROTECTED]: you have to add the classifier in the child On 6/20/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Hi there, I'm having a really strange problem related to dependency management. I have a parent pom with some dependencies declared in the dependency management section, and a child pom inheriting from it. One of the dependencies is the testng jar. Here you have excerpts from both files: Parent pom: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdorg.surveyforge/groupId artifactIdsurveyforge/artifactId packagingpom/packaging nameSurveyForge/name version0.1-SNAPSHOT/version [...] dependencyManagement dependencies [...] dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version4.7/version classifierjdk15/classifier scopetest/scope /dependency [...] /dependencies /dependencyManagement [...] /project Child pom: ?xml version=1.0 encoding=UTF-8? project parent groupIdorg.surveyforge/groupId artifactIdsurveyforge/artifactId version0.1-SNAPSHOT/version /parent modelVersion4.0.0/modelVersion artifactIdsurveyforge-classification/artifactId nameSurveyForge Classification API/name [...] dependencies dependency groupIdorg.testng/groupId artifactIdtestng/artifactId /dependency [...] /dependencies [...] /project If I try to run any goal I get with these two files I get the following: [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.surveyforge:surveyforge-classification POM Location: U:\proyectos\otros\surveyforge\surveyforge-classification\pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.testng:testng Reason: Failed to validate POM [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to validate POM at org.apache.maven.DefaultMaven.getProjects( DefaultMaven.java :365) at org.apache.maven.DefaultMaven.doExecute( DefaultMaven.java :278) at org.apache.maven.DefaultMaven.execute( DefaultMaven.java :115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced( Launcher.java :315) at org.codehaus.classworlds.Launcher.launch( Launcher.java :255) at org.codehaus.classworlds.Launcher.mainWithExitCode( Launcher.java :430) at org.codehaus.classworlds.Launcher.main(Launcher.java :375)
Re: Dependency management problem with classifier tag - bug?
correct IIRC On 6/21/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: I understand from your words that if you have a classifier the dependency is identified not only with groupId and artifactId but also with classifier, so if you have two dependencies with different classifiers you should include both dependencies in the dependency management section, each with its corresponding classifier, and then you would identify the dependency in the child pom using groupId, artifactId and classifier, am I right? 2006/6/20, Carlos Sanchez [EMAIL PROTECTED]: because you may have two dependencies with different classifiers On 6/20/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Ok, now it's working... may I ask what is the logic behind this? I mean, why must classifier be included in the child pom? Thanks a lot, best regards Jose 2006/6/20, Carlos Sanchez [EMAIL PROTECTED]: no, classifier in both On 6/20/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Do you mean this? parent pom: dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version4.7/version scopetest/scope /dependency child pom: dependency groupIdorg.testng/groupId artifactIdtestng/artifactId classifierjdk15/classifier /dependency I tried it, and it also fails 2006/6/20, Carlos Sanchez [EMAIL PROTECTED]: you have to add the classifier in the child On 6/20/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Hi there, I'm having a really strange problem related to dependency management. I have a parent pom with some dependencies declared in the dependency management section, and a child pom inheriting from it. One of the dependencies is the testng jar. Here you have excerpts from both files: Parent pom: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdorg.surveyforge/groupId artifactIdsurveyforge/artifactId packagingpom/packaging nameSurveyForge/name version0.1-SNAPSHOT/version [...] dependencyManagement dependencies [...] dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version4.7/version classifierjdk15/classifier scopetest/scope /dependency [...] /dependencies /dependencyManagement [...] /project Child pom: ?xml version=1.0 encoding=UTF-8? project parent groupIdorg.surveyforge/groupId artifactIdsurveyforge/artifactId version0.1-SNAPSHOT/version /parent modelVersion4.0.0/modelVersion artifactIdsurveyforge-classification/artifactId nameSurveyForge Classification API/name [...] dependencies dependency groupIdorg.testng/groupId artifactIdtestng/artifactId /dependency [...] /dependencies [...] /project If I try to run any goal I get with these two files I get the following: [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.surveyforge:surveyforge-classification POM Location: U:\proyectos\otros\surveyforge\surveyforge-classification\pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.testng:testng Reason: Failed to validate POM [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to validate POM at org.apache.maven.DefaultMaven.getProjects( DefaultMaven.java :365) at org.apache.maven.DefaultMaven.doExecute( DefaultMaven.java :278) at org.apache.maven.DefaultMaven.execute( DefaultMaven.java :115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced( Launcher.java :315) at
Re: Dependency management problem with classifier tag - bug?
you have to add the classifier in the child On 6/20/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Hi there, I'm having a really strange problem related to dependency management. I have a parent pom with some dependencies declared in the dependency management section, and a child pom inheriting from it. One of the dependencies is the testng jar. Here you have excerpts from both files: Parent pom: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdorg.surveyforge/groupId artifactIdsurveyforge/artifactId packagingpom/packaging nameSurveyForge/name version0.1-SNAPSHOT/version [...] dependencyManagement dependencies [...] dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version4.7/version classifierjdk15/classifier scopetest/scope /dependency [...] /dependencies /dependencyManagement [...] /project Child pom: ?xml version=1.0 encoding=UTF-8? project parent groupIdorg.surveyforge/groupId artifactIdsurveyforge/artifactId version0.1-SNAPSHOT/version /parent modelVersion4.0.0/modelVersion artifactIdsurveyforge-classification/artifactId nameSurveyForge Classification API/name [...] dependencies dependency groupIdorg.testng/groupId artifactIdtestng/artifactId /dependency [...] /dependencies [...] /project If I try to run any goal I get with these two files I get the following: [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.surveyforge:surveyforge-classification POM Location: U:\proyectos\otros\surveyforge\surveyforge-classification\pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.testng:testng Reason: Failed to validate POM [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to validate POM at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java :315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java :430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to validate POM at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic( DefaultMavenProjectBuilder.java:926) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal (DefaultMavenProjectBuilder.java:737) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal (DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build( DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java :447) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java :491) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) ... 11 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Tue Jun 20 12:11:45 CEST 2006 [INFO] Final Memory: 1M/2M [INFO] If I take away the classifier tag in the parent pom maven is able to validate the pom, but (obviously) fails because it cannot download the jar. If I include the whole dependency in the child pom and take it away from the parent pom I also get a correct execution. Any ideas? Is the classifier tag allowed in the dependency management section? Is this a bug? Best regards Jose -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency management problem with classifier tag - bug?
Do you mean this? parent pom: dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version4.7/version scopetest/scope /dependency child pom: dependency groupIdorg.testng/groupId artifactIdtestng/artifactId classifierjdk15/classifier /dependency I tried it, and it also fails 2006/6/20, Carlos Sanchez [EMAIL PROTECTED]: you have to add the classifier in the child On 6/20/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Hi there, I'm having a really strange problem related to dependency management. I have a parent pom with some dependencies declared in the dependency management section, and a child pom inheriting from it. One of the dependencies is the testng jar. Here you have excerpts from both files: Parent pom: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdorg.surveyforge/groupId artifactIdsurveyforge/artifactId packagingpom/packaging nameSurveyForge/name version0.1-SNAPSHOT/version [...] dependencyManagement dependencies [...] dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version4.7/version classifierjdk15/classifier scopetest/scope /dependency [...] /dependencies /dependencyManagement [...] /project Child pom: ?xml version=1.0 encoding=UTF-8? project parent groupIdorg.surveyforge/groupId artifactIdsurveyforge/artifactId version0.1-SNAPSHOT/version /parent modelVersion4.0.0/modelVersion artifactIdsurveyforge-classification/artifactId nameSurveyForge Classification API/name [...] dependencies dependency groupIdorg.testng/groupId artifactIdtestng/artifactId /dependency [...] /dependencies [...] /project If I try to run any goal I get with these two files I get the following: [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.surveyforge:surveyforge-classification POM Location: U:\proyectos\otros\surveyforge\surveyforge-classification\pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.testng:testng Reason: Failed to validate POM [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to validate POM at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java :365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java :278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced( Launcher.java :315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode( Launcher.java :430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to validate POM at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic( DefaultMavenProjectBuilder.java:926) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal (DefaultMavenProjectBuilder.java:737) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal (DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build( DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java :515) at org.apache.maven.DefaultMaven.collectProjects( DefaultMaven.java :447) at org.apache.maven.DefaultMaven.collectProjects( DefaultMaven.java :491) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java :351) ... 11 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Tue Jun 20 12:11:45 CEST 2006 [INFO] Final Memory: 1M/2M [INFO] If I take away the classifier tag in the parent pom maven is able to validate the pom, but (obviously) fails because it cannot download the jar. If I include the whole dependency in the child pom and take it away from the parent pom I
Re: Dependency management problem with classifier tag - bug?
no, classifier in both On 6/20/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Do you mean this? parent pom: dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version4.7/version scopetest/scope /dependency child pom: dependency groupIdorg.testng/groupId artifactIdtestng/artifactId classifierjdk15/classifier /dependency I tried it, and it also fails 2006/6/20, Carlos Sanchez [EMAIL PROTECTED]: you have to add the classifier in the child On 6/20/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Hi there, I'm having a really strange problem related to dependency management. I have a parent pom with some dependencies declared in the dependency management section, and a child pom inheriting from it. One of the dependencies is the testng jar. Here you have excerpts from both files: Parent pom: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdorg.surveyforge/groupId artifactIdsurveyforge/artifactId packagingpom/packaging nameSurveyForge/name version0.1-SNAPSHOT/version [...] dependencyManagement dependencies [...] dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version4.7/version classifierjdk15/classifier scopetest/scope /dependency [...] /dependencies /dependencyManagement [...] /project Child pom: ?xml version=1.0 encoding=UTF-8? project parent groupIdorg.surveyforge/groupId artifactIdsurveyforge/artifactId version0.1-SNAPSHOT/version /parent modelVersion4.0.0/modelVersion artifactIdsurveyforge-classification/artifactId nameSurveyForge Classification API/name [...] dependencies dependency groupIdorg.testng/groupId artifactIdtestng/artifactId /dependency [...] /dependencies [...] /project If I try to run any goal I get with these two files I get the following: [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.surveyforge:surveyforge-classification POM Location: U:\proyectos\otros\surveyforge\surveyforge-classification\pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.testng:testng Reason: Failed to validate POM [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to validate POM at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java :365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java :278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced( Launcher.java :315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode( Launcher.java :430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to validate POM at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic( DefaultMavenProjectBuilder.java:926) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal (DefaultMavenProjectBuilder.java:737) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal (DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build( DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java :515) at org.apache.maven.DefaultMaven.collectProjects( DefaultMaven.java :447) at org.apache.maven.DefaultMaven.collectProjects( DefaultMaven.java :491) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java :351) ... 11 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Tue Jun 20 12:11:45 CEST 2006 [INFO] Final Memory: 1M/2M [INFO] If I
Re: Dependency management problem with classifier tag - bug?
because you may have two dependencies with different classifiers On 6/20/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Ok, now it's working... may I ask what is the logic behind this? I mean, why must classifier be included in the child pom? Thanks a lot, best regards Jose 2006/6/20, Carlos Sanchez [EMAIL PROTECTED]: no, classifier in both On 6/20/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Do you mean this? parent pom: dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version4.7/version scopetest/scope /dependency child pom: dependency groupIdorg.testng/groupId artifactIdtestng/artifactId classifierjdk15/classifier /dependency I tried it, and it also fails 2006/6/20, Carlos Sanchez [EMAIL PROTECTED]: you have to add the classifier in the child On 6/20/06, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Hi there, I'm having a really strange problem related to dependency management. I have a parent pom with some dependencies declared in the dependency management section, and a child pom inheriting from it. One of the dependencies is the testng jar. Here you have excerpts from both files: Parent pom: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdorg.surveyforge/groupId artifactIdsurveyforge/artifactId packagingpom/packaging nameSurveyForge/name version0.1-SNAPSHOT/version [...] dependencyManagement dependencies [...] dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version4.7/version classifierjdk15/classifier scopetest/scope /dependency [...] /dependencies /dependencyManagement [...] /project Child pom: ?xml version=1.0 encoding=UTF-8? project parent groupIdorg.surveyforge/groupId artifactIdsurveyforge/artifactId version0.1-SNAPSHOT/version /parent modelVersion4.0.0/modelVersion artifactIdsurveyforge-classification/artifactId nameSurveyForge Classification API/name [...] dependencies dependency groupIdorg.testng/groupId artifactIdtestng/artifactId /dependency [...] /dependencies [...] /project If I try to run any goal I get with these two files I get the following: [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.surveyforge:surveyforge-classification POM Location: U:\proyectos\otros\surveyforge\surveyforge-classification\pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.testng:testng Reason: Failed to validate POM [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to validate POM at org.apache.maven.DefaultMaven.getProjects( DefaultMaven.java :365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java :278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java :115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced( Launcher.java :315) at org.codehaus.classworlds.Launcher.launch(Launcher.java :255) at org.codehaus.classworlds.Launcher.mainWithExitCode( Launcher.java :430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to validate POM at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic( DefaultMavenProjectBuilder.java:926) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal (DefaultMavenProjectBuilder.java:737) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal (DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build ( DefaultMavenProjectBuilder.java:192) at
Re: Dependency Management, Prioritize Repositories - Internal, Central, etc.
On 4/19/06, Roye, Suhneel BGI SF [EMAIL PROTECTED] wrote: Problem: I have a custom JAR (built by our team) installed in my local repository, and yet every time I do a build, Maven attempts to download it from Central (iBiblio) before realizing it's located in my local repository. I would like to prevent Maven from attempting to download this JAR from Central every time I do a build. Existing Solution: Has anyone successfully dealt with this problem? I've seen several threads on this topic without any resolution. I do not want to override Central or disable downloading of JAR's from Central. Potential Solution: I would like to be able to specify the order in which Maven looks up repositories. I would like for it to first look in my local repository, then at a shared (corporate) repository, and finally go out to the Central (iBiblio) repository. There was another thread about this topic a while back: http://mail-archives.apache.org/mod_mbox/maven-users/200604.mbox/%3cC0D4 [EMAIL PROTECTED] I also don't like this behaviour (it slows down the build) but haven't found a solution. Another potential solution could be to have Maven only check for updates on repositories where it has previously found the artifact. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependency Management, Prioritize Repositories - Internal, Central, etc.
Roye, Suhneel BGI SF wrote on Wednesday, April 19, 2006 12:06 PM: Problem: I have a custom JAR (built by our team) installed in my local repository, and yet every time I do a build, Maven attempts to download it from Central (iBiblio) before realizing it's located in my local repository. I would like to prevent Maven from attempting to download this JAR from Central every time I do a build. Existing Solution: Has anyone successfully dealt with this problem? I've seen several threads on this topic without any resolution. I do not want to override Central or disable downloading of JAR's from Central. Potential Solution: I would like to be able to specify the order in which Maven looks up repositories. I would like for it to first look in my local repository, then at a shared (corporate) repository, and finally go out to the Central (iBiblio) repository. This will not really help, for SNAPSHOTs Maven has to look in every repository. A solution would be a configuration section for repository definitions with includes and excludes to match groupIds e.g.: ... repository !-- merge with central definition, exclude stuff from own company or other commercial vendors -- idcentral/id configuration excludes excludecom.mycompany.*/exclude excludecom.commercial.vendor.*/exclude /excludes /configuration /repository repository !-- repo for stuff from commercial vendors -- idlocal-repo/id ... configuration includes includecom.commercial.vendor.*/include /includes /configuration /repository repository !-- repo for stuff from own company -- idproducts/id ... configuration includes includecom.mycompany.*/include /includes /configuration /repository ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependency Management, Prioritize Repositories - Internal, Central, etc.
On Wed, 2006-04-19 at 12:27 +0200, Jörg Schaible wrote: Roye, Suhneel BGI SF wrote on Wednesday, April 19, 2006 12:06 PM: Problem: I have a custom JAR (built by our team) installed in my local repository, and yet every time I do a build, Maven attempts to download it from Central (iBiblio) before realizing it's located in my local repository. I would like to prevent Maven from attempting to download this JAR from Central every time I do a build. Existing Solution: Has anyone successfully dealt with this problem? I've seen several threads on this topic without any resolution. I do not want to override Central or disable downloading of JAR's from Central. Potential Solution: I would like to be able to specify the order in which Maven looks up repositories. I would like for it to first look in my local repository, then at a shared (corporate) repository, and finally go out to the Central (iBiblio) repository. This will not really help, for SNAPSHOTs Maven has to look in every repository. True, for SNAPSHOT files. If you're getting this problem with something other than SNAPSHOT files, then did you use -DgeneratePom=true when installing the files? I've been working on doing exactly this kind of thing today, and it's working fine. However if there is no pom file next to the jarfile in the local repository, then maven tries to fetch the *pom* (and only the pom) from the central repository, then gets the jar from the local one. Putting a pom in the local repository fixes that. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency Management, Prioritize Repositories - Internal, Central, etc.
Shoot... I've got a bunch of poms to go generate, or jars to reinstall. ;-) Wayne On 4/19/06, Simon Kitching [EMAIL PROTECTED] wrote: On Wed, 2006-04-19 at 12:27 +0200, Jörg Schaible wrote: Roye, Suhneel BGI SF wrote on Wednesday, April 19, 2006 12:06 PM: Problem: I have a custom JAR (built by our team) installed in my local repository, and yet every time I do a build, Maven attempts to download it from Central (iBiblio) before realizing it's located in my local repository. I would like to prevent Maven from attempting to download this JAR from Central every time I do a build. Existing Solution: Has anyone successfully dealt with this problem? I've seen several threads on this topic without any resolution. I do not want to override Central or disable downloading of JAR's from Central. Potential Solution: I would like to be able to specify the order in which Maven looks up repositories. I would like for it to first look in my local repository, then at a shared (corporate) repository, and finally go out to the Central (iBiblio) repository. This will not really help, for SNAPSHOTs Maven has to look in every repository. True, for SNAPSHOT files. If you're getting this problem with something other than SNAPSHOT files, then did you use -DgeneratePom=true when installing the files? I've been working on doing exactly this kind of thing today, and it's working fine. However if there is no pom file next to the jarfile in the local repository, then maven tries to fetch the *pom* (and only the pom) from the central repository, then gets the jar from the local one. Putting a pom in the local repository fixes that. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependency Management, Prioritize Repositories - Internal,Central, etc.
Excellent. That fixed my problem. It would be nice if the documentation was updated to indicate what needs to be done to prevent this situation: http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html It would still be nice, however, to be able to specify the order in which various repositories are searched. Thanks for the suggestion. -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 19, 2006 3:47 AM To: Maven Users List Subject: RE: Dependency Management, Prioritize Repositories - Internal,Central, etc. On Wed, 2006-04-19 at 12:27 +0200, Jörg Schaible wrote: Roye, Suhneel BGI SF wrote on Wednesday, April 19, 2006 12:06 PM: Problem: I have a custom JAR (built by our team) installed in my local repository, and yet every time I do a build, Maven attempts to download it from Central (iBiblio) before realizing it's located in my local repository. I would like to prevent Maven from attempting to download this JAR from Central every time I do a build. Existing Solution: Has anyone successfully dealt with this problem? I've seen several threads on this topic without any resolution. I do not want to override Central or disable downloading of JAR's from Central. Potential Solution: I would like to be able to specify the order in which Maven looks up repositories. I would like for it to first look in my local repository, then at a shared (corporate) repository, and finally go out to the Central (iBiblio) repository. This will not really help, for SNAPSHOTs Maven has to look in every repository. True, for SNAPSHOT files. If you're getting this problem with something other than SNAPSHOT files, then did you use -DgeneratePom=true when installing the files? I've been working on doing exactly this kind of thing today, and it's working fine. However if there is no pom file next to the jarfile in the local repository, then maven tries to fetch the *pom* (and only the pom) from the central repository, then gets the jar from the local one. Putting a pom in the local repository fixes that. Regards, Simon This message and any attachments are confidential, proprietary, and may be privileged. If this message was misdirected, Barclays Global Investors (BGI) does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this e-mail message are the author's own and may not reflect the views and opinions of BGI, unless the author is authorized by BGI to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by BGI. Although BGI operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency Management - Need advice
Ok, there are a few ways to attack this. 1) dependency mangement, as you say. 2) hold each of the dependencies at snapshot. This will effectively do what you want, but that build won't be reproducible. 3) use a range. Again, not reproducible, but means you can get the latest release instead of just development versions without having to update the data (so have the freedom to bless which one will be used) We're still working on full support for (3). It sounds to me like you want (2), and want your nightly build to run the release plugin, and have it tag the project and update all the internal versions. - Brett On 8/14/05, dan tran [EMAIL PROTECTED] wrote: Hello all, I am going to have a m2 build system that contains lots of sub projects. my daily build uses the same version of all sub projects. and the version is incremented for each daily build. In M1, I use one global version property in project.properties of the master project root. For each daily build, the system increments the version in properties and tag the entire source tree. In m2, it seems that the only way to achieve this are: - Define all possible sub projects in dependencyMangement at the root pom or - I need to write a plugin to transerse to all subproject and change the version in poms and their dependencies,check in all the changes before the build Each has its own complexities that I wish to avoid I also notice that m2 and continuum builds also have to go thru my scecario for each new release ( offical alpha, beta,etc). Is there a better way? Or the capability is already there in M2. -Dan - 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: Dependency management
-Original Message- From: Dominik Dahlem [mailto:[EMAIL PROTECTED] Sent: Monday, May 10, 2004 12:20 PM To: [EMAIL PROTECTED] Subject: Dependency management Hi, I'm wondering which way maven is going in terms of dependency management. In my scenario and most I'm aware of, I'd like to distinguish between different types of dependencies to support e.g. a clever distribution of the application. I'm thinking of three types: compile time, runtime, and test dependencies. The distinction of those would help me in my scenarios to create a binary distribution including only the dependencies I need to run the application. Another distribution might be targeted to developers who need the sources as well as the compile-time and test dependencies. What do you think? Is that already doable with the latest maven? If not, is it an interesting feature for future maven releases? This is a thing which is planned since a long time and has been dissussed many time at our mailing lists and we have it in our schedule... Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
