You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2001/10/30 11:41:52 UTC
Donating Cocoon Components to Avalon
Hi Avalon Team, hi Cocoon Team,
we had some weeks ago discussions about moving common
components from Cocoon to Avalon. Both communitites
agreed to this step.
So, I think we should now start to identify the components
we could give to Avalon. As a first start I would
propose the following:
- XML Parser
- XSLT Processor
- XPath
- Resolver (Entity Resolver)
- XMLSerializer/XMLDeserializer (The XML to byte stream
compiler/interpreter)
- SourceHandler/SourceFactory/Source
One of the most important components I think is the SourceHandler which
is a replacement of the java.net.URL classes. It allows to define own
protocols
(like cocoon:, or cvs: etc) in a server environment. Many projects (Cocoon,
Batik, perhaps soon FOP etc) have their own implementations which makes
integrating
same difficult and sometimes impossible.
In addition Cocoon uses some interfaces (in the org.apache.cocoon.xml
package),
like XMLConsumer, XMLizable etc which are right placed in Avalon, too.
If we have identified the components to move/donate, we should start discuss
if they should be moved unchanged or if they could be redesigned. But
this should be the second step.
So, are there more components we could donate?
Avalon Team, are you interested in this?
What's the correct procedure for this?
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Donating Cocoon Components to Avalon
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler a écrit :
>
> Hi Avalon Team, hi Cocoon Team,
>
> we had some weeks ago discussions about moving common
> components from Cocoon to Avalon. Both communitites
> agreed to this step.
>
> So, I think we should now start to identify the components
> we could give to Avalon. As a first start I would
> propose the following:
>
> - XML Parser
> - XSLT Processor
> - XPath
> - Resolver (Entity Resolver)
> - XMLSerializer/XMLDeserializer (The XML to byte stream
> compiler/interpreter)
> - SourceHandler/SourceFactory/Source
+1 for all of them.
> One of the most important components I think is the SourceHandler which
> is a replacement of the java.net.URL classes. It allows to define own
> protocols
> (like cocoon:, or cvs: etc) in a server environment. Many projects (Cocoon,
> Batik, perhaps soon FOP etc) have their own implementations which makes
> integrating
> same difficult and sometimes impossible.
Agree. This is a "must move" to Avalon to increase its use. This
potentially allows smart things like passing a Cocoon pipeline or an
XMLdb query as the input of Batik.
> In addition Cocoon uses some interfaces (in the org.apache.cocoon.xml
> package),
> like XMLConsumer, XMLizable etc which are right placed in Avalon, too.
Some of these interfaces are highly used by the above components. So +1
for them also.
> If we have identified the components to move/donate, we should start discuss
> if they should be moved unchanged or if they could be redesigned. But
> this should be the second step.
>
> So, are there more components we could donate?
> Avalon Team, are you interested in this?
Cache management is also a good canditate. There's also some cache in
Excalibur's scratchpad, but I don't know its status.
> What's the correct procedure for this?
Now that you're an Avalon committer, this shouldn't be difficult ;)
Congrats !
> Carsten
>
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Donating Cocoon Components to Avalon
Posted by Mircea Toma <mi...@home.com>.
----- Original Message -----
From: "Carsten Ziegeler" <cz...@s-und-n.de>
To: "Cocoon-Dev@Xml. Apache. Org" <co...@xml.apache.org>; "Avalon
Development" <av...@jakarta.apache.org>
Sent: Tuesday, October 30, 2001 3:41 AM
Subject: Donating Cocoon Components to Avalon
> Hi Avalon Team, hi Cocoon Team,
>
> we had some weeks ago discussions about moving common
> components from Cocoon to Avalon. Both communitites
> agreed to this step.
Nice!
Then we should start thinking how to split Excalibur in two sub-projects...
I think right now the multitude of packages scares off the newcommers!
>
> So, I think we should now start to identify the components
> we could give to Avalon. As a first start I would
> propose the following:
>
> - XML Parser
> - XSLT Processor
+0
> - XPath
+1
> - Resolver (Entity Resolver)
+1
> - XMLSerializer/XMLDeserializer (The XML to byte stream
> compiler/interpreter)
+0
> - SourceHandler/SourceFactory/Source
+1000
>
> One of the most important components I think is the SourceHandler which
> is a replacement of the java.net.URL classes. It allows to define own
> protocols
> (like cocoon:, or cvs: etc) in a server environment. Many projects
(Cocoon,
> Batik, perhaps soon FOP etc) have their own implementations which makes
> integrating
> same difficult and sometimes impossible.
I agree! ... especially in the light of latest problems with Phoenix
installation process!
>
> In addition Cocoon uses some interfaces (in the org.apache.cocoon.xml
> package),
> like XMLConsumer, XMLizable etc which are right placed in Avalon, too.
>
> If we have identified the components to move/donate, we should start
discuss
> if they should be moved unchanged or if they could be redesigned. But
> this should be the second step.
>
> So, are there more components we could donate?
If the components we will select tend to too many maybe we should create a
XML only subproject?!
> Avalon Team, are you interested in this?
Definetelly!
>
> What's the correct procedure for this?
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
>
>
>
> ---------------------------------------------------------------------
> 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: Donating Cocoon Components to Avalon
Posted by Neeme Praks <ne...@one.ee>.
I already went ahead and added org.apache.cocoon.components.xpath package to
excalibur (needed it to port back by i18n classes), as agreed before.
But the other stuff would be also worth checking out :-)
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> Sent: Tuesday, October 30, 2001 2:42 AM
> To: Cocoon-Dev@Xml. Apache. Org; Avalon Development
> Subject: Donating Cocoon Components to Avalon
>
>
> Hi Avalon Team, hi Cocoon Team,
>
> we had some weeks ago discussions about moving common
> components from Cocoon to Avalon. Both communitites
> agreed to this step.
>
> So, I think we should now start to identify the components
> we could give to Avalon. As a first start I would
> propose the following:
>
> - XML Parser
> - XSLT Processor
> - XPath
> - Resolver (Entity Resolver)
> - XMLSerializer/XMLDeserializer (The XML to byte stream
> compiler/interpreter)
> - SourceHandler/SourceFactory/Source
>
> One of the most important components I think is the SourceHandler which
> is a replacement of the java.net.URL classes. It allows to define own
> protocols
> (like cocoon:, or cvs: etc) in a server environment. Many
> projects (Cocoon,
> Batik, perhaps soon FOP etc) have their own implementations which makes
> integrating
> same difficult and sometimes impossible.
>
> In addition Cocoon uses some interfaces (in the org.apache.cocoon.xml
> package),
> like XMLConsumer, XMLizable etc which are right placed in Avalon, too.
>
> If we have identified the components to move/donate, we should
> start discuss
> if they should be moved unchanged or if they could be redesigned. But
> this should be the second step.
>
> So, are there more components we could donate?
> Avalon Team, are you interested in this?
>
> What's the correct procedure for this?
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
>
>
>
> ---------------------------------------------------------------------
> 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: [vote] New Committer was Re: Donating Cocoon Components to Avalon
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>I propose "Carsten Ziegeler" <cz...@s-und-n.de> as a committer to Avalon
>project. All in favour say "aye"
>
>aye ... err I mean +1 ')
>
+1
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] New Committer was Re: Donating Cocoon Components to Avalon
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> On Wed, 31 Oct 2001 03:16, Carsten Ziegeler wrote:
> > Hm, OK, is there someone with time for it in the Avalon Team?
> > I would propose myself (being a little bit egoistic),
> > but unfortunately I'm not an Avalon comitter.
>
> well - lets fix that!
>
> I propose "Carsten Ziegeler" <cz...@s-und-n.de> as a committer to Avalon
> project. All in favour say "aye"
>
> aye ... err I mean +1 ')
+1
>From me!
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] New Committer was Re: Donating Cocoon Components to Avalon
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> On Wed, 31 Oct 2001 03:16, Carsten Ziegeler wrote:
> > Hm, OK, is there someone with time for it in the Avalon Team?
> > I would propose myself (being a little bit egoistic),
> > but unfortunately I'm not an Avalon comitter.
>
> well - lets fix that!
>
> I propose "Carsten Ziegeler" <cz...@s-und-n.de> as a committer to Avalon
> project. All in favour say "aye"
>
> aye ... err I mean +1 ')
aye :) +1
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] New Committer was Re: Donating Cocoon Components to Avalon
Posted by Jeff Turner <je...@socialchange.net.au>.
On Wed, Oct 31, 2001 at 12:16:54PM +0100, Carsten Ziegeler wrote:
> Jeff Turner wrote:
[..]
> > Idly wondering if Carsten prefers 'sundn.de' or 's-und-n.de'.. I've seen
> > a lot more of the former.
> >
> Our company just recently decided to change the domain.....and
> the new one is "s-und-n.de". "sundn.de" will be shutdown sometime
> next year.
Oh I get it. To discourage idiots like me from mentally pronouncing it
'sun dee enn' ;)
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [vote] New Committer was Re: Donating Cocoon Components to Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Jeff Turner wrote:
>
>
> On Wed, Oct 31, 2001 at 07:55:25AM +1100, Peter Donald wrote:
> > On Wed, 31 Oct 2001 03:16, Carsten Ziegeler wrote:
> > > Hm, OK, is there someone with time for it in the Avalon Team?
> > > I would propose myself (being a little bit egoistic),
> > > but unfortunately I'm not an Avalon comitter.
> >
> > well - lets fix that!
> >
> > I propose "Carsten Ziegeler" <cz...@s-und-n.de> as a
> committer to Avalon
> > project.
>
> +1 of course.
>
> Idly wondering if Carsten prefers 'sundn.de' or 's-und-n.de'.. I've seen
> a lot more of the former.
>
Our company just recently decided to change the domain.....and
the new one is "s-und-n.de". "sundn.de" will be shutdown sometime
next year.
To be honest, I like cziegeler@apache.org most.
Carsten
> > All in favour say "aye"
>
> I think you're on to something there.
>
> +1 = "Aye"
> +0 = "Hmm"
> -0 = "Hmmph"
> -1 = "Narrr"
>
> :)
>
> --Jeff
>
> > aye ... err I mean +1 ')
> >
> > --
> > Cheers,
> >
> > Pete
> >
> > ------------------------------------------------------
> > "If people are good only because they fear punishment,
> > and hope for reward, then we are a sorry lot indeed."
> > -Albert Einstein
> > ------------------------------------------------------
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] New Committer was Re: Donating Cocoon Components to Avalon
Posted by Jeff Turner <je...@socialchange.net.au>.
On Wed, Oct 31, 2001 at 07:55:25AM +1100, Peter Donald wrote:
> On Wed, 31 Oct 2001 03:16, Carsten Ziegeler wrote:
> > Hm, OK, is there someone with time for it in the Avalon Team?
> > I would propose myself (being a little bit egoistic),
> > but unfortunately I'm not an Avalon comitter.
>
> well - lets fix that!
>
> I propose "Carsten Ziegeler" <cz...@s-und-n.de> as a committer to Avalon
> project.
+1 of course.
Idly wondering if Carsten prefers 'sundn.de' or 's-und-n.de'.. I've seen
a lot more of the former.
> All in favour say "aye"
I think you're on to something there.
+1 = "Aye"
+0 = "Hmm"
-0 = "Hmmph"
-1 = "Narrr"
:)
--Jeff
> aye ... err I mean +1 ')
>
> --
> Cheers,
>
> Pete
>
> ------------------------------------------------------
> "If people are good only because they fear punishment,
> and hope for reward, then we are a sorry lot indeed."
> -Albert Einstein
> ------------------------------------------------------
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] New Committer was Re: Donating Cocoon Components to Avalon
Posted by Mircea Toma <mi...@home.com>.
> I propose "Carsten Ziegeler" <cz...@s-und-n.de> as a committer to
Avalon
> project. All in favour say "aye"
>
> aye ... err I mean +1 ')
+1 here too!
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [vote] New Committer was Re: Donating Cocoon Components to Avalon
Posted by Neeme Praks <ne...@one.ee>.
+1 (read: aye) ;-)
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Tuesday, October 30, 2001 12:55 PM
> To: Avalon Developers List
> Subject: [vote] New Committer was Re: Donating Cocoon Components to
> Avalon
>
>
> On Wed, 31 Oct 2001 03:16, Carsten Ziegeler wrote:
> > Hm, OK, is there someone with time for it in the Avalon Team?
> > I would propose myself (being a little bit egoistic),
> > but unfortunately I'm not an Avalon comitter.
>
> well - lets fix that!
>
> I propose "Carsten Ziegeler" <cz...@s-und-n.de> as a
> committer to Avalon
> project. All in favour say "aye"
>
> aye ... err I mean +1 ')
>
> --
> Cheers,
>
> Pete
>
> ------------------------------------------------------
> "If people are good only because they fear punishment,
> and hope for reward, then we are a sorry lot indeed."
> -Albert Einstein
> ------------------------------------------------------
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] New Committer was Re: Donating Cocoon Components to Avalon
Posted by giacomo <gi...@apache.org>.
On Wed, 31 Oct 2001, Peter Donald wrote:
> On Wed, 31 Oct 2001 03:16, Carsten Ziegeler wrote:
> > Hm, OK, is there someone with time for it in the Avalon Team?
> > I would propose myself (being a little bit egoistic),
> > but unfortunately I'm not an Avalon comitter.
>
> well - lets fix that!
>
> I propose "Carsten Ziegeler" <cz...@s-und-n.de> as a committer to Avalon
> project. All in favour say "aye"
Sure +1. He is a big one at Cocoon.
Giacomo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[vote] New Committer was Re: Donating Cocoon Components to Avalon
Posted by Peter Donald <do...@apache.org>.
On Wed, 31 Oct 2001 03:16, Carsten Ziegeler wrote:
> Hm, OK, is there someone with time for it in the Avalon Team?
> I would propose myself (being a little bit egoistic),
> but unfortunately I'm not an Avalon comitter.
well - lets fix that!
I propose "Carsten Ziegeler" <cz...@s-und-n.de> as a committer to Avalon
project. All in favour say "aye"
aye ... err I mean +1 ')
--
Cheers,
Pete
------------------------------------------------------
"If people are good only because they fear punishment,
and hope for reward, then we are a sorry lot indeed."
-Albert Einstein
------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Donating Cocoon Components to Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> Berin Loritsch wrote:
>
> giacomo wrote:
> >
> > On Tue, 30 Oct 2001, Carsten Ziegeler wrote:
> >
> > > Hi Avalon Team, hi Cocoon Team,
> > >
> > > we had some weeks ago discussions about moving common
> > > components from Cocoon to Avalon. Both communitites
> > > agreed to this step.
> > >
> > > So, I think we should now start to identify the components
> > > we could give to Avalon. As a first start I would
> > > propose the following:
> > >
> > > - XML Parser
> > > - XSLT Processor
> > > - XPath
> > > - Resolver (Entity Resolver)
> > > - XMLSerializer/XMLDeserializer (The XML to byte stream
> > > compiler/interpreter)
> > > - SourceHandler/SourceFactory/Source
> >
> > +1 on all above
>
> Neeme started on the XPath Component so he can use it for i18n
>
> > > One of the most important components I think is the
> SourceHandler which
> > > is a replacement of the java.net.URL classes. It allows to define own
> > > protocols
> > > (like cocoon:, or cvs: etc) in a server environment. Many
> projects (Cocoon,
> > > Batik, perhaps soon FOP etc) have their own implementations
> which makes
> > > integrating
> > > same difficult and sometimes impossible.
> >
> > This means we have to convice them to change from URL to SourceHandler
> > to have a smooth integration into Cocoon, right?
>
> Batik already has it's own mechanism which is also very nice. It might
> be worth it to take a look at it. FOP doesn't have anything like that,
> I placed a feature enhancement request into BugZilla for them, but no
> activity has happened on it yet.
>
> > > In addition Cocoon uses some interfaces (in the org.apache.cocoon.xml
> > > package),
> > > like XMLConsumer, XMLizable etc which are right placed in Avalon, too.
> >
> > +1, there package/classes/interfaces will interfer with the one above
> > because an XSLTProcessor is an XMLConsumer. Should the Abstract
> > implementations move into Excalibur as well?
>
> As long as they are not Cocoon specific.
>
> > > If we have identified the components to move/donate, we
> should start discuss
> > > if they should be moved unchanged or if they could be redesigned. But
> > > this should be the second step.
> > >
> > > So, are there more components we could donate?
> > > Avalon Team, are you interested in this?
>
> We are interested in it. We just have limited time.
>
> > > What's the correct procedure for this?
>
> Find someone with the time....
>
Hm, OK, is there someone with time for it in the Avalon Team?
I would propose myself (being a little bit egoistic),
but unfortunately I'm not an Avalon comitter.
Carsten
>
> --
>
> "Those who would trade liberty for
> temporary security deserve neither"
> - Benjamin Franklin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Donating Cocoon Components to Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> Berin Loritsch wrote:
>
> giacomo wrote:
> >
> > On Tue, 30 Oct 2001, Carsten Ziegeler wrote:
> >
> > > Hi Avalon Team, hi Cocoon Team,
> > >
> > > we had some weeks ago discussions about moving common
> > > components from Cocoon to Avalon. Both communitites
> > > agreed to this step.
> > >
> > > So, I think we should now start to identify the components
> > > we could give to Avalon. As a first start I would
> > > propose the following:
> > >
> > > - XML Parser
> > > - XSLT Processor
> > > - XPath
> > > - Resolver (Entity Resolver)
> > > - XMLSerializer/XMLDeserializer (The XML to byte stream
> > > compiler/interpreter)
> > > - SourceHandler/SourceFactory/Source
> >
> > +1 on all above
>
> Neeme started on the XPath Component so he can use it for i18n
>
> > > One of the most important components I think is the
> SourceHandler which
> > > is a replacement of the java.net.URL classes. It allows to define own
> > > protocols
> > > (like cocoon:, or cvs: etc) in a server environment. Many
> projects (Cocoon,
> > > Batik, perhaps soon FOP etc) have their own implementations
> which makes
> > > integrating
> > > same difficult and sometimes impossible.
> >
> > This means we have to convice them to change from URL to SourceHandler
> > to have a smooth integration into Cocoon, right?
>
> Batik already has it's own mechanism which is also very nice. It might
> be worth it to take a look at it. FOP doesn't have anything like that,
> I placed a feature enhancement request into BugZilla for them, but no
> activity has happened on it yet.
>
> > > In addition Cocoon uses some interfaces (in the org.apache.cocoon.xml
> > > package),
> > > like XMLConsumer, XMLizable etc which are right placed in Avalon, too.
> >
> > +1, there package/classes/interfaces will interfer with the one above
> > because an XSLTProcessor is an XMLConsumer. Should the Abstract
> > implementations move into Excalibur as well?
>
> As long as they are not Cocoon specific.
>
> > > If we have identified the components to move/donate, we
> should start discuss
> > > if they should be moved unchanged or if they could be redesigned. But
> > > this should be the second step.
> > >
> > > So, are there more components we could donate?
> > > Avalon Team, are you interested in this?
>
> We are interested in it. We just have limited time.
>
> > > What's the correct procedure for this?
>
> Find someone with the time....
>
Hm, OK, is there someone with time for it in the Avalon Team?
I would propose myself (being a little bit egoistic),
but unfortunately I'm not an Avalon comitter.
Carsten
>
> --
>
> "Those who would trade liberty for
> temporary security deserve neither"
> - Benjamin Franklin
>
> ---------------------------------------------------------------------
> 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: Donating Cocoon Components to Avalon
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
>
> On Tue, 30 Oct 2001, Carsten Ziegeler wrote:
>
> > Hi Avalon Team, hi Cocoon Team,
> >
> > we had some weeks ago discussions about moving common
> > components from Cocoon to Avalon. Both communitites
> > agreed to this step.
> >
> > So, I think we should now start to identify the components
> > we could give to Avalon. As a first start I would
> > propose the following:
> >
> > - XML Parser
> > - XSLT Processor
> > - XPath
> > - Resolver (Entity Resolver)
> > - XMLSerializer/XMLDeserializer (The XML to byte stream
> > compiler/interpreter)
> > - SourceHandler/SourceFactory/Source
>
> +1 on all above
Neeme started on the XPath Component so he can use it for i18n
> > One of the most important components I think is the SourceHandler which
> > is a replacement of the java.net.URL classes. It allows to define own
> > protocols
> > (like cocoon:, or cvs: etc) in a server environment. Many projects (Cocoon,
> > Batik, perhaps soon FOP etc) have their own implementations which makes
> > integrating
> > same difficult and sometimes impossible.
>
> This means we have to convice them to change from URL to SourceHandler
> to have a smooth integration into Cocoon, right?
Batik already has it's own mechanism which is also very nice. It might
be worth it to take a look at it. FOP doesn't have anything like that,
I placed a feature enhancement request into BugZilla for them, but no
activity has happened on it yet.
> > In addition Cocoon uses some interfaces (in the org.apache.cocoon.xml
> > package),
> > like XMLConsumer, XMLizable etc which are right placed in Avalon, too.
>
> +1, there package/classes/interfaces will interfer with the one above
> because an XSLTProcessor is an XMLConsumer. Should the Abstract
> implementations move into Excalibur as well?
As long as they are not Cocoon specific.
> > If we have identified the components to move/donate, we should start discuss
> > if they should be moved unchanged or if they could be redesigned. But
> > this should be the second step.
> >
> > So, are there more components we could donate?
> > Avalon Team, are you interested in this?
We are interested in it. We just have limited time.
> > What's the correct procedure for this?
Find someone with the time....
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Donating Cocoon Components to Avalon
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
>
> On Tue, 30 Oct 2001, Carsten Ziegeler wrote:
>
> > Hi Avalon Team, hi Cocoon Team,
> >
> > we had some weeks ago discussions about moving common
> > components from Cocoon to Avalon. Both communitites
> > agreed to this step.
> >
> > So, I think we should now start to identify the components
> > we could give to Avalon. As a first start I would
> > propose the following:
> >
> > - XML Parser
> > - XSLT Processor
> > - XPath
> > - Resolver (Entity Resolver)
> > - XMLSerializer/XMLDeserializer (The XML to byte stream
> > compiler/interpreter)
> > - SourceHandler/SourceFactory/Source
>
> +1 on all above
Neeme started on the XPath Component so he can use it for i18n
> > One of the most important components I think is the SourceHandler which
> > is a replacement of the java.net.URL classes. It allows to define own
> > protocols
> > (like cocoon:, or cvs: etc) in a server environment. Many projects (Cocoon,
> > Batik, perhaps soon FOP etc) have their own implementations which makes
> > integrating
> > same difficult and sometimes impossible.
>
> This means we have to convice them to change from URL to SourceHandler
> to have a smooth integration into Cocoon, right?
Batik already has it's own mechanism which is also very nice. It might
be worth it to take a look at it. FOP doesn't have anything like that,
I placed a feature enhancement request into BugZilla for them, but no
activity has happened on it yet.
> > In addition Cocoon uses some interfaces (in the org.apache.cocoon.xml
> > package),
> > like XMLConsumer, XMLizable etc which are right placed in Avalon, too.
>
> +1, there package/classes/interfaces will interfer with the one above
> because an XSLTProcessor is an XMLConsumer. Should the Abstract
> implementations move into Excalibur as well?
As long as they are not Cocoon specific.
> > If we have identified the components to move/donate, we should start discuss
> > if they should be moved unchanged or if they could be redesigned. But
> > this should be the second step.
> >
> > So, are there more components we could donate?
> > Avalon Team, are you interested in this?
We are interested in it. We just have limited time.
> > What's the correct procedure for this?
Find someone with the time....
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Donating Cocoon Components to Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Giacomo Pati wrote:
>
> On Tue, 30 Oct 2001, Carsten Ziegeler wrote:
>
> > Hi Avalon Team, hi Cocoon Team,
> >
> > we had some weeks ago discussions about moving common
> > components from Cocoon to Avalon. Both communitites
> > agreed to this step.
> >
> > So, I think we should now start to identify the components
> > we could give to Avalon. As a first start I would
> > propose the following:
> >
> > - XML Parser
> > - XSLT Processor
> > - XPath
> > - Resolver (Entity Resolver)
> > - XMLSerializer/XMLDeserializer (The XML to byte stream
> > compiler/interpreter)
> > - SourceHandler/SourceFactory/Source
>
> +1 on all above
>
> > One of the most important components I think is the SourceHandler which
> > is a replacement of the java.net.URL classes. It allows to define own
> > protocols
> > (like cocoon:, or cvs: etc) in a server environment. Many
> projects (Cocoon,
> > Batik, perhaps soon FOP etc) have their own implementations which makes
> > integrating
> > same difficult and sometimes impossible.
>
> This means we have to convice them to change from URL to SourceHandler
> to have a smooth integration into Cocoon, right?
>
Yes, more or less, e.g. Batik has already a very similar concept to
our SourceHandler, so the transition for either them or us would
be very easy. The transition from the "usual" URL approach, of course,
is an unavoidable step. But as we have the experince from this step
when we changed Cocoon, this was a rather small step. So this should
apply to all other projects already using Avalon as well. The main
part will be the switch to Avalon if they haven't already done.
> > In addition Cocoon uses some interfaces (in the org.apache.cocoon.xml
> > package),
> > like XMLConsumer, XMLizable etc which are right placed in Avalon, too.
>
> +1, there package/classes/interfaces will interfer with the one above
> because an XSLTProcessor is an XMLConsumer. Should the Abstract
> implementations move into Excalibur as well?
>
Yes, adding abstract implementations is always useful. So they should move,
too.
Carsten
> > If we have identified the components to move/donate, we should
> start discuss
> > if they should be moved unchanged or if they could be redesigned. But
> > this should be the second step.
> >
> > So, are there more components we could donate?
> > Avalon Team, are you interested in this?
> >
> > What's the correct procedure for this?
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: cziegeler@sundn.de
> > ================================================================
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Donating Cocoon Components to Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Giacomo Pati wrote:
>
> On Tue, 30 Oct 2001, Carsten Ziegeler wrote:
>
> > Hi Avalon Team, hi Cocoon Team,
> >
> > we had some weeks ago discussions about moving common
> > components from Cocoon to Avalon. Both communitites
> > agreed to this step.
> >
> > So, I think we should now start to identify the components
> > we could give to Avalon. As a first start I would
> > propose the following:
> >
> > - XML Parser
> > - XSLT Processor
> > - XPath
> > - Resolver (Entity Resolver)
> > - XMLSerializer/XMLDeserializer (The XML to byte stream
> > compiler/interpreter)
> > - SourceHandler/SourceFactory/Source
>
> +1 on all above
>
> > One of the most important components I think is the SourceHandler which
> > is a replacement of the java.net.URL classes. It allows to define own
> > protocols
> > (like cocoon:, or cvs: etc) in a server environment. Many
> projects (Cocoon,
> > Batik, perhaps soon FOP etc) have their own implementations which makes
> > integrating
> > same difficult and sometimes impossible.
>
> This means we have to convice them to change from URL to SourceHandler
> to have a smooth integration into Cocoon, right?
>
Yes, more or less, e.g. Batik has already a very similar concept to
our SourceHandler, so the transition for either them or us would
be very easy. The transition from the "usual" URL approach, of course,
is an unavoidable step. But as we have the experince from this step
when we changed Cocoon, this was a rather small step. So this should
apply to all other projects already using Avalon as well. The main
part will be the switch to Avalon if they haven't already done.
> > In addition Cocoon uses some interfaces (in the org.apache.cocoon.xml
> > package),
> > like XMLConsumer, XMLizable etc which are right placed in Avalon, too.
>
> +1, there package/classes/interfaces will interfer with the one above
> because an XSLTProcessor is an XMLConsumer. Should the Abstract
> implementations move into Excalibur as well?
>
Yes, adding abstract implementations is always useful. So they should move,
too.
Carsten
> > If we have identified the components to move/donate, we should
> start discuss
> > if they should be moved unchanged or if they could be redesigned. But
> > this should be the second step.
> >
> > So, are there more components we could donate?
> > Avalon Team, are you interested in this?
> >
> > What's the correct procedure for this?
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: cziegeler@sundn.de
> > ================================================================
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Donating Cocoon Components to Avalon
Posted by giacomo <gi...@apache.org>.
On Tue, 30 Oct 2001, Carsten Ziegeler wrote:
> Hi Avalon Team, hi Cocoon Team,
>
> we had some weeks ago discussions about moving common
> components from Cocoon to Avalon. Both communitites
> agreed to this step.
>
> So, I think we should now start to identify the components
> we could give to Avalon. As a first start I would
> propose the following:
>
> - XML Parser
> - XSLT Processor
> - XPath
> - Resolver (Entity Resolver)
> - XMLSerializer/XMLDeserializer (The XML to byte stream
> compiler/interpreter)
> - SourceHandler/SourceFactory/Source
+1 on all above
> One of the most important components I think is the SourceHandler which
> is a replacement of the java.net.URL classes. It allows to define own
> protocols
> (like cocoon:, or cvs: etc) in a server environment. Many projects (Cocoon,
> Batik, perhaps soon FOP etc) have their own implementations which makes
> integrating
> same difficult and sometimes impossible.
This means we have to convice them to change from URL to SourceHandler
to have a smooth integration into Cocoon, right?
> In addition Cocoon uses some interfaces (in the org.apache.cocoon.xml
> package),
> like XMLConsumer, XMLizable etc which are right placed in Avalon, too.
+1, there package/classes/interfaces will interfer with the one above
because an XSLTProcessor is an XMLConsumer. Should the Abstract
implementations move into Excalibur as well?
> If we have identified the components to move/donate, we should start discuss
> if they should be moved unchanged or if they could be redesigned. But
> this should be the second step.
>
> So, are there more components we could donate?
> Avalon Team, are you interested in this?
>
> What's the correct procedure for this?
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Donating Cocoon Components to Avalon
Posted by giacomo <gi...@apache.org>.
On Tue, 30 Oct 2001, Carsten Ziegeler wrote:
> Hi Avalon Team, hi Cocoon Team,
>
> we had some weeks ago discussions about moving common
> components from Cocoon to Avalon. Both communitites
> agreed to this step.
>
> So, I think we should now start to identify the components
> we could give to Avalon. As a first start I would
> propose the following:
>
> - XML Parser
> - XSLT Processor
> - XPath
> - Resolver (Entity Resolver)
> - XMLSerializer/XMLDeserializer (The XML to byte stream
> compiler/interpreter)
> - SourceHandler/SourceFactory/Source
+1 on all above
> One of the most important components I think is the SourceHandler which
> is a replacement of the java.net.URL classes. It allows to define own
> protocols
> (like cocoon:, or cvs: etc) in a server environment. Many projects (Cocoon,
> Batik, perhaps soon FOP etc) have their own implementations which makes
> integrating
> same difficult and sometimes impossible.
This means we have to convice them to change from URL to SourceHandler
to have a smooth integration into Cocoon, right?
> In addition Cocoon uses some interfaces (in the org.apache.cocoon.xml
> package),
> like XMLConsumer, XMLizable etc which are right placed in Avalon, too.
+1, there package/classes/interfaces will interfer with the one above
because an XSLTProcessor is an XMLConsumer. Should the Abstract
implementations move into Excalibur as well?
> If we have identified the components to move/donate, we should start discuss
> if they should be moved unchanged or if they could be redesigned. But
> this should be the second step.
>
> So, are there more components we could donate?
> Avalon Team, are you interested in this?
>
> What's the correct procedure for this?
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
>
>
>
> ---------------------------------------------------------------------
> 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