>>>>> Steven Huypens <[email protected]>:
> Hi Steinar,
> I tried to build the project, but ran into several issues. If you can
> update it, also updating the liquibase version, I'd be happy to take a look.
Ah, right! Sorry about that!
It was too much work, and too confusing, to update the liquibase-version
using git commits, especially when I wanted to try different versions
of liquibase against a set of modifications.
So what I'm doing during development, is set the liquibase.version in
~/.m2/settings.xml
Note: the version will be correct, if I make a release with a version
matching the actual liquibase version I'm making the feature for (which
is what I have been doing up to liquibase version 3.8.0, which is the
last version I didn't have any issues with.
(If I mess up and need to release a feature with a different version than
liquibase, I need to commit the liquibase version explicitly in the
pom. But that is a problem for the future)
Anyway, as I said: for development it is easiest to adjust the version in
~/.m2/settings.xml
To get it to build, use the setting
<settings>
<profiles>
<profile>
<id>non-snapshot-liquibase</id>
<activation><activeByDefault>true</activeByDefault></activation>
<properties>
<liquibase.version>3.8.0</liquibase.version>
</properties>
</profile>
</profiles>
</settings>
To get the version you're using, bump liquibase.version in
~/.m2/settings.xml to 4.9.1.
With the current master HEAD, this should fail with the "Cannot find
default log service" error in the pax exam karaf log (it is in
target/exim/<some-hash>/data/log/karaf.log after "mvn clean install" has
run its course).
I also have locally various experimental branches.
I have pushed the most promising
liquibase-karaf-feature/use-liquibase-slf4j-410,
which:
1. Removes the rebundling of liquibase-slf4j as a bundle fragment,
attached to the liquibase-core bundle
2. Load liquibase-slf4j 4.1.0 at runtime, see [1] (this version is an
OSGi bundle fragment that attaches to liquibase-core 4.9.1 and later)
3. Load the built-in spifly feature at runtime, which provides the
osgi.serviceloader.registrar capability (incidentially, the
serviceloader, is the code that currently fails to find the default
log service...)
Note: I *think* that the new version of liquibase-slf4j is effectively a
no-op wrt. to the the way liquibase 4.x finds its logs, but I've left it
in place for now (as I said: I have various failed experimental branches
that there is no point in pushing).
References:
[1] <https://github.com/mattbertolini/liquibase-slf4j/issues/12>
