[news.eclipse.tools] Re: Plugin.java instead of plugin.xml

["Jeff McAffer" <jeff_mcaffer@xxxxxxx>]

"Carl Rosenberger" <carl@xxxxxxxx> wrote in message
news:9lev2v$re6$1@xxxxxxxxxxxxxxxx
> Hi all,
>
> - Are you considering to support changing plugins while the engine is
> running? Rebooting steals everyones time while developing tools. A manual
> reload of a specified plugin would be good enough.

This has been discussed off and on for some time now.  I think that everyone
would like this to happen but there are some non-trivial technical issues.
For example, you would need hotswap capabilities if you want to replace code
in place.  If you want to unload and reload a plugin there are issues with
handling of the instances of the plugins classes (i.e., what do you do with
them).  One feature that would more tractable is the dynamic *addition* of
plugins.

> - Why is an XML file necessary to specify interfaces? Wouldn't it be much
> cleaner and more typesafe to stick to Java only? How about a file
> Plugin.java in every plugin Jar? Remember that reflection could be used to
> analyse this file so no redundant information would be necessary at all.
> Yes, I have seen the existing XML masks (and their bugs). XML always
remains
> a sloppy workaround, if not everything is doublechecked automatically. The
> combination of an XML-typo and restarting Eclipse to fix it is just awful.
> Java typechecking *is there* already.

Good question.  On of the key characteristics of Eclipse is that plugins are
not activated until they are actually needed.  Activation occurs when any of
the plugin's classes are loaded.  Using Plugin.java under this model would
cause all plugins to be activated at startup time.  It is conceivable that
the platform could load Plugin.java via a separate mechanism but then there
are issues with people wanting to reference other classes in their plugin
from Plugin.java etc.

Summary:  This is doable but many of the solutions in this space seem to
make things more subtle/complicated.  Using XML we get a simple, explicit,
declarative structure which can be parsed/managed/cached by the platform
without any third party code.  The XML solution also supports people who
want to write plugins which do not contribute code.  For example, the doc
people would have to figure out how to write Plugin.java and get the java
tooling, ...

I fully agree/understand the drawbacks of the current solution.  If its any
consolation, it used to be way worse :-)  Have you had a chance to look at
the PDE tooling?  The plugin.xml editor has significant support for creating
and maintaining valid plugin.xmls.  This uses XML schemas to ensure that,
for example, the extensions you provide have all the right bits and pieces.

> - Are you keeping in mind that an Eclipse-like interface could one day be
> running as a client in a webbrowser (hopefully Eclipse *will be* the
> webbrowser :-) ) ?

yes

> Congratulations for this beautiful piece of software. Thanks for your
great
> work! This will not be an IDE for software development only. The framework
> is perfectly suitable for just about any application I can think of.


Glad you are enjoying your experience.  I'm particularly pleased you see
this as more than a platform for IDEs.  This is something that many people
seem to miss.  Its true the most for the initial applications will be IDEs
for various programming languages but Eclipse can be used to tool just about
any domain.

> If my points have been brought up here before, sorry for repeating them. I
> am just too excited to read along silently first. We will definitely
supply
> an Eclipse plugin for our object database.

You're points are all valid/useful.  Keep 'em coming.  Looking forward to
seeing the plugin for your system.

Jeff

> Kind regards,
> Carl
> ---
> Carl Rosenberger
> db4o - database for objects - http://www.db4o.com
>
>
>