You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/10/11 00:58:55 UTC
new JSR on Java Compiler API
People,
Neal Gafter is about to start the process for a new JSR on Java Compiler
API which would hopefully make it fir Tiger (aka Java 1.5). He asked me
if there are people interested in helping out with the details of
bootstrapping this from Apache and since we (and Tomcat) are the one who
need this the most (for XSP and sitemap compilation), I thought about
asking here.
The idea is to allow us to compile stuff without having to use the
filesystem to retrieve both the source file and the classes on which the
code to be compiled depend upon.
So, if you are a committer and want to join, just raise your hand and
we'll see what happens.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Port
Posted by Berin Loritsch <bl...@apache.org>.
Tony Collen wrote:
> Dave Bettin wrote:
>
>> I have started a port of Cocoon to C#/.Net. Has anyone
>> heard of such a port, before I get to far?
>>
>> My goal behind this effort is to provide a cocoon
>> implementation on the .net platform and also to allow
>> users to have "cocoon platform independence".
>>
>>
>
> Just wondering, this is not a flame, but which platform doesn't Cocoon
> run on? AFAIK, it runs under IIS with ServletExec already.
> Tony.
C#/.Net has some things that are definitely worth considering:
#1) Can easily use C++/C#/J#/C libraries without having to do odd
imports. I.e. it is language neutral without the overhead of
CORBA
#2) The attributes/delegates functionality of C# is very powerful.
The Avalon team has been looking into mimicking that functionality
in Java. We have support for Delegates (of a fashion), but the
attributes are more difficult. BTW, Attribtutes are the key to
successful and predictable AOP (Aspect Oriented Programming).
Can Cocoon work with Windows/Solaris/AIX/AS400/Linux/put your JVM here?
Yes! And that is its biggest strength. However, there are other things
that we might want to do where Java limits us.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Port
Posted by Stefano Mazzocchi <st...@apache.org>.
Stefano Mazzocchi wrote:
> I'm personally happy if somebody ports Cocoon in other languages (people
> already did twice, for Perl and PHP)
I was referring to Axkit as the Cocoon's port in Perl but it's a
mistake: even if they offer similar functionalities and use similar
technologies, AxKit and Cocoon were built and designed independently.
I sincerely apologize for this.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Port
Posted by Stefano Mazzocchi <st...@apache.org>.
Dave Bettin wrote:
> Stefano,
>
> I will absolutely respect the "Cocoon" name.
Thank you, this is very appreciated.
> (I guess "CocoonSoft" is out :) ) I believe
> Cocoon is a tremendous framework that should be
> available for .Net.
I have no objections to this, as long as it doesn't get into our way.
> As I get farther into this "port" I will use
> some of my own ideas in the implementation. And it
> will slowly break from the Cocoon mold and live
> through it's own community.
It will be exiting to be challenged :) hopefully you'll be able to give
us ideas and suggestions that we weren't able to see from our
java-oriented point of view.
> The only thing I ask, Is I would like to acknowledge
> the ideas for the .Net project were conceived from
> Cocoon?
Sure. I actually like this. It shows that your effort respect ours but
at the same time doesn't try to use its visibility and name to promote
itself.
Just one thing: be aware of the fact that even if you use our source
code and automatically translate it into C# (I know it's possible), that
forces you to state somewhare in your docs that you are basing your work
on software written by the ASF, just like the license states.
That is: licenses apply also to mechanical code translations.
> I appreciate the great framework and will definitely
> not ruin the value of "Cocoon".
Thanks.
From our point of view, I can tell you that as long as mutual respect
is kept, collaboration (and design challenges!) will always be something
that we'll look for. And can potentially make both projects better.
Good luck with your effort.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Port
Posted by Dave Bettin <ja...@yahoo.com>.
>
> Dave,
>
> please be aware of the fact that Cocoon lives on
the
> value of its name
> and its license protects it.
>
> I'm personally happy if somebody ports Cocoon in
> other languages (people
> already did twice, for Perl and PHP) but I'll be
> personally pissed if
> they used 'cocoon' inside the name if they
> distribute something which is
> not coming *straight* from this project.
>
> So, whatever you end up with, please, don't call
it
> 'cocoon#' or 'Cocoon
> .NET' or "NCocoon" or anything that
contains Cocoon
> in it, unless you
> want to donate your code to this project and then
> the community will
> decide if we want to maintain two independent
> codebases written in two
> different languages. [but it would be easy to
guess
> the answer]
>
> As far as C# goes, I think .NET does things
better
> than java in a few
> circumstances, but for sure this is not a good
> reason to throw away
> those millions of lines of code we already have.
>
> So, at the end, all I personally ask you is to be
> respectful of our work
> by not abusing the name cocoon for your work.
>
> For anything else, expect great collaboration
from
> me even if I'm not
> going to move my programming skills to C# just
yet.
>
> [and people, please, no language-flamewars, ok?
the
> world is beautiful
> because it's diverse, we just have to be nice and
> respectful one another]
>
> --
> Stefano Mazzocchi
> <stefano@apache.org>
Stefano,
I will absolutely respect the "Cocoon" name.
(I guess "CocoonSoft" is out :) ) I believe
Cocoon is a tremendous framework that should be
available for .Net.
As I get farther into this "port" I will use
some of my own ideas in the implementation. And it
will slowly break from the Cocoon mold and live
through it's own community.
The only thing I ask, Is I would like to acknowledge
the ideas for the .Net project were conceived from
Cocoon?
I appreciate the great framework and will definitely
not ruin the value of "Cocoon".
Thanks,
Dave
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Port
Posted by Stefano Mazzocchi <st...@apache.org>.
Dave Bettin wrote:
> Sorry, should have explained that statement a little
> better. What I intended to mean, was to allow users to
> pick up an application on the .Net port and move it to
> cocoon w/o much hassle and vice a versa.
Dave,
please be aware of the fact that Cocoon lives on the value of its name
and its license protects it.
I'm personally happy if somebody ports Cocoon in other languages (people
already did twice, for Perl and PHP) but I'll be personally pissed if
they used 'cocoon' inside the name if they distribute something which is
not coming *straight* from this project.
So, whatever you end up with, please, don't call it 'cocoon#' or 'Cocoon
.NET' or "NCocoon" or anything that contains Cocoon in it, unless you
want to donate your code to this project and then the community will
decide if we want to maintain two independent codebases written in two
different languages. [but it would be easy to guess the answer]
As far as C# goes, I think .NET does things better than java in a few
circumstances, but for sure this is not a good reason to throw away
those millions of lines of code we already have.
So, at the end, all I personally ask you is to be respectful of our work
by not abusing the name cocoon for your work.
For anything else, expect great collaboration from me even if I'm not
going to move my programming skills to C# just yet.
[and people, please, no language-flamewars, ok? the world is beautiful
because it's diverse, we just have to be nice and respectful one another]
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Port
Posted by Dave Bettin <ja...@yahoo.com>.
Sorry, should have explained that statement a little
better. What I intended to mean, was to allow users to
pick up an application on the .Net port and move it to
cocoon w/o much hassle and vice a versa.
Dave
--- Tony Collen <tc...@hist.umn.edu> wrote:
> Dave Bettin wrote:
>
> >I have started a port of Cocoon to C#/.Net. Has
> anyone
> > heard of such a port, before I get to far?
> >
> > My goal behind this effort is to provide a cocoon
> >implementation on the .net platform and also to
> allow
> >users to have "cocoon platform independence".
> >
> >
> >
>
> Just wondering, this is not a flame, but which
> platform doesn't Cocoon
> run on? AFAIK, it runs under IIS with ServletExec
> already.
>
> Tony.
>
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email:
> cocoon-dev-help@xml.apache.org
>
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Port
Posted by Tony Collen <tc...@hist.umn.edu>.
Dave Bettin wrote:
>I have started a port of Cocoon to C#/.Net. Has anyone
> heard of such a port, before I get to far?
>
> My goal behind this effort is to provide a cocoon
>implementation on the .net platform and also to allow
>users to have "cocoon platform independence".
>
>
>
Just wondering, this is not a flame, but which platform doesn't Cocoon
run on? AFAIK, it runs under IIS with ServletExec already.
Tony.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Port
Posted by "Ilya A. Kriveshko" <il...@kaon.com>.
Search for 'J#'. All you may need to do to port Cocoon to .NET is
recompile it.
BTW, when you say port, do you mean port of a snapshot of Cocoon, or a
port that would be continuously maintained and track changes in Cocoon?
Do you have a deployment objective in mind, or is this just an exercise?
Just curious.
Best of luck.
--
Ilya
P.S.:
Dave Bettin wrote:
> port of Cocoon to C#/.NET ... to allow users to have "cocoon platform
> independence".
Isn't that an oxymoron. :-) Tee-hee.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Port
Posted by Tony Collen <tc...@hist.umn.edu>.
Dave Bettin wrote:
>My objectives are as follows:
>
>1) Use Avalon C# Port
>2) Take advantage of .Net benefits: caching, codedom,
>xml integration (possibly could be a disadvantage) :)
>3) Language support. Tha ability to have cocoon
>extensions, xsp written in smalltalk,java, eiffel,
>cobol would be nice
>4) Have this run on Mono and other .Net environments.
>5) It's a great framework. Why can't .Net developers
>enjoy.
>5) It's fun
>
>
Fair enough :) Good luck!
Tony
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Port
Posted by Dave Bettin <ja...@yahoo.com>.
My objectives are as follows:
1) Use Avalon C# Port
2) Take advantage of .Net benefits: caching, codedom,
xml integration (possibly could be a disadvantage) :)
3) Language support. Tha ability to have cocoon
extensions, xsp written in smalltalk,java, eiffel,
cobol would be nice
4) Have this run on Mono and other .Net environments.
5) It's a great framework. Why can't .Net developers
enjoy.
5) It's fun
Dave
--- Berin Loritsch <bl...@apache.org> wrote:
> Dave Bettin wrote:
> > I have started a port of Cocoon to C#/.Net. Has
> anyone
> > heard of such a port, before I get to far?
> >
> > My goal behind this effort is to provide a cocoon
> > implementation on the .net platform and also to
> allow
> > users to have "cocoon platform independence".
>
> The Avalon team (which is what Cocoon is built on)
> has
> a port of Avalon Framework for C#. It is largely
> untested,
> and we can't vouch for the build environment (I've
> been trying
> to get C# installed myself), but it is a starting
> point.
>
>
> --
>
> "They that give up essential liberty to obtain a
> little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email:
> cocoon-dev-help@xml.apache.org
>
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Port
Posted by Berin Loritsch <bl...@apache.org>.
Dave Bettin wrote:
> I have started a port of Cocoon to C#/.Net. Has anyone
> heard of such a port, before I get to far?
>
> My goal behind this effort is to provide a cocoon
> implementation on the .net platform and also to allow
> users to have "cocoon platform independence".
The Avalon team (which is what Cocoon is built on) has
a port of Avalon Framework for C#. It is largely untested,
and we can't vouch for the build environment (I've been trying
to get C# installed myself), but it is a starting point.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Cocoon Port
Posted by Dave Bettin <ja...@yahoo.com>.
I have started a port of Cocoon to C#/.Net. Has anyone
heard of such a port, before I get to far?
My goal behind this effort is to provide a cocoon
implementation on the .net platform and also to allow
users to have "cocoon platform independence".
Thanks,
Dave
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: new JSR on Java Compiler API
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ovidiu Predescu wrote:
> On Monday, October 14, 2002, at 01:20 AM, Sylvain Wallez wrote:
>
>> Ovidiu Predescu wrote:
>>
>>> On Friday, October 11, 2002, at 02:09 AM, Sylvain Wallez wrote:
>>>
>>>> Stefano Mazzocchi wrote:
>>>>
>>>>> People,
>>>>>
>>>>> Neal Gafter is about to start the process for a new JSR on Java
>>>>> Compiler API which would hopefully make it fir Tiger (aka Java
>>>>> 1.5). He asked me if there are people interested in helping out
>>>>> with the details of bootstrapping this from Apache and since we
>>>>> (and Tomcat) are the one who need this the most (for XSP and
>>>>> sitemap compilation), I thought about asking here.
>>>>>
>>>>> The idea is to allow us to compile stuff without having to use the
>>>>> filesystem to retrieve both the source file and the classes on
>>>>> which the code to be compiled depend upon.
>>>>>
>>>>> So, if you are a committer and want to join, just raise your hand
>>>>> and we'll see what happens.
>>>>
>>>>
>>>> What would be very cool is to be able to specify line numbers of
>>>> the source file that generated the Java code (like #line in C).
>>>> This would allow for source-level XSP debuggers !
>>>
>>>
>>> I've implemented this feature long time ago for the compiled
>>> sitemap, in the sitemap.xsl stylesheet. The generated sitemap would
>>> have lines like:
>>>
>>> // file: src/webapp/sitemap.xmap
>>> // line: 123
>>
>>
>> I know this, and what I'm proposing extends it to the source file and
>> line number information in the bytecode.
>>
>> The above allows to find the line in the sitemap/XSP that generated a
>> given statement in the Java code. But exceptions stacktraces still
>> refer to source lines of the generated java code, and not source
>> lines of the original sitemap/XSP.
>>
>> My proposal would allow to have exceptions carry the file name and
>> line number of the _sitemap/XSP file_ that originated the Java code.
>> You would then have stacktraces like this :
>>
>> my.app.MyException (app failed)
>> at my.app.MyClass (MyClass.java:315)
>> at my.webapp.myXsp_xsp.generate (myXsp.xsp:79) <===
>> at ServerPagesGenerator.generate (ServerPagesGenerator.java:89)
>> at my.webapp.sitemap_xmap.match123 (sitemap.xmap:152) <===
>> ...
>>
>> This kind of information would greatly help debugging Cocoon
>> applications, and would also allow source-level debugging of XSPs
>> using existing debuggers.
>
>
> Gotcha!
>
> I was thinking along the same lines when I've wrote the code to
> generate filename/line number in the sitemap. You can have an
> exception translator which maps line numbers from compiled XSP and
> sitemaps to the original source code. This is a common technique used
> in debuggers, including JSP debuggers. This mapping however happens by
> analyzing the translated source code, in our case the XSP or sitemap
> generated Java code, which embeds comments containing filename and
> line number information. You technically don't need to go to the low
> level Java bytecodes to generate this information.
I didn't knew this technique. It surely works, but requires a custom
debugger : you cannot use e.g. JSwat or Eclipse built-in debugger which
provide excellent features.
Do you know an open-source debugger that implements this ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: new JSR on Java Compiler API
Posted by Ovidiu Predescu <ov...@apache.org>.
On Monday, October 14, 2002, at 01:20 AM, Sylvain Wallez wrote:
> Ovidiu Predescu wrote:
>
>>
>> On Friday, October 11, 2002, at 02:09 AM, Sylvain Wallez wrote:
>>
>>> Stefano Mazzocchi wrote:
>>>
>>>> People,
>>>>
>>>> Neal Gafter is about to start the process for a new JSR on Java
>>>> Compiler API which would hopefully make it fir Tiger (aka Java
>>>> 1.5). He asked me if there are people interested in helping out
>>>> with the details of bootstrapping this from Apache and since we
>>>> (and Tomcat) are the one who need this the most (for XSP and
>>>> sitemap compilation), I thought about asking here.
>>>>
>>>> The idea is to allow us to compile stuff without having to use the
>>>> filesystem to retrieve both the source file and the classes on
>>>> which the code to be compiled depend upon.
>>>>
>>>> So, if you are a committer and want to join, just raise your hand
>>>> and we'll see what happens.
>>>
>>>
>>>
>>> What would be very cool is to be able to specify line numbers of
>>> the source file that generated the Java code (like #line in C). This
>>> would allow for source-level XSP debuggers !
>>
>>
>> I've implemented this feature long time ago for the compiled sitemap,
>> in the sitemap.xsl stylesheet. The generated sitemap would have lines
>> like:
>>
>> // file: src/webapp/sitemap.xmap
>> // line: 123
>
>
> I know this, and what I'm proposing extends it to the source file and
> line number information in the bytecode.
>
> The above allows to find the line in the sitemap/XSP that generated a
> given statement in the Java code. But exceptions stacktraces still
> refer to source lines of the generated java code, and not source lines
> of the original sitemap/XSP.
>
> My proposal would allow to have exceptions carry the file name and
> line number of the _sitemap/XSP file_ that originated the Java code.
> You would then have stacktraces like this :
>
> my.app.MyException (app failed)
> at my.app.MyClass (MyClass.java:315)
> at my.webapp.myXsp_xsp.generate (myXsp.xsp:79) <===
> at ServerPagesGenerator.generate (ServerPagesGenerator.java:89)
> at my.webapp.sitemap_xmap.match123 (sitemap.xmap:152) <===
> ...
>
> This kind of information would greatly help debugging Cocoon
> applications, and would also allow source-level debugging of XSPs
> using existing debuggers.
Gotcha!
I was thinking along the same lines when I've wrote the code to
generate filename/line number in the sitemap. You can have an exception
translator which maps line numbers from compiled XSP and sitemaps to
the original source code. This is a common technique used in debuggers,
including JSP debuggers. This mapping however happens by analyzing the
translated source code, in our case the XSP or sitemap generated Java
code, which embeds comments containing filename and line number
information. You technically don't need to go to the low level Java
bytecodes to generate this information.
Regards,
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU,
Emacs ...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: new JSR on Java Compiler API
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ovidiu Predescu wrote:
>
> On Friday, October 11, 2002, at 02:09 AM, Sylvain Wallez wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> People,
>>>
>>> Neal Gafter is about to start the process for a new JSR on Java
>>> Compiler API which would hopefully make it fir Tiger (aka Java 1.5).
>>> He asked me if there are people interested in helping out with the
>>> details of bootstrapping this from Apache and since we (and Tomcat)
>>> are the one who need this the most (for XSP and sitemap
>>> compilation), I thought about asking here.
>>>
>>> The idea is to allow us to compile stuff without having to use the
>>> filesystem to retrieve both the source file and the classes on which
>>> the code to be compiled depend upon.
>>>
>>> So, if you are a committer and want to join, just raise your hand
>>> and we'll see what happens.
>>
>>
>>
>> What would be very cool is to be able to specify line numbers of the
>> source file that generated the Java code (like #line in C). This
>> would allow for source-level XSP debuggers !
>
>
> I've implemented this feature long time ago for the compiled sitemap,
> in the sitemap.xsl stylesheet. The generated sitemap would have lines
> like:
>
> // file: src/webapp/sitemap.xmap
> // line: 123
I know this, and what I'm proposing extends it to the source file and
line number information in the bytecode.
The above allows to find the line in the sitemap/XSP that generated a
given statement in the Java code. But exceptions stacktraces still refer
to source lines of the generated java code, and not source lines of the
original sitemap/XSP.
My proposal would allow to have exceptions carry the file name and line
number of the _sitemap/XSP file_ that originated the Java code. You
would then have stacktraces like this :
my.app.MyException (app failed)
at my.app.MyClass (MyClass.java:315)
at my.webapp.myXsp_xsp.generate (myXsp.xsp:79) <===
at ServerPagesGenerator.generate (ServerPagesGenerator.java:89)
at my.webapp.sitemap_xmap.match123 (sitemap.xmap:152) <===
...
This kind of information would greatly help debugging Cocoon
applications, and would also allow source-level debugging of XSPs using
existing debuggers.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: new JSR on Java Compiler API
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Ovidiu Predescu wrote:
> I've implemented this feature long time ago for the compiled sitemap, in
> the sitemap.xsl stylesheet. The generated sitemap would have lines like:
>
> // file: src/webapp/sitemap.xmap
> // line: 123
>
> This was possible using some extension functions provided by Saxon for
> example. For Xalan I contributed a patch, but support for that seems to
> be broken. It may have changed with the latest releases, I don't know.
Unfortunately, nowadays the sitemap transformation seems to be
fed with SAX events, which means there is no line number information
even if Saxon is used...
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: new JSR on Java Compiler API
Posted by Ovidiu Predescu <ov...@apache.org>.
On Friday, October 11, 2002, at 02:09 AM, Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> People,
>>
>> Neal Gafter is about to start the process for a new JSR on Java
>> Compiler API which would hopefully make it fir Tiger (aka Java 1.5).
>> He asked me if there are people interested in helping out with the
>> details of bootstrapping this from Apache and since we (and Tomcat)
>> are the one who need this the most (for XSP and sitemap compilation),
>> I thought about asking here.
>>
>> The idea is to allow us to compile stuff without having to use the
>> filesystem to retrieve both the source file and the classes on which
>> the code to be compiled depend upon.
>>
>> So, if you are a committer and want to join, just raise your hand and
>> we'll see what happens.
>
>
> What would be very cool is to be able to specify line numbers of the
> source file that generated the Java code (like #line in C). This would
> allow for source-level XSP debuggers !
I've implemented this feature long time ago for the compiled sitemap,
in the sitemap.xsl stylesheet. The generated sitemap would have lines
like:
// file: src/webapp/sitemap.xmap
// line: 123
This was possible using some extension functions provided by Saxon for
example. For Xalan I contributed a patch, but support for that seems to
be broken. It may have changed with the latest releases, I don't know.
I use this feature in my XSLT-process for Emacs, the visual XSLT
debugger makes use of it to step through the XML input document and the
XSLT stylesheet. Pretty powerful stuff, check out the screenshots at:
http://xslt-process.sourceforge.net/screenshots.php
Regards,
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU,
Emacs ...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: new JSR on Java Compiler API
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
> People,
>
> Neal Gafter is about to start the process for a new JSR on Java
> Compiler API which would hopefully make it fir Tiger (aka Java 1.5).
> He asked me if there are people interested in helping out with the
> details of bootstrapping this from Apache and since we (and Tomcat)
> are the one who need this the most (for XSP and sitemap compilation),
> I thought about asking here.
>
> The idea is to allow us to compile stuff without having to use the
> filesystem to retrieve both the source file and the classes on which
> the code to be compiled depend upon.
>
> So, if you are a committer and want to join, just raise your hand and
> we'll see what happens.
What would be very cool is to be able to specify line numbers of the
source file that generated the Java code (like #line in C). This would
allow for source-level XSP debuggers !
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: new JSR on Java Compiler API
Posted by Ovidiu Predescu <ov...@apache.org>.
On Thursday, October 10, 2002, at 09:48 PM, Ivelin Ivanov wrote:
>
> I am interested to participate in the discovery stage.
> If I can bring enough value I will stay longer in the group.
>
> I assume this standard covers XSLTC as well.
> Is the XSLTC team invited ?
>
> What I would like to see in future is XSLT and Java programs being
> compiled
> and debugged in the same environment.
Um, shameless plug, try out XSLT-process for (X)Emacs ;) It doesn't yet
integrate with the Java debugger, but it can be definitely implemented.
I'm sure commercial vendors already have this though.
Cheers,
Ovidiu
> ----- Original Message -----
> From: "Ovidiu Predescu" <ov...@apache.org>
> To: <co...@xml.apache.org>
> Sent: Thursday, October 10, 2002 7:05 PM
> Subject: Re: new JSR on Java Compiler API
>
>
>> On Thursday, October 10, 2002, at 03:58 PM, Stefano Mazzocchi wrote:
>>
>>> People,
>>>
>>> Neal Gafter is about to start the process for a new JSR on Java
>>> Compiler API which would hopefully make it fir Tiger (aka Java 1.5).
>>> He asked me if there are people interested in helping out with the
>>> details of bootstrapping this from Apache and since we (and Tomcat)
>>> are the one who need this the most (for XSP and sitemap compilation),
>>> I thought about asking here.
>>>
>>> The idea is to allow us to compile stuff without having to use the
>>> filesystem to retrieve both the source file and the classes on which
>>> the code to be compiled depend upon.
>>>
>>> So, if you are a committer and want to join, just raise your hand and
>>> we'll see what happens.
>>
>> I'd be interested in this work too.
>>
>> I'd actually go a bit further in what gets exposed by the compiler.
>> I'd
>> like to see the syntax tree exposed as well, so it should be possible
>> to build Java preprocessors and program syntax manipulation tools
>> without the need for an external tool like JavaCC, Antlr etc that use
>> their own (often incomplete) Java grammar. This would come in handy
>> for
>> generating syntax beautifiers and other nifty tools, not necessarily
>> in
>> the context of Cocoon. I don't know if that is possible with the
>> current compiler, but is worth investigating.
>>
>> Regards,
>> Ovidiu
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU,
Emacs ...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: new JSR on Java Compiler API
Posted by Ivelin Ivanov <iv...@apache.org>.
I am interested to participate in the discovery stage.
If I can bring enough value I will stay longer in the group.
I assume this standard covers XSLTC as well.
Is the XSLTC team invited ?
What I would like to see in future is XSLT and Java programs being compiled
and debugged in the same environment.
Ivelin
----- Original Message -----
From: "Ovidiu Predescu" <ov...@apache.org>
To: <co...@xml.apache.org>
Sent: Thursday, October 10, 2002 7:05 PM
Subject: Re: new JSR on Java Compiler API
> On Thursday, October 10, 2002, at 03:58 PM, Stefano Mazzocchi wrote:
>
> > People,
> >
> > Neal Gafter is about to start the process for a new JSR on Java
> > Compiler API which would hopefully make it fir Tiger (aka Java 1.5).
> > He asked me if there are people interested in helping out with the
> > details of bootstrapping this from Apache and since we (and Tomcat)
> > are the one who need this the most (for XSP and sitemap compilation),
> > I thought about asking here.
> >
> > The idea is to allow us to compile stuff without having to use the
> > filesystem to retrieve both the source file and the classes on which
> > the code to be compiled depend upon.
> >
> > So, if you are a committer and want to join, just raise your hand and
> > we'll see what happens.
>
> I'd be interested in this work too.
>
> I'd actually go a bit further in what gets exposed by the compiler. I'd
> like to see the syntax tree exposed as well, so it should be possible
> to build Java preprocessors and program syntax manipulation tools
> without the need for an external tool like JavaCC, Antlr etc that use
> their own (often incomplete) Java grammar. This would come in handy for
> generating syntax beautifiers and other nifty tools, not necessarily in
> the context of Cocoon. I don't know if that is possible with the
> current compiler, but is worth investigating.
>
> Regards,
> Ovidiu
>
> --
> Ovidiu Predescu <ov...@apache.org>
> http://webweavertech.com/ovidiu/weblog/ (Weblog)
> http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU,
> Emacs ...)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: new JSR on Java Compiler API
Posted by Ovidiu Predescu <ov...@apache.org>.
On Thursday, October 10, 2002, at 03:58 PM, Stefano Mazzocchi wrote:
> People,
>
> Neal Gafter is about to start the process for a new JSR on Java
> Compiler API which would hopefully make it fir Tiger (aka Java 1.5).
> He asked me if there are people interested in helping out with the
> details of bootstrapping this from Apache and since we (and Tomcat)
> are the one who need this the most (for XSP and sitemap compilation),
> I thought about asking here.
>
> The idea is to allow us to compile stuff without having to use the
> filesystem to retrieve both the source file and the classes on which
> the code to be compiled depend upon.
>
> So, if you are a committer and want to join, just raise your hand and
> we'll see what happens.
I'd be interested in this work too.
I'd actually go a bit further in what gets exposed by the compiler. I'd
like to see the syntax tree exposed as well, so it should be possible
to build Java preprocessors and program syntax manipulation tools
without the need for an external tool like JavaCC, Antlr etc that use
their own (often incomplete) Java grammar. This would come in handy for
generating syntax beautifiers and other nifty tools, not necessarily in
the context of Cocoon. I don't know if that is possible with the
current compiler, but is worth investigating.
Regards,
Ovidiu
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/ (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU,
Emacs ...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org