[ https://issues.apache.org/jira/browse/DERBY-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268119#comment-17268119 ]
Daniel Le Berre commented on DERBY-7097:
My issue still holds.
Sure, I can drop derby.jar, derbyshared.jar and derbutools.jar in $TOMCATHOME/lib and my datasource will work fine.
But I have been dropping only derby.jar there for more than a decade to make it work.
Release 1.0.15 changes this. This is a huge change, not just for me, but for a lot of old and new users, which will not only use Derby official documentation but also tutorials found on the internet.
And from the description of the new packages, in [Libraries provided by Derby|https://db.apache.org/derby/docs/10.15/getstart/rgslib46043.html], I have no reason to use derbytools.jar to access the embedded driver, so no reason to put that jar in $TOMCATHOME/lib directory.
This issue is about making clear that a long standing way to proceed is no longer possible.
If the embedded driver in 10.15 is no longer
but a new non API one that is not meant to to be known from the user, then derbytools.jar should be described as providing wintage/legacy EmbeddedDriver for compatibility reasons.
Sorry to be picky about this, but I shouldn't need to check which class are in a jar file to use a tool. The documentation should be clear about requirements. It has always been the case for derby in the past. I wish it will be the same in the future.
> Update documentation to allow users to properly use EmbeddedDriver
> Key: DERBY-7097
> URL: https://issues.apache.org/jira/browse/DERBY-7097
> Project: Derby
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 10.15.2.0
> Reporter: Daniel Le Berre
> Priority: Major
> Attachments: derby-7097-01-aa-jpms-related-website-changes.diff, derby-7097-01-ab-jpms-related-website-changes.diff, derby-7097-02-aa-releaseSummary.diff, derby-7097-03-aa-embeddedDemo.diff
> In earlier version of Derby, and as reported in the documentation, the EmbeddedDriver class was in derby.jar.
> As such, it was quite easy to deploy a webapp with an embedded derby database: it was sufficient to just add a derby.jar file to the project library.
> In current releases of derby (10.15.2.0), the EmbeddedDriver class is no longer in the derby.jar file but in the derbytools.jar file.
> $ for i in `ls *.jar`; do echo $i ; jar tf $i | grep Driver ; done
> As such, most of the tutorials found on the internet about "how to use derby in embedded mode" are just wrong because they simply mention derby.jar as a dependency.
> Worst, derby own documentation is not up to date: as such, I had no way to understand why new releases of this tool that I have been using for more than a decade in the classroom suddenly did not work anymore.
> The explanation is finally simple: I just wonder how such impacting decision could be done without proper documentation.
> I am also surprised to be the first one reporting this, since the problem exists since at least a year.
> There are two possible fix to this issue:
> * move back the EmbeddedDriver class to derby.jar (my favorite option I would say), but I guess there is a good reason for moving those classes to derbytools.jar
> * update the documentation on Derby's web site, with a quite visible alert about this change.
> I have been a pretty happy user of derby for years, and will certainly be in the future. Thanks for that great tool. However, that breaking change has been particularly annoying, which is the reason of that bug report.
This message was sent by Atlassian Jira
|Free forum by Nabble||Edit this page|