Thanks for the response. On Fri, Jan 31, 2014 at 11:33 AM, Anders Hammar <[email protected]> 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. > > >
