db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <fuzzylo...@apache.org>
Subject Re: Derby Eclipse plug-in updates
Date Thu, 07 Feb 2008 04:01:18 GMT
Hi Lawrence,

On Feb 6, 2008 10:04 AM, Lawrence Mandel <lmandel@ca.ibm.com> wrote:
> Since v3.0 Eclipse has been based on OSGi. The Derby Eclipse plug-ins are
> still making use of the older plug-in style. I thought I could contribute
> by updating the Derby plug-ins to the new style. Checking Jira I see there
> are a few open Eclipse issues that have been open for some time including
> repackaging the Derby Eclipse plug-ins as OSGi bundles (as I intended on
> doing), creating Eclipse features (also a good idea), and repackaging
> org.apache.derby.core as 4 bundles instead of including the 4 jars in a
> single bundle. I'd add the creation of an Eclipse update site and changing
> the zip structure to include the eclipse directory so the extracted
> plug-ins are in the eclipse/plugins directory as is the Eclipse
> convention.

These are all good ideas, and I've thought of some other improvements
to the Eclipse plugins recently that aren't reflected in JIRA:

* stub out the Eclipse classes that are used by the plugins, so that
the Derby release managers can build the plugins w/o Eclipse

* provide a preference panel for options like where the network server
is started up, applying your own security policy or no security policy
(that's DERBY-2913), set an authentication provider, etc.

* provide an interface to any JMX functionality that is added (JMX
extensions for Derby are tracked by DERBY-1387), which would take care
of being able to do basic user management from inside Eclipse.

and a couple of larger items:

* provide a hierarchical interface for reading query plans and/or
derby.log. There have been several discussions about this. Search the
archives for 'derby "query plan extraction"'. Getting the information
into XML format would get you most of the way there, but that makes
this a big job. Just throwing it out there.

* provide an interface to the Network Server's tracing capabilities.
There's a couple of different ways you could go here, depending on how
you wanted to present the information.

These have all occurred to me while reading the list or working in
Eclipse, and I should really get around to filing some of these in
JIRA.

As for the update site, it's a great idea, but there was some
controversy on repository@apache because Eclipse update sites at the
time a) didn't use the Apache mirror system and b) didn't check
checksums on files. It looks like those problems have been solved, see
[1]. I would look into that a little more to figure out what Geronimo
did to make their update site.

> I'm posting for two reasons:
>
> 1. To declare my intention to contribute some changes to the Eclipse
> plug-ins and ask if anyone currently owns the Derby Eclipse plug-ins or is
> working on these issues.

To quote Dan [2] from a while ago: No-one is reponsible for any code
at the ASF, there is no code ownership. People work on anything that
scratches their itch.

JIRA is the means of communication for what you're working on. If it's
not there, file a new issue and assign it to yourself. If it's there,
but someone else is already assigned, it's polite to ask to take it
over, but if they don't respond, you should feel free to reassign an
issue to yourself.

> 2. To solicit thoughts on whether it is better to keep a single
> org.apache.derby.core plug-in or break up this plug-in into 4 plug-ins
> org.apache.derby, org.apache.derby.client, org.apache.derby.net, and
> org.apache.derby.tools. As well, I understand that there is already a
> Derby OSGi bundle. Is there a reason to have two bundles derby and
> org.apache.derby? Can we create a single bundle?

For the first question, it definitely makes sense to make different
plugins for each. They each expose different functionality and only
the network server requires the engine also be present. But since the
engine doesn't need the network server, it makes sense to have them as
separate bundles.

It is derby.jar itself that is packaged as an OSGi bundle. I would
expect a lot of pushback to renaming derby.jar to something else. :-)
I think it makes sense to add the new OSGi packaging alongside the
current set of jars, or is there some reason not to do that that I am
missing?

If you need any more information, there's a wealth of it on the wiki,
especially in the dev section:
http://wiki.apache.org/db-derby/DerbyDev

Welcome to Derby,
Andrew

[1] http://mail-archives.apache.org/mod_mbox/incubator-general/200711.mbox/%3C197D5DF8-3414-4CB0-9880-830AA345584B@codefaktor.de%3E
[2] http://mail-archives.apache.org/mod_mbox/db-derby-dev/200605.mbox/%3C4477155E.4050702@apache.org%3E

Mime
View raw message