Hi Fabian, I had not come across this strategy before in a project that appears to offer a single product, albeit with plugins for extensions, and I am not convinced that it will benefit in this case.
It is good that Jenkins will always be executing tests against the latest snapshots but that may actually make it harder, and not easier, to detect local bugs. Developers may not be aware that they need to update a particular version in a pom file to get a fix that may not be immediately obvious to them, as the tests for that module being executed on Jenkins may not be for the version that they are using, so they see passing tests an assume that it should pass for them as well. I would suggest that the size of the project scope should be re-examined as it may be too large to be effectively manageable in the long term. Have you thought about creating a stanbol-plugins project so that the various plugins that are currently in stanbol, notably the implementations for the entityhub, enhancers and enhancement plugins, could be developed independently. Then the core stanbol stack, including APIs, could have a single version and people would know exactly what version of stanbol they are developing for using a single version number, instead of having to describe the stanbol core in terms of the versions for every dependency. Peter On 18 May 2012 17:55, Fabian Christ <[email protected]> wrote: > Hi Peter, > > this POM configuration is on purpose. Apache Stanbol is a modular > software stack where each component may have its own release cycle. We > want to be able to release single components independent of others. So > each component defines its required dependencies independently. As > long as a component is not required to use a SNAPSHOT dep it should > stick to the stable version. This makes it possible to release only > required components and not to release the whole stack each time. By > the way, this is not an invention of Apache Stanbol but we follow best > practices established by projects like Apache Sling. > > If you look at the launcher configurations you will see that the > launchers always contain the latest SNAPSHOT versions of all > components. This ensures that the integration tests are executed > against the latest code base. > > I started and tried to document this at [1] but this documentation may > need further extensions if it is not clear enough. > > [1] http://incubator.apache.org/stanbol/development/ > > Best, > - Fabian > > 2012/5/18 Peter Ansell <[email protected]>: >> Some dependencies in the trunk doesn't seem to have been migrated >> across from 0.9.0-incubating-SNAPSHOT to 0.9.0-incubating and then to >> 0.10.0-incubating-SNAPSHOT completely. >> >> Is there an intentional slow migration of the versions of some packages >> across? >> >> The examples I am looking at right now are ontologymanager.registry: >> >> <dependency> >> <groupId>org.apache.stanbol</groupId> >> >> <artifactId>org.apache.stanbol.commons.stanboltools.datafileprovider</artifactId> >> <version>0.9.0-incubating</version> >> </dependency> >> <dependency> >> <groupId>org.apache.stanbol</groupId> >> <artifactId>org.apache.stanbol.commons.stanboltools.offline</artifactId> >> <version>0.9.0-incubating</version> >> </dependency> >> <dependency> >> <groupId>org.apache.stanbol</groupId> >> <artifactId>org.apache.stanbol.ontologymanager.ontonet</artifactId> >> <version>0.9.0-incubating</version> >> </dependency> >> <dependency> >> <groupId>org.apache.stanbol</groupId> >> <artifactId>org.apache.stanbol.commons.owl</artifactId> >> <version>0.10.0-incubating-SNAPSHOT</version> >> </dependency> >> >> and ontologymanager.web (which doesn't use the new >> ontologymanager.registry code!): >> >> <groupId>org.apache.stanbol</groupId> >> <artifactId>org.apache.stanbol.commons.indexedgraph</artifactId> >> <version>0.9.0-incubating</version> >> </dependency> >> <dependency> >> <groupId>org.apache.stanbol</groupId> >> <artifactId>org.apache.stanbol.commons.web.base</artifactId> >> <version>0.9.0-incubating</version> >> </dependency> >> <dependency> >> <groupId>org.apache.stanbol</groupId> >> <artifactId>org.apache.stanbol.ontologymanager.ontonet</artifactId> >> <version>0.10.0-incubating-SNAPSHOT</version> >> </dependency> >> <dependency> >> <groupId>org.apache.stanbol</groupId> >> <artifactId>org.apache.stanbol.ontologymanager.registry</artifactId> >> <version>0.9.0-incubating</version> >> </dependency> >> <dependency> >> <groupId>org.apache.stanbol</groupId> >> <artifactId>org.apache.stanbol.commons.owl</artifactId> >> <version>0.10.0-incubating-SNAPSHOT</version> >> </dependency> >> >> I typically declare module dependency versions like the following to >> avoid these inconsistencies, so that the version and groupId only have >> to be set once in the parent section for each POM file: >> >> <dependency> >> <groupId>${project.groupId}</groupId> >> <artifactId>org.apache.stanbol.commons.owl</artifactId> >> <version>${project.version}</version> >> </dependency> >> >> Cheers, >> >> Peter > > > > -- > Fabian > http://twitter.com/fctwitt
