| [news.eclipse.technology.equinox] Re: Work items posted |
|
I'd love to chime in on this thread. I have built
my own plugin engine similar to eclipse, OSGi and my own creation in one. A lot
of "new" ideas came for the Eclipse extension mechanism which I have implemented
in my engine. I also am in the works of redoing my original engine, which was
similar to OSGi in that it was service based. My engine will provide extensions,
services, load/unload/reload of plugins, event/listener connection management
(probably through extensions, not sure though). There are a couple of reasons I
developed this. Over a year ago I started on my "old" engine that I used in a
work project and have since revamped the engine to support services, extensions,
and so forth. While I borrowed some ideas from eclipse and OSGi, I have not
actually used any code from either project, and I can say that my engine does
have some flaws in its code. The point I want to bring about is why I went this
path. Well, first of all, I never knew about Eclipse until a couple of months
ago, long after my project was already using my engine. As most know, it is
pretty difficult to get buy in on rewriting an app that is to be delivered. More
so, none of our other applications are developed in this manner, I am the only
developer working on this one small project, so I had some freedom in how I
wanted to develop it. Sadly, my efforts to get our team to use and learn Eclipse
as I do, and to possibly consider a pluggable architecture for our future java
apps has been met with, oh, I don't know, disfavor I guess? Long story short, I
have bigger plans for the use of my engine, but the reason I have adopted
different engines instead of using any one is for a number of reasons. First,
the challenge of figuring out how to get dynamically reloadable plugins working,
that was fun and I did learn a lot about class loaders, classpaths, and so
forth. More so, because I think Eclipse, OSGi and other approaches (JEdit, IDEA,
etc) all have some good things in them. But mostly, I wanted a very tiny engine
that could easily be embeded and used in any type of application, not just GUI.
I found with Eclipse at the time, it was built around SWT and the plugin.xml
format was heavily tied into the GUI to allow lazy activation of plugins when
menu items or buttons were clicked. I have adopted the lazy approach in my
engine, which definitely makes the most sense. However, like Eclipse, my engine
allows plugins to be started immediately, and an application built 100% on
plugins would have to have at least some plugins started to be functional. I
also, honestly, found Eclipse a bit overwhelming in all the configurable options
in the config file. I wanted something very simple. I figured if I was going to
provide an engine that others may use for their own apps, it had better be very
easy to work with, add to an existing app and generic enough to be used for any
type of application. Thus, I started my "generic plugin engine" project. At
present the engine is about 30K in size with xml read/write parser (XML Pull
parser) embeded in it. It is able to dynamically load plugins at runtime, it is
configurable to add multiple directory locations to find plugin files from URL
paths, it allows each plugin to specify any number of extensions, and any plugin
can extend any plugin similar to how eclipse works (although since I didn't look
at any of the code, I am not quite sure if it works in the same manner to be
honest). My engine also provides the .par file format, which is nothing more
than a .jar file, but structured like a .war file. It can contain at the root
plugin-conf.xml, and either a .jar file or a /classes folder. Also it may
contain a /lib dir. Anything in the /lib dir (.jar/.zip) and either the .jar
file or the /classes folder is automatically part of that plugins classloader
classpath. Plugins that depend on it can use anything within the reach of the
plugins immediate classpath but not from any other plugins that plugin depends
on. I am not entirely sure how Eclipse exports libraries, classes, etc, I see it
does it. My engine simply makes anything with a plugins classpath available to
one level of dependents. The engine will work with open directory plugins, or
.par files. In the case it finds a .par file, it expands it into a working
directory that is similar to the eclipse plugin folder. The work dir is
configurable. Each file in the .par file is compared to the file on disk
(timestamp) and if they have changed, it overwrites the file on disk, otherwise
the file is not decompressed. This helps avoid long startup times after a plugin
is first expanded. As I found out the hard way, Java has no built in ability to
look at .jar files inside of .jar files as part of a .jar classpath, so like
Eclipse, I opted for the open-directory structure so that every plugin can
include a /lib/*.jar file(s) and have them added to its classpath. I have
in the plans a thread that can be set up to auto-watch URLs and auto-update
plugins on the fly (reload them).
Ok, so the whole reason I am emailing this is to
say that while I am sure most developers look at the Eclipse and OSGi engines as
powerful, I, and I am sure many others, feel they are a bit overwhelming and
difficult to quickly add to an application or build one around it. I decided
that not only would my engine be tiny and flexible, but at the expense of great
features, easy to add and use. I feel Eclipse is darn powerful, and I am sure
OSGi is in its own way as well. I think by combining what both offer into a
single engine will provide a very powerful, scalable and flexible architecture.
While I think any competent Java developer can learn to use the engine, I think
a critical factor in adoption is ease of use, maintainability and "buy in" from
those in the position to veto the decision to use it. As I have found out,
despite my efforts to promote the Eclipse engine as a possible candidate to
build applications from even with 172+ vendors supporting it, IBM behind it,
almost monthly updates, strong support, and so forth, it seems the "old way" of
developing is preferred. My point here is, how the hell do you get your
senior/lead/boss developers and/or CTO/CIO to buy in to allowing future apps
built around this type or architecture? For some reason it seems a lot of the
worry is in the way applications are developed in this manner. It honestly is a
different way of developing, in that instead of modules being written across
100's or 1000's of classes, you write small pieces that fit together in a
dependent yet easily maintainable manner. I think for me, the hard sell is
trying to instruct those to listen first of all, and if they do, to properly
inform them of all the advantages of why it is a better method of development.
Even more so for team development in remote locations!!
Shoot, I got a little off topic there. Well, here
is my deal. I like my engine, its pretty sweet I think, it is working pretty
well. However, I love Eclipse IDE, and would love to contribute anything I could
to the Equinox project. Most notably I would say my knoweldge of using XML Pull
Parsing might be helpful. The XML Pull Parser is not a 100% XML compliant parser
in that it doesn't do DTD or XML Schema validation, nor is it by any means the
normal DOM or SAX type of code to parse the xml file. It is however faster than
every parser out there, at least from the last tests done on it, it also uses
less memory than SAX2 parsing, and the code is extremely easy to figure out and
work with. I would think the parsing of the plugin.xml files, and any other .xml
files done by the engine would vastly benefit from a move to this parser
technology. You can actually validate a valid file during the parse by the way
and the spec (working on industry standard adoption right now) even has an API
to have a validation layer added to it easily, which is actually more flexible
than DOM/SAX parsers in that you can easily choose the validator wanted at
runtime.
So, while I'd like to keep on using my own tiny
little "kernel" of an engine that provides the basics of eclipse and OSGi with
the simplicity of a few lines of code to develop a plugin, I'd also like to
possibly help out with the OSGi/Eclipse marriage (I assume that is what Equinox
is about?) to see a better overall architecture, that will hopefully be a "bare
bones" engine that can be used for any application as well. I do want to build a
simple GUI around my engine for a shell app like thing, sort of like Eclipse
without any menus, buttons, plugins, etc, that can be ran as is, and I imagine
the same will be for Equinox. What would be even better is if I could develop a
way for my plugins to easily be converted into eclipse/OSGi/equinox plugins! But
that is for later.
|