db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lawrence Mandel <lman...@ca.ibm.com>
Subject Re: Derby Eclipse plug-in updates
Date Fri, 08 Feb 2008 00:23:34 GMT
Hi Andrew,

Thanks for the response.

>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.

Actually, I've been working on as ASF project for a while now. I'm leading 
the Web Services Woden project [1]. On Woden there are developers who 
"own" a piece of code in the sense that they know it best and are the 
first contact for reviews of patches related to the code. It sounds like 
things work a little differently with Derby. Once I have a patch ready for 
review is there someone specific I should cc on the Jira issue? Is there 
another mechanism by which reviews are requested? (Does someone monitor 
Jira updates? Should I post to the dev list?)

>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?

Are you suggesting that the current jars simply be augmented with an OSGi 
manifest and, if required, an activator? One reason I see for creating 
separate OSGi jars is that the current set does not follow the OSGi and 
Eclipse naming conventions [2,3]. This isn't the end of the world but it 
is nice to follow the convention where possible.

[1] http://ws.apache.org/woden
[2] 
http://www2.osgi.org/javadoc/r4/org/osgi/framework/Bundle.html#getSymbolicName()
[3] 
http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.isv/reference/misc/naming.html#Plug-ins

Lawrence






"Andrew McIntyre" <fuzzylogic@apache.org> 
Sent by: mcintyre.a@gmail.com
02/06/2008 11:01 PM
Please respond to
<derby-dev@db.apache.org>


To
derby-dev@db.apache.org
cc

Subject
Re: Derby Eclipse plug-in updates






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