Susan Cline wrote:
I think what you are asking for is a valid request. Could you file a
JIRA request for this as an enhancement to the Derby plug-ins?
https://issues.apache.org/jira/browse/DERBY-897 created.
Following the Derby recommendations, that would be the case. This
might be a special case
where it would be appropriate for each plugin to have their
databases in their own state
location so that the databases would be deployed/undeployed
automatically together w ith the
plugin that owns it. I know to little about Derby to see the
ramifications of that though.
Any advice is greatly appreciated.
I can understand what you mean here, and I'm not sure about the
best way to handle it either. If the database was part of the
"client" plug-in, the plug-in that depended on the derby plug-in,
then removing that client plug-in would also remove the database which
would be a clean way to do it. But on the other hand I'm not sure if
this would work from a standpoint of Derby - if the Derby plug-in were
to load the derby jar file I think this would not work, because only
one derby.system.home would be available for the multiple plug-ins
that relied on derby.jar. In this case, derby.system.home would need
to be in the derby plug-ins state directory.
I would think that the "client" plug-in would have to be
responsible for removing the derby database from derby.system.home if
there was an "uninstall" option for the plug-in - or something where
you could "clean-up" when you removed the plug-in.
Does that make sense?
It makes sense and the more I think of it it's probably not that
important anyway. The databases are local to one particular workspace. I
don't think Eclipse cleans out other meta-data when plugins are removed.
Thanks for all insights. I'll create my own central Derby plugin for now
(easy enough) and hope that someone creates the one that I requested so
that I can swap it in the future and perhaps avoid conflicts.
Kind regards,
Thomas Hallgren
