Hi Matthias, Am Sa., 16. Jan. 2021 um 21:53 Uhr schrieb Matthias Bläsing <[email protected]>: > > Am Samstag, den 16.01.2021, 21:12 +0100 schrieb Patrick Schulz: > > [Issue: NETBEANS-3424, derby distribution format was changed to multiple > > jars] > > > > I thought proposing a work around in the corresponding bug report or > > perhaps adding a missing file anywhere to make it work is a small enough > > amount of work to to start a first contribution with :-) > > > > I was a bit confused which parts of the code are used for what. > > RegisterDerby and DerbyOptions seem to be involved, but it also looks like > > it is nbbuild related as it seems to ship some of the files together with > > Netbeans. So when Netbeans is used with Java >= 9 (as NB's runtime ??? or > > as the project's runtime ??? - can't remember), the missing JPMS > > capabilities of Derby are problematic. > > Ok - Oracle tried to special case "their" products in NetBeans. Given > that they owned NetBeans this is fair. For MySQL and JavaDB special > support modules were introduced, that allowed to manage these servers.
This is good to know and perhaps worth a discussion whether this should be kept, extended to other drivers as well or going to be dropped to have an equal handling across all DB drivers. > For derby this code resides in the derby module. Further it was > obviously decided, that the drivers should not be shipped with NetBeans > . I can only speculate on the why, but I suppose some lawyer hinted, > that ALv2 and GPLv2 licenses don't mix well (might depend on your > lawyer and country). Does this question require any additional check with lawyers? A general question is whether drivers are / can be shipped or not, whether it is an "it depends" or a general "no" or a "we always do, except for...". Or specifically here, what are we going to do? There could be reasons why somebody wants to stay with an old version of the driver, so the decision which version to use should be in the hands of the developer, I'd say. > For the code. As far as I understand it, the derby module provides a DB > driver and a library to the NetBeans configuration. That code is in > DerbyOptions. The problem will be to keep compatiblity with old derby > version and still support new versions (maybe scanning the primary jar > file for MANIFEST.MF or the derby pom can be used). Perhaps it is sufficient just to add the derbyshared.jar if it exists. I am not deep enough in this topic to see if any other files are required for Netbeans to manage Derby. > The alternative would be to just ship a set of derby drivers. We > already bundle postgresql (in db.drivers) and we could add derby. It is > _Apache_ derby after all (JavaDB was just a rebranding). This then > raises the question whether new JavaDB drivers can read old DBs. With > the current setup "the right" DB is used, with shipped drivers maybe > incompatiblies arise (but we get more stability). DBs need to be migrated if the minor version number of Derby changes. So if we dictate the version to use this could lead to troubles in some workflows. Perhaps somebody acts with productive data an copies the data files locally to work on it and then wants to copy them back. If we enforce there an data file update to 10.15 we would also enforce an update on the target environment and might not be wanted. So I think I already answered one of my questions above... But I think we can perhaps propose versions that match the given environment, like the Java runtime or whatsoever. Or a simple documentation would do the job even better. Cheers, Patrick --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
