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

["Kevin" <kduffey@xxxxxxxxxxxxx>]

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
> >
> >
>
>