Hi Grzegorz,
Apologies for cross posting; although it did finally yet me an answer
;-).
I'll take a look at the tutorial you posted. However, I have to agree
with the other's on this list. Having to go to your ide (eclipse),
re-package the block jar, and re-deploy it to the application server
(sometimes you can't use jetty - i.e. you have apache tunnelling
requests though mod_jk to tomcat for instance and need to test it);
isn't pain free Rapid Application Development, especially for a css or
xml change. This is probably one of the great things in 2.1; that
people are now struggling with in 2.2; and could actually make the
difference between upgrading and not.
Although, for a packing, maintenance, splitting up of concerns,
asynchronous development, change management control production
environments, etc; blocks are the way forward.
One of the things I was thinking of doing, is introducing a property in
the block's sitemap, which resolved to my local development directory.
i.e.:
<map:generate src="${local.block.resources}content/{1}.xml"/>
Resolves to:
<map:generate
src="file://d:/projects/development/metadata_services/cocoon/cocoon2-2-s
table-projects/Search/Homepage/src/main/resources/COB-INF/content/{1}.xm
l"/>
At at deployment/packaging time have maven filter this property in the
sitemap. i.e:
<build>
<filters>
<filter>src/main/filter/filter-${env}.properties</filter>
</filters>
<resources>
<resource>
<directory>src/main/COB-INF</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
filter-dev.properties contains:
local.block.resources=file://d:/projects/development/metadata_services/c
ocoon/cocoon2-2-stable-projects/Search/Homepage/src/main/resources/COB-I
NF/
filter-prod.properties contains <purposely blank so it can use the
block's jar versions on live):
local.block.resources=
In my local settings.xml define a profile for dev, integration, qa, prod
(see
http://sujitpal.blogspot.com/2006/10/maven2-multi-environment-filter-set
up.html for more details)
<!-- default environment -->
<properties>
<env>dev</env>
</properties>
<profiles>
<profile>
<id>dev</id>
<properties>
<env>dev</env>
</properties>
</profile>
<profile>
<id>integration</id>
<properties>
<env>integration</env>
</properties>
</profile>
....
This means I can then edit my resoures in COB-INF in eclipse
(stylesheets, css, xml, etc) and have them picked up without redeploy
etc. The only downside is; you can only work on one block at a time;
which actually really enforces the separation of concerns that Block's
represent. And perhaps more of a concern, that you can't edit the
sitemap.xmap in the block. This would still require a package and
deployment.
At the moment, the above is one half-solution to easing development; but
is a bit of a maintenance nightmare. It's also just thinking off the
top of my Head and yet to be tested. Would be nice if it was just
supported in 2.2.
I could always you the "context://" protocol:
<map:generate src="context://contents/{1}.xml"/>
Which means I can copy the contents of COB-INF manually to
webapps/<MainWebApp>, but you lose the block structure and you have to
manually copy over the COB-INF.
Maybe others have some better ideas?
/dom
-----Original Message-----
From: Grzegorz Kossakowski [mailto:[EMAIL PROTECTED]
Sent: 30 May 2008 23:17
To: users@cocoon.apache.org
Subject: Re: Cocoon 2.2 resources outside of a Block
Dominic Tootell pisze:
> Hi all,
>
> Apologies if this has been sent around before.
Hi Dominic,
Actually, if you was going to apologize for anything cross-posting to
two lists would be my first choice. ;-)
> I'm trying to figure out how I can access resources outside of a Block
> jar's, just from a directory within the Webapp:
>
> For example:
>
> I have the simple pipe line:
>
> <map:pipeline>
> <map:match pattern="static/*.shtml">
> <map:generate src="content/{1}.xml"/>
> <map:serialize type="xml"/>
> </map:match>
> </map:pipeline>
>
>
> This is part of the block called Homepage. In Homepage block, I have
> /src/main/resources/COB-INF/content/index.xml. This is all fine, when
> access the block via jetty and tomcat, the content/index.xml file is
> served from COB-INF in the Homepage.jar.
>
> However, I don't want to have to store my xslt, xml and all other
> static files in a jar. I don't want to have to re-jar the block and
> redeploy it to tomcat or start up jetty each time I make a small
> change an xslt.
>
> I want a directory content/ within my webapp, where index.xml is read
> from there. i.e.:
>
>
> webapps/Homepage
> content/index.xml <---- serve this
.xml
> file so I can make changes to it quickly and see the results
>
> WEB-INF/lib/Homepage.jar <--- don't
> look at COB-INF/content/index.xml, if the above exists.
>
>
> This is so I can do RAD development on my local development
> environment. This was possible in 2.1, but it seems in 2.2 I can't
> find any documentation on how this is possible. It seems like a
simple thing....
Your resources should be always (or almost always) stored in a block.
For RAD purposes we have created special helper plug-in[1] for Maven.
You can see it in action here:
http://people.apache.org/~gkossakowski/cocoon-tutorial-rcl-2.html
Oh gosh, I forgot that I promised to publish it officially on our site.
I'll try to do it over this weekend.
[1]
http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/1295_1_1.htm
l
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
