On Thu, Jun 26, 2014 at 10:08 AM, Rupert Westenthaler <
rupert.westentha...@gmail.com> wrote:
> On Thu, Jun 26, 2014 at 9:38 AM, Reto Gmür <r...@wymiwyg.com> wrote:
> > On Thu, Jun 26, 2014 at 9:28 AM, Rupert Westenthaler <
> > rupert.westentha...@gmail.com> wrote:
> >
> >> On Wed, Jun 25, 2014 at 4:31 PM, Reto Gmür <r...@wymiwyg.com> wrote:
> >> > Rehi,
> >> >
> >> > I've updated the versions in trunk. I've updated the dependent
> projectes
> >> > and the bundlelist to depend on the new SNAPSHOT version. So that some
> >> > changes will be reflected in the SNAPSHOT launcher. However this might
> >> mean
> >> > that when the launcher will be released and nothing changed in these
> >> > security modules we might want to switch back from 1.0.1-SNAPSHOT to
> >> 1.0.0.
> >> >
> >>
> >> In that case we can just remove those modules from the release.
> >>
> > And also switch back the version of the dependency in the dependent
> > projects. The maven versions:force-releases goal might be of help to do
> > this. It still needs to e done manually for the bundlelists are they are
> > not currently created from dependencies in the pom.
> >
>
> OK I was assuming that you kept the maven dependencies to the release
> 1.0.0 modules and not updated them to 1.0.1-SNAPSHOT as this would
> allow to use both the release version as well as the 1.0.1-SNAPSHOT
> version at runtime (OSGI semantic versioning).
>
> For bundle lists there is the possibility to use maven properties
> instead of fixed version numbers. That means that we could define
> versions for modules in the parent pom.
>
> <properties>
> <stanbol-version>1.0.0-SNAPSHOT</stanbol-version>
> <stanbol-enhancer-version>${stanbol-version}</stanbol-enhancer-version>
> ...
> </properties>
>
> In the bundlelits one could than use
>
> <startLevel level="30">
> <bundle>
> <groupId>org.apache.stanbol</groupId>
> <artifactId>org.apache.stanbol.enhancer.servicesapi</artifactId>
> <version>${stanbol-enhancer-version}</version>
> </bundle>
>
> When adapting this it should be enough to adapt the version numbers in
> the parent when doing a release. In addition this could also be
> adopted for other important external dependencies (e.g. solr).
>
> best
> Rupert
>
In general variables do not work together well with the
maven-versions-plugin so I would avoid this.
So to me the preferred solution is to create the partialbundlelists from
the pom. This allows the dependencies to managed by standard maven tool and
to have full IDE support when editing the dependencies of a partial
bundlelist.
I hope this will soon be supported by the karaf-maven-plugin as requested
by: https://issues.apache.org/jira/browse/KARAF-2468
For the time being there is a fork of karaf-maven-plugin that can do
partialbundlelists, It is used in Clerezza and in Fusepool, for an example
migration see:
https://github.com/fusepool/fusepool-bundlelist/commit/bcf149ed6553b3335483de41be2e01f685519ae9
The karaf approach is a bit less easy to use when bundles withing the same
partialbundlelist should have different start level. But relying on a
start-order is an anti-pattern anyway.
Cheers,
Reto
>
> > Cheers,
> > Reto
> >
> >
> >>
> >> best
> >> Rupert
> >>
> >> --
> >> | Rupert Westenthaler rupert.westentha...@gmail.com
> >> | Bodenlehenstraße 11 ++43-699-11108907
> >> | A-5500 Bischofshofen
> >> | REDLINK.CO
> >>
> ..........................................................................
> >> | http://redlink.co/
> >>
>
>
>
> --
> | Rupert Westenthaler rupert.westentha...@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
> | REDLINK.CO
> ..........................................................................
> | http://redlink.co/
>
