There is a simple way to build a cocoon.war file without the samples. We
do it all the time to build our Azure product. First, you need to have a
minimal sitemap somewhere in the source directory. I call mine
sitemap-min.xmap (it's attached) and I put it in ./src/webapp. All I did
was take the original sitemap.xmap and edit out all the crap between the
<map:pipelines> tags.
Then I added a new target to ./build.xml:
<target name="strip" depends="webapp" description="* Strips the samples
out of the war package">
<copy file="./src/webapp/sitemap-min.xmap"
tofile="./build/cocoon/webapp/sitemap.xmap"/>
<jar jarfile="./build/cocoon/cocoon-min.war"
basedir="./build/cocoon/webapp"
includes="sitemap.xmap,WEB-INF/**"/>
</target>
Optionally, you can strip out extra jars and the stuff in the classes
directory, if you really wanted to get it lean.
Regards,
Lajos
galatea.com
Geoff Howard wrote:
>
>>>Now you are asking a bit much. How is Ant to know what
>>>
>>components you
>>
>>>need.
>>>
>>It already does.
>>If you remove jars from the lib/optional dir it doesn't use
>>those features,
>>and doesn't include them in the config.
>>
>
> Right - I knew this much. I've looked at adding a condition in the
> "excludes" in prepare-src-main that could be controlled from a
> .ant.properties file to keep stuff we don't need out. For instance:
> <exclude name="**/poi/**" unless="poi.present"/>
> <exclude name="**/poi/**" if="poi.ignore"/>
> ...
>
> And set poi.ignore in the .ant.properties file in user.home so that fresh
> cvs checkouts which put all the jars back in again don't undo your changes.
>
> Unfortunately, I can't find any Ant documentation which indicates whether
> you can combine both conditions into one statement ( unless="poi.present AND
> !poi.ignore" ) which would be more maintainable. This could also be done if
> the class-exists task would take an unless argument. I've looked at
> ClassAvailableTask and Task but can't quite figure out whether this is
> already provided for or would need to be coded for explicitly.
>
> What do you think?
>
> The issue of unwanted examples still remains however. I'm guessing that the
> only thing needed for this would be a build target with fewer dependencies.
>
> Geoff
>
>
>>What is still lacking is a more user-friendly system and to
>>complete the
>>samples refactoring.
>>
>>Blocks will make all this possible without recompiling, so it
>>will even be
>>better.
>>
>>--
>>Nicola Ken Barozzi [EMAIL PROTECTED]
>> - verba volant, scripta manent -
>> (discussions get forgotten, just code remains)
>>---------------------------------------------------------------------
>>
>>
>>---------------------------------------------------------------------
>>Please check that your question has not already been answered in the
>>FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>>
>>To unsubscribe, e-mail: <[EMAIL PROTECTED]>
>>For additional commands, e-mail: <[EMAIL PROTECTED]>
>>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>
>
<?xml version="1.0"?>
<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0";>
<!--
This is the 'heart' of Cocoon. The sitemap maps URI space to
resources. It consists basicly of two parts: components and
pipelines. Pipelines are made out of components. There is such a
vast number of components available that it would be impossible to
describe them here, please refer to the accompanying
documentation. For specific components, have a look also at the
javadocs for them. Most pipelines are present to demonstrate some
feature or technique, often they are explained in more detail in
the accompanying documentation.
There are some other, less important parts that deal with
resources, views and action sets. For now, ignore them.
-->
<!-- =========================== Components ================================ -->
<map:components>
<!--
All pipelines consist at least of two components: a generator, that
produces the content and a serialiser, that delivers the content to
the client.
More precisely: a generator generates SAX events and a serializer
consumes these events and produces a character stream.
Some things to note here: each generator has a unique name, this
name is mapped to a java class, one name is declared as default
generator. In addition each generator may have additional
configurations as child elements.
Additional attributes are targeted at the component manager. The optional
"label" attribute is relevant for the view concept below. The optional
"logger" attribute defines the logging category where messages produced
by a component should go. If there's no "logger" attribute, the category
used is the one defined for the "sitemap" component in cocoon.xconf.
We have chosen in this example sitemap to use a different logging category
for each component, which allows fine-grained classification of log
messages. But you are free to use any category you want.
It is possible to have the same java class declared as different
generators by using different names. No configuration options are
shared between these instances, however.
All components follow this schema.
-->
<map:generators default="file">
<map:generator name="file" src="org.apache.cocoon.generation.FileGenerator"
label="content,data"
logger="sitemap.generator.file"
pool-max="32" pool-min="8" pool-grow="4"/>
<map:generator name="serverpages"
src="org.apache.cocoon.generation.ServerPagesGenerator"
label="content,data"
logger="sitemap.generator.serverpages"
pool-max="32" pool-min="4" pool-grow="2"/>
<map:generator name="directory"
src="org.apache.cocoon.generation.DirectoryGenerator"
logger="sitemap.generator.directory"
label="content,data"
pool-max="16" pool-min="2" pool-grow="2"/>
<map:generator name="request" src="org.apache.cocoon.generation.RequestGenerator"
logger="sitemap.generator.request"
label="data"
pool-max="16" pool-min="2" pool-grow="2"/>
<map:generator name="status" src="org.apache.cocoon.generation.StatusGenerator"
logger="sitemap.generator.status"
label="data"
pool-max="16" pool-min="2" pool-grow="2"/>
<map:generator name="imagedirectory" logger="sitemap.generator.imagedirectory"
label="content,data"
src="org.apache.cocoon.generation.ImageDirectoryGenerator"/>
<map:generator name="extractor" logger="sitemap.generator.extractor"
label="data"
src="org.apache.cocoon.generation.FragmentExtractorGenerator"/>
</map:generators>
<!--
Transformers can be placed inside the pipeline between the generator
and the serializer. You may have as many transformers as you
like. Transformers consume SAX events and emmit SAX events.
The "xslt" transformer is an example of a component with additional
configuration.
-->
<map:transformers default="xslt">
<map:transformer name="xslt" src="org.apache.cocoon.transformation.TraxTransformer"
logger="sitemap.transformer.xslt"
pool-max="32" pool-min="8" pool-grow="2">
<use-request-parameters>false</use-request-parameters>
<use-browser-capabilities-db>false</use-browser-capabilities-db>
<use-deli>false</use-deli>
</map:transformer>
<map:transformer name="log" src="org.apache.cocoon.transformation.LogTransformer"
logger="sitemap.transformer.log"
pool-max="16" pool-min="2" pool-grow="2"/>
<map:transformer name="xinclude"
src="org.apache.cocoon.transformation.XIncludeTransformer"
logger="sitemap.transformer.xinclude"
pool-max="16" pool-min="2" pool-grow="2"/>
<map:transformer name="cinclude"
src="org.apache.cocoon.transformation.CIncludeTransformer"
logger="sitemap.transformer.cinclude"
pool-max="16" pool-min="2" pool-grow="2"/>
<map:transformer name="sql" logger="sitemap.transformer.sql"
src="org.apache.cocoon.transformation.SQLTransformer"/>
<map:transformer name="extractor" logger="sitemap.transformer.extractor"
src="org.apache.cocoon.transformation.FragmentExtractorTransformer"/>
<map:transformer name="i18n" logger="sitemap.transformer.i18n"
src="org.apache.cocoon.transformation.I18nTransformer">
<catalogue-name>messages</catalogue-name>
<catalogue-location>translations</catalogue-location>
</map:transformer>
<map:transformer name="filter" logger="sitemap.transformer.filter"
src="org.apache.cocoon.transformation.FilterTransformer"/>
<map:transformer name="writeDOMsession" logger="sitemap.transformer.writeDOMsession"
src="org.apache.cocoon.transformation.WriteDOMSessionTransformer"/>
<map:transformer name="readDOMsession" logger="sitemap.transformer.readDOMsession"
src="org.apache.cocoon.transformation.ReadDOMSessionTransformer"/>
<map:transformer name="encodeURL" logger="sitemap.transformer.encodeURL"
src="org.apache.cocoon.transformation.EncodeURLTransformer"/>
</map:transformers>
<!--
Readers are an exception to the above rule that a pipline need to
have exactly one generator and exactly one serializer. Readers
circumvent the XML oriented SAX pipeline model, think of a reader
being a generator and a serializer at once thus a pipeline may not
contain any generator, transformer or serializer in addition to a
reader. They are useful for delivering binary content like images.
-->
<map:readers default="resource">
<map:reader name="resource" src="org.apache.cocoon.reading.ResourceReader"
logger="sitemap.reader.resource"
pool-max="32"/>
</map:readers>
<!--
Serializers consume SAX events and produce a character stream. Every
pipeline needs to be terminated by a serializer.
-->
<map:serializers default="html">
<map:serializer name="links" src="org.apache.cocoon.serialization.LinkSerializer"
logger="sitemap.serializer.links"/>
<map:serializer name="xml" src="org.apache.cocoon.serialization.XMLSerializer"
mime-type="text/xml"
logger="sitemap.serializer.xml"/>
<map:serializer name="html" src="org.apache.cocoon.serialization.HTMLSerializer"
mime-type="text/html"
logger="sitemap.serializer.html"
pool-max="32" pool-min="4" pool-grow="4">
<buffer-size>1024</buffer-size>
</map:serializer>
<map:serializer name="vrml" mime-type="model/vrml"
logger="sitemap.serializer.vrml"
src="org.apache.cocoon.serialization.TextSerializer"/>
<map:serializer name="wml" mime-type="text/vnd.wap.wml"
logger="sitemap.serializer.wml"
src="org.apache.cocoon.serialization.XMLSerializer">
<doctype-public>-//WAPFORUM//DTD WML 1.1//EN</doctype-public>
<doctype-system>http://www.wapforum.org/DTD/wml_1.1.xml</doctype-system>
<encoding>ASCII</encoding>
<omit-xml-declaration>yes</omit-xml-declaration>
</map:serializer>
<map:serializer name="svgxml" mime-type="image/svg-xml"
logger="sitemap.serializer.svgxml"
src="org.apache.cocoon.serialization.XMLSerializer">
<doctype-public>-//W3C//DTD SVG 20000303 Stylable//EN</doctype-public>
<doctype-system>http://www.w3.org/TR/2000/03/WD-SVG-20000303/</doctype-system>
</map:serializer>
<map:serializer name="xhtml" mime-type="text/html"
logger="sitemap.serializer.xhtml"
src="org.apache.cocoon.serialization.XMLSerializer"
pool-max="64" pool-min="2" pool-grow="2">
<doctype-public>-//W3C//DTD XHTML 1.0 Strict//EN</doctype-public>
<doctype-system>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</doctype-system>
<encoding>UTF-8</encoding>
</map:serializer>
<map:serializer name="text" mime-type="text/text"
logger="sitemap.serializer.text"
src="org.apache.cocoon.serialization.TextSerializer"/>
</map:serializers>
<!--
Matchers are executed during pipeline setup. They decide if a
pipeline fragment is used within a pipeline. Usually, the decision
is based on a match on the requested URI but matchers exist, that
match different things as well. Most often the fragment contained in
a matcher has a generator as well as a serializer. This is not a
necessity, matchers can be nested while chaining does not work.
Related concepts are selectors and actions.
Since this is important, let me repeat it: Matchers are executed
during pipeline setup.
-->
<map:matchers default="wildcard">
<map:matcher name="wildcard" src="org.apache.cocoon.matching.WildcardURIMatcher"
logger="sitemap.matcher.wildcard"/>
<map:matcher name="regexp" src="org.apache.cocoon.matching.RegexpURIMatcher"
logger="sitemap.matcher.regexp"/>
<map:matcher name="request-parameter" logger="sitemap.matcher.request-parameter"
src="org.apache.cocoon.matching.RequestParameterMatcher"/>
<map:matcher name="cookie" logger="sitemap.matcher.cookie"
src="org.apache.cocoon.matching.CookieMatcher"/>
<map:matcher name="header" logger="sitemap.matcher.header"
src="org.apache.cocoon.matching.HeaderMatcher"/>
<map:matcher name="parameter" logger="sitemap.matcher.parameter"
src="org.apache.cocoon.matching.ParameterMatcher"/>
<map:matcher name="sessionstate" logger="sitemap.matcher.sessionstate"
src="org.apache.cocoon.matching.WildcardSessionAttributeMatcher">
<attribute-name>org.apache.cocoon.SessionState</attribute-name>
</map:matcher>
<map:matcher name="next-page" logger="sitemap.matcher.next-page"
src="org.apache.cocoon.matching.WildcardRequestParameterMatcher">
<parameter-name>next-state</parameter-name>
</map:matcher>
<map:matcher name="referer-match" logger="sitemap.matcher.referer-match"
src="org.apache.cocoon.matching.WildcardHeaderMatcher">
<header-name>referer</header-name>
</map:matcher>
</map:matchers>
<!--
Selectors are executed during pipeline setup. They can be used to
determine which pipeline fragments should be combined. They are best
compared with a switch statement in java. Matchers and actions are
related concepts.
Since this is important, let me repeat it: Selectors are executed
during pipeline setup.
-->
<map:selectors default="browser">
<map:selector name="browser" logger="sitemap.selector.browser"
src="org.apache.cocoon.selection.BrowserSelector">
<!-- # NOTE: The appearance indicates the search order. This is very important
since
# some words may be found in more than one browser description. (MSIE is
# presented as "Mozilla/4.0 (Compatible; MSIE 4.01; ...")
-->
<browser name="explorer" useragent="MSIE"/>
<browser name="pocketexplorer" useragent="MSPIE"/>
<browser name="handweb" useragent="HandHTTP"/>
<browser name="avantgo" useragent="AvantGo"/>
<browser name="imode" useragent="DoCoMo"/>
<browser name="opera" useragent="Opera"/>
<browser name="lynx" useragent="Lynx"/>
<browser name="java" useragent="Java"/>
<browser name="wap" useragent="Nokia"/>
<browser name="wap" useragent="UP"/>
<browser name="wap" useragent="Wapalizer"/>
<browser name="mozilla5" useragent="Mozilla/5"/>
<browser name="mozilla5" useragent="Netscape6/"/>
<browser name="netscape" useragent="Mozilla"/>
</map:selector>
<map:selector name="request-parameter" logger="sitemap.selector.request-parameter"
src="org.apache.cocoon.selection.RequestParameterSelector">
<!-- Define now which request parameter to use; or do it later,
when using this selector, via "parameter-name" parameter.
<parameter-name>myparam</parameter-name>
-->
</map:selector>
<map:selector name="request-attribute" logger="sitemap.selector.request-attribute"
src="org.apache.cocoon.selection.RequestAttributeSelector">
<!-- <attribute-name>myparam</attribute-name> -->
</map:selector>
<map:selector name="session-attribute" logger="sitemap.selector.session-attribute"
src="org.apache.cocoon.selection.SessionAttributeSelector">
<!-- <attribute-name>myparam</attribute-name> -->
</map:selector>
<map:selector name="parameter" logger="sitemap.selector.parameter"
src="org.apache.cocoon.selection.ParameterSelector"/>
<map:selector name="header" logger="sitemap.selector.header"
src="org.apache.cocoon.selection.HeaderSelector">
<!-- <header-name>myparam</header-name> -->
</map:selector>
<map:selector name="host" logger="sitemap.selector.host"
src="org.apache.cocoon.selection.HostSelector"/>
</map:selectors>
<!--
Actions are executed during pipeline setup. Their purpose is to
execute some arbitrary complex code. They are the work horses of
pipelines. Use them to update databases, check external resources
etc. The execution may fail or complete successfully. Only if the
execution was successful, the pipeline fragment contained inside is
used within the pipeline. Related concepts are matchers and
selectors.
Since this is important, let me repeat it: Actions are executed
during pipeline setup.
-->
<map:actions>
<map:action name="add-employee" src="org.apache.cocoon.acting.DatabaseAddAction"
logger="sitemap.action.add-employee"/>
<map:action name="del-employee" src="org.apache.cocoon.acting.DatabaseDeleteAction"
logger="sitemap.action.del-employee"/>
<map:action name="upd-employee" src="org.apache.cocoon.acting.DatabaseUpdateAction"
logger="sitemap.action.upd-employee"/>
<map:action name="lang-select" logger="sitemap.action.lang-select"
src="org.apache.cocoon.acting.LangSelect"/>
<map:action name="locale" logger="sitemap.action.locale"
src="org.apache.cocoon.acting.LocaleAction"/>
<map:action name="request" logger="sitemap.action.request"
src="org.apache.cocoon.acting.RequestParamAction"/>
<map:action name="form-validator" logger="sitemap.action.form-validator"
src="org.apache.cocoon.acting.FormValidatorAction"/>
<map:action name="session-state" logger="sitemap.action.session-state"
src="org.apache.cocoon.acting.SessionStateAction"/>
<map:action name="session-isvalid" logger="sitemap.action.session-isvalid"
src="org.apache.cocoon.acting.SessionIsValidAction"/>
<map:action name="resource-exists" logger="sitemap.action.resource-exists"
src="org.apache.cocoon.acting.ResourceExistsAction"/>
<map:action name="set-header" logger="sitemap.action.set-header"
src="org.apache.cocoon.acting.HttpHeaderAction"/>
</map:actions>
</map:components>
<!-- =========================== Views =================================== -->
<!--
Views provide diffent, well, views to resources. Views are
orthogonal to pipelines. Please refer to the docs.
-->
<map:views>
<map:view name="content" from-label="content">
<map:serialize type="xml"/>
</map:view>
<map:view name="pretty-content" from-label="data">
<map:transform src="stylesheets/simple-xml2html.xsl"/>
<map:serialize type="html"/>
</map:view>
<map:view name="links" from-position="last">
<map:serialize type="links"/>
</map:view>
</map:views>
<!-- =========================== Resources ================================= -->
<!--
Resources are pipeline fragments that may be used from different
pipeline fragments. For our needs, they behave exactly like
pipelines, only that they are not accessible from outside.
Hence I will explain what's inside below for pipelines.
-->
<map:resources>
<map:resource name="slides">
<map:generate src="docs/samples/slides/slides.xml"/>
<map:transform src="stylesheets/slides/slides-navigation.xsl">
<map:parameter name="use-request-parameters" value="true"/>
<map:parameter name="use-browser-capabilities-db" value="true"/>
</map:transform>
<map:transform src="stylesheets/slides/slides-apachecon.xsl"/>
<map:serialize/>
</map:resource>
<map:resource name="dynamic-page">
<map:generate type="serverpages" src="{target}.xsp"/>
<map:transform src="stylesheets/dynamic-page2html.xsl">
<map:parameter name="view-source" value="{target}.xsp"/>
</map:transform>
<map:serialize/>
</map:resource>
<map:resource name="dynamic-page1">
<!-- print all current sitemap parameters to log -->
<map:act type="session-state">
<map:parameter name="new-state" value="{../0}" />
<!--
use the complete string that was matched as a parameter. Compare
this with the target parameter below. There the third
sitemap parameter refers to the very same string. Verfy this
by looking at the log. This irritating effect stems from
the fact, that the above map:parameter belongs conceptually
still to the parent element while all other nested tags
are, well, nested.
-->
<map:call resource="dynamic-page">
<map:parameter name="target"
value="{../target}/state{../../../0}{../../0}"/>
</map:call>
</map:act>
</map:resource>
<map:resource name="dynamic-page2">
<map:act type="session-state">
<map:parameter name="new-state" value="1"/>
<map:call resource="dynamic-page">
<map:parameter name="target" value="{../target}1"/>
</map:call>
</map:act>
</map:resource>
<map:resource name="simple-page">
<map:generate type="file" src="{target}.xml"/>
<map:transform src="stylesheets/page/simple-page2html.xsl">
<map:parameter name="view-source" value="{target}.xml"/>
</map:transform>
<map:serialize/>
</map:resource>
</map:resources>
<!-- ========================== Action sets ================================ -->
<!--
Action sets group actions together. If some actions are often used
together in pipeline fragments, it's easier to group them and refer
to the group. For more info, please see the docs.
-->
<map:action-sets>
<map:action-set name="employee">
<map:act type="add-employee" action="Add"/>
<map:act type="del-employee" action="Delete"/>
<map:act type="upd-employee" action="Update"/>
</map:action-set>
</map:action-sets>
<!-- =========================== Pipelines ================================= -->
<!--
Pipelines. The beef. Pipelines specify, how the processing of your
content is done. Usually, a pipeline consists of several fragments
that specify the generation, transformation, and serialization of
SAX events.
Processing is done in two steps:
1) The top level elements are executed in order of appearance until
one signals success. These top level elements are usually
matchers. AFAIK other components are not supported for this.
Other components are called depth-first to determine what
fragments make up the processing pipeline. When a component
fails, no nested components are called but the next component on
the same level.
2) Once it is determined which generator, which transformers and
wich serializer is used, these components are executed. During
this, the pipeline may not be changed.
You may have as many pipelines in your sitemap as you like. However,
it seems that the only purposes would be to specify different error
handlers.
-->
<map:pipelines>
</map:pipelines>
</map:sitemap>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
