Just in case you don not need all the fancy magic of pax exam what is
really only rarely needed in most cases you can use osgi-test framework
as a lightweight alternative:
https://github.com/osgi/osgi-test/
sadly their maven example is a bit overcrowded, you can find a more
focused example here:
https://github.com/microsoft/mssql-jdbc/pull/2066/files
I have even written a small Junit5 extension that allows running it with
plain surefire here:
https://github.com/laeubisoft/osgi-test-framework
Am 12.12.23 um 11:03 schrieb Steinar Bang:
Grzegorz Grzybek <gr.grzybek-re5jqeeqqe8avxtiumw...@public.gmane.org>:
I see your messages about Pax Exam problems and frustrations and while I
don't have answers for your questions about liquibase OSGi problems
Well... heh!
I worked my way around the liquibase problems yesterday by swapping
derby in the pax exam test of the feature with h2.
So now there is a new version of the liquibase feature post 4.23.0 released.
But then I decided to go back and recreate the error with derby and
bisect my way through the liquibase changes from 4.23.0 to 4.23.1 and
find out which change broke things.
Only: today I couldn't reproduce the pax exam problem that has bugged me
since early autumn this year. The problem I'm getting now is the same
one I saw in h2: the order of the returned objects had changed.
So I'm wondering if what I spent a lot of time looking at was completely
the wrong thing?
Ie. that what I thought was a problem in liquibase/derby in acquiring
the lock, was actually an artifact of the test being restarted because
an assert failed?
So I'm trying to learn the pax exam life cycle to not be fooled again.
It *has* to be possible to understand, doesn't it...? :-)
For the record: Version 4.24.0 of the feature is the newest.
(there is a 4.25.0 version of the feature but that is a mistaken
release, and also version 4.25.0 of liquibase doesn't work right in
OSGi, but there is a fix underway
(I simply would have to setup the environment, but I'm super-busy at
the end of 2023), I can only say I went the hard way with Pax Exam.
I didn't use documentation, just good old debugger... After some time spent
hitting continue/step in/step out, I came up with a class like
https://github.com/ops4j/org.ops4j.pax.web/blob/main/pax-web-itest/pax-web-itest-common/src/main/java/org/ops4j/pax/web/itest/AbstractControlledTestBase.java
which I use in several projects (Pax Web, Pax Logging, ...).
Thanks! I'll take a look at that!
And yes - setting it up correctly with proper logging (with conflicting
classloaders from Pax Exam, maven-failsafe-plugin and OSGi itself) is very
tricky...
Indeed it is!
And everytime I think I've understood it I'm hit by something
unexpected.
But right now, what I don't like, is that an error that has been stable
for several months, an error that was reproducable on several machines
and in gitlab actions, have gone away and I can't bring it back by going
back in my git history.
I have a feeling this has happened to me in my pax exam years...?
So it would be nice to actually understand how pax exam works! :-)
--
--
------------------
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ops4j+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ops4j/eed93285-d042-48fb-8783-eb59ee1cfc53%40googlemail.com.
