You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/02/11 22:32:25 UTC
[proposal] aiming to a naked cocoon
I think the cocoon core (aka 'naked cocoon') is defined by those classes
that don't depend on any external library but those found in /lib/core
and /lib/endorsed.
Everything else should be a block.
This allows us to create a build system where people can specify (at
compile time) what they want to include into the system they are creating.
This is just a first step toward hot-deployable COBs, but it's important
that we agree on what to factor out.
Looking into the current trunk, there are a few components that, IMO,
should be moved to blocks.
They are:
- XMLDB stuff
- XMLForm
- Deli
- XScript (what the hell is this anyway?)
anything else I'm missing that should be factored out?
Moreover, I propose to move the libraries that are block-related, into
the block space, for example FOP will end up being in
/src/block/fop/lib/fop-xxx.jar
and so on and each block will have its own build file (not the current
build system generated by an XSLT stylesheet)
This will make it easier to migrate the blocks when a better component
architecture will be in place after we release cocoon 2.1
What do you think?
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RT: Simplified build automation (was Re: [proposal] aiming to a naked cocoon)
Posted by Bill Barnhill <gw...@yahoo.com>.
[Centipede vs. Maven]
> Krysalis Centipede www.krysalis.org/centiepde/ is a
> project that does
> what Maven does in a slightly different manner, and
> is compatible OOTB with Gump and Forrest.
I've now read through the etiquette URLs and through a
portion of the Krysalis Centipede site. Haven't tried
it yet, but from the docs I like it better than Maven.
Found this out just in time too, as I am scheduled to
show developers on two other projects where I work how
to automate their release process, and now will
demonstrate Centipede rather than Maven, assuming it
tests out.
[Re: my previously proposal/rt of Maven builds]
I Will be submitting a proposal this weekend regarding
splitting all of the Cocoon sources into blocks with
each block being a separate mini-project, separately
buildable (with Centipede) and distributable. I'm
also pouring through the block documents on the Cocoon
Wiki, which I found yesterday. Obviously my idea of
par files == cob files, I didn't know.
Thanks for patience as I learn Open Source dev,
Bill Barnhill
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Bill Barnhill wrote, On 12/02/2003 13.57:
...
> If you don't like the idea, fine. There's probably a
> reason I don't know about, as just about everyone on
> this project has more experience with Open Source than
> I do. But if you don't like what I'm saying, at least
> tell me why.
It happens that nobody replies. It usually means that there is no big
interest. So if you feel you have enough compelling reasons, you can
continue on the proposed path, or else just wait.
> I'm eager to contribute and while it's
> too early to say I'm getting ignored (or kill file'd),
> I am starting to wonder.
It's too early to say you're getting ignored.
And most of all, being ignored is not necessarily a bad thing. It's a
neural stance, not positive, but not negative either.
Anyway, to get to the point, Maven-built projects do not work natively
in Gump, and this is an important point. They do generate a gump
descriptor with a simple ant buildfile, but it's not the real thing.
Krysalis Centipede www.krysalis.org/centiepde/ is a project that does
what Maven does in a slightly different manner, and is compatible OOTB
with Gump and Forrest.
I am the initial Centipede developer so I am certainly baised, but IMHO
for Cocoon it's better ATM, because it's based on Ant and fully
compatible and integrated with Gump and Forrest.
--
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
Mailing list subject lines (was: [proposal] aiming to a naked cocoon)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 12 fév 2003, à 15:05 Europe/Zurich, Bill Barnhill a écrit :
> Not my day. I thought the message the URL referred to
> was an etiquette guide for Open Source mailing lists.
See "Contribution Notes and Tips" at
http://xml.apache.org/cocoon/contrib.html, I don't know if it is
complete but it should help.
AW: is German ("Antwort") for RE: meaning that someone is replying to a
message.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Bill Barnhill <gw...@yahoo.com>.
Not my day. I thought the message the URL referred to
was an etiquette guide for Open Source mailing lists.
If someone has such a URL, and/or one explaining
posting conventions such as RT:, AW:, and the use of
Proposal: please post it to the list so myself and
other raw newbies can avoid future mistakes.
Thank you,
Bill Barnhill
--- Bertrand Delacretaz <bd...@codeconsult.ch>
wrote:
> Le Mercredi, 12 f�v 2003, � 13:57 Europe/Zurich,
> Bill Barnhill a �crit :
>
> > ...Also if I've posted in the wrong way somehow
> then
> > point me to a url with a project mailing list
> > etiquette guide, or tell me what I did wrong.
>
> Assuming you refer to
>
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104500066006401&w=2,
> I
> don't think you did anything wrong, but sometimes
> messages get lost in
> the flow...
>
> I don't know enough about the current build system's
> shortcomings to
> give meaningful advice about a possible move to
> Maven, but you might
> want to restate your intention in a message titled
> "[proposal] using
> Maven for the build system" or something like this,
> to make it more
> visible and hopefully trigger a discussion.
>
> --
> Bertrand Delacretaz (codeconsult.ch, jfor.org)
> XML, java, XSLT, Cocoon, FOP,
> mentoring/programming/teaching
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email:
> cocoon-dev-help@xml.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Bill Barnhill <gw...@yahoo.com>.
Thank you for the URL, I hadn't seen a reference to it
yet, and for the re-work suggestion.
I may do some more work on my own before re-submitting
the proposal with a first cut to demonstrate what I'm
talking about, as I've already got the source code
separated into a set of ccblock-core-* dirs and a set
of ccblock-opt-* dirs, each dir representing a
separate build component and a deliverable versioned
jar. I've started a dependency graph between the
blocks and will use that to determine dependency jars
for each block.
I also should familiarize myself more with the current
Cocoon build system.
Thank you for responding,
Bill Barnhill
--- Bertrand Delacretaz <bd...@codeconsult.ch>
wrote:
> Le Mercredi, 12 f�v 2003, � 13:57 Europe/Zurich,
> Bill Barnhill a �crit :
>
> > ...Also if I've posted in the wrong way somehow
> then
> > point me to a url with a project mailing list
> > etiquette guide, or tell me what I did wrong.
>
> Assuming you refer to
>
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104500066006401&w=2,
> I
> don't think you did anything wrong, but sometimes
> messages get lost in
> the flow...
>
> I don't know enough about the current build system's
> shortcomings to
> give meaningful advice about a possible move to
> Maven, but you might
> want to restate your intention in a message titled
> "[proposal] using
> Maven for the build system" or something like this,
> to make it more
> visible and hopefully trigger a discussion.
>
> --
> Bertrand Delacretaz (codeconsult.ch, jfor.org)
> XML, java, XSLT, Cocoon, FOP,
> mentoring/programming/teaching
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email:
> cocoon-dev-help@xml.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 12 fév 2003, à 13:57 Europe/Zurich, Bill Barnhill a écrit :
> ...Also if I've posted in the wrong way somehow then
> point me to a url with a project mailing list
> etiquette guide, or tell me what I did wrong.
Assuming you refer to
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104500066006401&w=2, I
don't think you did anything wrong, but sometimes messages get lost in
the flow...
I don't know enough about the current build system's shortcomings to
give meaningful advice about a possible move to Maven, but you might
want to restate your intention in a message titled "[proposal] using
Maven for the build system" or something like this, to make it more
visible and hopefully trigger a discussion.
--
Bertrand Delacretaz (codeconsult.ch, jfor.org)
XML, java, XSLT, Cocoon, FOP, mentoring/programming/teaching
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Bill Barnhill <gw...@yahoo.com>.
FYI Maven handles both versioning and autmatic
retrieval of dependencies. Dependencies can come from
either a local repository or a remote repository. It
also handles automatic unit testing and automatic
project site generation, including cross-referenced
source code.
If you don't like the idea, fine. There's probably a
reason I don't know about, as just about everyone on
this project has more experience with Open Source than
I do. But if you don't like what I'm saying, at least
tell me why. I'm eager to contribute and while it's
too early to say I'm getting ignored (or kill file'd),
I am starting to wonder.
Also if I've posted in the wrong way somehow then
point me to a url with a project mailing list
etiquette guide, or tell me what I did wrong.
Bill Barnhill
--- Gianugo Rabellino <gi...@apache.org> wrote:
> Nicola Ken Barozzi wrote:
>
> >> Looking into the current trunk, there are a few
> components that, IMO,
> >> should be moved to blocks.
> >>
> >> They are:
> >>
> >> - XMLDB stuff
> >>
> >> - XMLForm
> >>
> >> - Deli
> >>
> >> - XScript (what the hell is this anyway?)
> >
> >
> > +1 to all
> >
> > Gianugo IIRC had a block done for XMLDB and didn't
> commit it.
> > Gianugo?
>
> Ouch. :-) Yes, I used to have something ready, but
> it's not current
> anymore. However yes, I'll try to put something
> together in the next few
> days (not earlier than friday, most probably over
> the weekend/beginning
> next week).
>
> Ciao,
>
> --
> Gianugo Rabellino
> Pro-netics s.r.l.
> http://www.pro-netics.com
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email:
> cocoon-dev-help@xml.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Gianugo Rabellino <gi...@apache.org>.
Nicola Ken Barozzi wrote:
>> Looking into the current trunk, there are a few components that, IMO,
>> should be moved to blocks.
>>
>> They are:
>>
>> - XMLDB stuff
>>
>> - XMLForm
>>
>> - Deli
>>
>> - XScript (what the hell is this anyway?)
>
>
> +1 to all
>
> Gianugo IIRC had a block done for XMLDB and didn't commit it.
> Gianugo?
Ouch. :-) Yes, I used to have something ready, but it's not current
anymore. However yes, I'll try to put something together in the next few
days (not earlier than friday, most probably over the weekend/beginning
next week).
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 11/02/2003 22.32:
> I think the cocoon core (aka 'naked cocoon') is defined by those classes
> that don't depend on any external library but those found in /lib/core
> and /lib/endorsed.
>
> Everything else should be a block.
>
> This allows us to create a build system where people can specify (at
> compile time) what they want to include into the system they are creating.
>
> This is just a first step toward hot-deployable COBs, but it's important
> that we agree on what to factor out.
Yes, that's IIUC the current agreement.
> Looking into the current trunk, there are a few components that, IMO,
> should be moved to blocks.
>
> They are:
>
> - XMLDB stuff
>
> - XMLForm
>
> - Deli
>
> - XScript (what the hell is this anyway?)
+1 to all
Gianugo IIRC had a block done for XMLDB and didn't commit it.
Gianugo?
> anything else I'm missing that should be factored out?
The environments. The depend on other jars, like the servlet one.
I would like to see them factored out into src/environments, as
previously suggested.
Also the ServletGenerator, and most important the StreamGenerator which
depends on servlets! Remember?
The last conclusion IIRC was to add getting the inputstream in the
environment, and additional ones in a container-specific way.
Other things will become apparent later.
> Moreover, I propose to move the libraries that are block-related, into
> the block space, for example FOP will end up being in
>
> /src/block/fop/lib/fop-xxx.jar
Or put in place the downloading of jars from a repository.
> and so on and each block will have its own build file (not the current
> build system generated by an XSLT stylesheet)
That was done to ensure that we could use the same build system for Gump
and our build.
Separating builds of similar projects is a worse mess, look at
Excalibur. If we separate buildfiles it will be a mess to update them,
and from a management perspective it sucks. I'm -1 in separating the
buildfiles, but +1 in making the current system better and more cleanly
layered.
> This will make it easier to migrate the blocks when a better component
> architecture will be in place after we release cocoon 2.1
--
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] aiming to a naked cocoon
Posted by Torsten Curdt <tc...@dff.st>.
<aggree/>
> Looking into the current trunk, there are a few components that, IMO,
> should be moved to blocks.
>
> They are:
>
> - XMLDB stuff
+1
> - XMLForm
+0.5
> - Deli
+1
> - XScript (what the hell is this anyway?)
+1 (or is anything but the SOAP logicsheet using it?)
> anything else I'm missing that should be factored out?
schematron validation - should it go into the XMLForm block?
> Moreover, I propose to move the libraries that are block-related, into
> the block space, for example FOP will end up being in
>
> /src/block/fop/lib/fop-xxx.jar
I brought that up a while ago... but it was rejected because of jar
interdepencies between blocks. (What if block A needs the same jar as
block B needs? Having the jar twice in the repository feels a bit clumsy)
> and so on and each block will have its own build file (not the current
> build system generated by an XSLT stylesheet)
+0 ...don't know - keeping the builds consistent across the blocks might
be a tedious task :-/
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Vadim Gritsenko <va...@verizon.net>.
Stefano Mazzocchi wrote:
> I think the cocoon core (aka 'naked cocoon') is defined by those
> classes that don't depend on any external library but those found in
> /lib/core and /lib/endorsed.
>
> Everything else should be a block.
>
> This allows us to create a build system where people can specify (at
> compile time) what they want to include into the system they are
> creating.
>
> This is just a first step toward hot-deployable COBs, but it's
> important that we agree on what to factor out.
>
> Looking into the current trunk, there are a few components that, IMO,
> should be moved to blocks.
>
> They are:
>
> - XMLDB stuff
+1
> - XMLForm
May be it should stay in core, don't know. -0.
> - Deli
+0
> - XScript (what the hell is this anyway?)
Fancy stuff ;-)
SOAP logicsheet implemented on top of it.
I would merge XScript with session-fw, and would rename session-fw to
something better reflecting its nature.
> anything else I'm missing that should be factored out?
- XSLT. Must be pluggable. You should be able to choose either Xalan
or SAXON.
> Moreover, I propose to move the libraries that are block-related, into
> the block space, for example FOP will end up being in
>
> /src/block/fop/lib/fop-xxx.jar
+1
> and so on and each block will have its own build file (not the current
> build system generated by an XSLT stylesheet)
+0 - haven't look into current build yet.
Vadim
> This will make it easier to migrate the blocks when a better component
> architecture will be in place after we release cocoon 2.1
>
> What do you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 12/02/2003 10.59:
> Nicola Ken Barozzi wrote:
>
>> Krysalis Ruper can already get Jars from a remote repository, and it's
>> an Ant task. IF we decide that we want to keep the repository in the
>> Cocoon CSV, it can already do the above and "synch" with that.
>
> How does it work offline?
It uses the downloaded jars. If you want you can place them in the local
repository and it will pick them up / use them.
Ruper is a "Resource Updater". So it downloads-synchs the resources
(here jars) in a local repository from a remote one if they are not
already in the local one. In case it's already in the local one, none is
downloaded. RuperDepend then adds the jars to a classpath variable.
BTW, there is a proposal on Jakarta to move Ruper to Apache.
--
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] aiming to a naked cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> Krysalis Ruper can already get Jars from a remote repository, and it's
> an Ant task. IF we decide that we want to keep the repository in the
> Cocoon CSV, it can already do the above and "synch" with that.
How does it work offline?
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Bertrand Delacretaz wrote, On 12/02/2003 10.20:
> Le Mercredi, 12 fév 2003, à 10:12 Europe/Zurich, Stephan Michels a écrit :
>
>> ...
>> +1, especially moving the libs into the blocks...
>
>
> Wouldn't the duplication of jars generate a huuuuuge CVS repository?
> It's big enough already.
>
> An option might be to keep the jars in a well-structured lib/
> subdirectory and have the block's build.xml copy the required jars to
> its workspace before compiling. Easy to do with ant filtered copy task.
>
> The lib/ could then include "version directories" if different versions
> of jars are needed for different blocks (at compile time - I know it's
> going to be a problem at runtime):
>
> lib/fop/0.20.1/fop-0.20.1.jar
> lib/fop/0.20.4/fop-0.20.4.jar
> lib/fop/0.20.4/some-additional-jar-for-0.20.4.jar
>
> And then each block pulls what it needs from this tree.
Krysalis Ruper can already get Jars from a remote repository, and it's
an Ant task. IF we decide that we want to keep the repository in the
Cocoon CSV, it can already do the above and "synch" with that.
--
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] aiming to a naked cocoon
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 12 fév 2003, à 11:02 Europe/Zurich, Stefano Mazzocchi a
écrit :
> ...why duplicating jars? FOP relies on fop. Batik relies on batik and
> so on. The blocks that rely on shared jars, will have those jars
> shared in another location. Besides, how many are we talking about?...
Ok, if shared jars are not duplicated in the blocks subdirectories it
won't be a problem.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
> Le Mercredi, 12 fév 2003, à 10:12 Europe/Zurich, Stephan Michels a écrit :
>
>> ...
>> +1, especially moving the libs into the blocks...
>
>
> Wouldn't the duplication of jars generate a huuuuuge CVS repository?
> It's big enough already.
why duplicating jars? FOP relies on fop. Batik relies on batik and so
on. The blocks that rely on shared jars, will have those jars shared in
another location. Besides, how many are we talking about?
> An option might be to keep the jars in a well-structured lib/
> subdirectory and have the block's build.xml copy the required jars to
> its workspace before compiling. Easy to do with ant filtered copy task.
>
> The lib/ could then include "version directories" if different versions
> of jars are needed for different blocks (at compile time - I know it's
> going to be a problem at runtime):
>
> lib/fop/0.20.1/fop-0.20.1.jar
> lib/fop/0.20.4/fop-0.20.4.jar
> lib/fop/0.20.4/some-additional-jar-for-0.20.4.jar
>
> And then each block pulls what it needs from this tree.
nononononono, versioning is another step down the road for COBs.
People, all those problems are already solved on paper, we just need to
find a way to move incrementally from here to there.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 12 fév 2003, à 10:12 Europe/Zurich, Stephan Michels a
écrit :
> ...
> +1, especially moving the libs into the blocks...
Wouldn't the duplication of jars generate a huuuuuge CVS repository?
It's big enough already.
An option might be to keep the jars in a well-structured lib/
subdirectory and have the block's build.xml copy the required jars to
its workspace before compiling. Easy to do with ant filtered copy task.
The lib/ could then include "version directories" if different versions
of jars are needed for different blocks (at compile time - I know it's
going to be a problem at runtime):
lib/fop/0.20.1/fop-0.20.1.jar
lib/fop/0.20.4/fop-0.20.4.jar
lib/fop/0.20.4/some-additional-jar-for-0.20.4.jar
And then each block pulls what it needs from this tree.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Stephan Michels <st...@apache.org>.
On Tue, 11 Feb 2003, Stefano Mazzocchi wrote:
> I think the cocoon core (aka 'naked cocoon') is defined by those classes
> that don't depend on any external library but those found in /lib/core
> and /lib/endorsed.
>
> Everything else should be a block.
>
> This allows us to create a build system where people can specify (at
> compile time) what they want to include into the system they are creating.
>
> This is just a first step toward hot-deployable COBs, but it's important
> that we agree on what to factor out.
>
> Looking into the current trunk, there are a few components that, IMO,
> should be moved to blocks.
>
> They are:
>
> - XMLDB stuff
>
> - XMLForm
>
> - Deli
>
> - XScript (what the hell is this anyway?)
>
> anything else I'm missing that should be factored out?
>
> Moreover, I propose to move the libraries that are block-related, into
> the block space, for example FOP will end up being in
>
> /src/block/fop/lib/fop-xxx.jar
>
> and so on and each block will have its own build file (not the current
> build system generated by an XSLT stylesheet)
>
> This will make it easier to migrate the blocks when a better component
> architecture will be in place after we release cocoon 2.1
>
> What do you think?
+1, especially moving the libs into the blocks. And what about the
testcases?
Stephan.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [proposal] aiming to a naked cocoon
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 11/2/03 21:32, "Stefano Mazzocchi" <st...@apache.org> wrote:
> - Deli
+1, it relies on the assumption that certain things are in "WEB-INF" so, I
don't want to see it in there! :-)
> and so on and each block will have its own build file (not the current
> build system generated by an XSLT stylesheet)
I like this! :-) The less-trivial part was to figure out how HttpProxy could
have been built if I didn't write a build.xml! :-)
> This will make it easier to migrate the blocks when a better component
> architecture will be in place after we release cocoon 2.1
Agreed on all points...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org