Hello,
I agree that a Derby plug-in will be useful for the application and plug-in developers using
the Eclipse framework.
I have some ideas about creating a simple Derby plug-in. The plug-in could consist of:
Name Details
----------- -------------
org.apache.derby.core contains all the Derby related jars (derby.jar,derbytools.jar and derbynet.jar)
and the plugin.xml
By creating this plug-in for Derby all the related jars can be made available to the Eclipse environment.
This plugin can be used in application and other plug-in development that would require an 'embedded'
database. Other plug-ins can create dependency on this and build on top to provide more functionality.
The version of this plug-in can follow the same Derby versioning (similar to JUnit plug-in for Eclipse,
which follows the versioning of the JUnit testing framework).
For example: org.apache.derby.core_10.0.2.1 (or whichever the latest release of Derby will be).
The JCC jdbc driver (Network Server Connectivity) part is not included, as it is not open sourced by IBM.
I will be happy to work on the 'core' plug-in and contribute it to the same mailing list for review.
BC, regarding the questions in your e-mail:
1) Is it reasonable that such a plug-in be maintained and released with the Derby project, rather than the Web Tools project? I'm happy to contribute a patch for such a plug-in.
I can submit the plug-in to the committers and ask for a vote on whether they will host it at Apache.
2) Is it possible to have an Eclipse "update site" from the Apache web site (that is, a site from which Eclipse can look for new updates to the Derby plug-in)? If so, what would it take to do that?
I will also describe the update site and ask for a vote on that.
3) Like JUnit, I expect that we'd want the plug-in release numbers to be in synch with the Derby release numbers. Has the release number scheme been figured out? (Does the version available from the incubator have a version number?)
I agree, the right approach should be to have the plug-in release number to be in sync with the
Derby ones. Derby does have a versioning scheme. The current version of Derby, I believe, is 10.0.2.1.
Please feel free to send me your comments.
Regards, Rajesh
----- Message from "B.C. Holmes" <[EMAIL PROTECTED]> on Sun, 17 Oct 2004 11:23:53 -0400 -----
To:[email protected] Subject: Eclipse plug-in for Derby base
Hi,
My name is BC Holmes, and I've started working with the Data Tools part of the Eclipse Web Tools project. One of the goals for data tools is to include Derby as an "easy to test with" database. Some example operations include: being able to start and stop Derby (like so many J2EE plug-ins allow one to start and stop a J2EE container), install and test Java stored procedures (and debug them), etc.
Obviously one of the plugins that needs to be created for Eclipse is a simple Derby plug-in. This plug-in would simply contain the Derby code so that other plug-ins could call the Derby API. There's some concern that if Eclipse distributes such a Derby plug-in, that it looks like Eclipse is endorsing one DB over another.
So I'm interested in three things:
1) Is it reasonable that such a plug-in be maintained and released with the Derby project, rather than the Web Tools project? I'm happy to contribute a patch for such a plug-in.
2) Is it possible to have an Eclipse "update site" from the Apache web site (that is, a site from which Eclipse can look for new updates to the Derby plug-in)? If so, what would it take to do that?
3) Like JUnit, I expect that we'd want the plug-in release numbers to be in synch with the Derby release numbers. Has the release number scheme been figured out? (Does the version available from the incubator have a version number?)
Thanks,
BC
-- B.C. Holmes \u2625 http://www.bcholmes.org/ "I can bend minds with my spoon."
