You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/03/06 14:17:31 UTC
[PROPOSAL] Reducing the size of the build - ease use of optional components
I was about to commit the POI stuff, but then I felt a bit uneasy with how
the current build is organized.
Since there are so many optional components, it has become very big,
difficult to maintain IMHO and to understand for starters.
Also, the examples are structured better than before, but still a bit
confused as with directory structure and, most of all, they create problems
with the treeprocessor, that (correctly) complains when a sitemap uses
components that are not declared.
I've sent some patches for a restructuring of the build in the past, and in
the process of cleaning it for POI and Forrest I've created a project called
Centipede (http://www.krysalis.org/) that is used as a project starter.
I'm not proposing to use Centipede, but I think that some ideas-solutions
that came up with it could be applied to Cocoon.
DISCLAIMER: This has nothing to do with the current thread on cocoon Blocks.
Cocoon Blocks could change in the future some of the things proposed here
(optional components will be Blocks?), but IMHO it doesn't invalidate
current needs.
I could do the following:
1. Make a task that searches, like the xconf tool, in the classpath, for
.xoptional descriptor files and decides if a set of resources is to be
copied in the build dir (as the build does now in a more extensive way).
A sample could be:
<?xml version="1.0"?>
<xoptional name="BSF"
lib-url="http://oss.software.ibm.com/developerworks/projects/bsf/">
<if>
<class-available classname="com.ibm.bsf.BSFException"/>
</if>
<then>
<xsamples>
<!-- mount samples -->
</xsamples>
<xconf>
<component role="org.apache..." class="org.apache..."/>
</xconf>
</then>
<else>
<exclude name="**/ScriptAction.java"/>
<exclude name="**/ScriptGenerator.java"/>
</else>
</xoptional>
2. make all samples to be mounted in a "samples" dir, each with its
subsitemap. This could make it easy to not put them in when there are
optional components not presents, or also use Cocoon easily without the
samples.
3. Structure the build as in Centipede or Forrest by using external
entities, by dividing the build targets in many .xpart files. Forrest has an
example of this in CVS.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release early? (was: Roadmap Executive Plan)
Posted by Matthew Langham <ml...@s-und-n.de>.
>>
> What are we waiting for?
I guess we are waiting when Carsten gets well ;)
<<
Wow....please.....it will get to his head :-).
Carsten will be back in "limited" action from Monday.
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
Weblogging at: http://www.need-a-cake.com
=================================================================
-----Original Message-----
From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
Sent: Friday, March 08, 2002 4:09 PM
To: cocoon-dev@xml.apache.org; 'Nicola Ken Barozzi'
Subject: Release early? (was: Roadmap Executive Plan)
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
<snip/>
> Finally, when are we doing 2.0.2?
Does somebody remember what is "release early, release often" means? I
must confess I forgot the meaning of this...
> What are we waiting for?
I guess we are waiting when Carsten gets well ;)
Disclaimer: This mail supposed to be provocative... That's my first try,
don't mail-bomb me please :)
Vadim
---------------------------------------------------------------------
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: Release early? (was: Roadmap Executive Plan)
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> Quoting Carsten Ziegeler <cz...@s-und-n.de>:
>
> > > Sylvain Wallez wrote:
> > > <snip>
> > > >
> > > >>A question about sunRise : is it possible to use standard HTTP
> > > >>authentication and authorization ? AFAICS, it seems to be very tied
> > to
> > > >>form-based and application-managed authentication.
> > > >>
> > > >
> > > >You can use any information you can reach from within the Java code.
> > > >I'm not sure if there is a change to get the HTTP authentication
> > infos.
> > > >If yes, you can use sunRise.
> > > >
> > > The problem comes from the login page. With HTTP authentication, you
> > > don't have a dedicated login page, and thus cannot use this one to
> > > handle authentication. Or did I miss something ?
> > >
> >
> > Hm, correct me if I'm wrong as we never used HTTP authentication with
> > sunRise.
> > If a user requests a URI from the web server which is protected, the web
> > server
> > (or the browser) prompts for the authentication information.
>
> Yes. This is true for all kinds of authentication types (BASIC-AUTH as
well as
> SSL client certs).
>
> > Only if the
> > user is authenticated this request is forwarded to the servlet engine.
> ^ by the web server
And the web server can be the same as the servlet engine.
>
> > Is this correct?
>
> Yes.
>
> > If this is so, the servlet engine can - without using a form - use the
> > sunRise-login
> > action, get the information from the web server (if possible) and log
> > the
> > user
> > into sunRise.
>
> Yes, without redirecting it to a login page (in any case). In the case the
> Action thinks a user is not authorized it has to tell it back to the web
server
> by using the corresponding HTTP response code (5xx IIRC).
SC_UNAUTHORIZED
public static final int SC_UNAUTHORIZED
Status code (401) indicating that the request requires HTTP authentication.
Regards,
Konstantin
>
> The authenticating server and the application share a common user base
(the web
> server for authentication and the application for authorisation).
>
> > Does this make sense?
>
> I think so.
>
> Giacomo
>
> ---------------------------------------------------------------------
> 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: Release early? (was: Roadmap Executive Plan)
Posted by gi...@apache.org.
Quoting Carsten Ziegeler <cz...@s-und-n.de>:
> > Sylvain Wallez wrote:
> > <snip>
> > >
> > >>A question about sunRise : is it possible to use standard HTTP
> > >>authentication and authorization ? AFAICS, it seems to be very tied
> to
> > >>form-based and application-managed authentication.
> > >>
> > >
> > >You can use any information you can reach from within the Java code.
> > >I'm not sure if there is a change to get the HTTP authentication
> infos.
> > >If yes, you can use sunRise.
> > >
> > The problem comes from the login page. With HTTP authentication, you
> > don't have a dedicated login page, and thus cannot use this one to
> > handle authentication. Or did I miss something ?
> >
>
> Hm, correct me if I'm wrong as we never used HTTP authentication with
> sunRise.
> If a user requests a URI from the web server which is protected, the web
> server
> (or the browser) prompts for the authentication information.
Yes. This is true for all kinds of authentication types (BASIC-AUTH as well as
SSL client certs).
> Only if the
> user is authenticated this request is forwarded to the servlet engine.
^ by the web server
> Is this correct?
Yes.
> If this is so, the servlet engine can - without using a form - use the
> sunRise-login
> action, get the information from the web server (if possible) and log
> the
> user
> into sunRise.
Yes, without redirecting it to a login page (in any case). In the case the
Action thinks a user is not authorized it has to tell it back to the web server
by using the corresponding HTTP response code (5xx IIRC).
The authenticating server and the application share a common user base (the web
server for authentication and the application for authorisation).
> Does this make sense?
I think so.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release early? (was: Roadmap Executive Plan)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> Sylvain Wallez wrote:
> <snip>
> >
> >>A question about sunRise : is it possible to use standard HTTP
> >>authentication and authorization ? AFAICS, it seems to be very tied to
> >>form-based and application-managed authentication.
> >>
> >
> >You can use any information you can reach from within the Java code.
> >I'm not sure if there is a change to get the HTTP authentication infos.
> >If yes, you can use sunRise.
> >
> The problem comes from the login page. With HTTP authentication, you
> don't have a dedicated login page, and thus cannot use this one to
> handle authentication. Or did I miss something ?
>
Hm, correct me if I'm wrong as we never used HTTP authentication with
sunRise.
If a user requests a URI from the web server which is protected, the web
server
(or the browser) prompts for the authentication information. Only if the
user is authenticated this request is forwarded to the servlet engine.
Is this correct?
If this is so, the servlet engine can - without using a form - use the
sunRise-login
action, get the information from the web server (if possible) and log the
user
into sunRise.
Does this make sense?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Release early? (was: Roadmap Executive Plan)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>>Carsten Ziegeler wrote:
>><snip>
>>
>>>a) Sitemap components in the cocoon.xconf.
>>>Now, personally I don't like this - but that's my own opinion about this.
>>>If you want to edit the sitemap, you not only have to look at the sitemap
>>>but also at the cocoon.xconf. This makes handling the sitemap even more
>>>complicated.
>>>I know a lot of people complaining about the complexity of Cocoon and
>>>the many places of configuration. By this splitting of component
>>>definition it gets even harder for beginners.
>>>
>>>So I would like to have all these definitions back in the sitemap.
>>>What is the benefit of having them in the cocoon.xconf?
>>>
>>The benefit is reduced length of the <map:components> section in the
>>sitemap, which is both tedious to copy/paste in every sitemap and really
>>frightening for some beginners, and provide some sitemap components to
>>other components that could use them (thinking mainly about the xml
>>serializer).
>>
>
>What do you mean by copy/paste in every sitemap? I assume you don't mean
>sub-sitemaps as they inherit the components from the main sitemap, right?
>
No, of course no :) I was talking about the root sitemap of each
application.
>Hm, other components can use the sitemap components if they are instantiated
>from within a sitemap component.
>
Yes, but some are created outside of this scope. These are for example
SourceFactories, which may need a serializer.
>>About frightened users, what about reversing the order of sections in
>>the sitemap : start with pipelines, which describe the contract with the
>>external world, then resources, view, actions and lastly components ?
>>
>
>Sounds not so bad.
>
Cool.
>>>b) the sunRise and sunSpot components
>>>What is the feeling of the community to move them out of the scratchpad
>>>into the main trunk? I'm - of course :) - +1 on moving them.
>>>
>>Before moving sun* to the main trunk, we should discuss how it could be
>>better integrated into Cocoon. For now, it's in Cocoon's CVS (thanks
>>again for this donation), but is built 'on top' of it, while some of its
>>components are of general purpose and could be moved in existing Cocoon
>>packages where they could gain more exposure and thus a wider use.
>>
>
>Yes, good idea!
>
>>A question about sunRise : is it possible to use standard HTTP
>>authentication and authorization ? AFAICS, it seems to be very tied to
>>form-based and application-managed authentication.
>>
>
>You can use any information you can reach from within the Java code.
>I'm not sure if there is a change to get the HTTP authentication infos.
>If yes, you can use sunRise.
>
The problem comes from the login page. With HTTP authentication, you
don't have a dedicated login page, and thus cannot use this one to
handle authentication. Or did I miss something ?
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: Release early? (was: Roadmap Executive Plan)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
> <snip>
> >
> >a) Sitemap components in the cocoon.xconf.
> >Now, personally I don't like this - but that's my own opinion about this.
> >If you want to edit the sitemap, you not only have to look at the sitemap
> >but also at the cocoon.xconf. This makes handling the sitemap even more
> >complicated.
> >I know a lot of people complaining about the complexity of Cocoon and
> >the many places of configuration. By this splitting of component
> definition
> >it gets even harder for beginners.
> >So I would like to have all these definitions back in the sitemap.
> >What is the benefit of having them in the cocoon.xconf?
> >
> The benefit is reduced length of the <map:components> section in the
> sitemap, which is both tedious to copy/paste in every sitemap and really
> frightening for some beginners, and provide some sitemap components to
> other components that could use them (thinking mainly about the xml
> serializer).
>
What do you mean by copy/paste in every sitemap? I assume you don't mean
sub-sitemaps as they inherit the components from the main sitemap, right?
Hm, other components can use the sitemap components if they are instantiated
from within a sitemap component.
> About frightened users, what about reversing the order of sections in
> the sitemap : start with pipelines, which describe the contract with the
> external world, then resources, view, actions and lastly components ?
>
Sounds not so bad.
> >b) the sunRise and sunSpot components
> >What is the feeling of the community to move them out of the scratchpad
> >into the main trunk? I'm - of course :) - +1 on moving them.
> >
> Before moving sun* to the main trunk, we should discuss how it could be
> better integrated into Cocoon. For now, it's in Cocoon's CVS (thanks
> again for this donation), but is built 'on top' of it, while some of its
> components are of general purpose and could be moved in existing Cocoon
> packages where they could gain more exposure and thus a wider use.
>
Yes, good idea!
> A question about sunRise : is it possible to use standard HTTP
> authentication and authorization ? AFAICS, it seems to be very tied to
> form-based and application-managed authentication.
>
You can use any information you can reach from within the Java code.
I'm not sure if there is a change to get the HTTP authentication infos.
If yes, you can use sunRise.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Release early? (was: Roadmap Executive Plan)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Hmm, "release early" what does it mean?
>I think we should release a new version before lunch. Is that
>early enough?
>
>Ok, odd joke, let's get serious now:
>
>The problem with Cocoon and release early is the wast amount of
>changes that occur between versions. But I really would like
>to make a 2.0.2 asap.
>As I couldn't follow all the changes and discussions in the
>last two weeks, can someone summarize this please? Are the changes.xml
>up-to-date?
>
>I have at least two topics I would like to address:
>
>a) Sitemap components in the cocoon.xconf.
>Now, personally I don't like this - but that's my own opinion about this.
>If you want to edit the sitemap, you not only have to look at the sitemap
>but also at the cocoon.xconf. This makes handling the sitemap even more
>complicated.
>I know a lot of people complaining about the complexity of Cocoon and
>the many places of configuration. By this splitting of component definition
>it gets even harder for beginners.
>So I would like to have all these definitions back in the sitemap.
>What is the benefit of having them in the cocoon.xconf?
>
The benefit is reduced length of the <map:components> section in the
sitemap, which is both tedious to copy/paste in every sitemap and really
frightening for some beginners, and provide some sitemap components to
other components that could use them (thinking mainly about the xml
serializer).
About frightened users, what about reversing the order of sections in
the sitemap : start with pipelines, which describe the contract with the
external world, then resources, view, actions and lastly components ?
>b) the sunRise and sunSpot components
>What is the feeling of the community to move them out of the scratchpad
>into the main trunk? I'm - of course :) - +1 on moving them.
>
Before moving sun* to the main trunk, we should discuss how it could be
better integrated into Cocoon. For now, it's in Cocoon's CVS (thanks
again for this donation), but is built 'on top' of it, while some of its
components are of general purpose and could be moved in existing Cocoon
packages where they could gain more exposure and thus a wider use.
A question about sunRise : is it possible to use standard HTTP
authentication and authorization ? AFAICS, it seems to be very tied to
form-based and application-managed authentication.
<snip/>
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: Release early? (was: Roadmap Executive Plan)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Carsten Ziegeler" <cz...@s-und-n.de>
> > Carsten Ziegeler wrote:
> > a) Sitemap components in the cocoon.xconf.
> > Now, personally I don't like this - but that's my own opinion about
this.
> > If you want to edit the sitemap, you not only have to look at the
sitemap
> > but also at the cocoon.xconf. This makes handling the sitemap even more
> > complicated.
> > I know a lot of people complaining about the complexity of Cocoon and
> > the many places of configuration. By this splitting of component
> > definition
> > it gets even harder for beginners.
> > So I would like to have all these definitions back in the sitemap.
> > What is the benefit of having them in the cocoon.xconf?
How I see it, the components should be configured out of the sitemap, but
cocoon.xconf is not the best solution for this.
AFAIK, there was a discussion on the configuration files going on, and on
Cocoon Blocks.
I'd put also this point:
d) restructure samples using subsitemaps.
I'm halfway through, and with the new dir layout, it makes more sense to
have basic Sitemap Cocmponents included in xconf.
> > b) the sunRise and sunSpot components
> > What is the feeling of the community to move them out of the scratchpad
> > into the main trunk? I'm - of course :) - +1 on moving them.
Hmmm... I'm not so sure. I love what they do, don't get me wrong, but I
would prefer to have them integrated in the *whole* Cocoon samples instead
of being just part of it.
>
> c) Rename the CVS repository as by Stefano's suggestion:
> Rename xml-cocoon to xml-cocoon1 and xml-cocoon2 to xml-cocoon
> to keep the history.
+0
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release early? (was: Roadmap Executive Plan)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
I added a third point, see below:
> Carsten Ziegeler wrote:
>
> Hmm, "release early" what does it mean?
> I think we should release a new version before lunch. Is that
> early enough?
>
> Ok, odd joke, let's get serious now:
>
> The problem with Cocoon and release early is the wast amount of
> changes that occur between versions. But I really would like
> to make a 2.0.2 asap.
> As I couldn't follow all the changes and discussions in the
> last two weeks, can someone summarize this please? Are the changes.xml
> up-to-date?
>
> I have at least two topics I would like to address:
>
> a) Sitemap components in the cocoon.xconf.
> Now, personally I don't like this - but that's my own opinion about this.
> If you want to edit the sitemap, you not only have to look at the sitemap
> but also at the cocoon.xconf. This makes handling the sitemap even more
> complicated.
> I know a lot of people complaining about the complexity of Cocoon and
> the many places of configuration. By this splitting of component
> definition
> it gets even harder for beginners.
> So I would like to have all these definitions back in the sitemap.
> What is the benefit of having them in the cocoon.xconf?
>
> b) the sunRise and sunSpot components
> What is the feeling of the community to move them out of the scratchpad
> into the main trunk? I'm - of course :) - +1 on moving them.
>
c) Rename the CVS repository as by Stefano's suggestion:
Rename xml-cocoon to xml-cocoon1 and xml-cocoon2 to xml-cocoon
to keep the history.
> Cheers,
> Carsten
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Release early? (was: Roadmap Executive Plan)
Posted by Stuart Roebuck <st...@adolos.co.uk>.
On Monday, March 11, 2002, at 09:40 am, Carsten Ziegeler wrote:
> a) Sitemap components in the cocoon.xconf.
> Now, personally I don't like this - but that's my own opinion about
> this.
> If you want to edit the sitemap, you not only have to look at the
> sitemap
> but also at the cocoon.xconf. This makes handling the sitemap even more
> complicated.
> I know a lot of people complaining about the complexity of Cocoon and
> the many places of configuration. By this splitting of component
> definition
> it gets even harder for beginners.
> So I would like to have all these definitions back in the sitemap.
> What is the benefit of having them in the cocoon.xconf?
We have a growing number of sites under development that use a common
configuration. Being able to put all the general cocoon configuration
in the cocoon.xconf file (configuration that requires knowledge of Java
class names and is quite often impacted by updates to cocoon and its
components), and keep site specific stuff in one or more "sitemap.xmap"
files is definitely beneficial.
Otherwise, every time Cocoon is updated we have to compare the diffs of
the supplied sitemap with the previous supplied version and implement
these in all our sitemaps. If, on the other hand, all of this is in
cocoon.xconf, we may be able to just get away with using the supplied
file (but for database configuration).
If we want to reduce complexity I would be in favour of deprecating the
facility for declaring components within sitemap.xmap.
Stuart.
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Release early? (was: Roadmap Executive Plan)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hmm, "release early" what does it mean?
I think we should release a new version before lunch. Is that
early enough?
Ok, odd joke, let's get serious now:
The problem with Cocoon and release early is the wast amount of
changes that occur between versions. But I really would like
to make a 2.0.2 asap.
As I couldn't follow all the changes and discussions in the
last two weeks, can someone summarize this please? Are the changes.xml
up-to-date?
I have at least two topics I would like to address:
a) Sitemap components in the cocoon.xconf.
Now, personally I don't like this - but that's my own opinion about this.
If you want to edit the sitemap, you not only have to look at the sitemap
but also at the cocoon.xconf. This makes handling the sitemap even more
complicated.
I know a lot of people complaining about the complexity of Cocoon and
the many places of configuration. By this splitting of component definition
it gets even harder for beginners.
So I would like to have all these definitions back in the sitemap.
What is the benefit of having them in the cocoon.xconf?
b) the sunRise and sunSpot components
What is the feeling of the community to move them out of the scratchpad
into the main trunk? I'm - of course :) - +1 on moving them.
Cheers,
Carsten
> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Sent: Friday, March 08, 2002 4:09 PM
> To: cocoon-dev@xml.apache.org; 'Nicola Ken Barozzi'
> Subject: Release early? (was: Roadmap Executive Plan)
>
>
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> <snip/>
>
> > Finally, when are we doing 2.0.2?
>
> Does somebody remember what is "release early, release often" means? I
> must confess I forgot the meaning of this...
>
>
> > What are we waiting for?
>
> I guess we are waiting when Carsten gets well ;)
>
>
> Disclaimer: This mail supposed to be provocative... That's my first try,
> don't mail-bomb me please :)
>
> Vadim
>
>
> ---------------------------------------------------------------------
> 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
Release early? (was: Roadmap Executive Plan)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
<snip/>
> Finally, when are we doing 2.0.2?
Does somebody remember what is "release early, release often" means? I
must confess I forgot the meaning of this...
> What are we waiting for?
I guess we are waiting when Carsten gets well ;)
Disclaimer: This mail supposed to be provocative... That's my first try,
don't mail-bomb me please :)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Roadmap Executive Plan (was Re: [PROPOSAL] Reducing the size of the build - ease use of optionalcomponents)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Stefano Mazzocchi" <st...@apache.org>
> giacomo wrote:
> >
> > On Thu, 7 Mar 2002, Jeremy Quinn wrote:
> > > Regardless of the particular issue of reorganisation proposed by
Nicola Ken
> > > Barozzi and Stefano's response, which I agree with ..... I think the
> > > samples in the main sitemap would definitely be improved by being
seperated
> > > into several sub-sitemaps. The main sitemap is far too complicated, it
> > > makes Cocoon look more complicated than it really is to use!
> >
> > Good point. As a general usage pattern to show how stuff can be
> > implemented with the current instrumentation it would make sense to have
> > the root sitemap only mounts all examples. The Cocoon samples site have
> > grown to a point where this will make absolutely sense.
>
> +1
Ok, so I'll start reorganizing them (from a directory POV) incrementally as
subsitemaps served under "samples".
If anyone sees issues with this happening, I'll be happy to know them and
change my actions accordingly.
As for patches-bugs, I've been trying to get them to a low level in these
days, and patches are basically all applied-reviewed.
There is one that IMHO needs detailed scrutiny: "Cache improvement using ESI
invalidation protocol"
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6879). Anyone has
comments on this?
As for bugs, they are 32.
I'm starting to try and fix them now that patches are applied.
If anyone wants to give a hand, I don't mind ;-)
Finally, when are we doing 2.0.2?
What are we waiting for?
Following Stefano's roadmap:
1) DOCUMENTATION
IMO samples are the best documentation one can give. Hey, did you guys learn
XSLT reading the spec or hacking on ready made ones? ;-) This is where the
sample reorganization can help a bit.
As for the proper documentation, the usual rule applies: who want to
contribute is well accepted :-)
As for the auto-documenting classes using Javadoc tags, any news? IMO it
would be great!
2) SPEED
The compiled sitemap is part of the solution. To make it easier to be
tested, I propose a simple installinterpretedwar (I'm not the king of names,
suggestions are welcome ;-) that can install Cocoon with the new sitemap
easily. And we can use the treeprocessor, starting from now, to make
documentation with it, like Forrest does.
3) SYMMETRY
Where are we at currently? I've seen Jeremy's editor and saw great
possibilities ahead. Comments?
4) APPLICATION MODULARITY
Scheduled for 2.1 Can't wait to see it happen :-)
4) FLOWMAPS
2.2 and beyond, in the deep space of XML nirvana...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Reducing the size of the build - ease use of
optionalcomponents
Posted by Stefano Mazzocchi <st...@apache.org>.
giacomo wrote:
>
> On Thu, 7 Mar 2002, Jeremy Quinn wrote:
>
> > At 1:52 am +0100 7/3/02, Stefano Mazzocchi wrote:
> > >Nicola Ken Barozzi wrote:
> > >>
> > >> I was about to commit the POI stuff, but then I felt a bit uneasy with how
> > >> the current build is organized.
> >
> > <snip/>
> >
> > >I don't like the markup semantics but I see your point and I like the
> > >concept.
> > >
> > >> 2. make all samples to be mounted in a "samples" dir, each with its
> > >> subsitemap. This could make it easy to not put them in when there are
> > >> optional components not presents, or also use Cocoon easily without the
> > >> samples.
> > >
> > >I like this so far.
> > >
> > >> 3. Structure the build as in Centipede or Forrest by using external
> > >> entities, by dividing the build targets in many .xpart files. Forrest has an
> > >> example of this in CVS.
> > >
> > >I don't like this, we should stay away from entities as much as
> > >possible.[also true for forrest, I'd love that to be changed]
> > >
> > >What do others think about this?
> >
> > Regardless of the particular issue of reorganisation proposed by Nicola Ken
> > Barozzi and Stefano's response, which I agree with ..... I think the
> > samples in the main sitemap would definitely be improved by being seperated
> > into several sub-sitemaps. The main sitemap is far too complicated, it
> > makes Cocoon look more complicated than it really is to use!
>
> Good point. As a general usage pattern to show how stuff can be
> implemented with the current instrumentation it would make sense to have
> the root sitemap only mounts all examples. The Cocoon samples site have
> grown to a point where this will make absolutely sense.
+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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Reducing the size of the build - ease use of optional
components
Posted by giacomo <gi...@apache.org>.
On Thu, 7 Mar 2002, Jeremy Quinn wrote:
> At 1:52 am +0100 7/3/02, Stefano Mazzocchi wrote:
> >Nicola Ken Barozzi wrote:
> >>
> >> I was about to commit the POI stuff, but then I felt a bit uneasy with how
> >> the current build is organized.
>
> <snip/>
>
> >I don't like the markup semantics but I see your point and I like the
> >concept.
> >
> >> 2. make all samples to be mounted in a "samples" dir, each with its
> >> subsitemap. This could make it easy to not put them in when there are
> >> optional components not presents, or also use Cocoon easily without the
> >> samples.
> >
> >I like this so far.
> >
> >> 3. Structure the build as in Centipede or Forrest by using external
> >> entities, by dividing the build targets in many .xpart files. Forrest has an
> >> example of this in CVS.
> >
> >I don't like this, we should stay away from entities as much as
> >possible.[also true for forrest, I'd love that to be changed]
> >
> >What do others think about this?
>
> Regardless of the particular issue of reorganisation proposed by Nicola Ken
> Barozzi and Stefano's response, which I agree with ..... I think the
> samples in the main sitemap would definitely be improved by being seperated
> into several sub-sitemaps. The main sitemap is far too complicated, it
> makes Cocoon look more complicated than it really is to use!
Good point. As a general usage pattern to show how stuff can be
implemented with the current instrumentation it would make sense to have
the root sitemap only mounts all examples. The Cocoon samples site have
grown to a point where this will make absolutely sense.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Reducing the size of the build - ease use of
optional components
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 1:52 am +0100 7/3/02, Stefano Mazzocchi wrote:
>Nicola Ken Barozzi wrote:
>>
>> I was about to commit the POI stuff, but then I felt a bit uneasy with how
>> the current build is organized.
<snip/>
>I don't like the markup semantics but I see your point and I like the
>concept.
>
>> 2. make all samples to be mounted in a "samples" dir, each with its
>> subsitemap. This could make it easy to not put them in when there are
>> optional components not presents, or also use Cocoon easily without the
>> samples.
>
>I like this so far.
>
>> 3. Structure the build as in Centipede or Forrest by using external
>> entities, by dividing the build targets in many .xpart files. Forrest has an
>> example of this in CVS.
>
>I don't like this, we should stay away from entities as much as
>possible.[also true for forrest, I'd love that to be changed]
>
>What do others think about this?
Regardless of the particular issue of reorganisation proposed by Nicola Ken
Barozzi and Stefano's response, which I agree with ..... I think the
samples in the main sitemap would definitely be improved by being seperated
into several sub-sitemaps. The main sitemap is far too complicated, it
makes Cocoon look more complicated than it really is to use!
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Reducing the size of the build - ease use of optional components
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Stefano Mazzocchi" <stefano@apache.org
> David Crossley wrote:
> >
> > Stefano Mazzocchi wrote:
> ... I agree with you that currently
> there is nothing sufficiently expressive to allow people to use XML and
> avoid using entities.
This is the problem.
I asked the Ant team what I could do to structure the build without
entities. As for the replies I got, XML entities are the only current way.
But looking at all the Ant2 proposals, it seems we will have something
better in Ant2!
So, as I see it, entities are going to be an interim solution :-)
> > I actually like Ken's proposal. It uses the power of XML
> > to provide a very clean build configuration. It pulls
> > the separate pieces together, rather than have one
> > monolithic build.xml which has become cumbersome.
>
> I agree with the fact that 75Kb of build.xml are probably the most
> complex build file ever in the history of Ant and this is clearly not a
> good thing.
>
> At the same time, I'm afraid of fragmenting the pieces too much.
The first step is to provide a tool that eliminates the need of repeating so
many lines for optional components.
This is what I'm doing in the restructuring.
When that is done, we can see what is left, and decide how to split it.
For anyone who wants to see an example of this, there is xml-forrest in CVS.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Reducing the size of the build - ease use of optional
components
Posted by Stefano Mazzocchi <st...@apache.org>.
David Crossley wrote:
>
> Stefano Mazzocchi wrote:
> > Nicola Ken Barozzi wrote:
> > >
> > > I was about to commit the POI stuff, but then I felt a bit uneasy with how
> > > the current build is organized.
>
> <snip/>
> >
> > > 3. Structure the build as in Centipede or Forrest by using external
> > > entities, by dividing the build targets in many .xpart files. Forrest has an
> > > example of this in CVS.
> >
> > I don't like this, we should stay away from entities as much as
> > possible.[also true for forrest, I'd love that to be changed]
> >
> > What do others think about this?
>
> Why do you say "stay away from entities"? Are saying
> take away the ability for one XML document to declare
> and include another document/fragment? Or are you
> meaning the ability to define a piece of re-usable text?
Both. I don't like entities. I pray for a day when XML 2.0 will remove
the notion of DTDs altogether. All inclusion should be performed with
xinclude and an xpipeline definition.... but this is Sci-Fi for now.
I personally never liked books done like this
<book>
&chapter1;
&chapter2;
&chapter3;
</book>
this is the SGML way, it's old and ugly and, besides, I consider
entities a huge hack that got sedimented too much.
> The term "entity" is often misused and used to mean
> many different things. So i will wait until you explain
> and provide reasons.
I'm pretty sure we disagree on this and I agree with you that currently
there is nothing sufficiently expressive to allow people to use XML and
avoid using entities.
> I actually like Ken's proposal. It uses the power of XML
> to provide a very clean build configuration. It pulls
> the separate pieces together, rather than have one
> monolithic build.xml which has become cumbersome.
I agree with the fact that 75Kb of build.xml are probably the most
complex build file ever in the history of Ant and this is clearly not a
good thing.
At the same time, I'm afraid of fragmenting the pieces too much.
Oh well, I'm +0 on this anyway.
--
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Reducing the size of the build - ease use of optional components
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
> >
> > I was about to commit the POI stuff, but then I felt a bit uneasy with how
> > the current build is organized.
<snip/>
>
> > 3. Structure the build as in Centipede or Forrest by using external
> > entities, by dividing the build targets in many .xpart files. Forrest has an
> > example of this in CVS.
>
> I don't like this, we should stay away from entities as much as
> possible.[also true for forrest, I'd love that to be changed]
>
> What do others think about this?
Why do you say "stay away from entities"? Are saying
take away the ability for one XML document to declare
and include another document/fragment? Or are you
meaning the ability to define a piece of re-usable text?
The term "entity" is often misused and used to mean
many different things. So i will wait until you explain
and provide reasons.
I actually like Ken's proposal. It uses the power of XML
to provide a very clean build configuration. It pulls
the separate pieces together, rather than have one
monolithic build.xml which has become cumbersome.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Reducing the size of the build - ease use of optional
components
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> I was about to commit the POI stuff, but then I felt a bit uneasy with how
> the current build is organized.
>
> Since there are so many optional components, it has become very big,
> difficult to maintain IMHO and to understand for starters.
> Also, the examples are structured better than before, but still a bit
> confused as with directory structure and, most of all, they create problems
> with the treeprocessor, that (correctly) complains when a sitemap uses
> components that are not declared.
>
> I've sent some patches for a restructuring of the build in the past, and in
> the process of cleaning it for POI and Forrest I've created a project called
> Centipede (http://www.krysalis.org/) that is used as a project starter.
> I'm not proposing to use Centipede, but I think that some ideas-solutions
> that came up with it could be applied to Cocoon.
>
> DISCLAIMER: This has nothing to do with the current thread on cocoon Blocks.
> Cocoon Blocks could change in the future some of the things proposed here
> (optional components will be Blocks?), but IMHO it doesn't invalidate
> current needs.
>
> I could do the following:
>
> 1. Make a task that searches, like the xconf tool, in the classpath, for
> .xoptional descriptor files and decides if a set of resources is to be
> copied in the build dir (as the build does now in a more extensive way).
> A sample could be:
>
> <?xml version="1.0"?>
> <xoptional name="BSF"
> lib-url="http://oss.software.ibm.com/developerworks/projects/bsf/">
>
> <if>
> <class-available classname="com.ibm.bsf.BSFException"/>
> </if>
>
> <then>
> <xsamples>
> <!-- mount samples -->
> </xsamples>
> <xconf>
> <component role="org.apache..." class="org.apache..."/>
> </xconf>
> </then>
>
> <else>
> <exclude name="**/ScriptAction.java"/>
> <exclude name="**/ScriptGenerator.java"/>
> </else>
>
> </xoptional>
I don't like the markup semantics but I see your point and I like the
concept.
> 2. make all samples to be mounted in a "samples" dir, each with its
> subsitemap. This could make it easy to not put them in when there are
> optional components not presents, or also use Cocoon easily without the
> samples.
I like this so far.
> 3. Structure the build as in Centipede or Forrest by using external
> entities, by dividing the build targets in many .xpart files. Forrest has an
> example of this in CVS.
I don't like this, we should stay away from entities as much as
possible.[also true for forrest, I'd love that to be changed]
What do others think about this?
--
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org