> 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. > > > > > >
