[news.eclipse.technology.equinox] Re: Work items posted

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

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@xxxxxxxxxxxxx> wrote in message
news:b6so3g$pch$1@xxxxxxxxxxxxxxxx
> 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@xxxxxxxxxx> wrote in message
> news:b6pkf2$ghj$1@xxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxx> wrote in message
> > news:b6pe3s$d6n$1@xxxxxxxxxxxxxxxx
> > >
> > > "Kevin" <kduffey@xxxxxxxxxxxxx> wrote in message
> > > news:b6olbs$r6g$1@xxxxxxxxxxxxxxxx
> > > > 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
> > >
> > >
> >
> >
>
>