Hi Reto, In general I agree with the approach. I have been investigating this issue earlier too. I don't really have time to get familiar with the details of this problem again but I remember, that the method I suggested pretty much had the following features:
1. No Centralized Dependency Management in higher level POMs (except for general utilities that we *want* all modules to use, e.g. slf4j). 2. Modules have to be developed as if they are self-contained (so they manage their own dependencies to other modules). 3. (Released) modules can only depend on released versions but it is not necessary to depend on the latest released version. This point is important for not having to touch other modules that have no code changes when releasing your module. More info for point 3: Modules depend on the oldest/lowest version they *need*. There is not problem for a module to depend on version 1.0 when we are at 1.8 - given the module does not need any of the new features. However there should be a minimal version number policy that makes sure we handle non-backwards compatible changes correctly because the OSGi container will only have the latest version of the module running but it needs to satisfy dependencies for older versions as well. When there a re non-backwards compatible changes in the new version, this needs to be addressed in some manner. There is a whole lot coming into this point if you want to use OSGi semantic versioning though. Maybe we can just skip that for now. But we need to make sure that the OSGi runtime will run with the latest modules (e.g. Version 1.8) but dependencies on older Versions (e.g. 1.0) will be satisfied by the 1.8 bundle (this is actually what the OSGi semantic versioning is meant for - but it's quite complex because it forces the devs to understand the version policy when making changes). Is that more or less what you meant? Regards, Daniel 2013/2/12 Tommaso Teofili <tommaso.teof...@gmail.com> > I see your point, let's go with this approach and if we find anything > better in the meantime then we'll switch to that ;) > > Tommaso > > > 2013/2/12 Reto Bachmann-Gmür <r...@apache.org> > > > Hi Tommaso > > > > I know. But the alternative of updating internal dependencies only > > when needed is quite tedious too. Also this way one can compile the > > clerezza trunk without downloading any clerezza dependency (i.e. > > offline after deleting org/apache/clerezza from the maven repository) > > I thing its good to have such a self-contained set of sources. > > > > Cheers, > > Reto > > > > On Tue, Feb 12, 2013 at 6:28 PM, Tommaso Teofili > > <tommaso.teof...@gmail.com> wrote: > > > Hi Reto, > > > I generally agree but I've to say it doesn't sound really smart to have > > > this back and forth version work on the branch, or at least a little > > > annoying for the release manager. > > > Apart from that +1, > > > Tommaso > > > > > > > > > 2013/2/12 Reto Bachmann-Gmür <r...@apache.org> > > > > > >> Hallo > > >> > > >> We have already been discussing this once: > > >> > > >> > > > http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201203.mbox/%3ccaewfvjkk4czkwy+w3afuokob8i+00e4_dyq_-2wst1eeqzd...@mail.gmail.com%3E > > >> > > >> Now also after having more experience with the stanbol approach I > > >> would like to suggest the following: > > >> > > >> 1) The dependency management does not contain internal dependencies > > >> 2) All modules in trunk depend on the latest versions of the modules > > >> in trunk, this is achieved by regularly running the mvn dependency > > >> plugin > > >> 3) before modules are relased they are copied to a branch and the > > >> trunk snapshot-version is increased > > >> 4) In the branch the module the dependencies to modules that are not > > >> part of the released are switched back to the latest released version > > >> (if incompatibilities become manifest the other modules are added to > > >> the release branch) > > >> 5) a release is prepared on the release branch > > >> 6) vote > > >> > > >> The idea is to reduce to effort of developing in trunk whithout having > > >> to worry about dependencies while making it straight forward to > > >> release only a part of the modules. > > >> > > >> > > >> WDYT? > > >> > > >> Cheers, > > >> Reto > > >> > > >
