Home » Eclipse Projects » Equinox » Work items posted
| | |
| Re: Work items posted [message #17565 is a reply to message #16459] |
Mon, 31 March 2003 08:53   |
Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
I'd like to work on the dynamic plugins ... (Obviously :-)
Kind regards,
Peter Kriens
Pascal Rapicault wrote:
> Hello everybody,
>
> Jeff and I posted lists of work items on every "work areas" pages.
> Sign up for the items you want to work on by responding to the
> newsgroup or directly updating the webpage.
>
> Obviously those lists are not frozen and will evolve as items will show up.
>
> Some items are already attributed, but help is always welcome!
>
> Waiting to hear from you,
>
> Regards,
>
> PaScaL
>
>
>
|
|
|
| Alternative runtimes (Re: Work items posted) [message #17592 is a reply to message #16459] |
Mon, 31 March 2003 13:36 |
| Eclipse User |
|
|
|
Originally posted by: ted.stockwell.acxiom.com
"Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
news:b5vrhk$fl1$1@rogue.oti.com...
> Hello everybody,
>
> Jeff and I posted lists of work items on every "work areas" pages.
> Sign up for the items you want to work on by responding to the
> newsgroup or directly updating the webpage.
>
> Obviously those lists are not frozen and will evolve as items will show
up.
>
> Some items are already attributed, but help is always welcome!
>
> Waiting to hear from you,
>
Since I am already working on plugin-based alternative runtime
implementations for JMX and Tomcat I will follow up by filling in the 'State
of the Art' table for JMX and Tomcat and posting the result to the list. I
also would be more than happy to donate my JBoss JMX, Tomcat, JBoss EJB, and
Apache Axis plugins if they are deemed to be appropriate for Equinox.
Eventually I would like to get these plugins to where they are kinda like
the OSGi HTTP bundle. Other plugins should be able to dynamically deploy
and undeploy MBeans, web applications, EJBs, and web services.
As a reality check, here is how I see Equinox developing and the difference
between OSGi and Equinox. To deploy a Servlet in OSGi a bundle would lookup
the HttpService interface and then call specific methods to deploy a
Servlet. In Equinox I think the procedure would be to use the extension
point registry to lookup a specific extension point and then create a new
extension of that extension point. The extension point concept adds a level
of power to the whole framework. Consider this scenario for example: I
create a plugin that exports an extension point for registering web
services. Later I can add another plugin that creates RMI facades to any
registered web services. This can be done in Equinox in a way that is
decoupled from the web services plugin. The RMI plugin will listen to
registrations against the web services extension point. In OSGi I would
have to add the capability to listen for registrations to each service that
I intended, in advance, to be extendable in this way.
I am more interested in how to eventually use dynamic plugins to implement a
secure, updateable, extendable, and interoperable web service framework than
I am in the specifics of dynamic plugins themselves. Implementing such a
web service framework for publishing web services, and client-side plugins
for consuming web services, is my goal for my JLense project. This is where
my interests and the Equinox project overlap. Besides, architecting dynamic
plugins will be the truly hard part of Equinox so I'm more than happy to
leave that to the real experts!
ted stockwell
jlense.sf.net
|
|
| |
| Re: Alternative runtimes (Re: Work items posted) [message #17706 is a reply to message #17592] |
Mon, 31 March 2003 19:32 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Ted,
I look forward to seeing the state of the art information for JMX and
Tomcat.
Just for clarity, I would like to point out that while Equinox/Eclipse may
turn out to be useful for web stuff, this is not the goal of Equinox (or
Eclipse). We are in no way aiming to replace function provided by JMX,
OSGi, Tomcat, etc etc. We are just looking at how we can run Eclipse on top
of those things.
Jeff
"ted stockwell" <ted.stockwell@acxiom.com> wrote in message
news:b69g27$an7$1@rogue.oti.com...
>
> "Pascal Rapicault" <pascal_rapicault@ca.ibm.com> wrote in message
> news:b5vrhk$fl1$1@rogue.oti.com...
> > Hello everybody,
> >
> > Jeff and I posted lists of work items on every "work areas" pages.
> > Sign up for the items you want to work on by responding to the
> > newsgroup or directly updating the webpage.
> >
> > Obviously those lists are not frozen and will evolve as items will show
> up.
> >
> > Some items are already attributed, but help is always welcome!
> >
> > Waiting to hear from you,
> >
>
> Since I am already working on plugin-based alternative runtime
> implementations for JMX and Tomcat I will follow up by filling in the
'State
> of the Art' table for JMX and Tomcat and posting the result to the list.
I
> also would be more than happy to donate my JBoss JMX, Tomcat, JBoss EJB,
and
> Apache Axis plugins if they are deemed to be appropriate for Equinox.
> Eventually I would like to get these plugins to where they are kinda like
> the OSGi HTTP bundle. Other plugins should be able to dynamically deploy
> and undeploy MBeans, web applications, EJBs, and web services.
>
> As a reality check, here is how I see Equinox developing and the
difference
> between OSGi and Equinox. To deploy a Servlet in OSGi a bundle would
lookup
> the HttpService interface and then call specific methods to deploy a
> Servlet. In Equinox I think the procedure would be to use the extension
> point registry to lookup a specific extension point and then create a new
> extension of that extension point. The extension point concept adds a
level
> of power to the whole framework. Consider this scenario for example: I
> create a plugin that exports an extension point for registering web
> services. Later I can add another plugin that creates RMI facades to any
> registered web services. This can be done in Equinox in a way that is
> decoupled from the web services plugin. The RMI plugin will listen to
> registrations against the web services extension point. In OSGi I would
> have to add the capability to listen for registrations to each service
that
> I intended, in advance, to be extendable in this way.
>
> I am more interested in how to eventually use dynamic plugins to implement
a
> secure, updateable, extendable, and interoperable web service framework
than
> I am in the specifics of dynamic plugins themselves. Implementing such a
> web service framework for publishing web services, and client-side plugins
> for consuming web services, is my goal for my JLense project. This is
where
> my interests and the Equinox project overlap. Besides, architecting
dynamic
> plugins will be the truly hard part of Equinox so I'm more than happy to
> leave that to the real experts!
>
>
> ted stockwell
> jlense.sf.net
>
>
|
|
|
| Re: Alternative runtimes (Re: Work items posted) [message #18554 is a reply to message #17592] |
Tue, 01 April 2003 07:21 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
ted stockwell wrote:
> As a reality check, here is how I see Equinox developing and the difference
> between OSGi and Equinox. To deploy a Servlet in OSGi a bundle would lookup
> the HttpService interface and then call specific methods to deploy a
> Servlet. In Equinox I think the procedure would be to use the extension
> point registry to lookup a specific extension point and then create a new
> extension of that extension point. The extension point concept adds a level
> of power to the whole framework. Consider this scenario for example: I
> create a plugin that exports an extension point for registering web
> services. Later I can add another plugin that creates RMI facades to any
> registered web services. This can be done in Equinox in a way that is
> decoupled from the web services plugin. The RMI plugin will listen to
> registrations against the web services extension point. In OSGi I would
> have to add the capability to listen for registrations to each service that
> I intended, in advance, to be extendable in this way.
The Http Service was one of the first services we developed and has
therefore a model where it keeps a private registry of Servlets and
static resources. However, since then most of our services are developed
with the "white board approach" where the client is registered instead
of the server (i.e. if we had to design the Http Service we would
register an object modeling the servlet, not the web server). This
allows different applications to pick up the same objects for different
purposes. I think this matches your desired model exactly :-)
Kind regards,
Peter Kriens
>
> I am more interested in how to eventually use dynamic plugins to implement a
> secure, updateable, extendable, and interoperable web service framework than
> I am in the specifics of dynamic plugins themselves. Implementing such a
> web service framework for publishing web services, and client-side plugins
> for consuming web services, is my goal for my JLense project. This is where
> my interests and the Equinox project overlap. Besides, architecting dynamic
> plugins will be the truly hard part of Equinox so I'm more than happy to
> leave that to the real experts!
>
>
> ted stockwell
> jlense.sf.net
>
>
>
|
|
|
| Re: Work items posted [message #19815 is a reply to message #16508] |
Thu, 03 April 2003 21:39 |
 Keith Kimball
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
This is a multipart message in MIME format.
--=_alternative 00777F1185256CFD_=
Content-Type: text/plain; charset="US-ASCII"
I'd like to propose a particular area of research and see if that can be
aligned with the goals of the overall group. I've been hesitant to comment
in the newsgroup because I've never worked on an open source project
before, don't want to make a fool of myself, and want to follow proper
etiquette. Apologies in advance if I step on someone's toes.
I have strong management support with at least 50% of my time allocated to
Equinox. Unfortunately, I have limited knowledge of Eclipse internals
but am confident I can quickly come up to speed. I have access to several
other people interested in the project - Mel Martinez works in the same
building, Rick Wilson frequently visits, and Olivier has shown a strong
willingness to give technical guidance -:)
My personal interest is in driving a solution for the "additive" use
case. Someone (perhaps it was Jeff) documented the case of Eclipse being
used as a web browser, loaded a page containing flash, installed the flash
feature (or plug-in), and proceeding.
Personal goals include:
- No hidden agendas
- Work in the Dynamic_Plugins branch
- Compatible with existing plug-ins
- Leverage Pascal's plug-in deactivation work
- Develop in a manner likely to be accepted by the platform group.
- Target Eclipse 2.2.
- Since this feature is not on the proposed list, is it possible?
- Should I propose it for 2.2?
- Where appropriate, leverage work from the OSGi thread.
Suggestions on how to proceed?
--=_alternative 00777F1185256CFD_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">I'd like to propose a particular area
of research and see if that can be aligned with the goals of the overall
group. I've been hesitant to comment in the newsgroup because I've never
worked on an open source project before, don't want to make a fool of myself,
and want to follow proper etiquette. Apologies in advance if I step
on someone's toes.</font>
<br>
<br><font size=2 face="sans-serif">I have strong management support with
at least 50% of my time allocated to Equinox. Unfortunately, I
have limited knowledge of Eclipse internals but am confident I can quickly
come up to speed. I have access to several other people interested in the
project - Mel Martinez works in the same building, Rick Wilson frequently
visits, and Olivier has shown a strong willingness to give technical guidance
-:)</font>
<br>
<br><font size=2 face="sans-serif">My personal interest is in driving a
solution for the "additive" use case. Someone (perhaps it was
Jeff) documented the case of Eclipse being used as a web browser, loaded
a page containing flash, installed the flash feature (or plug-in), and
proceeding.</font>
<br>
<br><font size=2 face="sans-serif">Personal goals include:</font>
<br><font size=2 face="sans-serif"> - No hidden agendas</font>
<br><font size=2 face="sans-serif"> - Work in the Dynamic_Plugins
branch</font>
<br><font size=2 face="sans-serif"> - Compatible with existing plug-ins</font>
<br><font size=2 face="sans-serif"> - Leverage Pascal's plug-in deactivation
work</font>
<br><font size=2 face="sans-serif"> - Develop in a manner likely
to be accepted by the platform group.</font>
<br><font size=2 face="sans-serif"> - Target Eclipse 2.2. </font>
<br><font size=2 face="sans-serif"> - Since this feature
is not on the proposed list, is it possible?</font>
<br><font size=2 face="sans-serif"> - Should I propose
it for 2.2?</font>
<br><font size=2 face="sans-serif"> - Where appropriate, leverage
work from the OSGi thread.</font>
<br>
<br><font size=2 face="sans-serif">Suggestions on how to proceed?</font>
--=_alternative 00777F1185256CFD_=--
|
|
|
| Re: Work items posted [message #19862 is a reply to message #19815] |
Fri, 04 April 2003 04:48 |
Kevin Duffey
Messages: 304
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C2FA22.6A70E1D0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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.
"Keith Kimball" <keith2@us.ibm.com> wrote in message =
news:b6i9md$odg$1@rogue.oti.com...
I'd like to propose a particular area of research and see if that can =
be aligned with the goals of the overall group. I've been hesitant to =
comment in the newsgroup because I've never worked on an open source =
project before, don't want to make a fool of myself, and want to follow =
proper etiquette. Apologies in advance if I step on someone's toes.=20
I have strong management support with at least 50% of my time =
allocated to Equinox. Unfortunately, I have limited knowledge of =
Eclipse internals but am confident I can quickly come up to speed. I =
have access to several other people interested in the project - Mel =
Martinez works in the same building, Rick Wilson frequently visits, and =
Olivier has shown a strong willingness to give technical guidance -:)=20
My personal interest is in driving a solution for the "additive" use =
case. Someone (perhaps it was Jeff) documented the case of Eclipse being =
used as a web browser, loaded a page containing flash, installed the =
flash feature (or plug-in), and proceeding.=20
Personal goals include:=20
- No hidden agendas=20
- Work in the Dynamic_Plugins branch=20
- Compatible with existing plug-ins=20
- Leverage Pascal's plug-in deactivation work=20
- Develop in a manner likely to be accepted by the platform group.=20
- Target Eclipse 2.2.=20
- Since this feature is not on the proposed list, is it =
possible?=20
- Should I propose it for 2.2?=20
- Where appropriate, leverage work from the OSGi thread.=20
Suggestions on how to proceed?
------=_NextPart_000_000B_01C2FA22.6A70E1D0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I'd love to chime in on this thread. I =
have built=20
my own plugin engine similar to eclipse, OSGi and my own creation in =
one. A lot=20
of "new" ideas came for the Eclipse extension mechanism which I have =
implemented=20
in my engine. I also am in the works of redoing my original engine, =
which was=20
similar to OSGi in that it was service based. My engine will provide =
extensions,=20
services, load/unload/reload of plugins, event/listener connection =
management=20
(probably through extensions, not sure though). There are a couple of =
reasons I=20
developed this. Over a year ago I started on my "old" engine that I used =
in a=20
work project and have since revamped the engine to support services, =
extensions,=20
and so forth. While I borrowed some ideas from eclipse and OSGi, I have =
not=20
actually used any code from either project, and I can say that my engine =
does=20
have some flaws in its code. The point I want to bring about is why I =
went this=20
path. Well, first of all, I never knew about Eclipse until a couple of =
months=20
ago, long after my project was already using my engine. As most know, it =
is=20
pretty difficult to get buy in on rewriting an app that is to be =
delivered. More=20
so, none of our other applications are developed in this manner, I am =
the only=20
developer working on this one small project, so I had some freedom in =
how I=20
wanted to develop it. Sadly, my efforts to get our team to use and learn =
Eclipse=20
as I do, and to possibly consider a pluggable architecture for our =
future java=20
apps has been met with, oh, I don't know, disfavor I guess? Long story =
short, I=20
have bigger plans for the use of my engine, but the reason I have =
adopted=20
different engines instead of using any one is for a number of reasons. =
First,=20
the challenge of figuring out how to get dynamically reloadable plugins =
working,=20
that was fun and I did learn a lot about class loaders, classpaths, and =
so=20
forth. More so, because I think Eclipse, OSGi and other approaches =
(JEdit, IDEA,=20
etc) all have some good things in them. But mostly, I wanted a very tiny =
engine=20
that could easily be embeded and used in any type of application, not =
just GUI.=20
I found with Eclipse at the time, it was built around SWT and the =
plugin.xml=20
format was heavily tied into the GUI to allow lazy activation of plugins =
when=20
menu items or buttons were clicked. I have adopted the lazy approach in =
my=20
engine, which definitely makes the most sense. However, like Eclipse, my =
engine=20
allows plugins to be started immediately, and an application built 100% =
on=20
plugins would have to have at least some plugins started to be =
functional. I=20
also, honestly, found Eclipse a bit overwhelming in all the configurable =
options=20
in the config file. I wanted something very simple. I figured if I was =
going to=20
provide an engine that others may use for their own apps, it had better =
be very=20
easy to work with, add to an existing app and generic enough to be used =
for any=20
type of application. Thus, I started my "generic plugin engine" project. =
At=20
present the engine is about 30K in size with xml read/write parser (XML =
Pull=20
parser) embeded in it. It is able to dynamically load plugins at =
runtime, it is=20
configurable to add multiple directory locations to find plugin files =
from URL=20
paths, it allows each plugin to specify any number of extensions, and =
any plugin=20
can extend any plugin similar to how eclipse works (although since I =
didn't look=20
at any of the code, I am not quite sure if it works in the same manner =
to be=20
honest). My engine also provides the .par file format, which is nothing =
more=20
than a .jar file, but structured like a .war file. It can contain at the =
root=20
plugin-conf.xml, and either a .jar file or a /classes folder. Also it =
may=20
contain a /lib dir. Anything in the /lib dir (.jar/.zip) and either the =
..jar=20
file or the /classes folder is automatically part of that plugins =
classloader=20
classpath. Plugins that depend on it can use anything within the reach =
of the=20
plugins immediate classpath but not from any other plugins that plugin =
depends=20
on. I am not entirely sure how Eclipse exports libraries, classes, etc, =
I see it=20
does it. My engine simply makes anything with a plugins classpath =
available to=20
one level of dependents. The engine will work with open directory =
plugins, or=20
..par files. In the case it finds a .par file, it expands it into a =
working=20
directory that is similar to the eclipse plugin folder. The work dir is=20
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=20
the file is not decompressed. This helps avoid long startup times after =
a plugin=20
is first expanded. As I found out the hard way, Java has no built in =
ability to=20
look at .jar files inside of .jar files as part of a .jar classpath, so =
like=20
Eclipse, I opted for the open-directory structure so that every plugin =
can=20
include a /lib/*.jar file(s) and have them added to its =
classpath. I have=20
in the plans a thread that can be set up to auto-watch URLs and =
auto-update=20
plugins on the fly (reload them).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Ok, so the whole reason I am emailing =
this is to=20
say that while I am sure most developers look at the Eclipse and OSGi =
engines as=20
powerful, I, and I am sure many others, feel they are a bit overwhelming =
and=20
difficult to quickly add to an application or build one around it. I =
decided=20
that not only would my engine be tiny and flexible, but at the expense =
of great=20
features, easy to add and use. I feel Eclipse is darn powerful, and I am =
sure=20
OSGi is in its own way as well. I think by combining what both offer =
into a=20
single engine will provide a very powerful, scalable and flexible =
architecture.=20
While I think any competent Java developer can learn to use the engine, =
I think=20
a critical factor in adoption is ease of use, maintainability and "buy =
in" from=20
those in the position to veto the decision to use it. As I have found =
out,=20
despite my efforts to promote the Eclipse engine as a possible candidate =
to=20
build applications from even with 172+ vendors supporting it, IBM behind =
it,=20
almost monthly updates, strong support, and so forth, it seems the "old =
way" of=20
developing is preferred. My point here is, how the hell do you get your=20
senior/lead/boss developers and/or CTO/CIO to buy in to allowing future =
apps=20
built around this type or architecture? For some reason it seems a lot =
of the=20
worry is in the way applications are developed in this manner. It =
honestly is a=20
different way of developing, in that instead of modules being written =
across=20
100's or 1000's of classes, you write small pieces that fit together in =
a=20
dependent yet easily maintainable manner. I think for me, the hard sell =
is=20
trying to instruct those to listen first of all, and if they do, to =
properly=20
inform them of all the advantages of why it is a better method of =
development.=20
Even more so for team development in remote locations!!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Shoot, I got a little off topic there. =
Well, here=20
is my deal. I like my engine, its pretty sweet I think, it is working =
pretty=20
well. However, I love Eclipse IDE, and would love to contribute anything =
I could=20
to the Equinox project. Most notably I would say my knoweldge of using =
XML Pull=20
Parsing might be helpful. The XML Pull Parser is not a 100% XML =
compliant parser=20
in that it doesn't do DTD or XML Schema validation, nor is it by any =
means the=20
normal DOM or SAX type of code to parse the xml file. It is however =
faster than=20
every parser out there, at least from the last tests done on it, it also =
uses=20
less memory than SAX2 parsing, and the code is extremely easy to figure =
out and=20
work with. I would think the parsing of the plugin.xml files, and any =
other .xml=20
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=20
and the spec (working on industry standard adoption right now) even has =
an API=20
to have a validation layer added to it easily, which is actually more =
flexible=20
than DOM/SAX parsers in that you can easily choose the validator wanted =
at=20
runtime.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>So, while I'd like to keep on using my =
own tiny=20
little "kernel" of an engine that provides the basics of eclipse and =
OSGi with=20
the simplicity of a few lines of code to develop a plugin, I'd also like =
to=20
possibly help out with the OSGi/Eclipse marriage (I assume that is what =
Equinox=20
is about?) to see a better overall architecture, that will hopefully be =
a "bare=20
bones" engine that can be used for any application as well. I do want to =
build a=20
simple GUI around my engine for a shell app like thing, sort of like =
Eclipse=20
without any menus, buttons, plugins, etc, that can be ran as is, and I =
imagine=20
the same will be for Equinox. What would be even better is if I could =
develop a=20
way for my plugins to easily be converted into eclipse/OSGi/equinox =
plugins! But=20
that is for later.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Keith Kimball" <<A=20
href=3D"mailto:keith2@us.ibm.com">keith2@us.ibm.com</A>> wrote in =
message <A=20
=
href=3D"news:b6i9md$odg$1@rogue.oti.com">news:b6i9md$odg$1@rogue.oti.com<=
/A>...</DIV><BR><FONT=20
face=3Dsans-serif size=3D2>I'd like to propose a particular area of =
research and=20
see if that can be aligned with the goals of the overall group. I've =
been=20
hesitant to comment in the newsgroup because I've never worked on an =
open=20
source project before, don't want to make a fool of myself, and =
want to=20
follow proper etiquette. Apologies in advance if I step on someone's=20
toes.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>I have strong =
management=20
support with at least 50% of my time allocated to Equinox.=20
Unfortunately, I have limited knowledge of Eclipse =
internals but=20
am confident I can quickly come up to speed. I have access to several =
other=20
people interested in the project - Mel Martinez works in the same =
building,=20
Rick Wilson frequently visits, and Olivier has shown a strong =
willingness to=20
give technical guidance -:)</FONT> <BR><BR><FONT face=3Dsans-serif =
size=3D2>My=20
personal interest is in driving a solution for the "additive" =
use case.=20
Someone (perhaps it was Jeff) documented the case of Eclipse being =
used as a=20
web browser, loaded a page containing flash, installed the flash =
feature (or=20
plug-in), and proceeding.</FONT> <BR><BR><FONT face=3Dsans-serif =
size=3D2>Personal=20
goals include:</FONT> <BR><FONT face=3Dsans-serif size=3D2> - No =
hidden=20
agendas</FONT> <BR><FONT face=3Dsans-serif size=3D2> - Work in =
the=20
Dynamic_Plugins branch</FONT> <BR><FONT face=3Dsans-serif =
size=3D2> -=20
Compatible with existing plug-ins</FONT> <BR><FONT face=3Dsans-serif=20
size=3D2> - Leverage Pascal's plug-in deactivation work</FONT> =
<BR><FONT=20
face=3Dsans-serif size=3D2> - Develop in a manner likely to be =
accepted by=20
the platform group.</FONT> <BR><FONT face=3Dsans-serif size=3D2> =
- Target=20
Eclipse 2.2. </FONT><BR><FONT face=3Dsans-serif size=3D2> =
-=20
Since this feature is not on the proposed list, is it possible?</FONT> =
<BR><FONT face=3Dsans-serif size=3D2> - Should I =
propose it=20
for 2.2?</FONT> <BR><FONT face=3Dsans-serif size=3D2> - Where =
appropriate,=20
leverage work from the OSGi thread.</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
size=3D2>Suggestions on how to =
proceed?</FONT></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000B_01C2FA22.6A70E1D0--
|
|
|
| Re: Work items posted [message #19913 is a reply to message #19862] |
Fri, 04 April 2003 14:49 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Meta note: Lets stick to plain text posts in the newsgroup.
"Kevin" <supreme_java_guru_1@yahoo.com> wrote in message
news:b6j2lq$9ql$1@rogue.oti.com...
.....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
<jm>Some clarification... The Eclipse runtime is not GUI based or related.
The plugin model is completely devoid of any GUI notions. There are many
applications of Eclipse which are entirely headless.
</jm>
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
<jm>This is interesting. Currently Eclipse uses Xerces for all its XML
parsing. The Eclipse requirements are very modest and Xerces is largely
overkill (as well as being 1.2MB on disk).
</jm>
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
<jm>The goals of Equinox are mentioned on the web site. An Eclipse/OSGi
marriage is not a stated goal though it may well be an outcome. The
ultimate goals are centered around dynamic plugins, increased flexibility,
service models, ... We'll use/create whatever technology helps reach those
goals.
</jm>
Jeff
|
|
|
| Re: Work items posted [message #19946 is a reply to message #19815] |
Fri, 04 April 2003 15:04 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Welcome Keith. So others know, Keith was actually on the original list of
committers/participants but has been "otherwise occupied" until now. His
availability as a committer is now reflected in the website. He comes to
the project with a set real problems that need to be solved. I hope that
his participation will help drive us to real solutions to real problems in a
timely fashion.
"Keith Kimball" <keith2@us.ibm.com> wrote in message
news:b6i9md$odg$1@rogue.oti.com...
> My personal interest is in driving a solution for the "additive" use
> case. Someone (perhaps it was Jeff) documented the case of Eclipse being
> used as a web browser, loaded a page containing flash, installed the flash
> feature (or plug-in), and proceeding.
The additive work is currently lurking in the Dynamic plugins/dynamic
registry area of the web. Basically adding a plugin on the fly is
equivalent to installing one and then enabling it. This requires the new
plugin to be woven into the registry structure. This intern means that
interested parties (i.e., plugins providing related extensions and
extension-points) need to be notified and take the appropriate action. To
date the direction has been to include this kind of lifecycle with the
deactivation and disable etc notifications using deltas.
> Suggestions on how to proceed?
As with other people new to Equinox/Eclipse, I suggest coming up to speed on
the details of the Eclipse model. I also recommend reading parts of the
OSGi spec. Not because we are tied to OSGi but because there is lots of
great information/ideas there. Even if we don't end up explicitly OSGi
related, there are many approaches and solutions we can borrow. There is
also a fair bit of background on the website.
Once you feel comfortable (but not too comfortable :-) bite off a small
chunk and go to town.
Communication is the key. Clear, concise and frequent communication is
educational and beneficial to all.
Jeff
|
|
|
| Re: Work items posted [message #20476 is a reply to message #19913] |
Sun, 06 April 2003 07:41 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
I can only give you my own time tables that I have seen in terms of how fast
XMLPullParsing is. I was using JDOM on a 11MB file. It ate up 80+MB in
memory and took over 20 seconds to load/parse on my PIII 800Mhz with 512MB
RAM. The same file took less than 2 seconds using either of the two current
xml pull parser implementations at the xmlpull.org site (xpp3 and mxparser).
It didn't come close to even 15MB or memory being used. These are ROUGH
times and memory consumption, I did not use pro caliber tools.
However, for things like parsing plugin xml files, writing config files out,
or parsing web service xml input/output, as far as I am concerned nothing
comes close to being as easy, fast and resource-free as xml pull parsing.
Yeah, it may look a little different in code, but the code is super beginner
easy to deal with, runs VERY fast, and you can validate inline, or add a
validation class via the xml pull API for validation. I think there is a
Xerces xmlpull tie-in as well, read the site (xmlpull.org) for more info. I
think if Eclipse wants to speed up the parsing of xml, switching to xmlpull
would be a huge improvement in this area. I am willing to bet that it will
increase the performance of all xml related tasks exponentially in eclipse.
Not sure though exactly where/how xml parsing is being used. It would no
doubt require a complete retrofit of the current parsing though.
I am rather surprised that xmlpull hasn't been getting more attention given
its small size (25K), extremely fast speed and less resource usage than a
SAX2 parser! Again, it may be a bit unconventional compared to dom/jdom/sax
parsing, but I find it much faster, easier and more maintanable.
And having used it for some time, I can offer my help in this area.
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b6k5np$9ku$1@rogue.oti.com...
> Meta note: Lets stick to plain text posts in the newsgroup.
>
> "Kevin" <supreme_java_guru_1@yahoo.com> wrote in message
> news:b6j2lq$9ql$1@rogue.oti.com...
>
> ....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
>
> <jm>Some clarification... The Eclipse runtime is not GUI based or related.
> The plugin model is completely devoid of any GUI notions. There are many
> applications of Eclipse which are entirely headless.
> </jm>
>
> 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
>
> <jm>This is interesting. Currently Eclipse uses Xerces for all its XML
> parsing. The Eclipse requirements are very modest and Xerces is largely
> overkill (as well as being 1.2MB on disk).
> </jm>
>
> 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
>
> <jm>The goals of Equinox are mentioned on the web site. An Eclipse/OSGi
> marriage is not a stated goal though it may well be an outcome. The
> ultimate goals are centered around dynamic plugins, increased flexibility,
> service models, ... We'll use/create whatever technology helps reach
those
> goals.
> </jm>
>
> Jeff
>
>
|
|
|
| Re: Work items posted [message #20482 is a reply to message #20476] |
Sun, 06 April 2003 14:43 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Kevin" <kduffey@marketron.com> wrote in message
news:b6olbs$r6g$1@rogue.oti.com...
> I can only give you my own time tables that I have seen in terms of how
fast
> XMLPullParsing is. I was using JDOM on a 11MB file. It ate up 80+MB in
> memory and took over 20 seconds to load/parse on my PIII 800Mhz with 512MB
> RAM. The same file took less than 2 seconds using either of the two
current
> xml pull parser implementations at the xmlpull.org site (xpp3 and
mxparser).
> It didn't come close to even 15MB or memory being used. These are ROUGH
> times and memory consumption, I did not use pro caliber tools.
> I am rather surprised that xmlpull hasn't been getting more attention
given
> its small size (25K), extremely fast speed and less resource usage than a
> SAX2 parser! Again, it may be a bit unconventional compared to
dom/jdom/sax
> parsing, but I find it much faster, easier and more maintanable.
>
> And having used it for some time, I can offer my help in this area.
This sounds great. To try this out in the Eclipse context, could you
prototype pull parsing the plugin structure? Basically replace the class
PluginParser in org.eclipse.core.runtime. It is currently a SAX parser.
The DTD is very simple and is spec'd in the runtime doc. Once we have an
idea of the speed/space improvement there we can recommend to plugin writers
how to us this technique for their parsing.
I have created a bug report for this work. You can attach a patch or whole
new parser when you feel its worth trying.
Jeff
|
|
|
| Re: Work items posted [message #20493 is a reply to message #20482] |
Sun, 06 April 2003 16:32 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Sigh, it would have helped if I attached the bug number. See
http://bugs.eclipse.org/bugs/show_bug.cgi?id=36112
Jeff
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b6pe3s$d6n$1@rogue.oti.com...
>
> "Kevin" <kduffey@marketron.com> wrote in message
> news:b6olbs$r6g$1@rogue.oti.com...
> > I can only give you my own time tables that I have seen in terms of how
> fast
> > XMLPullParsing is. I was using JDOM on a 11MB file. It ate up 80+MB in
> > memory and took over 20 seconds to load/parse on my PIII 800Mhz with
512MB
> > RAM. The same file took less than 2 seconds using either of the two
> current
> > xml pull parser implementations at the xmlpull.org site (xpp3 and
> mxparser).
> > It didn't come close to even 15MB or memory being used. These are ROUGH
> > times and memory consumption, I did not use pro caliber tools.
> > I am rather surprised that xmlpull hasn't been getting more attention
> given
> > its small size (25K), extremely fast speed and less resource usage than
a
> > SAX2 parser! Again, it may be a bit unconventional compared to
> dom/jdom/sax
> > parsing, but I find it much faster, easier and more maintanable.
> >
> > And having used it for some time, I can offer my help in this area.
>
> This sounds great. To try this out in the Eclipse context, could you
> prototype pull parsing the plugin structure? Basically replace the class
> PluginParser in org.eclipse.core.runtime. It is currently a SAX parser.
> The DTD is very simple and is spec'd in the runtime doc. Once we have an
> idea of the speed/space improvement there we can recommend to plugin
writers
> how to us this technique for their parsing.
>
> I have created a bug report for this work. You can attach a patch or
whole
> new parser when you feel its worth trying.
>
> Jeff
>
>
|
|
|
| Re: Work items posted [message #20557 is a reply to message #20493] |
Mon, 07 April 2003 20:52 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
I added myself to the CC list. I will look into this as soon as possible.
Thing is, I am a bit overwhelmed by the task, meaning that it appears there
are a TON of possible nodes!
So, to help me out, can you explain a few things, bring me up to speed. You
say replacing the current PluginParser class with my own version using pull
parser is all I need to do? I recall looking at that class and I sure
couldn't figure out how the heck all the plugin.xml nodes were handled. I
didn't see all the names of the possible nodes. So, is there some reflection
going on, in that it reads a node, uses reflection to call into a specific
class passing attributes, etc to that class method? Or does it indeed have
all the code necessary to read every possible xml node in any plugin.xml
file?
Given the task, is it as simple as just delete (or renaming)
PluginParser.java and copying the basics into my own PluginParser? Do I need
to compile the entire Equinox code, run it, etc? How do I get to compile my
one class, and where do I stick the kxml.jar file so that it is visible in
the classpath for both compiling and runtime for equinox?
Thanks.
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b6pkf2$ghj$1@rogue.oti.com...
> Sigh, it would have helped if I attached the bug number. See
> http://bugs.eclipse.org/bugs/show_bug.cgi?id=36112
>
> Jeff
>
> "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> news:b6pe3s$d6n$1@rogue.oti.com...
> >
> > "Kevin" <kduffey@marketron.com> wrote in message
> > news:b6olbs$r6g$1@rogue.oti.com...
> > > I can only give you my own time tables that I have seen in terms of
how
> > fast
> > > XMLPullParsing is. I was using JDOM on a 11MB file. It ate up 80+MB in
> > > memory and took over 20 seconds to load/parse on my PIII 800Mhz with
> 512MB
> > > RAM. The same file took less than 2 seconds using either of the two
> > current
> > > xml pull parser implementations at the xmlpull.org site (xpp3 and
> > mxparser).
> > > It didn't come close to even 15MB or memory being used. These are
ROUGH
> > > times and memory consumption, I did not use pro caliber tools.
> > > I am rather surprised that xmlpull hasn't been getting more attention
> > given
> > > its small size (25K), extremely fast speed and less resource usage
than
> a
> > > SAX2 parser! Again, it may be a bit unconventional compared to
> > dom/jdom/sax
> > > parsing, but I find it much faster, easier and more maintanable.
> > >
> > > And having used it for some time, I can offer my help in this area.
> >
> > This sounds great. To try this out in the Eclipse context, could you
> > prototype pull parsing the plugin structure? Basically replace the
class
> > PluginParser in org.eclipse.core.runtime. It is currently a SAX parser.
> > The DTD is very simple and is spec'd in the runtime doc. Once we have
an
> > idea of the speed/space improvement there we can recommend to plugin
> writers
> > how to us this technique for their parsing.
> >
> > I have created a bug report for this work. You can attach a patch or
> whole
> > new parser when you feel its worth trying.
> >
> > Jeff
> >
> >
>
>
|
|
|
| Re: Work items posted [message #20609 is a reply to message #20557] |
Tue, 08 April 2003 03:45 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Kevin,
Yup, all you have to do is implement a replacement PluginParser. The
current one is SAX-based. The handle* methods indicate the different nodes
that are required. Note that all nodes under the <extension> tag get
generically parsed into ConfigurationElements with their attributes are
represented by ConfigurationProperties. So in total there are only about 9
or 10 different tags. One other note, this parser reads both plugin.xml and
fragment.xml files. The only DTD difference is in the top level element
(<plugin> and <fragment> respectively).
As for the mechanics of doing this, here are the easiest steps for someone
not too familiar with Eclipse plugin development. I recommend you use the
Eclipes plugin development environment (PDE). There is pretty good doc on
how to set that up and run it. Basically ,
- start eclipse
- follow the PDE steps for importing the Eclipse plugins from org.eclipse.ui
down (all required plugins).
- Open a CVS repo view and create a repo location for
dev.eclipse.org/home/technology using pserver and an anonymous login.
- navigate to HEAD/org.eclipse.equinox/plugins and "check out as project"
the following modules
- org.eclispe.core.runtime
- drop/copy the kxml.jar into the runtime project
- edit runtime's plugin.xml to add a new <library> entry for kxml.jar
- ctrl-shitf-T and open PluginParser
- hack as you will
- when you want to try it follow the PDE instructions for running/debugging
a runtime workbench.
The folks on eclipse.tools could likely help out if you get stuck with the
mechanics.
Jeff
"Kevin" <kduffey@marketron.com> wrote in message
news:b6so3g$pch$1@rogue.oti.com...
> I added myself to the CC list. I will look into this as soon as possible.
> Thing is, I am a bit overwhelmed by the task, meaning that it appears
there
> are a TON of possible nodes!
>
> So, to help me out, can you explain a few things, bring me up to speed.
You
> say replacing the current PluginParser class with my own version using
pull
> parser is all I need to do? I recall looking at that class and I sure
> couldn't figure out how the heck all the plugin.xml nodes were handled. I
> didn't see all the names of the possible nodes. So, is there some
reflection
> going on, in that it reads a node, uses reflection to call into a specific
> class passing attributes, etc to that class method? Or does it indeed have
> all the code necessary to read every possible xml node in any plugin.xml
> file?
>
> Given the task, is it as simple as just delete (or renaming)
> PluginParser.java and copying the basics into my own PluginParser? Do I
need
> to compile the entire Equinox code, run it, etc? How do I get to compile
my
> one class, and where do I stick the kxml.jar file so that it is visible in
> the classpath for both compiling and runtime for equinox?
>
> Thanks.
>
>
> "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> news:b6pkf2$ghj$1@rogue.oti.com...
> > Sigh, it would have helped if I attached the bug number. See
> > http://bugs.eclipse.org/bugs/show_bug.cgi?id=36112
> >
> > Jeff
> >
> > "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> > news:b6pe3s$d6n$1@rogue.oti.com...
> > >
> > > "Kevin" <kduffey@marketron.com> wrote in message
> > > news:b6olbs$r6g$1@rogue.oti.com...
> > > > I can only give you my own time tables that I have seen in terms of
> how
> > > fast
> > > > XMLPullParsing is. I was using JDOM on a 11MB file. It ate up 80+MB
in
> > > > memory and took over 20 seconds to load/parse on my PIII 800Mhz with
> > 512MB
> > > > RAM. The same file took less than 2 seconds using either of the two
> > > current
> > > > xml pull parser implementations at the xmlpull.org site (xpp3 and
> > > mxparser).
> > > > It didn't come close to even 15MB or memory being used. These are
> ROUGH
> > > > times and memory consumption, I did not use pro caliber tools.
> > > > I am rather surprised that xmlpull hasn't been getting more
attention
> > > given
> > > > its small size (25K), extremely fast speed and less resource usage
> than
> > a
> > > > SAX2 parser! Again, it may be a bit unconventional compared to
> > > dom/jdom/sax
> > > > parsing, but I find it much faster, easier and more maintanable.
> > > >
> > > > And having used it for some time, I can offer my help in this area.
> > >
> > > This sounds great. To try this out in the Eclipse context, could you
> > > prototype pull parsing the plugin structure? Basically replace the
> class
> > > PluginParser in org.eclipse.core.runtime. It is currently a SAX
parser.
> > > The DTD is very simple and is spec'd in the runtime doc. Once we have
> an
> > > idea of the speed/space improvement there we can recommend to plugin
> > writers
> > > how to us this technique for their parsing.
> > >
> > > I have created a bug report for this work. You can attach a patch or
> > whole
> > > new parser when you feel its worth trying.
> > >
> > > Jeff
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Work items posted [message #21814 is a reply to message #20609] |
Wed, 09 April 2003 07:12 |
Kevin Duffey
Messages: 304
Registered: July 2009 |
Senior Member |
|
|
Ok, so I got the latest kxml2.jar, got the CVS stuff set up, and added the
kxml2.jar to the org.eclipse.runtime project in that directory. I added
ksml2.jar to the runtime and removed the dependency of xerces. So far the
only class I see that uses xerces is the PluginParser class, so I am
assuming its ok to do this?
A lot of classes show that they depend on things like org.eclipse.boot.* and
org.eclipse.internal.*. I don't see a runtime.jar file in the initial root
dir of this project either. Is this why all the src files have these errors?
I have something like 209 errors right now, its not a pretty site!
Wow, having not done any Sax/2 parsing, this code is ugly! Any hints on how
to find the various nodes that are parsed from the plugin.xml and
features.xml files? I'll keep plugging away.
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b6tg9f$9pt$1@rogue.oti.com...
> Kevin,
>
> Yup, all you have to do is implement a replacement PluginParser. The
> current one is SAX-based. The handle* methods indicate the different
nodes
> that are required. Note that all nodes under the <extension> tag get
> generically parsed into ConfigurationElements with their attributes are
> represented by ConfigurationProperties. So in total there are only about
9
> or 10 different tags. One other note, this parser reads both plugin.xml
and
> fragment.xml files. The only DTD difference is in the top level element
> (<plugin> and <fragment> respectively).
>
> As for the mechanics of doing this, here are the easiest steps for someone
> not too familiar with Eclipse plugin development. I recommend you use the
> Eclipes plugin development environment (PDE). There is pretty good doc on
> how to set that up and run it. Basically ,
>
> - start eclipse
> - follow the PDE steps for importing the Eclipse plugins from
org.eclipse.ui
> down (all required plugins).
> - Open a CVS repo view and create a repo location for
> dev.eclipse.org/home/technology using pserver and an anonymous login.
> - navigate to HEAD/org.eclipse.equinox/plugins and "check out as project"
> the following modules
> - org.eclispe.core.runtime
> - drop/copy the kxml.jar into the runtime project
> - edit runtime's plugin.xml to add a new <library> entry for kxml.jar
> - ctrl-shitf-T and open PluginParser
> - hack as you will
> - when you want to try it follow the PDE instructions for
running/debugging
> a runtime workbench.
>
> The folks on eclipse.tools could likely help out if you get stuck with the
> mechanics.
>
> Jeff
>
>
> "Kevin" <kduffey@marketron.com> wrote in message
> news:b6so3g$pch$1@rogue.oti.com...
> > I added myself to the CC list. I will look into this as soon as
possible.
> > Thing is, I am a bit overwhelmed by the task, meaning that it appears
> there
> > are a TON of possible nodes!
> >
> > So, to help me out, can you explain a few things, bring me up to speed.
> You
> > say replacing the current PluginParser class with my own version using
> pull
> > parser is all I need to do? I recall looking at that class and I sure
> > couldn't figure out how the heck all the plugin.xml nodes were handled.
I
> > didn't see all the names of the possible nodes. So, is there some
> reflection
> > going on, in that it reads a node, uses reflection to call into a
specific
> > class passing attributes, etc to that class method? Or does it indeed
have
> > all the code necessary to read every possible xml node in any plugin.xml
> > file?
> >
> > Given the task, is it as simple as just delete (or renaming)
> > PluginParser.java and copying the basics into my own PluginParser? Do I
> need
> > to compile the entire Equinox code, run it, etc? How do I get to compile
> my
> > one class, and where do I stick the kxml.jar file so that it is visible
in
> > the classpath for both compiling and runtime for equinox?
> >
> > Thanks.
> >
> >
> > "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> > news:b6pkf2$ghj$1@rogue.oti.com...
> > > Sigh, it would have helped if I attached the bug number. See
> > > http://bugs.eclipse.org/bugs/show_bug.cgi?id=36112
> > >
> > > Jeff
> > >
> > > "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> > > news:b6pe3s$d6n$1@rogue.oti.com...
> > > >
> > > > "Kevin" <kduffey@marketron.com> wrote in message
> > > > news:b6olbs$r6g$1@rogue.oti.com...
> > > > > I can only give you my own time tables that I have seen in terms
of
> > how
> > > > fast
> > > > > XMLPullParsing is. I was using JDOM on a 11MB file. It ate up
80+MB
> in
> > > > > memory and took over 20 seconds to load/parse on my PIII 800Mhz
with
> > > 512MB
> > > > > RAM. The same file took less than 2 seconds using either of the
two
> > > > current
> > > > > xml pull parser implementations at the xmlpull.org site (xpp3 and
> > > > mxparser).
> > > > > It didn't come close to even 15MB or memory being used. These are
> > ROUGH
> > > > > times and memory consumption, I did not use pro caliber tools.
> > > > > I am rather surprised that xmlpull hasn't been getting more
> attention
> > > > given
> > > > > its small size (25K), extremely fast speed and less resource usage
> > than
> > > a
> > > > > SAX2 parser! Again, it may be a bit unconventional compared to
> > > > dom/jdom/sax
> > > > > parsing, but I find it much faster, easier and more maintanable.
> > > > >
> > > > > And having used it for some time, I can offer my help in this
area.
> > > >
> > > > This sounds great. To try this out in the Eclipse context, could you
> > > > prototype pull parsing the plugin structure? Basically replace the
> > class
> > > > PluginParser in org.eclipse.core.runtime. It is currently a SAX
> parser.
> > > > The DTD is very simple and is spec'd in the runtime doc. Once we
have
> > an
> > > > idea of the speed/space improvement there we can recommend to plugin
> > > writers
> > > > how to us this technique for their parsing.
> > > >
> > > > I have created a bug report for this work. You can attach a patch
or
> > > whole
> > > > new parser when you feel its worth trying.
> > > >
> > > > Jeff
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Work items posted [message #21859 is a reply to message #21814] |
Wed, 09 April 2003 08:01 |
Kevin Duffey
Messages: 304
Registered: July 2009 |
Senior Member |
|
|
Ok, I am on my way. I have all the outer nodes being processed (in code). I
am lost though, how the heck do I get my code to run? I see it compiles fine
(I think). Can I do something as simple as sticking my compiled class into
my existing Eclipse, restart it and see if it works? Also, I am used to the
old System.out.println() stuff to verify something is working. Is there a
way to run eclipse with a console so I can see that? Or is there a better
way to test out my results? I haven't a lot of time right now to read
in-depth on how to use PDE and such.
Another question, how is it that the core of the engine revolves around
plugin.xml and such, yet it is a plugin that actually parses it? In my own
engine, I have the parsing, the engine, repository, etc all as part of the
core classes that are not plugins. So how is eclipse able to load the plugin
parsing plugin without first being able to parse the plugin the parser
belongs to? Is this paradoxical? Which came first, the egg or the chicken?
Thanks.
|
|
|
Goto Forum:
Current Time: Sat Apr 27 00:26:12 GMT 2024
Powered by FUDForum. Page generated in 0.04674 seconds |
] 
Search
Help
Register
Login
Home
