cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Cocoon 2.2 - Build and deployment with Maven2
Date Mon, 12 Dec 2005 20:28:40 GMT
Reinhard Poetz skrev:
> 
> After working on the deployer and learning more about the Maven2 
> internals, I want to share 2 thougths:
> 
> 
> I've already raised the question whether it is possible to merge 
> block.xml and pom.xml. For now it's not as dependencies in pom.xml can't 
> carry all the necessary information for us. Maven 1.1 models had support 
> for properties elements, but they have been dropped in Maven 2.0 (Does 
> anybody know the reason for it?).

There is a configuration element within the plugin element where you can 
put any xml, the OSGi M2 plugin of Felix uses that, see 
http://docs.safehaus.org/display/OSGI/OSGi+Plugin+for+Maven+2.0.

> I also mentioned my concerns about 
> tieing us to closely to Maven.

I can agree about that, but I don't think it is the right time to care 
about that right now. Even if we happen to have well designed formats 
with schemes for wiring and block descriptions, they are basically 
armchair speculations. We haven't exactly checked them with a lot of 
detailed use cases, not talking about used them in practice.

So although they seem to be good designs, we don't know, experience will 
tell. So I think worrying about the final format is premature. Lets get 
something that work that we can start experimenting with.

> I think the solution for this is very simple: Our contract is block.xml.
> As soon as a Maven pom.xml can give us all the required information and 
> people use it as build descriptor, block.xml can be *automatically* 
> generated for them during the build lifecycle and they don't have to 
> care for it anymore.

I'm not such a large fan of automatically generated configuration file. 
If you need to generate it, it means that the basic desigend sucked. 
Also it means that you are going to get error messages from a file that 
you don't recognize whan you deply the block, and that is not user friendly.

> People that don't want to use Maven, have to 
> provide a hand-crafted block.xml.

IMO that is FS, we should start by making it work before we start to 
generalize the stuff. I'm all for making parts of Cocoon more reusable. 
But I don't think we should achieve that by supporting all kinds of uses 
at each abstraction level. IMO for the block and deployment level we 
support M2, period.

If there comes something much greater than M2 the next year or so it 
will do things conceptually different from M2, so trying to adapt to 
that will just complicate things.

> Going this way we are not blocked by getting the missing Maven features 
> and blocks don't get tied to Maven which would make a future replacement 
> of Maven very difficult.

As said above, we shouldn't worry to much about future replacements of 
M2. If it happen, we solve it then.


> 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.

As long as the non class resource are put into easy recognizable file 
and directories, it should be easy to filter them in our block class 
loader, for non block uses people are probably only using the Java 
classes and the facts that there are resources with the same name in 
different jars shouldn't matter.

> 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 ...

No, one jar per block is a must from usablity POV. Then in practice it 
is probable that most blocks will be class only or resource only, but 
that is a different matter.

/Daniel

Mime
View raw message