2013/2/21 Reto Bachmann-Gmür <[email protected]> > On Thu, Feb 21, 2013 at 7:55 PM, Daniel Spicar <[email protected] > >wrote: > > > 2013/2/21 Reto Bachmann-Gmür <[email protected]> > > > > > Hi Daniel > > > > > > I'm not arguing for a centralized dependency management. so be both > agree > > > there. My question is how to best move the dependency versions from the > > > dependency management to the projects. > > > > > > The mvn versions plugin doesn't seem to support this. > > > > > > But there is an issue with this approach as well. Often you will want > to > > > > use the new features of a module A from some other module B. So you > > need > > > to > > > > go to B's pom and adapt the version number of its dependency. Maybe > you > > > > need to do this with several other modules as well. But you don't do > > this > > > > with all modules (e.g. Stable Module C has no changes and does not > > > require > > > > any new feature). > > > > > > No. I suggest you do this for all modules in trunk which is easily done > > by > > > executing the following: > > > > > > mvn versions:use-latest-versions -Dincludes="org.apache.clerezza" > > > -DallowSnapshots=true -DexcludeReactor=false > > > > > > If C is mantianes it should be adapted to use the new version of A. If > C > > is > > > not mantained it should be moved out of trunk. > > > > > > > And this is, what should be avoided in my opinion if possible. What you > > describe means a new version of C needs to be released. > > > No, you only release C if added some new features there otherwise you just > have C 2-SNAPSHOT version in trunk which keeps being updated to depend on > the latest versions of the other modules.
> If you have a module D that depends on C and you want to release this the > you either have to release C as well or have D depend on the released C 1 > in the release branch (and for depending on the latest release the > versions-plugin has support too).. > > Yes this is the same in practice. Dependencies don't care about branches, because they are defined in maven. Maven cares about version numbers. But what happens with D is not so much the question. It's pretty clear. Either D needs new features from C or not. If not it can depend on the old version. Otherwise the new version of C is required for the new version of D and both need to be released. The question is what happens to C when it depends on B and B is changed (the other direction in the dependency graph). Of course you can update C's meta data in a SNAPSHOT version. As long as C not released we don't really care about it. But when you want to release a module A (or launcher) with updated B (maybe A needs new features from B or non API changing bugfixes have been implemented). What do you do with C? I say nothing. OSGi will happily satisfy C's dependency on B if version numbers or dependency declarations are semantically correct. Semantically speaking, if B evolves from 1.0 to 1.5, B needs to satisfy at least dependencies for [1.0, 1.5] or OSGi will throw exceptions at you because C can not satisfy its dependency for B. Note: this example ignores OSGi semantic versioning, just speaking conceptually. Practically we can just declare OSGi version 0.0.0 for all bundles and it will work (until someone makes API breaking changes and forgets to update all modules that depend on the changed module). The alternative is you release C as well because you don't want to mix version numbers in dependencies. This as quite awkward effects in my opinion. Stable modules will go trough various version changes without ever changing code, only because their dependencies change. The whole scheme I came up with is aimed at preventing these unnecessary changes in version number. It's not my idea. I compiled it from other Apache projects using maven and OSGi that seem to have the hang of this (mainly sling [1,2]). > > > > > But you are right. Back when I investigated this there was no support for > > this workflow in the mvn release plugin. Nevertheless it strikes me wrong > > to have to change version numbers of modules that contain no changes. > > > > But that's like that also with normal usage of the relase plugin, After the > release you have a SNAPSHOT version in trunk which is identical (apart from > the version number) to the released version. > Well after battling it out with the release plugin many times already I am not so convinced it actually does the right thing. It does not seem to work well with modular projects in mind. The scheme I suggest will probably not work with the plugin but on the other hand there is no need to actually snapshotize every single module after release. I imagine many modules will remain stable (and untouched) for quite some time. It would shift the focus on releasing singular modules and small groups of collaborating modules at a time. How much effort this actually creates I can not tell now. It would need to be tested. > > But yes, rather than trying to foresee every possible future it would be > good to have some indispiputed things done. Do you see any options to move > our iternal dependencies out the dependency management without doing this > by hand? > I have spend a lot of time in 2011, early 2012 with this question. I don't see an option to get a satisfactory workflow only with small changes. All the elements I talked about are interdependent. Currently - from a dependency management view - we treat Clerezza as one big software project. If you change something in it - clerezza changes. So there's no clear way how to only change small parts without affecting all of them. The other approach means to shift to a module centric setup. Basically each module is a software project that can evolve independently. Relations between modules should be very similar to relations to external dependencies. This means sacrificing central management. If you know how to make small changes to improve the situation, I am all for it. But I don't see such a solution. I have to admit that I also don't have too much time currently to try things out. I just wanted to comment on the things I noticed when I checked the situation last time. I believe Stanbol wanted to move to a similar versioning policy back then as well. I did not follow up on how they implemented it. Maybe we can get some inspiration there though. > > Cheers, > Reto > Daniel [1] https://cwiki.apache.org/confluence/display/SLING/Thoughts+on+Release+Management [2] http://sling.apache.org/site/version-policy.html
