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