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/12/04 16:28:05 UTC
[PROPOSAL] make Cocoon modules alongside blocks (was Re: [RT] A deprecated
module )
Now I'm a bit lost on the results of the RT deprecated thread 8-) so I'm
making this into a proposal.
_Proposal_
This proposal is to create a source section parallel to blocks, to hold
Cocoon "parts", or "modules", that are not part of the Cocoon minimal
core but need nevertheless to be included in the classpath and config
files at startup.
They would look identical to the current "blocks", ie jars. The
difference is that they will never be hot-pluggable as Cocoon
Components, and are not part of the Block concept.
Thus, when proper .cob blocks will arrive, the /blocks will migrate to
that packaging format, while these "modules" will not.
Possible candidates to be repackaged as modules:
1 - deprecated classes that are not Cocoon Components
2 - Environment implememtations
3 - "frontends" like CocoonServlet.java and Main.java
4 - samples
5 - module implementations
6 - profiler
Many more can be moved, but these are the ones that ATM make more sense
to me.
We also need a name for these "parts", currently I'm for "modules", but
suggestions are welcome.
Also module.xml is confusing, since it means CVSmodule...
project-info.xml is a proposal, any other or it's ok?
Thanks.
Below is part of the original thread.
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
>>Carsten Ziegeler wrote:
>>
>>>I still think that the current "blocks" we have in the cvs head are the
>>>modules - and when we introduced them, I proposed to call them modules
>>>first. Ok, but that's the past - let's be constructive.
>>
>>Currently they are in fact packaged as "modules", ie as jars that need
>>to be there at startup. In this I agree with you.
>>
>>But IIUC there is no code there that cannot be in the future repackaged
>>in a cob and be dynamically loaded. There are only Cocoon Components and
>>Avalon Components.
>
> True
>
>>Making a deprecated thing, would probably become a deprecated block for
>>deprecated Cocoon components, and a deprecated module for Cocoon modules
>>(ie all that can be taken out of Cocoon core but is not to go in COBs).
>>
>>
>>>I'm fine with the name modules and this separation. But then we should
>>>perhaps rename the modules.xml to something else.
>>
>>the root module.xml?
>
>
> Yupp :)
>
>
>>hehehe, that's the gump descriptor, some call it gump.xml, some
>>projectname.xml, I called it module.xml because of CVS module.
>>hehehe it does create confusion. What would you prefer as a name?
>>
>>project-info.xml ?
>
> Good choice! +1 for project-info.xml
--
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] Take two: modules -> environments + features ( was:
make Cocoon modules alongside blocks)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
...
> environments
...
> features
...
I forgot this:
deprecated
It should be a separate dir. In fact, it seemed quite strange that we
would have a "deprecated module", and now it would be even wierder:
"deprecated feature".
--
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
[PROPOSAL] Take two: modules -> environments + features ( was: make
Cocoon modules alongside blocks)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
>>> Nicola Ken Barozzi wrote:
>>>
>>>> This proposal is to create a source section parallel to blocks, to
>>>> hold Cocoon "parts", or "modules", that are not part of the Cocoon
>>>> minimal core but need nevertheless to be included in the classpath
>>>> and config files at startup.
[...]
>>>>Possible candidates to be repackaged as modules:
>>>> 1 - deprecated classes that are not Cocoon Components
>>>> 2 - Environment implememtations
>>>> 3 - "frontends" like CocoonServlet.java and Main.java
[...]
>>>> 5 - module implementations
>>>> 6 - profiler
So here is my second take at the proposal. It seems that it's not a bad
idea but we couldn't find a name for them. I felt a bit uncomfortable
seeing that we couldn't name it, and usually it means that it's mixing
concerns or too generic. Actually it seems that it's both.
This new proposal keeps the same idea of creating Cocoon "parts" that
should be present at startup, but differentiates between the two, by
making environments and features.
environments
--------------
The Cocoon environments are in fact composed by o.a.c.environment.*
implmentations and other classes, Main.java+other transformers and
serializers in the CLI and the servlet package for servlets.
So we would have:
./src/environments/cli/**
./src/environments/servlet/**
./src/environments/ant/**
these can depend on one another, but not with a circular dependency. For
example the ant env would depend on the CLI one.
This takes care of points 2,3 in the initial list that is cited above.
features
--------------
Features are non-compulsory parts of Cocoon that add... err... features
to Cocoon.
These would be the profiler stuff for example or eventually part of the
caching...
Actually, looking at the code better, it seems that all these "features"
can be put in blocks, since they will be able to add Avalon components
to Cocoon.
What do you guys think?
-o-
As for the Cocoon Components that do not depend on non-JDK jars, I would
make a single block of each of them, and leave in the core only the
default ones we are using now, like the file generator, xslt ransformer,
xml serializer and the-matcher-that's-so-standard-I-don't-remember-its-name.
--
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] make Cocoon modules alongside blocks (was Re: [RT] A deprecated module )
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> Stefano Mazzocchi wrote:
> > Nicola Ken Barozzi wrote:
> >
> >> Now I'm a bit lost on the results of the RT deprecated thread 8-) so
> >> I'm making this into a proposal.
> >>
> >> _Proposal_
> >>
> >> This proposal is to create a source section parallel to blocks, to
> >> hold Cocoon "parts", or "modules", that are not part of the Cocoon
> >> minimal core but need nevertheless to be included in the classpath and
> >> config files at startup.
> >>
> >> They would look identical to the current "blocks", ie jars. The
> >> difference is that they will never be hot-pluggable as Cocoon
> >> Components, and are not part of the Block concept.
> >> Thus, when proper .cob blocks will arrive, the /blocks will migrate to
> >> that packaging format, while these "modules" will not.
> >>
> >> Possible candidates to be repackaged as modules:
> >> 1 - deprecated classes that are not Cocoon Components
> >> 2 - Environment implememtations
> >> 3 - "frontends" like CocoonServlet.java and Main.java
> >> 4 - samples
> >> 5 - module implementations
> >> 6 - profiler
> >>
> >> Many more can be moved, but these are the ones that ATM make more
> >> sense to me.
> >>
> >> We also need a name for these "parts", currently I'm for "modules",
> >> but suggestions are welcome.
> >> Also module.xml is confusing, since it means CVSmodule...
> >> project-info.xml is a proposal, any other or it's ok?
> >>
> >> Thanks.
> >
+1
> >
> > I like the concept but I'm afraid of overloading 'module'....
> it's wild,
> > but what about
> >
> > 'organs'
> >
> > Just like Cocoon is a body and you take and remove organs that are not
> > necessary for its life.
>
> Hmmm, too atristic. After the fancy name overload in Avalon and in some
> of my projects, I now start to think that one fancy name per project is
> enough ;-)
>
Yes, please, no fancy names.
> But still IMHO Chris is right about the "module" name clashes, and
> overmore Apache has them too but they are probably more akin to blocks.
>
> Guys, you'd better come out with a good name here, or I'll stick to the
> ugly one out of necessity! ;-P
>
Good idea - as a non native speaker I can only think of modules or parts.
But I don't have anything better.
> > [note: from the list above, I think 'samples' should be a block, not a
> > module]
>
> Looking at the actual code better... I guess you're right.
>
Yes, samples are more a block or part of a block.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] make Cocoon modules alongside blocks (was Re: [RT]
A deprecated module )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
>
>> Now I'm a bit lost on the results of the RT deprecated thread 8-) so
>> I'm making this into a proposal.
>>
>> _Proposal_
>>
>> This proposal is to create a source section parallel to blocks, to
>> hold Cocoon "parts", or "modules", that are not part of the Cocoon
>> minimal core but need nevertheless to be included in the classpath and
>> config files at startup.
>>
>> They would look identical to the current "blocks", ie jars. The
>> difference is that they will never be hot-pluggable as Cocoon
>> Components, and are not part of the Block concept.
>> Thus, when proper .cob blocks will arrive, the /blocks will migrate to
>> that packaging format, while these "modules" will not.
>>
>> Possible candidates to be repackaged as modules:
>> 1 - deprecated classes that are not Cocoon Components
>> 2 - Environment implememtations
>> 3 - "frontends" like CocoonServlet.java and Main.java
>> 4 - samples
>> 5 - module implementations
>> 6 - profiler
>>
>> Many more can be moved, but these are the ones that ATM make more
>> sense to me.
>>
>> We also need a name for these "parts", currently I'm for "modules",
>> but suggestions are welcome.
>> Also module.xml is confusing, since it means CVSmodule...
>> project-info.xml is a proposal, any other or it's ok?
>>
>> Thanks.
>
>
> I like the concept but I'm afraid of overloading 'module'.... it's wild,
> but what about
>
> 'organs'
>
> Just like Cocoon is a body and you take and remove organs that are not
> necessary for its life.
Hmmm, too atristic. After the fancy name overload in Avalon and in some
of my projects, I now start to think that one fancy name per project is
enough ;-)
But still IMHO Chris is right about the "module" name clashes, and
overmore Apache has them too but they are probably more akin to blocks.
Guys, you'd better come out with a good name here, or I'll stick to the
ugly one out of necessity! ;-P
> [note: from the list above, I think 'samples' should be a block, not a
> module]
Looking at the actual code better... I guess you're right.
--
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] make Cocoon modules alongside blocks (was Re: [RT]
A deprecated module )
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> Now I'm a bit lost on the results of the RT deprecated thread 8-) so I'm
> making this into a proposal.
>
> _Proposal_
>
> This proposal is to create a source section parallel to blocks, to hold
> Cocoon "parts", or "modules", that are not part of the Cocoon minimal
> core but need nevertheless to be included in the classpath and config
> files at startup.
>
> They would look identical to the current "blocks", ie jars. The
> difference is that they will never be hot-pluggable as Cocoon
> Components, and are not part of the Block concept.
> Thus, when proper .cob blocks will arrive, the /blocks will migrate to
> that packaging format, while these "modules" will not.
>
> Possible candidates to be repackaged as modules:
> 1 - deprecated classes that are not Cocoon Components
> 2 - Environment implememtations
> 3 - "frontends" like CocoonServlet.java and Main.java
> 4 - samples
> 5 - module implementations
> 6 - profiler
>
> Many more can be moved, but these are the ones that ATM make more sense
> to me.
>
> We also need a name for these "parts", currently I'm for "modules", but
> suggestions are welcome.
> Also module.xml is confusing, since it means CVSmodule...
> project-info.xml is a proposal, any other or it's ok?
>
> Thanks.
I like the concept but I'm afraid of overloading 'module'.... it's wild,
but what about
'organs'
Just like Cocoon is a body and you take and remove organs that are not
necessary for its life.
[note: from the list above, I think 'samples' should be a block, not a
module]
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] make Cocoon modules alongside blocks (was Re: [RT]
A deprecated module )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
tcurdt@dff.st wrote:
> Quoting Nicola Ken Barozzi <ni...@apache.org>:
>
>
>>Now I'm a bit lost on the results of the RT deprecated thread 8-) so I'm
>>making this into a proposal.
>>
>>_Proposal_
>>
>>This proposal is to create a source section parallel to blocks, to hold
>>Cocoon "parts", or "modules", that are not part of the Cocoon minimal
>>core but need nevertheless to be included in the classpath and config
>>files at startup.
>>
>>They would look identical to the current "blocks", ie jars. The
>>difference is that they will never be hot-pluggable as Cocoon
>>Components, and are not part of the Block concept.
>>Thus, when proper .cob blocks will arrive, the /blocks will migrate to
>>that packaging format, while these "modules" will not.
>>
>>Possible candidates to be repackaged as modules:
>> 1 - deprecated classes that are not Cocoon Components
>> 2 - Environment implememtations
>> 3 - "frontends" like CocoonServlet.java and Main.java
>> 4 - samples
>> 5 - module implementations
>> 6 - profiler
>
>
> Hm... this could really make it hard to have an overview of the codebase.
Actually, the motive is exactly that of having a cleaner codebase...
> Consider you are looking for a specific class... It might be in module A
> java/org/apache/cocoon/... or in module B java/org/...
> For some classes it *might* not be obvious in which module to find them...
It should be. Look at the other side: how many know what is core in
Cocoon and what isn't? JSP block showed that it's *totally* non-core,
but it was not configured as such, it was in the base xconf.
> BTW: I bet people will getting cross-eyed having to deal with modules as well
> as with blocks. ("What's the difference?" gonna be a candidate for the FAQ)
Probably till we have cobs it could be so.
> ...so I am currently -0.25 :-/
--
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] make Cocoon modules alongside blocks (was Re: [RT] A deprecated module )
Posted by tc...@dff.st.
Quoting Nicola Ken Barozzi <ni...@apache.org>:
> Now I'm a bit lost on the results of the RT deprecated thread 8-) so I'm
> making this into a proposal.
>
> _Proposal_
>
> This proposal is to create a source section parallel to blocks, to hold
> Cocoon "parts", or "modules", that are not part of the Cocoon minimal
> core but need nevertheless to be included in the classpath and config
> files at startup.
>
> They would look identical to the current "blocks", ie jars. The
> difference is that they will never be hot-pluggable as Cocoon
> Components, and are not part of the Block concept.
> Thus, when proper .cob blocks will arrive, the /blocks will migrate to
> that packaging format, while these "modules" will not.
>
> Possible candidates to be repackaged as modules:
> 1 - deprecated classes that are not Cocoon Components
> 2 - Environment implememtations
> 3 - "frontends" like CocoonServlet.java and Main.java
> 4 - samples
> 5 - module implementations
> 6 - profiler
Hm... this could really make it hard to have an overview of the codebase.
Consider you are looking for a specific class... It might be in module A
java/org/apache/cocoon/... or in module B java/org/...
For some classes it *might* not be obvious in which module to find them...
BTW: I bet people will getting cross-eyed having to deal with modules as well
as with blocks. ("What's the difference?" gonna be a candidate for the FAQ)
...so I am currently -0.25 :-/
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] make Cocoon modules alongside blocks (was Re: [RT] A deprecated module )
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 04.Dec.2002 -- 04:28 PM, Nicola Ken Barozzi wrote:
> Now I'm a bit lost on the results of the RT deprecated thread 8-) so I'm
> making this into a proposal.
>
> _Proposal_
>
> This proposal is to create a source section parallel to blocks, to hold
> Cocoon "parts", or "modules", that are not part of the Cocoon minimal
> core but need nevertheless to be included in the classpath and config
> files at startup.
>
> They would look identical to the current "blocks", ie jars. The
> difference is that they will never be hot-pluggable as Cocoon
> Components, and are not part of the Block concept.
> Thus, when proper .cob blocks will arrive, the /blocks will migrate to
> that packaging format, while these "modules" will not.
>
> Possible candidates to be repackaged as modules:
> 1 - deprecated classes that are not Cocoon Components
why shouldn't deprecated components go into this (or another) thingy?
('phase_out' ?)
> 2 - Environment implememtations
> 3 - "frontends" like CocoonServlet.java and Main.java
> 4 - samples
> 5 - module implementations
> 6 - profiler
>
> Many more can be moved, but these are the ones that ATM make more sense
> to me.
>
> We also need a name for these "parts", currently I'm for "modules", but
> suggestions are welcome.
> Also module.xml is confusing, since it means CVSmodule...
> project-info.xml is a proposal, any other or it's ok?
I was the culprit that caused the fuzz last time, I
believe. Personally, I think of org.apache.cocoon.components.modules
when "module" is used. Anyway, I will not stir this up again.
Thus I'm -0 on the name.
Apart from that, I'm +1
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org