Hi Peter, 2012/5/21 Peter Ansell <[email protected]>: > 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.
The only way to convince is to give it a try and look at the results. > 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. You're right. There is the possibility of such situations. But maybe the Stanbol developers will learn easily to first look at their dependencies in cases of weird bugs. > 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. These may be options for the future. But there is nothing like the Stanbol core at the moment. You can easily use, e.g. the EntityHub, without using any Enhancers. So defining a core is not that easy. Let's see how the current approach will work over the next months. If there are problems coming up, we have something concrete we can discuss and decide what to do. Best, - Fabian > 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 -- Fabian http://twitter.com/fctwitt
