Hi Reto, Well as I elaborated earlier, one of the problems is the dependency management for our modules. As long as we manage dependency versions centrally in a parent POM or reactor that is 'higher up the hierarchy', each time you release a module, you want to update the parent or reactor POM as well. And therefore you need to release the parent or reactor POM as well. Now you will always need to do this in some form if you want to offer a launcher with the latest modules. But this is not strictly necessary for each module release. Not all modules are part of a launcher to start with and it is possible to establish different release cycles for launchers/reactors than that of single modules.
This is not so much a technical requirement but a change of thinking. You can always achieve the same by having a mixture of central and module-level dependency management but when you think of it. If modules should be able to evolve over time independently of other modules you should let them manage their dependencies (and dependency versions!) by themselves. This makes them almost stand alone projects and in some cases you can change things in them and release them without having to touch any other module (provided of course your changes do not break the old interface and the changes are self contained in the module). 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). The result is that now you have modules that require different versions of the same module at runtime. In OSGi this can be done and that is what I suggest to use in point 3. But it places more responsibility on the developer. Not all changes are "backwards-compatible" and the developer needs to be be aware that he makes such changes and has to make sure to update the dependencies in all modules when he does such changes. OSGi proposes its semantic versioning to help manage that [1]. Note most of the additional effort from non-backwards compatible changes would happen as well with centralized dependency management because in both cases you will actually need to touch the code of other modules and adapt them to use the new API of the module in question. Daniel [1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf 2013/2/20 Reto Bachmann-Gmür <r...@apache.org> > Hi Daniel > > I do not really understand your point 3. Why should a module not depend on > the latest released version of the modules it depends on? I would say go > for the newset version in maven and if there is a need for it configure the > bundle plugin to make sure the older version are accepted. But the latter I > would only do if people shout for it. OSGi is considered complex by many > developers so I think we should keep it as easy as possible. > > Another thing: Do you know of any easy way to add the version numbers to > the individul poms? > > Cheers, > Reto > > > On Wed, Feb 13, 2013 at 10:53 AM, Daniel Spicar <dspi...@apache.org> > wrote: > > > 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 > > > > >> > > > > > > > > > >
