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
