You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Thorsten Scherler <th...@apache.org> on 2007/01/24 01:34:08 UTC
PoC StAX implementation of dispatcher
Hi all,
I just added a StAX implementation of the dispatcher to the whiteboard.
It is very basic and should be seen as proof of concept.
To make the version compile you need to download
the JSR 173 API from
http://www.ibiblio.org/maven2/stax/stax-api/1.0/stax-api-1.0.jar
and copy it to lib/api/. We cannot redistribute the API (it was once a
discussion on cocoon-dev when the jcr got introduced). The
specifications can be found http://www.jcp.org/en/jsr/detail?id=173
After building
./build.sh
try
./dispatch
Right now we are using a master structurer and ignore any parameter
coming in.
It should be easy to make the structurer configurable, but like said
above: it is a PoF. Further I have turned caching off while developing.
To get kick started with StAX have a look at
http://today.java.net/pub/a/today/2006/07/20/introduction-to-stax.html
I did not really cleaned up the sysout but I reckon this way it will be
easier to follow the code.
TIA for any feedback
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: PoC StAX implementation of dispatcher
Posted by David Crossley <cr...@apache.org>.
We need to know how this action fits with ASF guidelines.
http://www.apache.org/legal/#dev-links
See the "Third-Party Licensing" section.
-David
Re: PoC StAX implementation of dispatcher
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2007-01-25 at 09:58 +1100, David Crossley wrote:
> Gav.... wrote:
> > > From: Thorsten Scherler
> > > David Crossley wrote:
> > > > Thorsten Scherler wrote:
> > > > >
> > > > > To make the version compile you need to download
> > > > > the JSR 173 API from
> > > > > http://www.ibiblio.org/maven2/stax/stax-api/1.0/stax-api-1.0.jar
> > > > > and copy it to lib/api/. We cannot redistribute the API (it was once a
> > > > > discussion on cocoon-dev when the jcr got introduced).
> > > >
> > > > Would you please explain that further.
> > >
> > > I cannot post any citation from the mail I referred since I just saw
> > > that it was a private list where I read it.
> > >
> > > Bottom line of the mail was that the JSR-170 terms of license allowed by
> > > Sun's lawyers for the JCR specification (which includes the JCR
> > > interface jar) are not compatible with ASF.
> >
> > You sure about that ? I have not looked deeply into it so I apologise, but
> > With me being on a number of Apache Mailing Lists, JSR-170 rang a bell
> > When I saw it in your mail.
>
> Wait, you are both confusing the issue. Thorsten started talking
> about JSR-173 then made a mistake and referred to JSR-170.
>
> Thorsten, please clearly explain.
I used JSR-170 as example. JCR specifications in general includes the
JCR interface jar and the license AFAIK is not compatible with the ASF.
salu2
>
> > Please take a look at :-
> >
> > http://jackrabbit.apache.org/ (Jackrabbit)
> > http://jcp.org/en/jsr/detail?id=170 (ASF is member of expert group)
> > http://www.openwfe.org/openwfe-jcr-beancoder.html (Used with Maven)
> >
> > > Futher it was pointed out that the JCR API (as interface), will either
> > > already be present in the J2SE engine (with or without an implementation
> > > from java 6 up) or must be downloaded and installed by the user (either
> > > directly in $JAVA_HOME/lib or into the location I pointed out before
> > > (whiteboard/dispatcher/lib/api)).
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: PoC StAX implementation of dispatcher
Posted by David Crossley <cr...@apache.org>.
Gav.... wrote:
> > From: Thorsten Scherler
> > David Crossley wrote:
> > > Thorsten Scherler wrote:
> > > >
> > > > To make the version compile you need to download
> > > > the JSR 173 API from
> > > > http://www.ibiblio.org/maven2/stax/stax-api/1.0/stax-api-1.0.jar
> > > > and copy it to lib/api/. We cannot redistribute the API (it was once a
> > > > discussion on cocoon-dev when the jcr got introduced).
> > >
> > > Would you please explain that further.
> >
> > I cannot post any citation from the mail I referred since I just saw
> > that it was a private list where I read it.
> >
> > Bottom line of the mail was that the JSR-170 terms of license allowed by
> > Sun's lawyers for the JCR specification (which includes the JCR
> > interface jar) are not compatible with ASF.
>
> You sure about that ? I have not looked deeply into it so I apologise, but
> With me being on a number of Apache Mailing Lists, JSR-170 rang a bell
> When I saw it in your mail.
Wait, you are both confusing the issue. Thorsten started talking
about JSR-173 then made a mistake and referred to JSR-170.
Thorsten, please clearly explain.
> Please take a look at :-
>
> http://jackrabbit.apache.org/ (Jackrabbit)
> http://jcp.org/en/jsr/detail?id=170 (ASF is member of expert group)
> http://www.openwfe.org/openwfe-jcr-beancoder.html (Used with Maven)
>
> > Futher it was pointed out that the JCR API (as interface), will either
> > already be present in the J2SE engine (with or without an implementation
> > from java 6 up) or must be downloaded and installed by the user (either
> > directly in $JAVA_HOME/lib or into the location I pointed out before
> > (whiteboard/dispatcher/lib/api)).
Re: Ivy or Maven2 (was Re: PoC StAX implementation of dispatcher)
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2007-01-25 at 13:19 +0100, C.Grobmeier wrote:
> Hi,
>
> >Is IVY+ANT better than Maven? My desk research says yes, but I have
> >never done anything in Maven, so I can't support this from experience.
> >All I know is I am sticking with IVY+ANT in my own work because I'm
> >happy with it.
Thanks Ross for sharing your research.
>
> i have expierences in maven and in ant.
I more with ant then maven2. I worked as well a bit with maven1.
> I didn't try ivy at the moment.
me neither.
> But i figured out, that it's hard to build with maven when i have special requirements.
One think I really hate on maven is the properties system. I love the
local.build.properties override style in ant and with maven that means
always headaches. I agree with you Chris.
> It needs lots time to configure everything you want
totally agreed.
> and in my opinion maven has two benefits: dependency management,the documentation stuff and the easy integration of metric reports.
>
> Dependency management can be done by ivy. It sounded like ivy is quite cool and easy for this. I am really eager to see ivy in action.
>
me too.
> Documentation in forrest will be done in forrest. I think there is no discussion.
eat your own dog food.
>
> Metric reports: it's possible to do this in ant too. Maybe it's more work here, but i don't think it's too hard.
yes
>
> Forrest is more complex to build than a standard day-life project. If i could decide i would go the ant/ivy way too and maybe borrow some ideas of maven where possible.
I need to look into ivy, sounds it does one think and this very well. I
like that. Maven is more the complete package that you hardly ever need
together.
>
> Just my 2 pence :-)
Thanks for the feedback.
salu2
> cheers,
> Chris
>
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Ivy or Maven2 (was Re: PoC StAX implementation of dispatcher)
Posted by Ross Gardler <rg...@apache.org>.
C.Grobmeier wrote:
> Hi,
>
>> Is IVY+ANT better than Maven? My desk research says yes, but I have
>> never done anything in Maven, so I can't support this from experience.
>> All I know is I am sticking with IVY+ANT in my own work because I'm
>> happy with it.
>
> i have expierences in maven and in ant. I didn't try ivy at the moment. But i figured out, that it's hard to build with maven when i have special requirements. It needs lots time to configure everything you want and in my opinion maven has two benefits: dependency management,the documentation stuff and the easy integration of metric reports.
>
> Dependency management can be done by ivy. It sounded like ivy is quite cool and easy for this. I am really eager to see ivy in action.
>
> Documentation in forrest will be done in forrest. I think there is no discussion.
>
> Metric reports: it's possible to do this in ant too. Maybe it's more work here, but i don't think it's too hard.
Most of the decent metrics applications have ANT plugins so no problem
there. Furthermore, Forrest is about content integration so getting the
outputs of those plugins in our site should not be hard, but more work
than with Maven that does it out of the box.
> Forrest is more complex to build than a standard day-life project. If i could decide i would go the ant/ivy way too and maybe borrow some ideas of maven where possible.
>
> Just my 2 pence :-)
Thanks.
Ross
Re: Ivy or Maven2 (was Re: PoC StAX implementation of dispatcher)
Posted by "C.Grobmeier" <gr...@possessed.de>.
Hi,
>Is IVY+ANT better than Maven? My desk research says yes, but I have
>never done anything in Maven, so I can't support this from experience.
>All I know is I am sticking with IVY+ANT in my own work because I'm
>happy with it.
i have expierences in maven and in ant. I didn't try ivy at the moment. But i figured out, that it's hard to build with maven when i have special requirements. It needs lots time to configure everything you want and in my opinion maven has two benefits: dependency management,the documentation stuff and the easy integration of metric reports.
Dependency management can be done by ivy. It sounded like ivy is quite cool and easy for this. I am really eager to see ivy in action.
Documentation in forrest will be done in forrest. I think there is no discussion.
Metric reports: it's possible to do this in ant too. Maybe it's more work here, but i don't think it's too hard.
Forrest is more complex to build than a standard day-life project. If i could decide i would go the ant/ivy way too and maybe borrow some ideas of maven where possible.
Just my 2 pence :-)
cheers,
Chris
Ivy or Maven2 (was Re: PoC StAX implementation of dispatcher)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Wed, 2007-01-24 at 13:53 +0000, Ross Gardler wrote:
...
>
> I have not looked in Ivy but saw that you used it. I was thinking to
> switch the stax dispatcher to maven2.
>
> What are the differences? Why you prefer Ivy to maven?
>
> I ask out of curiosity.
The main difference is that IVY is nothing more than a dependency
management tool, whereas Maven is a complete build management tool. Ivy
does what it does very well, Maven, IMHO, tries to do too much.
IVY integrates really well with ANT and therefore allows the user to
have control over the whole build process. Of course, Maven2 advocates
would say that it too provides a high degree of control over how a
project is structured etc. But I don't have Maven skills whereas I do
have ANT skills.
Furthermore, our desk research showed that projects that were large
and/or different from a standard Maven2 project had difficulties making
things work. Look at the mess Cocoon got into with Maven2. This may be
the same lack of skills issue, or it may be fundamental problems with
Maven2, not having actually used Maven2 I can't claim to know which it is.
Finally, Ivy works, and it works well for me. I now have a set of
"standard" ant script that I use for every IVY+ANT project. I intend to
give these to the IVY project, but am still waiting for the CCLA to be
signed etc. These scripts allow the quick, and easy creation of a
"standard" project, but being ANT scripts there is loads of opportunity
for customisation by ANT skilled people.
There is no need to install IVY to use it with these scripts, they do
that for you (assuming you have ANT installed).
Is IVY+ANT better than Maven? My desk research says yes, but I have
never done anything in Maven, so I can't support this from experience.
All I know is I am sticking with IVY+ANT in my own work because I'm
happy with it.
What we do here in Forrest should be discussed.
Ross
Re: PoC StAX implementation of dispatcher
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> Ross Gardler wrote:
> > Gav.... wrote:
> > >> From: Thorsten Scherler
> > >>
> > >> The following has to be done once:
> > >> cd whiteboard/dispatcher/lib
> > >> mkdir api
> > >> cd api
> > >> wget http://www.ibiblio.org/maven2/stax/stax-api/1.0/stax-api-1.0.jar .
> > >
> > > I think I would prefer %FORREST_HOME%/lib/optional , keeps all these
> > > Required but not endorsed jars in the same place, and no need to
> > > Re-write anything when things move from one place to another, i.e.
> > > From whiteboard to plugin.
> >
> > There is no guarantee that anything in whiteboard will every come out,
> > so whiteboard is the right place.
> >
> > Having said that, my CCLA should be signed soon and one of the things I
> > intend to do is move Forrest to Ivy (pending community approval of
> > course). This will remove the need to worry about where libs are located
> > as we will not be distributing them.
>
> I have not looked in Ivy but saw that you used it. I was thinking to
> switch the stax dispatcher to maven2.
>
> What are the differences? Why you prefer Ivy to maven?
>
> I ask out of curiosity.
It has already been mentioned that we need to discuss this.
It came up when Ross added the forrest2 to whiteboard.
It would also have been on all our minds anyway.
Please discuss it as a separate topic.
-David
Re: PoC StAX implementation of dispatcher
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2007-01-24 at 13:53 +0000, Ross Gardler wrote:
> Gav.... wrote:
> >
> >> -----Original Message-----
> >> From: Thorsten Scherler [mailto:thorsten.scherler.ext@juntadeandalucia.es]
>
> ...
>
> >> The following has to be done once:
> >> cd whiteboard/dispatcher/lib
> >> mkdir api
> >> cd api
> >> wget http://www.ibiblio.org/maven2/stax/stax-api/1.0/stax-api-1.0.jar .
> >
> > I think I would prefer %FORREST_HOME%/lib/optional , keeps all these
> > Required but not endorsed jars in the same place, and no need to
> > Re-write anything when things move from one place to another, i.e.
> > From whiteboard to plugin.
>
> There is no guarantee that anything in whiteboard will every come out,
> so whiteboard is the right place.
>
> Having said that, my CCLA should be signed soon and one of the things I
> intend to do is move Forrest to Ivy (pending community approval of
> course). This will remove the need to worry about where libs are located
> as we will not be distributing them.
I have not looked in Ivy but saw that you used it. I was thinking to
switch the stax dispatcher to maven2.
What are the differences? Why you prefer Ivy to maven?
I ask out of curiosity.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: PoC StAX implementation of dispatcher
Posted by Ross Gardler <rg...@apache.org>.
Gav.... wrote:
>
>> -----Original Message-----
>> From: Thorsten Scherler [mailto:thorsten.scherler.ext@juntadeandalucia.es]
...
>> The following has to be done once:
>> cd whiteboard/dispatcher/lib
>> mkdir api
>> cd api
>> wget http://www.ibiblio.org/maven2/stax/stax-api/1.0/stax-api-1.0.jar .
>
> I think I would prefer %FORREST_HOME%/lib/optional , keeps all these
> Required but not endorsed jars in the same place, and no need to
> Re-write anything when things move from one place to another, i.e.
> From whiteboard to plugin.
There is no guarantee that anything in whiteboard will every come out,
so whiteboard is the right place.
Having said that, my CCLA should be signed soon and one of the things I
intend to do is move Forrest to Ivy (pending community approval of
course). This will remove the need to worry about where libs are located
as we will not be distributing them.
Ross
RE: PoC StAX implementation of dispatcher
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2007-01-24 at 22:32 +0900, Gav.... wrote:
>
> > -----Original Message-----
> > From: Thorsten Scherler [mailto:thorsten.scherler.ext@juntadeandalucia.es]
> > Sent: Wednesday, 24 January 2007 8:54 PM
> > To: dev@forrest.apache.org
> > Subject: Re: PoC StAX implementation of dispatcher
> >
> > On Wed, 2007-01-24 at 13:41 +1100, David Crossley wrote:
> > > Thorsten Scherler wrote:
> > > >
> > > > To make the version compile you need to download
> > > > the JSR 173 API from
> > > > http://www.ibiblio.org/maven2/stax/stax-api/1.0/stax-api-1.0.jar
> > > > and copy it to lib/api/. We cannot redistribute the API (it was once a
> > > > discussion on cocoon-dev when the jcr got introduced).
> > >
> > > Would you please explain that further.
> >
> > I cannot post any citation from the mail I referred since I just saw
> > that it was a private list where I read it.
> >
> > Bottom line of the mail was that the JSR-170 terms of license allowed by
> > Sun's lawyers for the JCR specification (which includes the JCR
> > interface jar) are not compatible with ASF.
>
> You sure about that ? I have not looked deeply into it so I apologise, but
> With me being on a number of Apache Mailing Lists, JSR-170 rang a bell
> When I saw it in your mail.
>
> Please take a look at :-
>
> http://jackrabbit.apache.org/ (Jackrabbit)
> http://jcp.org/en/jsr/detail?id=170 (ASF is member of expert group)
> http://www.openwfe.org/openwfe-jcr-beancoder.html (Used with Maven)
>
Actually the background mail came from one PMC member of Jackrabbit.
I actually do not have much time to research whether we can directly
include the lib in the dispatcher, so I think downloading and install is
the safest way.
> >
> > Futher it was pointed out that the JCR API (as interface), will either
> > already be present in the J2SE engine (with or without an implementation
> > from java 6 up) or must be downloaded and installed by the user (either
> > directly in $JAVA_HOME/lib or into the location I pointed out before
> > (whiteboard/dispatcher/lib/api)).
> >
> > The following has to be done once:
> > cd whiteboard/dispatcher/lib
> > mkdir api
> > cd api
> > wget http://www.ibiblio.org/maven2/stax/stax-api/1.0/stax-api-1.0.jar .
>
> I think I would prefer %FORREST_HOME%/lib/optional , keeps all these
> Required but not endorsed jars in the same place, and no need to
> Re-write anything when things move from one place to another, i.e.
> From whiteboard to plugin.
>
Hmm, the dispatcher is standalone. Like said if you want StAX support on
your OS you will have to place it into the JAVA lib.
salu2
> >
> > After this you can
> > ./build.sh
> > ./dispatch.
>
> I could probably do a build.bat version for us windoze users, will dispatch
> Require the same treatment ?
>
> Gav...
>
> >
> > salu2
> >
> > P.S.: Does this answer your question?
> > >
> > > -David
>
RE: PoC StAX implementation of dispatcher
Posted by "Gav...." <br...@brightontown.com.au>.
> -----Original Message-----
> From: Thorsten Scherler [mailto:thorsten.scherler.ext@juntadeandalucia.es]
> Sent: Wednesday, 24 January 2007 8:54 PM
> To: dev@forrest.apache.org
> Subject: Re: PoC StAX implementation of dispatcher
>
> On Wed, 2007-01-24 at 13:41 +1100, David Crossley wrote:
> > Thorsten Scherler wrote:
> > >
> > > To make the version compile you need to download
> > > the JSR 173 API from
> > > http://www.ibiblio.org/maven2/stax/stax-api/1.0/stax-api-1.0.jar
> > > and copy it to lib/api/. We cannot redistribute the API (it was once a
> > > discussion on cocoon-dev when the jcr got introduced).
> >
> > Would you please explain that further.
>
> I cannot post any citation from the mail I referred since I just saw
> that it was a private list where I read it.
>
> Bottom line of the mail was that the JSR-170 terms of license allowed by
> Sun's lawyers for the JCR specification (which includes the JCR
> interface jar) are not compatible with ASF.
You sure about that ? I have not looked deeply into it so I apologise, but
With me being on a number of Apache Mailing Lists, JSR-170 rang a bell
When I saw it in your mail.
Please take a look at :-
http://jackrabbit.apache.org/ (Jackrabbit)
http://jcp.org/en/jsr/detail?id=170 (ASF is member of expert group)
http://www.openwfe.org/openwfe-jcr-beancoder.html (Used with Maven)
>
> Futher it was pointed out that the JCR API (as interface), will either
> already be present in the J2SE engine (with or without an implementation
> from java 6 up) or must be downloaded and installed by the user (either
> directly in $JAVA_HOME/lib or into the location I pointed out before
> (whiteboard/dispatcher/lib/api)).
>
> The following has to be done once:
> cd whiteboard/dispatcher/lib
> mkdir api
> cd api
> wget http://www.ibiblio.org/maven2/stax/stax-api/1.0/stax-api-1.0.jar .
I think I would prefer %FORREST_HOME%/lib/optional , keeps all these
Required but not endorsed jars in the same place, and no need to
Re-write anything when things move from one place to another, i.e.
>From whiteboard to plugin.
>
> After this you can
> ./build.sh
> ./dispatch.
I could probably do a build.bat version for us windoze users, will dispatch
Require the same treatment ?
Gav...
>
> salu2
>
> P.S.: Does this answer your question?
> >
> > -David
Re: PoC StAX implementation of dispatcher
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2007-01-24 at 13:41 +1100, David Crossley wrote:
> Thorsten Scherler wrote:
> >
> > To make the version compile you need to download
> > the JSR 173 API from
> > http://www.ibiblio.org/maven2/stax/stax-api/1.0/stax-api-1.0.jar
> > and copy it to lib/api/. We cannot redistribute the API (it was once a
> > discussion on cocoon-dev when the jcr got introduced).
>
> Would you please explain that further.
I cannot post any citation from the mail I referred since I just saw
that it was a private list where I read it.
Bottom line of the mail was that the JSR-170 terms of license allowed by
Sun's lawyers for the JCR specification (which includes the JCR
interface jar) are not compatible with ASF.
Futher it was pointed out that the JCR API (as interface), will either
already be present in the J2SE engine (with or without an implementation
from java 6 up) or must be downloaded and installed by the user (either
directly in $JAVA_HOME/lib or into the location I pointed out before
(whiteboard/dispatcher/lib/api)).
The following has to be done once:
cd whiteboard/dispatcher/lib
mkdir api
cd api
wget http://www.ibiblio.org/maven2/stax/stax-api/1.0/stax-api-1.0.jar .
After this you can
./build.sh
./dispatch.
salu2
P.S.: Does this answer your question?
>
> -David
Re: PoC StAX implementation of dispatcher
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
>
> To make the version compile you need to download
> the JSR 173 API from
> http://www.ibiblio.org/maven2/stax/stax-api/1.0/stax-api-1.0.jar
> and copy it to lib/api/. We cannot redistribute the API (it was once a
> discussion on cocoon-dev when the jcr got introduced).
Would you please explain that further.
-David