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 <[email protected]> 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 <[email protected]> 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > >
