Daniel Fagerstrom wrote:
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.
yes I know this but it doesn't really help as the information gets scattered
over different places which isn't really better than having two files ...
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.
ok
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.
Ok, I will come up with a first version of the deployer and than we continue our
discussions based on code.
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.
ok, wasn't sure about this.
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.
More details about Jorg's and my findings in a separate mail.
Thanks!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
