JXR2

[Jeff Martin <jm...@silacom.com>]

I've just checked in a proposal for the next version of JXR. Basically, I'm
not happy with some of the internals of JXR and want to move it to an event
based system. Also I'm to lazy to write a java parser so I think that using
something like ANTLR is a good idea.

Following on from the idea of an event based model it struck me that there's
already a fairly good system for handling even based tree info (Java source
files can be looked at as trees) and that's SAX. So the code I've got here
generates SAX events from a Java source file, it's then should be possible
to apply XSL style sheets to them to view the code in different ways e.g.
Javadoc or JXR style. It also seems like quite a good way of handling things
like metrics as people can write DocumentHandlers to listen to documents and
then generate metrics.

---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org

Re: JXR2

["Kevin A. Burton" <bu...@relativity.yi.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff Martin <jm...@silacom.com> writes:

> I've just checked in a proposal for the next version of JXR. Basically, I'm
> not happy with some of the internals of JXR and want to move it to an event
> based system. Also I'm to lazy to write a java parser so I think that using
> something like ANTLR is a good idea.
> 
> Following on from the idea of an event based model it struck me that there's
> already a fairly good system for handling even based tree info (Java source
> files can be looked at as trees) and that's SAX. So the code I've got here
> generates SAX events from a Java source file, it's then should be possible
> to apply XSL style sheets to them to view the code in different ways e.g.

... not without any major performance overhead :(

XML/XSLT was *not* part of JXR1 for a reason... When you have a LOT of projects
to generate source for it shouldn't take 10 hours just because of XSLT :(.
There are some downsides to JXR1 but this is for performance reasons.

The major problem is the linking which you have to do via a two step process.
You can do one step with an event model but you have to have everything in
memory and then dump it.  

> Javadoc or JXR style.

Granted it would be nice to have a mechanism like this for an open Javadoc style
engine (just rewrite your XSLT to include only Javadoc) but I think it wouldn't
scale.  Granted this would be REALLY nice on the low end.  The problem is I
originally saw Alexandria working as ONE BIG REPOSITORY for tons of source code
projects.  If you have 100 projects under Alexandria this would break it :(
Hopefully Moores Law will come to the rescue some day...

> It also seems like quite a good way of handling things like metrics as people
> can write DocumentHandlers to listen to documents and then generate metrics.
<snip>

In short I generally think this is a good idea but the major issue is
performance.  Back when I originally wrote Alexandria it was taking about 5
hours to run.  Adding XSLT to JXR would have killed it even further.  If you can
get this feature set done within an acceptable performance curve I would be a
big +1024 but I would like to see it...

Do you have any performance metrics you can publish for you code/proposal?

Kevin

- -- 
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
        Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596 

Yes I know my enemies, they're the teachers who taught me to fight me;
compromise, conformity, assimilation, submission, ignorance, hypocrisy,
brutality, The Elite. All of which are American Dreams.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

iD8DBQE63j/RAwM6xb2dfE0RAtm1AKCVbqITuaxjkSetTG3BkELANcYP0QCeNtx0
s/W6vialZ+RkJdRba/uoBic=
=aCUH
-----END PGP SIGNATURE-----


---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org

Re: JXR2

[Josh Lucas <lu...@collab.net>]

On Wed, Apr 18, 2001 at 06:28:06PM +0100, Jeff Martin wrote:
> I've just checked in a proposal for the next version of JXR. Basically, I'm
> not happy with some of the internals of JXR and want to move it to an event
> based system. Also I'm to lazy to write a java parser so I think that using
> something like ANTLR is a good idea.
> 
> Following on from the idea of an event based model it struck me that there's
> already a fairly good system for handling even based tree info (Java source
> files can be looked at as trees) and that's SAX. So the code I've got here
> generates SAX events from a Java source file, it's then should be possible
> to apply XSL style sheets to them to view the code in different ways e.g.
> Javadoc or JXR style. It also seems like quite a good way of handling things
> like metrics as people can write DocumentHandlers to listen to documents and
> then generate metrics.
>

jeff -

I'll look at the code more later tonight but one thing which I think *might* be cool would be to come up with a generic code parser and then have individual language transformers so that jxr could be used for more than just java.

Just a thought off the top of my head...


josh

---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org

Re: JXR2

[Jason van Zyl <jv...@apache.org>]

Jeff Martin wrote:
> 
> I've just checked in a proposal for the next version of JXR. Basically, I'm
> not happy with some of the internals of JXR and want to move it to an event
> based system. Also I'm to lazy to write a java parser so I think that using
> something like ANTLR is a good idea.

Antlr and JavaCC both have full java grammars as part of the
distribution, and both create an AST with which you can do almost
anything you want. Either create a self walking AST, or use Visitors
to do various tasks. I highly recommend using a parser generator. And
the ones for java are already done.

> 
> Following on from the idea of an event based model it struck me that there's
> already a fairly good system for handling even based tree info (Java source
> files can be looked at as trees) and that's SAX. So the code I've got here
> generates SAX events from a Java source file, it's then should be possible
> to apply XSL style sheets to them to view the code in different ways e.g.
> Javadoc or JXR style. It also seems like quite a good way of handling things
> like metrics as people can write DocumentHandlers to listen to documents and
> then generate metrics.

You could easily make a visitor that transformed a java source file
into whatever XML format you wanted. Or you could simply use a single
visitor that fires off events to listeners. Either way a parser
generator
is definitely the way to go IMHO. You don't want to get into hand-coding
a java parser, that's nasty business :-)


-- 
jvz.

Jason van Zyl
jvanzyl@apache.org

http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org

---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org