db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrna van Lunteren <m.v.lunte...@gmail.com>
Subject Re: Eclipse plugins
Date Wed, 11 May 2011 21:43:23 GMT
On Mon, May 2, 2011 at 8:09 AM, Rick Hillegas <rick.hillegas@oracle.com> wrote:
> Now that has been published, I would like to revisit the question
> of what to do with the Eclipse plugins. As I understand it, many Derby users
> develop data-rich applications using these add-ons to the Eclipse IDE. These
> plugins, however, have two problems:
> 1) They violate the Derby charter. The charter explicitly states that we do
> not develop IDEs:
> http://db.apache.org/derby/derby_charter.html#Database+Technology
> 2) As release artifacts, they violate the principle that any Derby committer
> should be able to produce a complete Derby release.
> Over the past five years, I have managed many of our releases. For each of
> these releases, I have had to rely on other community members to supply the
> appropriate Eclipse doc plugin. I have never felt comfortable signing an
> artifact which I did not build myself.
> I would like to fix this situation and end up with a solution which has the
> following general shape:
> A) It is easy for Eclipse users to obtain the right plugins for developing
> Derby-powered applications.
> B) The Derby developer community gets out of the business of supplying IDE
> code which violates our charter.
> C) We return to the principle that any committer can build a complete
> release, and we stop asking release managers to sign artifacts which they
> did not actually build.
> I would like the community's advice about how to move forward on this.
> Thanks,
> -Rick

I'll jump in as I've been the one most recently building and testing
the plugins and minimally maintaining the code.
So, here are my thoughts:
- Everything we can do to lighten the release manager's load helps.
- Testing of the eclipse plugin is manual, so labor intensive.
- I agree with the claim the plugins are contrary to the charter.
They're not exactly an IDE, but they're an interface to one, and they
are GUI tooling.
- There is some technical issue with the plugins regarding the
installation, probably because they've not changed since contribution,
except for basic bug fixing.
- Although the plugins are certainly a nice way to get ij, sysinfo,
and network server inside eclipse and come with helpful documentation,
you can get these tools to work with a little manual effort without
the plugin from within eclipse by just specifying the tools' class in
a 'Run As' entry.
- I have no idea about the accessibility of the eclipse plugin which
limits its usefulness for me.

But I agree with Kathey, the first step should be to announce on
derby-user list that we intend to stop hosting the plugin(s) after
10.8, suggesting that perhaps one of the users of the plugins is
interested in hosting it themselves.

Then, somewhat depending on the response we get, I think we should aim
to actually remove the plugin code from trunk (It will still be there
on the branches where we provided the plugins).


View raw message