Dominic Tootell wrote:
> 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
Dominic, you would better have watched my video before posting anything
here. ;-)
Actually, what you described above is what our RCL (Maven plug-in) does
but it does it in much convenient way with more features and multi-block
support...
The video shows how you can modify Java classes and Spring configuration
and see changes immediately but (obviously) the same applies to other
block resources like XML files, sitemaps, CSS etc.
After seeing all these e-mails complaining about some non-existing
problems of C2.2 I think it's right time to prepare "Top 10
misconceptions on Cocoon 2.2".
Something to worth consideration...
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
