You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/08/14 16:28:17 UTC
Extending the build system for modules
Hi Team,
we recently had our thread about Cocoon organization etc. and
it's now time to recapitulate the results.
One main result is to split the core from optional things that
we from now on call modules (and not blocks!).
This is the proposed directory structure:
/src/java The core
webapp
/modules/fop/src
samples
conf
A build results in a separate jar file for the src and if
the webapp target is choosen the configuration is merged
into the webapp and if samples are choosen as well, the
samples are copied to the webapp/samples directory.
So, there remain some open problems:
a) Documentation
Where does the docs belong to? I think they should go into
the modules directory, so for examples /modules/fop/xdocs.
The build script can then automatically combine all these xdocs
sections during build, so it's in the end no difference if the
docs are residing in the module directory or not.
b) Libraries
Where are libraries for the optional components stored? A natural
fit would be directly in the modules, like /modules/fop/lib.
But I think this is not a good idea, because it could be that
two different modules require the same optional library. And
storing the jar twice is no solution.
So, here is my suggestion: Everything stays at it is. All
jars go either into lib/core or lib/optional (or lib/local).
The optional modules check these places for availability of
libraries.
And now the fun part: The build system checks which optional
libraries are really used and only copies those to the webapp!
Why not simply copying all optional jars? For example, imagine
the fop.jar in the lib/optional directory (which is there by
default) and you built Cocoon without fop module, then you don't
want the fop.jar in your app.
I think this checking can be done by the...
c) Dependency Checker
Now, we need a dependency checker like Avalon Excalibur with the
ability to specify inter-module dependencies and libraries dependencies.
If we have this dependency information it should be easy to implement
the above topic b). (Collection which optional modules where build
and which libraries they require and then copying only these libs).
Or a simpler solution is that the optional libraries are not copied
at all by the main (=core) build script but by the module build scripts.
Then automatically only the required ones are copied.
d) A deeper hierarchy for modules?
Do we want this? For example grouping similar modules, like
modules/pdf/fop
pdf/itext
webapps/session
webapps/authentication
or is only a plain hierarchy allowed?
modules/fop
modules/itext
modules/session
modules/authentication
e) A selection system
were a user can specify which modules she wants (like an interactive
build) - the default should be all modules (which can be built).
This could simply be done by an ant properties file, like
modules.pdf.fop=no
modules.pdf.itext=yes
f) Something I forgot
Comments?
Carsten
Carsten Ziegeler Chief Architect Open Source Group, S&N AG
------------------------------------------------------------------
Cocoon Consulting, Training and Projects
------------------------------------------------------------------
mailto:cziegeler@s-und-n.de http://www.s-und-n.de
http://ziegeler.bei.t-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Extending the build system for modules
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
>
> Carsten Ziegeler wrote:
>
> >Hi Team,
> >
> >we recently had our thread about Cocoon organization etc. and
> >it's now time to recapitulate the results.
> >
> >One main result is to split the core from optional things that
> >we from now on call modules (and not blocks!).
> >
> >This is the proposed directory structure:
> >
> >/src/java The core
> > webapp
> >/modules/fop/src
> > samples
> > conf
> >
>
> And every module has build script:
> /modules/fop/build.xml
>
Yes.
>
> >A build results in a separate jar file for the src and if
> >
>
> With option of creating one JAR file.
>
Hmm, ok, why not.
>
> >the webapp target is choosen the configuration is merged
> >into the webapp and if samples are choosen as well, the
> >samples are copied to the webapp/samples directory.
> >
> >So, there remain some open problems:
> >
> >a) Documentation
> >
> >Where does the docs belong to? I think they should go into
> >the modules directory, so for examples /modules/fop/xdocs.
> >
> >The build script can then automatically combine all these xdocs
> >sections during build, so it's in the end no difference if the
> >docs are residing in the module directory or not.
> >
> >
>
> I don't think it is great idea to fragment documentation. I imagine that
> you can turn on only some features, then explore documentation, see that
> you need some feature you don't have, turn this feature on, and continue
> grow usage of components this way.
>
Yes, of course - ok, I forgot to mention the detail that the docs
of the optional modules are not controlled by any dependency checks. So
if you build the docs, you get the docs for all optional modules wheter
they will appear in your web application or not.
>
> >b) Libraries
> >
> >Where are libraries for the optional components stored? A natural
> >fit would be directly in the modules, like /modules/fop/lib.
> >
>
> Agreed, seems natural.
>
>
> >But I think this is not a good idea, because it could be that
> >two different modules require the same optional library. And
> >storing the jar twice is no solution.
> >
> >So, here is my suggestion: Everything stays at it is. All
> >jars go either into lib/core or lib/optional (or lib/local).
> >The optional modules check these places for availability of
> >libraries.
> >And now the fun part: The build system checks which optional
> >libraries are really used and only copies those to the webapp!
> >
>
> module-specific build.xml will copy jars it needs to the build
> directory. Ant will not copy it more then once.
>
Yes, that's easier.
>
> >Why not simply copying all optional jars? For example, imagine
> >the fop.jar in the lib/optional directory (which is there by
> >default) and you built Cocoon without fop module, then you don't
> >want the fop.jar in your app.
> >I think this checking can be done by the...
> >
> >
>
> build.xml in module directory should be enough, and there is no need for
> dep checker (for jar dependencies). But is still needed for
> inter-modules dependencies.
>
Yup.
>
> >c) Dependency Checker
> >
> >Now, we need a dependency checker like Avalon Excalibur with the
> >ability to specify inter-module dependencies and libraries dependencies.
> >If we have this dependency information it should be easy to implement
> >the above topic b). (Collection which optional modules where build
> >and which libraries they require and then copying only these libs).
> >Or a simpler solution is that the optional libraries are not copied
> >at all by the main (=core) build script but by the module build scripts.
> >
>
> Exactly.
>
>
> >Then automatically only the required ones are copied.
> >
> >d) A deeper hierarchy for modules?
> >
> >Do we want this? For example grouping similar modules, like
> >
> >modules/pdf/fop
> > pdf/itext
> > webapps/session
> > webapps/authentication
> >
>
> No.
>
>
> >or is only a plain hierarchy allowed?
> >
> >modules/fop
> >modules/itext
> >modules/session
> >modules/authentication
> >
>
> Yes.
>
>
> >e) A selection system
> >
> >were a user can specify which modules she wants (like an interactive
> >build) - the default should be all modules (which can be built).
> >This could simply be done by an ant properties file, like
> >
> >modules.pdf.fop=no
> >modules.pdf.itext=yes
> >
>
> YESSS!!!
>
>
> >f) Something I forgot
> >
>
> What's your vision - lots of small modules or several coarse-grained? I
> think consensus was - several coarse-grained modules.
>
>
My vision is functional modules which can range from small to
coarse-grained. For example fop is for me a module which is
rather small. The flow engine is the opposite.
But I think we will have several smaller modules.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Extending the build system for modules
Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:
>Hi Team,
>
>we recently had our thread about Cocoon organization etc. and
>it's now time to recapitulate the results.
>
>One main result is to split the core from optional things that
>we from now on call modules (and not blocks!).
>
>This is the proposed directory structure:
>
>/src/java The core
> webapp
>/modules/fop/src
> samples
> conf
>
And every module has build script:
/modules/fop/build.xml
>A build results in a separate jar file for the src and if
>
With option of creating one JAR file.
>the webapp target is choosen the configuration is merged
>into the webapp and if samples are choosen as well, the
>samples are copied to the webapp/samples directory.
>
>So, there remain some open problems:
>
>a) Documentation
>
>Where does the docs belong to? I think they should go into
>the modules directory, so for examples /modules/fop/xdocs.
>
>The build script can then automatically combine all these xdocs
>sections during build, so it's in the end no difference if the
>docs are residing in the module directory or not.
>
>
I don't think it is great idea to fragment documentation. I imagine that
you can turn on only some features, then explore documentation, see that
you need some feature you don't have, turn this feature on, and continue
grow usage of components this way.
>b) Libraries
>
>Where are libraries for the optional components stored? A natural
>fit would be directly in the modules, like /modules/fop/lib.
>
Agreed, seems natural.
>But I think this is not a good idea, because it could be that
>two different modules require the same optional library. And
>storing the jar twice is no solution.
>
>So, here is my suggestion: Everything stays at it is. All
>jars go either into lib/core or lib/optional (or lib/local).
>The optional modules check these places for availability of
>libraries.
>And now the fun part: The build system checks which optional
>libraries are really used and only copies those to the webapp!
>
module-specific build.xml will copy jars it needs to the build
directory. Ant will not copy it more then once.
>Why not simply copying all optional jars? For example, imagine
>the fop.jar in the lib/optional directory (which is there by
>default) and you built Cocoon without fop module, then you don't
>want the fop.jar in your app.
>I think this checking can be done by the...
>
>
build.xml in module directory should be enough, and there is no need for
dep checker (for jar dependencies). But is still needed for
inter-modules dependencies.
>c) Dependency Checker
>
>Now, we need a dependency checker like Avalon Excalibur with the
>ability to specify inter-module dependencies and libraries dependencies.
>If we have this dependency information it should be easy to implement
>the above topic b). (Collection which optional modules where build
>and which libraries they require and then copying only these libs).
>Or a simpler solution is that the optional libraries are not copied
>at all by the main (=core) build script but by the module build scripts.
>
Exactly.
>Then automatically only the required ones are copied.
>
>d) A deeper hierarchy for modules?
>
>Do we want this? For example grouping similar modules, like
>
>modules/pdf/fop
> pdf/itext
> webapps/session
> webapps/authentication
>
No.
>or is only a plain hierarchy allowed?
>
>modules/fop
>modules/itext
>modules/session
>modules/authentication
>
Yes.
>e) A selection system
>
>were a user can specify which modules she wants (like an interactive
>build) - the default should be all modules (which can be built).
>This could simply be done by an ant properties file, like
>
>modules.pdf.fop=no
>modules.pdf.itext=yes
>
YESSS!!!
>f) Something I forgot
>
What's your vision - lots of small modules or several coarse-grained? I
think consensus was - several coarse-grained modules.
>Comments?
>
>Carsten
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Extending the build system for modules
Posted by Conal Tuohy <co...@paradise.net.nz>.
My comments on terminology:
> > > portion
implies a part taken from a whole, a "share", not a unit of *construction*
> > > element
good, but XML also has elements
> > > ingredient
my favourite! Is it just because I like food? ;-)
> > > unit
a unit is just a single thing ... too vague IMHO
> > > bit
1/8 of a byte?
> > > fragment
see portion
> > > piece
see portion
> > > item
see unit
> > > particle
To me personally, this implies one of a large number of similar parts ...
whereas they should be quite different kinds of parts.
I think "component" should be avoided because of Avalon, "package" because
of Java, and "module" because of CVS. The potential for confusion is great
and we should take special care to avoid it!
My 2c
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Extending the build system for modules
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 16.Aug.2002 -- 03:22 PM, Nicola Ken Barozzi wrote:
>
> Christian Haul wrote:
> >On 14.Aug.2002 -- 04:28 PM, Carsten Ziegeler wrote:
> >
> >>Hi Team,
> >>
> >>we recently had our thread about Cocoon organization etc. and
> >>it's now time to recapitulate the results.
> >>
> >>One main result is to split the core from optional things that
> >>we from now on call modules (and not blocks!).
> >
> >
> >Objection! We have "modules" already. This is going to cause
> >confusion.
>
> And CVS modules? ;-)
>
> >After looking in my Oxford Thesaurus, the following alternatives might
> >be suitable:
> >
> > portion
> > element
> > ingredient
> > unit
> > bit
> > fragment
> > piece
> > item
> > particle
> >
> >I like "particle" and "ingredient" best :-)
> >
> >"Oh, you need to include the XMLForm ingredient for that..."
>
> I think that they simply are Cocoon "component"s, no?
Although this is a good term, I fear the close relationship with
Avalon (-> Avalon Components) will cause confusion as well.
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
Re: Extending the build system for modules
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Christian Haul wrote:
> On 14.Aug.2002 -- 04:28 PM, Carsten Ziegeler wrote:
>
>>Hi Team,
>>
>>we recently had our thread about Cocoon organization etc. and
>>it's now time to recapitulate the results.
>>
>>One main result is to split the core from optional things that
>>we from now on call modules (and not blocks!).
>
>
> Objection! We have "modules" already. This is going to cause
> confusion.
And CVS modules? ;-)
> After looking in my Oxford Thesaurus, the following alternatives might
> be suitable:
>
> portion
> element
> ingredient
> unit
> bit
> fragment
> piece
> item
> particle
>
> I like "particle" and "ingredient" best :-)
>
> "Oh, you need to include the XMLForm ingredient for that..."
I think that they simply are Cocoon "component"s, no?
--
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: Extending the build system for modules
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 14.Aug.2002 -- 04:28 PM, Carsten Ziegeler wrote:
> Hi Team,
>
> we recently had our thread about Cocoon organization etc. and
> it's now time to recapitulate the results.
>
> One main result is to split the core from optional things that
> we from now on call modules (and not blocks!).
Objection! We have "modules" already. This is going to cause
confusion.
After looking in my Oxford Thesaurus, the following alternatives might
be suitable:
portion
element
ingredient
unit
bit
fragment
piece
item
particle
I like "particle" and "ingredient" best :-)
"Oh, you need to include the XMLForm ingredient for that..."
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
Re: Extending the build system for modules
Posted by Stephan Michels <st...@apache.org>.
On Wed, 14 Aug 2002, Carsten Ziegeler wrote:
> This is the proposed directory structure:
>
> /src/java The core
> webapp
> /modules/fop/src
> samples
> conf
Where should the Sitemap components go?
modules/fop/src/org/apache/cocoon/serializer/FOPSerializer.java
modules/bla/src/org/apache/cocoon/components/bla/BLAComponent.java
And which files should be in conf?
> So, there remain some open problems:
>
> a) Documentation
>
> Where does the docs belong to? I think they should go into
> the modules directory, so for examples /modules/fop/xdocs.
+1
> b) Libraries
>
> So, here is my suggestion: Everything stays at it is. All
> jars go either into lib/core or lib/optional (or lib/local).
> The optional modules check these places for availability of
> libraries.
+1.
> And now the fun part: The build system checks which optional
> libraries are really used and only copies those to the webapp!
Will be difficult, I think.
> c) Dependency Checker
>
> Now, we need a dependency checker like Avalon Excalibur with the
> ability to specify inter-module dependencies and libraries dependencies.
Simply we could begin with dependency checker of Avalon.
> d) A deeper hierarchy for modules?
>
> or is only a plain hierarchy allowed?
>
> modules/fop
> modules/itext
> modules/session
> modules/authentication
+1, is easier to maintain.
> e) A selection system
>
> were a user can specify which modules she wants (like an interactive
> build) - the default should be all modules (which can be built).
> This could simply be done by an ant properties file, like
>
> modules.pdf.fop=no
> modules.pdf.itext=yes
+1.
> f) Something I forgot
I saw that somebodies don't like the word 'module', perhaps 'extension'
is better?!
ext/fop/..
Stephan.5~
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org