-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
It would be very nice if derby could be updated #364
Comments
Thanks for the report and some nice arguments. Actually we should be able to preserve JDK8 compatibility where possible and simply highlight that some Karaf features (and JDBC drivers) require newer JDK. Please give me some time to think and prepare an update. |
A note on using derby Use derby 10.16.1.1 (which is the current version for Java 17): it has a completely broken OSGi support
So in conclusion: derby has OSGi support that is thoroughly broken. Only way to fix it is to pull everything into the jar creating the DataSourceFactory, or rebundle the derby jars (or create an issue with derby and provide a fix for OSGi bundling everything). But the problem with providing a fix was that I couldn't make heads or tails of the build system of derby. There was an and build and there was a maven build in a completely separate place to the source code Oh well! |
Still ANT-based? :) |
>>>> Grzegorz Grzybek ***@***.***>:
Still ANT-based? :)
There is both ANT build files and a maven build.
I don't know which one is used by the derby team and/or in releases?
The maven build tree is in a separate directory tree from the code (which probably makes for a lot of config in the pom files?).
Also derby is still using subversion which makes it harder to provide a patch (I haven't used subversion (much) since 2010 or thereabouts).
So the barrier to provide an OSGi fix for derby feels high! :-)
|
Drop FIXME for ODLPARENT-311 because its not feasible for us to adapt new derby version: - Even current main branch of pax-jdb (1.5.8-SNAPSHOT) supports Java 8 and uses derby version 10.14.2.0 - In addition, it seems that OSGi support in derby in recent versions is "broken": see ops4j/org.ops4j.pax.jdbc#364 In addition, we have concluded to remove not-needed dependencies in ODLPARENT-309. JIRA: ODLPARENT-311 Change-Id: I964170899cdf8303e556a274556ada116c515cb0 Signed-off-by: Ivan Hrasko <[email protected]>
It would be nice if derby could be updated from the now 6 year old 10.14.2.0.
I did a quick search through the closed issues and found this (JDK 8 compatibility keeps derby at 10.: #351 (comment)
And I had already guessed from the release notes that JDK 8 was the reason for staying with ths version
But the derby version is 6 years old now. Maybe it is time to let JDK 8 compatibility go? Are there many people requesting and requiring it?
My problem: I use pax jdbc-config to provide me with a Datasource from config and has used this to run my applications with PostgreSQL as the production database, and using in-memory derby with dummy data for testing in local karaf and in pax exam integraion tests.
However, with a liquibase upgrade a while back my pax exam tests started breaking: liquibase/liquibase#5357
Funnily enough using derby in real karaf (rather than pax exam karaf) worked fine, so it wasn't possible to debug this. I suspect a race condition somewhere.
A fix was introduced in liquibase and the above issue was closed, but the fix wasn't consistent (testing with liquibase 4.26.0 it worked one time out of 5 tries, I think...?) and with 4.27.0 the problem has starting breaking the pax exam tests not just of the liquibase karaf feature, but of my web applications using liquibase as well.
My workaround for the liquibase karaf feature pax exam test was to throw out derby and replace it with h2 (at least for the pax exam test).
The text was updated successfully, but these errors were encountered: