Apache Derby Management Tool

[Øyvind Jensen <oy...@tihlde.org>]

Introduction

We're two graduates from South Trøndelag University College (Høgskolen I
Sør-Trøndelag, HiST) in Norway. We've developed an administration tool for
Apache Derby as a student project and would like to open it to the
community process and continue working on it.


Why we choose this project

For a number of reasons actually. All of the database management systems
(DBMS) out there has some sort of utility which enables you to administer
the system. Apache Derby has no such thing, not officially that is. We see
the demand for such a tool and we're going to try to fill that gap.

We're setting it free both because we're big fans of free and open source
software, and because Apache Derby is released under the Apache License we
have adopted the same for our code.

Finally because of the challenge. Trying to get the code accepted and to
gain acceptance as developers from a large community is a great challenge.
Especially when trying to make a user interface good enough and functional
for everyone which is a challenge in itself.


Basic functionality

Application programming interface (API)

-Start/Stop database (DB)
-Change port and DB default directory
-Run Apache Derby as network server and embedded
-Create tables and retrieve data
-Show server parameters and monitoring information
-Logging (client and server)
-Manage multiple instances of Apache Derby

Graphical user interface (GUI)
-Using above functionality
-Easy access to SQL query tool (ij)
-Tray icon (Gnome panel on *nix and task bar on Windows)

Status
Almost all of the functions in the API works and the GUI is coming close
to something usable.

Target users
Everyone! But especially new Apache Derby users and those who tries Apache
Derby out for the first time. To have such a tool easily available to
users makes it less probable for them to run away when they read CLI only
somewhere, and in the long run this may encourage more people to
participate in the Community.


Technologies and tools used

-Apache Derby
-Java Management Extension (JMX)
-Swing
-JDBC
-NetBeans IDE

We have set forth a goal to use as little outside of the JRE as possible
when running the tool. No need to install additional software and thus
make it easier to get started using it. The reasoning behind using JMX is
to ease the sharing of information between the running instance and the
client side API. A lot in Apache Derby has been instrumented as manageable
beans and we would like to leverage these capabilities.

We've chosen NetBeans as our IDE because we're both familiar with it, it's
easy to make a good looking GUI with NetBeans, and because there is a good
amount of developers out there using it.


Calling out to all Derby developers

We would like to know your opinions on including a graphical management
tool into Apache Derby. We're aware of the project details when it comes
to GUIs, but we believe there is no better place to host the code. It will
ease development and the tool will in turn potentially benefit the
community.



Our email addresses:
Øyvind Jensen - oyvindje AT tihlde.org
Håvard Barkhall - haavaba AT tihlde.org



Thanks,
-Øyvind J.

Re: Apache Derby Management Tool

[Øyvind Jensen <oy...@tihlde.org>]

Daniel John Debrunner-2 wrote:
> 
>> Basic functionality
>> 
>> Application programming interface (API)
>> 
>> -Start/Stop database (DB)
>> -Change port and DB default directory
>> -Run Apache Derby as network server and embedded
>> -Create tables and retrieve data
>> -Show server parameters and monitoring information
>> -Logging (client and server)
> 
> I'm not sure what is being proposed here for the above list, Derby 
> already has api's to do all of the above, is this introducing new 
> alternate (non-standard?) mechanisms?
> 

The API is client-side only and includes the JMX part connecting to a
running Apache Derby instance. All functionality is implemented here. The
only reason for doing this is to separating out the swing specific parts
completely, if someone wants to make use of what we've done and implement it
with non-swing components. (See below for clarification on possible overlap)


Daniel John Debrunner-2 wrote:
> 
>> We would like to know your opinions on including a graphical management
>> tool into Apache Derby. We're aware of the project details when it comes
>> to GUIs, but we believe there is no better place to host the code. It
>> will
>> ease development and the tool will in turn potentially benefit the
>> community.
> 
> Such a contribution would require a software grant (see 
> http://www.apache.org/licenses/#grants ) which in turn requires that 
> belief from a PMC that it will gain a viable community. One concern is 
> that typically the overlap in interest and skills between database 
> internal folk (e.g. the Derby community) and GUI folk is small.
> 
> On the other hand it's possible that having a different community work 
> on an api for management would be confusing as the Derby community 
> starts to expose management itself through JMX.
> 

I've touched on this with Håvard. I do see things being done by the Derby
community making most or all of our API code obsolete in the long run, and
we have removed some chunks of code leading up to the 10.4 release. I guess
the API will be a transitional part only.
-- 
View this message in context: http://www.nabble.com/Apache-Derby-Management-Tool-tp18931716p18997186.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.

Re: Apache Derby Management Tool

[Daniel John Debrunner <dj...@apache.org>]

Øyvind Jensen wrote:
> Introduction
> 
> We're two graduates from South Trøndelag University College (Høgskolen I
> Sør-Trøndelag, HiST) in Norway. We've developed an administration tool for
> Apache Derby as a student project and would like to open it to the
> community process and continue working on it.

