Hi Steinar,
Manually changing the liquibse version to 4.9.1 results in
... 15 more
Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to
resolve org.liquibase.core/4.9.1: missing requirement
[org.liquibase.core/4.9.1] osgi.extender;
filter:="(osgi.extender=osgi.serviceloader.registrar)"
at
org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341)
... 16 more
Isn't there a way to chat online? Otherwise this is going to take a lot of
time :-)
Best regards,
Steven
On Sat, Aug 6, 2022 at 8:03 PM Steinar Bang <s...@dod.no> wrote:
> >>>>> Steven Huypens <steven.huyp...@gmail.com>:
>
> > 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>
>
>
