You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Peter Ansell <an...@gmail.com> on 2012/05/18 07:38:49 UTC
Version consistency between modules
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
Re: Version consistency between modules
Posted by Fabian Christ <ch...@googlemail.com>.
Hi Peter,
2012/5/21 Peter Ansell <an...@gmail.com>:
> 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 <ch...@googlemail.com> 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 <an...@gmail.com>:
>>> 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
Re: Version consistency between modules
Posted by Peter Ansell <an...@gmail.com>.
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 <ch...@googlemail.com> 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 <an...@gmail.com>:
>> 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
Re: Version consistency between modules
Posted by Fabian Christ <ch...@googlemail.com>.
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 <an...@gmail.com>:
> 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
Re: Version consistency between modules
Posted by Peter Ansell <an...@gmail.com>.
On 18 May 2012 18:00, Fabian Christ <ch...@googlemail.com> wrote:
> 2012/5/18 Peter Ansell <an...@gmail.com>:
>> In addition, the parent groupId and version can be inherited by the
>> pom file, so the pom file header can be reduced from:
>>
>> <groupId>org.apache.stanbol</groupId>
>> <artifactId>org.apache.stanbol.ontologymanager.web</artifactId>
>> <version>0.10.0-incubating-SNAPSHOT</version>
>> <packaging>bundle</packaging>
>>
>> to:
>>
>> <artifactId>org.apache.stanbol.ontologymanager.web</artifactId>
>> <packaging>bundle</packaging>
>
> The parent POM's release cycle is also independent of the components'
> release cycle. So the parent POM and its version may be stable for
> some time but during this time different components get released. In
> this configuration it is not possible to inherit the version from the
> parent POM. I am not sure about the groupId.
>
> Best,
> - Fabian
You should be okay to inherit groupId unless you expect the parent
pom's groupId to change or the child to not inherit it.
Peter
Re: Version consistency between modules
Posted by Fabian Christ <ch...@googlemail.com>.
2012/5/18 Peter Ansell <an...@gmail.com>:
> In addition, the parent groupId and version can be inherited by the
> pom file, so the pom file header can be reduced from:
>
> <groupId>org.apache.stanbol</groupId>
> <artifactId>org.apache.stanbol.ontologymanager.web</artifactId>
> <version>0.10.0-incubating-SNAPSHOT</version>
> <packaging>bundle</packaging>
>
> to:
>
> <artifactId>org.apache.stanbol.ontologymanager.web</artifactId>
> <packaging>bundle</packaging>
The parent POM's release cycle is also independent of the components'
release cycle. So the parent POM and its version may be stable for
some time but during this time different components get released. In
this configuration it is not possible to inherit the version from the
parent POM. I am not sure about the groupId.
Best,
- Fabian
Re: Version consistency between modules
Posted by Peter Ansell <an...@gmail.com>.
In addition, the parent groupId and version can be inherited by the
pom file, so the pom file header can be reduced from:
<groupId>org.apache.stanbol</groupId>
<artifactId>org.apache.stanbol.ontologymanager.web</artifactId>
<version>0.10.0-incubating-SNAPSHOT</version>
<packaging>bundle</packaging>
to:
<artifactId>org.apache.stanbol.ontologymanager.web</artifactId>
<packaging>bundle</packaging>
This should make it easier to maintain the pom files.
On 18 May 2012 15:38, Peter Ansell <an...@gmail.com> wrote:
> 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