[snip]

Sounds interesting.

> Basic functionality
> 
> Application programming interface (API)
> 
> -Start/Stop database (DB)
> -Change port and DB default directory
> -Run Apache Derby as network server and embedded
> -Create tables and retrieve data
> -Show server parameters and monitoring information
> -Logging (client and server)

I'm not sure what is being proposed here for the above list, Derby 
already has api's to do all of the above, is this introducing new 
alternate (non-standard?) mechanisms?

[snip]

> We would like to know your opinions on including a graphical management
> tool into Apache Derby. We're aware of the project details when it comes
> to GUIs, but we believe there is no better place to host the code. It will
> ease development and the tool will in turn potentially benefit the
> community.

Such a contribution would require a software grant (see 
http://www.apache.org/licenses/#grants ) which in turn requires that 
belief from a PMC that it will gain a viable community. One concern is 
that typically the overlap in interest and skills between database 
internal folk (e.g. the Derby community) and GUI folk is small.

On the other hand it's possible that having a different community work 
on an api for management would be confusing as the Derby community 
starts to expose management itself through JMX.

As Rick pointed out demonstrating a community somewhere (Apache 
Incubator or elsewhere) would be a good first step, also having the code 
open might determine a natural split between the api (hosted within 
Derby) and the GUI (hosted tbd).

Thanks,
Dan.

Re: Apache Derby Management Tool

[Øyvind Jensen <oy...@tihlde.org>]

Rick Hillegas-2 wrote:
> 
> Another approach might be for you to incubate your code as a separate 
> Apache DB subproject. Let me know if that's an appealing option. If it 
> is, I can start a conversation about this on the incubator mailing list.
> 

Indeed it is. We would really like to get this hosted in an Apache
repository. Subproject of Apache DB seems ideal if inclusion in Apache Derby
isn't an option. So if this is what the conversation is leaning towards
please feel free to start a conversation on the incubator mailing list.
-- 
View this message in context: http://www.nabble.com/Apache-Derby-Management-Tool-tp18931716p18997064.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.

Re: Apache Derby Management Tool

[Mike Matrigali <mi...@sbcglobal.net>]

I would rather see the current derby project concentrate on the
engine and not have tools included in it's charter.  It would be
  great to see a separate
project formed for those interested in derby based tools such
as this and others.  Then this could go through the proper
incubation/legal steps.  Sort of how lucene is set up with a
base core project and multiple other projects that are built
on top of the base project.

This new project might also be a good place for database extensions that
are now possible and those that may be enabled in the future.   For 
instance I think sharing table function implementations could be 
valuable.  This might also be a place to collect libraries of user
defined functions usable in derby - I think one such set suggested in 
the past was those implementing spatial capabilities.


Dag H. Wanvik wrote:
> Rick Hillegas <Ri...@Sun.COM> writes:
> 
>> Derby may be the wrong place for your tool itself, however. I don't
>> want to discourage you but it seems to me that the Derby charter
>> pointedly excludes "Database GUI tooling":
>> http://db.apache.org/derby/derby_charter.html#Database+Technology I
>> hope that someone will correct me here if I am mis-interpreting that
>> part of our charter. I don't know why the charter excludes GUI
>> tools. I suppose the community could consider changing that clause.
> 
> When I read this wording I get the idea that the intention here is
> exclude general database tools, e.f. for constructing SQL queries
> based on existing tables etc. I am not sure the intention was to
> exclude a dedicated tool to administer Derby? But I can see it is at
> least arguable that exclusion is intended. Note that a command line
> based management tool would not be excluded...
> 
> What would it take to change to charter wording to allow an
> administration tool for Derby?
> 
> I think it would benefit Derby to make the threshold as low as
> possible for people wanting to contribute in this area, by allowing
> this to coexist with Derby.
> 
> Dag
> 

Re: Apache Derby Management Tool

["Dag H. Wanvik" <Da...@Sun.COM>]

Rick Hillegas <Ri...@Sun.COM> writes:

> Derby may be the wrong place for your tool itself, however. I don't
> want to discourage you but it seems to me that the Derby charter
> pointedly excludes "Database GUI tooling":
> http://db.apache.org/derby/derby_charter.html#Database+Technology I
> hope that someone will correct me here if I am mis-interpreting that
> part of our charter. I don't know why the charter excludes GUI
> tools. I suppose the community could consider changing that clause.

When I read this wording I get the idea that the intention here is
exclude general database tools, e.f. for constructing SQL queries
based on existing tables etc. I am not sure the intention was to
exclude a dedicated tool to administer Derby? But I can see it is at
least arguable that exclusion is intended. Note that a command line
based management tool would not be excluded...

What would it take to change to charter wording to allow an
administration tool for Derby?

I think it would benefit Derby to make the threshold as low as
possible for people wanting to contribute in this area, by allowing
this to coexist with Derby.

Dag

Re: Apache Derby Management Tool

[Rick Hillegas <Ri...@Sun.COM>]

Hi Øyvind and Håvard,

Welcome to derby-dev! What you have built sounds very exciting and 
useful. We are definitely in the business of building JMX support for 
tools like yours and we can certainly use your help. We get a lot of 
requests for GUI admin tools and it would be great to be able to point 
those people at your project. I suspect that some of those people would 
even be willing to study your code and help you extend it. I could see a 
community forming around your contribution.

Derby may be the wrong place for your tool itself, however. I don't want 
to discourage you but it seems to me that the Derby charter pointedly 
excludes "Database GUI tooling": 
http://db.apache.org/derby/derby_charter.html#Database+Technology I hope 
that someone will correct me here if I am mis-interpreting that part of 
our charter. I don't know why the charter excludes GUI tools. I suppose 
the community could consider changing that clause.

Another approach might be for you to incubate your code as a separate 
Apache DB subproject. Let me know if that's an appealing option. If it 
is, I can start a conversation about this on the incubator mailing list.

Another option would be to open-source this code outside Apache but keep 
us informed so that we can point people at your project. Once your code 
develops a community, it will be more attractive to Apache.

Does anyone else have ideas about how we can help Øyvind and Håvard 
develop what sounds like a very useful tool?

Thanks,
-Rick




Øyvind Jensen wrote:
> Introduction
>
> We're two graduates from South Trøndelag University College (Høgskolen I
> Sør-Trøndelag, HiST) in Norway. We've developed an administration tool for
> Apache Derby as a student project and would like to open it to the
> community process and continue working on it.
>
>
> Why we choose this project
>
> For a number of reasons actually. All of the database management systems
> (DBMS) out there has some sort of utility which enables you to administer
> the system. Apache Derby has no such thing, not officially that is. We see
> the demand for such a tool and we're going to try to fill that gap.
>
> We're setting it free both because we're big fans of free and open source
> software, and because Apache Derby is released under the Apache License we
> have adopted the same for our code.
>
> Finally because of the challenge. Trying to get the code accepted and to
> gain acceptance as developers from a large community is a great challenge.
> Especially when trying to make a user interface good enough and functional
> for everyone which is a challenge in itself.
>
>
> Basic functionality
>
> Application programming interface (API)
>
> -Start/Stop database (DB)
> -Change port and DB default directory
> -Run Apache Derby as network server and embedded
> -Create tables and retrieve data
> -Show server parameters and monitoring information
> -Logging (client and server)
> -Manage multiple instances of Apache Derby
>
> Graphical user interface (GUI)
> -Using above functionality
> -Easy access to SQL query tool (ij)
> -Tray icon (Gnome panel on *nix and task bar on Windows)
>
> Status
> Almost all of the functions in the API works and the GUI is coming close
> to something usable.
>
> Target users
> Everyone! But especially new Apache Derby users and those who tries Apache
> Derby out for the first time. To have such a tool easily available to
> users makes it less probable for them to run away when they read CLI only
> somewhere, and in the long run this may encourage more people to
> participate in the Community.
>
>
> Technologies and tools used
>
> -Apache Derby
> -Java Management Extension (JMX)
> -Swing
> -JDBC
> -NetBeans IDE
>
> We have set forth a goal to use as little outside of the JRE as possible
> when running the tool. No need to install additional software and thus
> make it easier to get started using it. The reasoning behind using JMX is
> to ease the sharing of information between the running instance and the
> client side API. A lot in Apache Derby has been instrumented as manageable
> beans and we would like to leverage these capabilities.
>
> We've chosen NetBeans as our IDE because we're both familiar with it, it's
> easy to make a good looking GUI with NetBeans, and because there is a good
> amount of developers out there using it.
>
>
> Calling out to all Derby developers
>
> We would like to know your opinions on including a graphical management
> tool into Apache Derby. We're aware of the project details when it comes
> to GUIs, but we believe there is no better place to host the code. It will
> ease development and the tool will in turn potentially benefit the
> community.
>
>
>
> Our email addresses:
> Øyvind Jensen - oyvindje AT tihlde.org
> Håvard Barkhall - haavaba AT tihlde.org
>
>
>
> Thanks,
> -Øyvind J.
>
>