Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Reinhard Poetz wrote:
A second thought: As outlined in one of my previous mails, a Cocoon
block will become a valid jar file, for example with following content:
ROOT
+-- block.xml
+-- pom.xml
+-- sitemap.xmap
+-- org
| +--myProject
| +-- MyJavaflowController.class
+-- app
+-- formTemplate.jx
+-- image.gif
+-- formDefinition.xml
At deployment this file is extracted into e.g.
/WEB-INF/blocks/0000001. I wonder if this can cause problems as a
lot of resources become part of the classpath but only
MyJavaflowController.class should be.
If it is a problem we could provide two artifacts, one JAR file
containing the classes and one that contains the resources which is
extracted into /WEB-INF/blocks/0000001 but not added to the
classpath. ... but this makes the build and the deployment more
complicated for our users ...
I skyped with Jorg about this and we found a (possible) solution.
When a block
is created, it should get following structure in our opinion:
ROOT
+-- org
| +-- myProject
| +-- MyJavaFlowController.class
+-- META-INF
| +-- org
| +-- myProject
| +-- pom.xml
| +-- block.xml
+-- COCOON-APP
+-- sitemap.xmap
+-- formTemplate.jx
+-- ...
Why is org.myProject needed under META-INF?
Bydefault, maven stores this information there. I guess this is for
dependency tracking.
Best Regards,
Antonio Gallardo.
