Re: Cocoon 2.2 - Build and deployment with Maven2
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
Ah, very insightful!
This would be a good start.
But with this interim solutions we have to be aware of the fact, that
the block has to define all potential XSL:FO implementations as
optional dependencies. This might not be the possible in every case.
Think about choosing some commercial XSL:FO implementation to be used
for all blocks wich depend on the XSL:FO contract or providing your
own implementation for another contract.
Why is just adding the block dependency that I *want* to use not
enough? The only issue that I can think of is that it doesn't prevent
the developer from using implementation internal classes. Right?
For blocks and deployments which are fully under the control of the
developer this is right.
The point I'm trying to make has something to do with SoC and more
specific with the role of the deployer:
The block A, which uses an XSL:FO processor should IMHO only depend on
the XSL:FO contract (API) since it can not assume which concrete
implementation will be used in a certain deployment scenario.
An application developer which uses block A (developed by somebody else)
now wants to use a certain XSL:FO implementation for his application. It
would not make sense that this application developer has to modify the
pom of block A just to put his prefered XSL:FO implementation to the
list of dependencies.
In short:
Isn't it enough to let the pom of block A just depend on the XSL:FO
contract?
That's one of the differnces between block requirements and Maven2 dependencies.
Maven2 dependencies are concrete implementations and block requirement always
point to a contract which have to be implemented by a block.
What we _could_ do is having real artifacts for our contracts and not just URIs.
Well, I think that future experiments with a working deployment system will
help us to understand better what we really need. For now I will implement it
the way it was designed a long time ago (based on the block.xml and it's IMO
well-designed features) and we can use this as starting point for further
discussions.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Cocoon 2.2 - Build and deployment with Maven2
Reinhard Poetz schrieb: That's one of the differnces between block requirements and Maven2 dependencies. Maven2 dependencies are concrete implementations and block requirement always point to a contract which have to be implemented by a block. What we _could_ do is having real artifacts for our contracts and not just URIs. Well, I think that future experiments with a working deployment system will help us to understand better what we really need. For now I will implement it the way it was designed a long time ago (based on the block.xml and it's IMO well-designed features) and we can use this as starting point for further discussions. Ah, I see. I wasn't aware, that the contracts weren't meant to be real maven artifacts. So what you proposed looks like a good way for me and we can continue the discussions when an implementation is available. Andreas
Re: Cocoon 2.2 - Build and deployment with Maven2
Jörg Schaible wrote: But how would it be possible to say that the samples block depends on any implementation which implements a certain API, like the roles are used in Cocoon today? For example, my-block-samples-block needs an XSL:FO processor but does not depend on a concrete implementation (e.g. Xalan). I don't think maven allows this at the moment. It's a valid usecase though. You can define the dependency as optional (although this is partly still buggy). Good point! I forgot all about this property. I asked around on #maven about this. The general opinion there is that if you have a project that can use multiple implementations of a library, you should split up the project and make multiple poms for this. Idea is that all optional libraries need to be redeclared by the user using the pom they are declared in, not very user friendly. So in effect this could be realized in the scheme ./api pom.xml ./implBase pom.xml ./implA pom.xml ./implB pom.xml Both implA and implB include implBase as dependency and additionally declare the implementation for the optional libraries. That way our users would only need to point to implA or implB and can do so without pom editing. Regards Jorg
Re: Cocoon 2.2 - Build and deployment with Maven2
Andreas Hochsteger wrote:
Ah, very insightful!
This would be a good start.
But with this interim solutions we have to be aware of the fact, that
the block has to define all potential XSL:FO implementations as optional
dependencies. This might not be the possible in every case.
Think about choosing some commercial XSL:FO implementation to be used
for all blocks wich depend on the XSL:FO contract or providing your own
implementation for another contract.
Why is just adding the block dependency that I *want* to use not enough? The
only issue that I can think of is that it doesn't prevent the developer from
using implementation internal classes. Right?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Cocoon 2.2 - Build and deployment with Maven2
Ah, very insightful! This would be a good start. But with this interim solutions we have to be aware of the fact, that the block has to define all potential XSL:FO implementations as optional dependencies. This might not be the possible in every case. Think about choosing some commercial XSL:FO implementation to be used for all blocks wich depend on the XSL:FO contract or providing your own implementation for another contract. Andreas Reinhard Poetz schrieb: Splitting up the directory structure in our code repository into api, impl and samples has the purpose of making it easier for us the get three artifacts out of one block: - two block jars (the block itself, samples) - one jar that is not a block (the API jar) and to make IDE integration and the development of the three mini-projects simpler. If my-block-samples-block needs a XSL:FO processor the block.xml has following notation: block xmlns=http://apache.org/cocoon/blocks/cob/1.0; id=http://cocoon.apache.org/blocks/my-block-samples/1.0; requirements requires interface=http://cocoon.apache.org/contract/xsl-fo/1.0; name=xsl-fo default=http://cocoon.apache.org/blocks/fop/1.0.2; / requires interface=http://cocoon.apache.org/contract/my-block/2.0; name=my-block default=http://cocoon.apache.org/blocks/my-block/2.7.14; / /requirements /block In /my-block/samples/pom.xml you will find following entries: dependencies dependency groupIdorg.apache.cocoon.fop/groupId artifactIdfop/artifactId version1.0.2/version /dependency dependency groupIdorg.apache.cocoon.my-block/groupId artifactIdmy-block/artifactId version2.7.14/version /dependency /dependencies (I'm not sure about the details, e.g. what's the correct name for all the IDs ... but I will hopefully get more insight during the development of the deployer) As you can see here, we have the problem that block.xml and pom.xml describe similar things and should be unified but ATM I don't see a good way for it except that Maven poms give us the possibility to add properties to the dependencies. As this is not possible now I will start with using block.xml and when it's possible we can think how we can merge it with pom.xml.
Re: Cocoon 2.2 - Build and deployment with Maven2
Reinhard Poetz schrieb: Andreas Hochsteger wrote: Ah, very insightful! This would be a good start. But with this interim solutions we have to be aware of the fact, that the block has to define all potential XSL:FO implementations as optional dependencies. This might not be the possible in every case. Think about choosing some commercial XSL:FO implementation to be used for all blocks wich depend on the XSL:FO contract or providing your own implementation for another contract. Why is just adding the block dependency that I *want* to use not enough? The only issue that I can think of is that it doesn't prevent the developer from using implementation internal classes. Right? For blocks and deployments which are fully under the control of the developer this is right. The point I'm trying to make has something to do with SoC and more specific with the role of the deployer: The block A, which uses an XSL:FO processor should IMHO only depend on the XSL:FO contract (API) since it can not assume which concrete implementation will be used in a certain deployment scenario. An application developer which uses block A (developed by somebody else) now wants to use a certain XSL:FO implementation for his application. It would not make sense that this application developer has to modify the pom of block A just to put his prefered XSL:FO implementation to the list of dependencies. In short: Isn't it enough to let the pom of block A just depend on the XSL:FO contract? Cheers, Andreas
Re: Cocoon 2.2 - Build and deployment with Maven2
Jorg Heymans wrote: Andreas Hochsteger wrote: But how would it be possible to say that the samples block depends on any implementation which implements a certain API, like the roles are used in Cocoon today? For example, my-block-samples-block needs an XSL:FO processor but does not depend on a concrete implementation (e.g. Xalan). I don't think maven allows this at the moment. It's a valid usecase though. You can define the dependency as optional (although this is partly still buggy). - Jörg
Re: Cocoon 2.2 - Build and deployment with Maven2
Jorg Heymans schrieb: Reinhard Poetz wrote: We also discussed the structure of projects as proposed by Jorg some time ago (http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113102875010469w=2). /my-block pom.xml /api pom.xml /impl pom.xml /samples pom.xml The (usual) dependencies are: - impl depends on api (normal JAR dependency) - the sample block depends on the impl block Out of this we will get two blocks: - my-block-block Don't you mean my-block-impl-block ? The main thing here is that we feel that api is not a real block (ie it won't have a block descriptor). impl is the thing people can actually use when building webapps. samples is just an example of how the impl block can be used in a webapp ie it demonstrates the blocks' capabilities. It is a real block on its own and has a block dependency (not a normal jar dependency) on impl. But how would it be possible to say that the samples block depends on any implementation which implements a certain API, like the roles are used in Cocoon today? For example, my-block-samples-block needs an XSL:FO processor but does not depend on a concrete implementation (e.g. Xalan). Taken your example then my-block-samples-block would depend on my-block-block (assuming it would contain the API) - or am I missing something? Jorg Andreas
Re: Cocoon 2.2 - Build and deployment with Maven2
Andreas Hochsteger wrote: But how would it be possible to say that the samples block depends on any implementation which implements a certain API, like the roles are used in Cocoon today? For example, my-block-samples-block needs an XSL:FO processor but does not depend on a concrete implementation (e.g. Xalan). I don't think maven allows this at the moment. It's a valid usecase though. Jorg
Re: Cocoon 2.2 - Build and deployment with Maven2
Andreas Hochsteger wrote:
Jorg Heymans schrieb:
Reinhard Poetz wrote:
We also discussed the structure of projects as proposed by Jorg some
time ago
(http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113102875010469w=2).
/my-block
pom.xml
/api
pom.xml
/impl
pom.xml
/samples
pom.xml
The (usual) dependencies are:
- impl depends on api (normal JAR dependency)
- the sample block depends on the impl block
Out of this we will get two blocks:
- my-block-block
Don't you mean my-block-impl-block ?
The main thing here is that we feel that api is not a real block (ie
it won't have a block descriptor).
impl is the thing people can actually use when building webapps.
samples is just an example of how the impl block can be used in a
webapp ie it demonstrates the blocks' capabilities. It is a real block
on its own and has a block dependency (not a normal jar dependency) on
impl.
But how would it be possible to say that the samples block depends on
any implementation which implements a certain API, like the roles are
used in Cocoon today?
For example, my-block-samples-block needs an XSL:FO processor but does
not depend on a concrete implementation (e.g. Xalan).
Taken your example then my-block-samples-block would depend on
my-block-block (assuming it would contain the API) - or am I missing
something?
yes :-)
Splitting up the directory structure in our code repository into api, impl and
samples has the purpose of making it easier for us the get three artifacts out
of one block:
- two block jars (the block itself, samples)
- one jar that is not a block (the API jar)
and to make IDE integration and the development of the three mini-projects
simpler.
If my-block-samples-block needs a XSL:FO processor the block.xml has following
notation:
block xmlns=http://apache.org/cocoon/blocks/cob/1.0;
id=http://cocoon.apache.org/blocks/my-block-samples/1.0;
requirements
requires
interface=http://cocoon.apache.org/contract/xsl-fo/1.0;
name=xsl-fo
default=http://cocoon.apache.org/blocks/fop/1.0.2;
/
requires
interface=http://cocoon.apache.org/contract/my-block/2.0;
name=my-block
default=http://cocoon.apache.org/blocks/my-block/2.7.14;
/
/requirements
/block
In /my-block/samples/pom.xml you will find following entries:
dependencies
dependency
groupIdorg.apache.cocoon.fop/groupId
artifactIdfop/artifactId
version1.0.2/version
/dependency
dependency
groupIdorg.apache.cocoon.my-block/groupId
artifactIdmy-block/artifactId
version2.7.14/version
/dependency
/dependencies
(I'm not sure about the details, e.g. what's the correct name for all the IDs
... but I will hopefully get more insight during the development of the deployer)
As you can see here, we have the problem that block.xml and pom.xml describe
similar things and should be unified but ATM I don't see a good way for it
except that Maven poms give us the possibility to add properties to the
dependencies. As this is not possible now I will start with using block.xml and
when it's possible we can think how we can merge it with pom.xml.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Cocoon 2.2 - Build and deployment with Maven2
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/001. 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/001 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
Re: Cocoon 2.2 - Build and deployment with Maven2
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/001.
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/001 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
+-- ...
This way, the only used namespace is COCOON-APP and if necessary we may find
some way to make the resources under it invisible for the classloader.
AFAWU it should be straight forward package the blocks as Maven provides more
than one option to solve this.
- o -
We also discussed the structure of projects as proposed by Jorg some time ago
(http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113102875010469w=2).
/my-block
pom.xml
/api
pom.xml
/impl
pom.xml
/samples
pom.xml
The (usual) dependencies are:
- impl depends on api (normal JAR dependency)
- the sample block depends on the impl block
Out of this we will get two blocks:
- my-block-block
- my-block-samples-block
... which can be used by the block deployer.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Cocoon 2.2 - Build and deployment with Maven2
Reinhard Poetz wrote: We also discussed the structure of projects as proposed by Jorg some time ago (http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113102875010469w=2). /my-block pom.xml /api pom.xml /impl pom.xml /samples pom.xml The (usual) dependencies are: - impl depends on api (normal JAR dependency) - the sample block depends on the impl block Out of this we will get two blocks: - my-block-block Don't you mean my-block-impl-block ? The main thing here is that we feel that api is not a real block (ie it won't have a block descriptor). impl is the thing people can actually use when building webapps. samples is just an example of how the impl block can be used in a webapp ie it demonstrates the blocks' capabilities. It is a real block on its own and has a block dependency (not a normal jar dependency) on impl. Jorg
Re: Cocoon 2.2 - Build and deployment with Maven2
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/001. 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/001 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? /Daniel
Re: Cocoon 2.2 - Build and deployment with Maven2
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/001. 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/001 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.
Re: Cocoon 2.2 - Build and deployment with Maven2
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?). I also mentioned my concerns about tieing us to closely to Maven.
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. People
that don't want to use Maven, have to provide a hand-crafted block.xml.
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.
- o -
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/001. 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/001 but not added to the classpath. ... but this makes the
build and the deployment more complicated for our users ...
Ideas/opinions?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Cocoon 2.2 - Build and deployment with Maven2
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/001. 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/001 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
Re: Cocoon 2.2 - Build and deployment with Maven2
Reinhard Poetz wrote: Today, Jorg and I had a long chat about this. In short, we failed to find a solution that works with Maven 2 as it is today. The problem is that Cocoon block requirements have a different purpose than Maven 2 dependencies. Cocoon block requirements desribe what a block needs to run while Maven 2 dependencies describe what a project needs to compile. Additionally we want to describe our dependencies as contracts and not as direct dependencies to a JAR. how is that different? I would guess this just means your 'contract' is available in a separate jar/artifact from your implementation? is that a constraint that is hard to keep up with? -marc= (only taking first steps in the maven/block work, so seeking no more then understanding) -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Cocoon 2.2 - Build and deployment with Maven2
Marc Portier wrote:
Reinhard Poetz wrote:
Today, Jorg and I had a long chat about this. In short, we failed to
find a solution that works with Maven 2 as it is today. The problem is
that Cocoon block requirements have a different purpose than Maven 2
dependencies. Cocoon block requirements desribe what a block needs to
run while Maven 2 dependencies describe what a project needs to compile.
Additionally we want to describe our dependencies as contracts and not
as direct dependencies to a JAR.
how is that different?
well, in Cocoon we don't have direct dependencies between blocks. A Cocoon
block only requires other blocks that implement a certain contract. Have a look
at this example:
block xmlns=http://apache.org/cocoon/blocks/cob/1.0;
id=http://cocoon.apache.org/blocks/anyblock/1.0;
requirements
requires
interface=http://cocoon.apache.org/contracts/portal/1.0;
name=portal
default=http://cocoon.apache.org/blocks/portal/1.0.2;
/
/requirements
/block
Here the block http://cocoon.apache.org/blocks/anyblock/1.0; requires a block
that implements the contract http://cocoon.apache.org/contract/portal/1.0;.
One block that obiously implements this contract is
http://cocoon.apache.org/blocks/portal/1.0.2;.
Compare this with a Maven project descriptor. There we say which *concrete
dependencies (jars, blocks) one project has. In this special case this is a
block dependency.
I would guess this just means your 'contract' is available in a separate
jar/artifact from your implementation?
I'm not sure if I understand completly what you're asking/suggesting here. Do
you mean that we should make the contract a JAR dependency too?
is that a constraint that is hard to keep up with?
I'm not sure. I have to think more about it. In any case, having the contracts
as JAR dependencies is an interesting thought!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Cocoon 2.2 - Build and deployment with Maven2
Jorg Heymans wrote:
Reinhard Poetz wrote:
What do you think about moving block dependecy handling from
block.xml to pom.xml? It means reduced flexibilty as block
dependencies becomes
IIUC, the dependency handling discussed here is the deploy-time
dependency handling, thus only relevant for the deployer?
In that case if we have something like
dependency
artifactIdmyBlock/artifactId
groupIdorg.apache.cocoon.blocks/groupId
version1.2alpha/version
/dependency
then the deployer could check for all declared dependencies with groupId
org.apache.cocoon.blocks and treat them as block dependencies. There
are other ways to distinguish between dependencies in maven, but this
would be the easiest initially i think.
dependencies we can add it later. There would be a need to give the
dependencies POM unique ids that can be used in the block protocol and
not sure on how to best solve this, i'll give it some thought.
Today, Jorg and I had a long chat about this. In short, we failed to find a
solution that works with Maven 2 as it is today. The problem is that Cocoon
block requirements have a different purpose than Maven 2 dependencies. Cocoon
block requirements desribe what a block needs to run while Maven 2 dependencies
describe what a project needs to compile. Additionally we want to describe our
dependencies as contracts and not as direct dependencies to a JAR.
In our opinion there are two possible options:
A) We talk with the Maven guys whether there is some way to add our Cocoon
specific information to a dependency description.
B) We use block.xml.
I'm in favour of B) as
- we don't bend Maven to something which it wasn't created for
- we shouldn't force everybody to use Maven just as we are so
exited about it
- it doesn't tie Cocoon unnecessarily to Maven
Of course we can provide a Maven goal that checks if block.xml and pom.xml
describe the same dependencies.
Maybe some of you guys find some time to talk about this with the Maven folks at
the ApacheCon. Maybe they see a simple solution for our problem.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Cocoon 2.2 - Build and deployment with Maven2
Reinhard Poetz wrote: Jorg Heymans wrote: Reinhard Poetz wrote: What do you think about moving block dependecy handling from block.xml to pom.xml? It means reduced flexibilty as block dependencies becomes IIUC, the dependency handling discussed here is the deploy-time dependency handling, thus only relevant for the deployer? In that case if we have something like dependency artifactIdmyBlock/artifactId groupIdorg.apache.cocoon.blocks/groupId version1.2alpha/version /dependency then the deployer could check for all declared dependencies with groupId org.apache.cocoon.blocks and treat them as block dependencies. There are other ways to distinguish between dependencies in maven, but this would be the easiest initially i think. dependencies we can add it later. There would be a need to give the dependencies POM unique ids that can be used in the block protocol and not sure on how to best solve this, i'll give it some thought. Today, Jorg and I had a long chat about this. In short, we failed to find a solution that works with Maven 2 as it is today. The problem is that Cocoon block requirements have a different purpose than Maven 2 dependencies. Cocoon block requirements desribe what a block needs to run while Maven 2 dependencies describe what a project needs to compile. Can't you use scoperuntime/scope? Additionally we want to describe our dependencies as contracts and not as direct dependencies to a JAR. Yes and no ;) My idea was to start simple with only jar dependencies which solves our current needs and is simple. Then we could add indirect dependencies later when we need it. In our opinion there are two possible options: A) We talk with the Maven guys whether there is some way to add our Cocoon specific information to a dependency description. B) We use block.xml. I'm in favour of B) as - we don't bend Maven to something which it wasn't created for - we shouldn't force everybody to use Maven just as we are so exited about it - it doesn't tie Cocoon unnecessarily to Maven Simplicity vs flexibillity ;) Anyway, the important thing is to get something that works ASAP, and the block code is designed for B) and you seem to think that it is easier with M2, so go ahead with B). We can impove usabillity with various conventions at a later stage. Of course we can provide a Maven goal that checks if block.xml and pom.xml describe the same dependencies. Maybe some of you guys find some time to talk about this with the Maven folks at the ApacheCon. Maybe they see a simple solution for our problem. There have been a long discussion on Felix-dev about how to use M2 (which is jar based) with OSGi (which is contract based, although at the package level) in the best way. Both people from Maven and Eclipse have been involved. We can use what they come up with later, and I will try to discuss the problem with them at ApacheCon. /Daniel
Re: Cocoon 2.2 - Build and deployment with Maven2
Daniel Fagerstrom wrote:
Simplicity vs flexibillity ;)
Anyway, the important thing is to get something that works ASAP, and the
block code is designed for B) and you seem to think that it is easier
with M2, so go ahead with B). We can impove usabillity with various
conventions at a later stage.
yes, for now I think it is simpler (and more flexible) with B)
thanks for your feedback!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Cocoon 2.2 - Build and deployment with Maven2
BURGHARD Éric wrote: Daniel Fagerstrom wrote: What do you think about moving block dependecy handling from block.xml to pom.xml? It means reduced flexibilty as block dependencies becomes direct instead of indirect as in the current schema. OTH it reduce complexity and fullfills our current use cases. If we need indirect dependencies we can add it later. There would be a need to give the dependencies POM unique ids that can be used in the block protocol and we also need a way to be able to mark a dependency as extension, any idea if this would be possible? Hmm, while that would be nice at some point I think that it currently would be enough to have a block aware variant of the war pluggin. That fetch and install all needed blocks in the webapp one i developing. Maybe wiring.xml could even be expressed as a POM for this pluggin? 2 wonderfull ideas ! Before you wrote that, daniel, i was very frightened by the new 'hot' block framework because of * the new kind of descriptor, The current design involves a pom.xml and a block.xml (and a Manifest.mf whith OSGi) for each block and a wiring.xml globally. This is certainly to much, some merging of configuration files is needed on the block level. How to do this is an open question. With Jorg's and Reinhard's ongoing work and the block mechanism in place we hopefully will be able to real blockify a number of blocks in trunk RSN. Then hopefully the community can take some interst in such mundane questions as configuration file formats ;) * all the new jar introduced (osgi, knopflerfish: even if don't know if there are really related to this, it's part of the cocoon new face) They will be removed from the 2.2 releases and only be part of 3.0. And it is not as bad as it might seem, framework, log and http which together is less than 350kB is needed for actually running serving webpages with Cocoon in OSGi mode. The rest (rather small as well) are for the Knopflerfish OSGi runtime console. * the fact that blocks are not regular jar (even if i don't know what it means it's frightening for a java developer :-) Bundles are regular jars that happen to include some extra fields in the manifest. Blocks will be as well. After 2 years using cocoon i just can't explain clearly how to build an application over cocoon-core and a few blocks staticaly. You should do something with block management for sure, but IMHO hot deployment should not be a priority. It just seems like adding an unecessary new layer of complexity (i know that you think this is simpler :-). No I don't think complete hot deployment is simple. Block that are leaves in the dependency chain and that not are connected to complicated external things like DBs, is not that complicated to get hot deployable. And having hot deployable user blocks will make wonders for development. Think about having your Cocoon (which will be a couple of bundles) deployed within Eclipse while you develop your own block with the pluggin development mode in Eclipse. But as you suggest hot deployment is far from the main priority. First we need to get everything working statically and even without OSGi. ... So please (poor user request) define first a clean static build process with well defined dependencies (concern 99% of users) before thinking of hot deployment stuff. This build process could be defined for cocoon 2.1.9 without redefining the block management nor the jar stucture. It would give new users the possibility to fire a new cocoon project in 30s (how lucky ! it took me several month just to know how to build a minimal cocoon webapp). Hmm ... might there be simpler things we could do than redefining ourself completely, to attract users? Could a first step be as easy as reducing the startup phase of Cocoon from 3 months to ... say 1 month ;) Or maybe to a few minutes. The ongoing M2 and blocks work will get us there. /Daniel
Re: Cocoon 2.2 - Build and deployment with Maven2
Daniel Fagerstrom wrote: There have been a long discussion on Felix-dev about how to use M2 (which is jar based) with OSGi (which is contract based, although at the package level) in the best way. Both people from Maven and Eclipse have been involved. We can use what they come up with later, and I will try to discuss the problem with them at ApacheCon. Yes, Jason Vanzyl asked me if we could find some time during ApacheCon to discuss the cocoon maven integration issues. Unfortunately i won't be attending, so it would be great if you and anyone else remotely interested in maven (Jason's own words!) could get in touch with him there for a chat. Regards Jorg
Re: Cocoon 2.2 - Build and deployment with Maven2
Jorg Heymans wrote: Daniel Fagerstrom wrote: There have been a long discussion on Felix-dev about how to use M2 (which is jar based) with OSGi (which is contract based, although at the package level) in the best way. Both people from Maven and Eclipse have been involved. We can use what they come up with later, and I will try to discuss the problem with them at ApacheCon. Yes, Jason Vanzyl asked me if we could find some time during ApacheCon to discuss the cocoon maven integration issues. Unfortunately i won't be attending, so it would be great if you and anyone else remotely interested in maven (Jason's own words!) could get in touch with him there for a chat. I'm far over the stage of remote interest, I can't wait until we have switched completely to M2. And Carsten might be interested in discussing Maven as well ;) /Daniel
Re: Cocoon 2.2 - Build and deployment with Maven2
Daniel Fagerstrom wrote: Jorg Heymans wrote: Daniel Fagerstrom wrote: There have been a long discussion on Felix-dev about how to use M2 (which is jar based) with OSGi (which is contract based, although at the package level) in the best way. Both people from Maven and Eclipse have been involved. We can use what they come up with later, and I will try to discuss the problem with them at ApacheCon. Yes, Jason Vanzyl asked me if we could find some time during ApacheCon to discuss the cocoon maven integration issues. Unfortunately i won't be attending, so it would be great if you and anyone else remotely interested in maven (Jason's own words!) could get in touch with him there for a chat. I'm far over the stage of remote interest, I can't wait until we have switched completely to M2. And Carsten might be interested in discussing Maven as well ;) I plan to be in on it too. Upayavira
Re: Cocoon 2.2 - Build and deployment with Maven2
I'm far over the stage of remote interest, I can't wait until we have switched completely to M2. And Carsten might be interested in discussing Maven as well ;) Yupp, definitly :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Cocoon 2.2 - Build and deployment with Maven2
Reinhard Poetz wrote: What do you think about moving block dependecy handling from block.xml to pom.xml? It means reduced flexibilty as block dependencies becomes IIUC, the dependency handling discussed here is the deploy-time dependency handling, thus only relevant for the deployer? In that case if we have something like dependency artifactIdmyBlock/artifactId groupIdorg.apache.cocoon.blocks/groupId version1.2alpha/version /dependency then the deployer could check for all declared dependencies with groupId org.apache.cocoon.blocks and treat them as block dependencies. There are other ways to distinguish between dependencies in maven, but this would be the easiest initially i think. dependencies we can add it later. There would be a need to give the dependencies POM unique ids that can be used in the block protocol and not sure on how to best solve this, i'll give it some thought. we also need a way to be able to mark a dependency as extension, any idea if this would be possible? parent groupIdorg.apache.cocoon.blocks/groupId artifactIdmyParentBlock/artifactId version0.5.6/version /parent i'ld say declare a parent section in pom.xml that points to the parent. This information is again only relevant to the deployer right ? (because it needs to make sure the parent block is deployed as well) The deployer could use the maven api to find out the block parent (recursively?) Regards Jorg
Re: Cocoon 2.2 - Build and deployment with Maven2
Daniel Fagerstrom wrote: What do you think about moving block dependecy handling from block.xml to pom.xml? It means reduced flexibilty as block dependencies becomes direct instead of indirect as in the current schema. OTH it reduce complexity and fullfills our current use cases. If we need indirect dependencies we can add it later. There would be a need to give the dependencies POM unique ids that can be used in the block protocol and we also need a way to be able to mark a dependency as extension, any idea if this would be possible? Hmm, while that would be nice at some point I think that it currently would be enough to have a block aware variant of the war pluggin. That fetch and install all needed blocks in the webapp one i developing. Maybe wiring.xml could even be expressed as a POM for this pluggin? 2 wonderfull ideas ! Before you wrote that, daniel, i was very frightened by the new 'hot' block framework because of * the new kind of descriptor, * all the new jar introduced (osgi, knopflerfish: even if don't know if there are really related to this, it's part of the cocoon new face) * the fact that blocks are not regular jar (even if i don't know what it means it's frightening for a java developer :-) After 2 years using cocoon i just can't explain clearly how to build an application over cocoon-core and a few blocks staticaly. You should do something with block management for sure, but IMHO hot deployment should not be a priority. It just seems like adding an unecessary new layer of complexity (i know that you think this is simpler :-). Since a few week i'm just about to see the end of the tunnel thanks to maven 2 and its archetypes, and i'm full of hope again because it's simple and clear. My application is now constructed by maven, all the jar, ant, jelly, tools disappear from my repository. It just a lot easier to synchonise my app my a new cocoon snapshot. It took me only a few days to understand the process and even contribute to maven. Just to tell you that i felt very far away from the vertical learning slope of cocoon. I'm quite fed up with cocoon and it's complexity, and a few people in my team already drop it. It's just sad because everybody gave a lot of time on this. Maven 2.0 is the next big thing in java tools. And you took a really good choice here. It would be a pain if users, used to maven (and they will be more and more), had to learn another dependency management system. IMHO, the reason of this complexity is that cocoon has always been thought in terms of flexibility instead of usability and simplicity, constraints instead of conventions. I really think that the kind of refactor that occurs between maven 1 and 2 is a model of what has to be done for cocoon. So please (poor user request) define first a clean static build process with well defined dependencies (concern 99% of users) before thinking of hot deployment stuff. This build process could be defined for cocoon 2.1.9 without redefining the block management nor the jar stucture. It would give new users the possibility to fire a new cocoon project in 30s (how lucky ! it took me several month just to know how to build a minimal cocoon webapp). My 0.02€ Regards.
Re: Cocoon 2.2 - Build and deployment with Maven2
Jorg Heymans wrote:
Reinhard Poetz wrote:
What do you think about moving block dependecy handling from
block.xml to pom.xml? It means reduced flexibilty as block
dependencies becomes
IIUC, the dependency handling discussed here is the deploy-time
dependency handling, thus only relevant for the deployer?
In that case if we have something like
dependency
artifactIdmyBlock/artifactId
groupIdorg.apache.cocoon.blocks/groupId
version1.2alpha/version
/dependency
then the deployer could check for all declared dependencies with groupId
org.apache.cocoon.blocks and treat them as block dependencies. There
are other ways to distinguish between dependencies in maven, but this
would be the easiest initially i think.
I think we should use the classifier attribute for this purpose (as I want to
use blocks in my own namespace).
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Cocoon 2.2 - Build and deployment with Maven2
Reinhard Poetz wrote: - o - +---+ | Build and deployment from a Cocoon user's POV| +---+ ROOT +-- block.xml +-- pom.xml +-- src +-- main | +-- java | +-- myApp | +-- MyJavaFlowController.java | +-- webapp | +-- sitemap.xmap | +-- hello.xml +-- test Note that this follows the standard M2 project structure which makes the M2 life much easier as it saves you configuration time (greetings from RoR). yes. Include also src/main/resources , contents here gets automatically added to the classpath as well. The next step is adding your block to Cocoon application server by mvn cocoon:deploy -Dserver=/home/rpoetz/cocoon2.2 -Dmount-point=/myBlock at a later stage we could also provide mvn cocoon:deploy -Dserver=/home/rpoetz/cocoon2.2 -Dmount-point=/myBlock -DartifactId=myblock -DgroupId=org.apache.cocoon.blocks -Dversion=1.0beta which would just fetch the block and install it. This will add an entry to the wiring.xml and will resolve all block dependencies by putting them into the connections part. I'm assuming it will deploy the block dependencies as well ? For Cocoon 2.2 this will also make sure that all library dependencies specified in pom.xml are resolved. If we hook in to the normal lifecycle then maven will resolve declared library dependencies for us. They should be available from the local repo by the time our deployer kicks in. Now you can start your Cocoon server and enter http://[server]/myBlock/hello or http://[server]/myBlock/javaflow-hello If you want to use the block from other blocks you simply have to call mvn install and it is available for other local projects. this standard maven goal would jar up the compiled project and put it as is in the local maven repo. What do you mean by use the block from other blocks, from IDE/container/... ? - o - +---+ | Build and deployment :: in depth | +---+ Now let's look a bit deeper into the implementation. A Cocoon block is 1. well, a valid Cocoon block by providing block.xml 2. a valid Maven2 artifact 3. a valid JAR file IMO 2. and 3. are equivalent, or maybe i don't fully understand what a valid jar file encompasses. The jar (packaged block) has following content: ROOT +-- block.xml +-- myApp | +-- MyJavaFlowController.java +-- sitemap.xmap +-- hello.xml +-- META-INF +-- maven +-- ... +-- pom.properties +-- pom.xml Are you sure we want to include the sources in each block by default? By packaged block i'm assuming you're referring to the artifact that get's deployed to the repository for others to grab. Same should work for creating IDEA and Eclipse project properties files. For the purpose of RAD, the output directory of the IDE can be set to the target directory of Maven. maven creates idea and eclipse project files out of the box. These mojos are highly configurable so we wouldn't need to do much there. http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html This requires special Maven goal. Thanks to Maven2 it has become very easy to write your own goals (they call them MOJOs). This goal will be able to deploy a block and - resolve all JAR dependencies (pom.xml) - resolve all block dependencies (block.xml) again i think if we hook up the deployer to the correct lifecycle phase the jar dependencies will be resolved already. Resolving the block dependencies should be trivial as at this point they are nothing but plain artifacts from a maven point of view. and copies (and for now unpacks) the block into /cocoon-app/WEB-INF/blocks/myBlock. And, in Cocoon 2.2 it will also copy all JARs the block depends on into /WEB-INF/lib. The mojo has to be smart enough to avoid JAR version conflicts. Thanks to the Maven naming conventions for JARs this should be at least possible. (Note: OSGi will help us to overcome this problem once and for all). yes. And Jorg, if you agree with my ideas, are the proposed changes difficult to implement? Thanks for the summary. No I don't think any of this stuff is difficult to implement at all. Have a look at the ArtifactFactory for artifact resolution. maven's jar conflict strategy is pluggable so we should be able to reuse that as well. Maybe you could start a block deployer directory in the whiteboard ? Regards Jorg
Re: Cocoon 2.2 - Build and deployment with Maven2
Great guys, let us go back to work again :) Jorg Heymans wrote: Reinhard Poetz wrote: - o - +---+ | Build and deployment from a Cocoon user's POV| +---+ ROOT +-- block.xml +-- pom.xml +-- src +-- main | +-- java | +-- myApp | +-- MyJavaFlowController.java | +-- webapp | +-- sitemap.xmap | +-- hello.xml +-- test Note that this follows the standard M2 project structure which makes the M2 life much easier as it saves you configuration time (greetings from RoR). yes. Include also src/main/resources , contents here gets automatically added to the classpath as well. Yes follow M2 conventions as long as possible. What do you think about moving block dependecy handling from block.xml to pom.xml? It means reduced flexibilty as block dependencies becomes direct instead of indirect as in the current schema. OTH it reduce complexity and fullfills our current use cases. If we need indirect dependencies we can add it later. There would be a need to give the dependencies POM unique ids that can be used in the block protocol and we also need a way to be able to mark a dependency as extension, any idea if this would be possible? The next step is adding your block to Cocoon application server by mvn cocoon:deploy -Dserver=/home/rpoetz/cocoon2.2 -Dmount-point=/myBlock at a later stage we could also provide mvn cocoon:deploy -Dserver=/home/rpoetz/cocoon2.2 -Dmount-point=/myBlock -DartifactId=myblock -DgroupId=org.apache.cocoon.blocks -Dversion=1.0beta which would just fetch the block and install it. This will add an entry to the wiring.xml and will resolve all block dependencies by putting them into the connections part. Hmm, while that would be nice at some point I think that it currently would be enough to have a block aware variant of the war pluggin. That fetch and install all needed blocks in the webapp one i developing. Maybe wiring.xml could even be expressed as a POM for this pluggin? /Daniel
Re: Cocoon 2.2 - Build and deployment with Maven2
Jorg Heymans wrote: Reinhard Poetz wrote: - o - +---+ | Build and deployment from a Cocoon user's POV| +---+ ROOT +-- block.xml +-- pom.xml +-- src +-- main | +-- java | +-- myApp | +-- MyJavaFlowController.java | +-- webapp | +-- sitemap.xmap | +-- hello.xml +-- test Note that this follows the standard M2 project structure which makes the M2 life much easier as it saves you configuration time (greetings from RoR). yes. Include also src/main/resources , contents here gets automatically added to the classpath as well. The next step is adding your block to Cocoon application server by mvn cocoon:deploy -Dserver=/home/rpoetz/cocoon2.2 -Dmount-point=/myBlock at a later stage we could also provide mvn cocoon:deploy -Dserver=/home/rpoetz/cocoon2.2 -Dmount-point=/myBlock -DartifactId=myblock -DgroupId=org.apache.cocoon.blocks -Dversion=1.0beta which would just fetch the block and install it. This will add an entry to the wiring.xml and will resolve all block dependencies by putting them into the connections part. I'm assuming it will deploy the block dependencies as well ? Future versions, yes ;-) The first implementation will show a meaningful error that dependencies are missing. For Cocoon 2.2 this will also make sure that all library dependencies specified in pom.xml are resolved. If we hook in to the normal lifecycle then maven will resolve declared library dependencies for us. They should be available from the local repo by the time our deployer kicks in. yes we only have to take care that library dependencies are different from block dependencies *at deployment*. During development they are equal. Now you can start your Cocoon server and enter http://[server]/myBlock/hello or http://[server]/myBlock/javaflow-hello If you want to use the block from other blocks you simply have to call mvn install and it is available for other local projects. this standard maven goal would jar up the compiled project and put it as is in the local maven repo. it also has to put in the block application (sitemaps, templates, images, ...) What do you mean by use the block from other blocks, from IDE/container/... ? From IDE or during build as another block can compile against my block. - o - +---+ | Build and deployment :: in depth | +---+ Now let's look a bit deeper into the implementation. A Cocoon block is 1. well, a valid Cocoon block by providing block.xml 2. a valid Maven2 artifact 3. a valid JAR file IMO 2. and 3. are equivalent, or maybe i don't fully understand what a valid jar file encompasses. yes, but until last week I believed that there is a different as I had put Java binaries into /BLOCK-INF/classes and not directly into the root directory. The jar (packaged block) has following content: ROOT +-- block.xml +-- myApp | +-- MyJavaFlowController.java +-- sitemap.xmap +-- hello.xml +-- META-INF +-- maven +-- ... +-- pom.properties +-- pom.xml Are you sure we want to include the sources in each block by default? Sorry, replace MyJavaFlowController.java with MyJavaFlowController.class. By packaged block i'm assuming you're referring to the artifact that get's deployed to the repository for others to grab. Same should work for creating IDEA and Eclipse project properties files. For the purpose of RAD, the output directory of the IDE can be set to the target directory of Maven. maven creates idea and eclipse project files out of the box. These mojos are highly configurable so we wouldn't need to do much there. http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html yes the only thing I'm not sure about is how to differentiate between binary dependencies (one Eclipse project depends on a block as JAR) and project dependencies (one Eclipse project depends on a block as another Eclipse project). How do I set this? This requires special Maven goal. Thanks to Maven2 it has become very easy to write your own goals (they call them MOJOs). This goal will be able to deploy a block and - resolve all JAR dependencies (pom.xml) - resolve all block dependencies (block.xml) again i think if we hook up the deployer to the correct lifecycle phase the jar dependencies will be resolved already. Resolving the block dependencies should be trivial as at this point they are nothing but plain artifacts from a maven point of view. for building blocks, right but not for the deployment
Re: Cocoon 2.2 - Build and deployment with Maven2
Daniel Fagerstrom wrote:
Great guys, let us go back to work again :)
yep :-)
Jorg Heymans wrote:
Reinhard Poetz wrote:
- o -
+---+
| Build and deployment from a Cocoon user's POV|
+---+
ROOT
+-- block.xml
+-- pom.xml
+-- src
+-- main
| +-- java
| +-- myApp
| +-- MyJavaFlowController.java
| +-- webapp
| +-- sitemap.xmap
| +-- hello.xml
+-- test
Note that this follows the standard M2 project structure which makes
the M2 life much easier as it saves you configuration time (greetings
from RoR).
yes. Include also src/main/resources , contents here gets
automatically added to the classpath as well.
Yes follow M2 conventions as long as possible.
What do you think about moving block dependecy handling from block.xml
to pom.xml? It means reduced flexibilty as block dependencies becomes
direct instead of indirect as in the current schema. OTH it reduce
complexity and fullfills our current use cases. If we need indirect
dependencies we can add it later. There would be a need to give the
dependencies POM unique ids that can be used in the block protocol and
we also need a way to be able to mark a dependency as extension, any
idea if this would be possible?
I don't think so, but maybe Jorg has some ideas. The problem is that our block
dependencies are only telling which contract a dependant block has to fullfill
(+ the information about a default implementation). Additionally we have other
dependencies as a block can extend another block or implement interfaces.
IMO the only thing we can do is that we add a goal to the Maven lifecycle that
checks whether block.xml and pom.xml are in sync.
The next step is adding your block to Cocoon application server by
mvn cocoon:deploy
-Dserver=/home/rpoetz/cocoon2.2
-Dmount-point=/myBlock
at a later stage we could also provide
mvn cocoon:deploy
-Dserver=/home/rpoetz/cocoon2.2
-Dmount-point=/myBlock
-DartifactId=myblock
-DgroupId=org.apache.cocoon.blocks
-Dversion=1.0beta
which would just fetch the block and install it.
This will add an entry to the wiring.xml and will resolve all block
dependencies by putting them into the connections part.
Hmm, while that would be nice at some point I think that it currently
would be enough to have a block aware variant of the war pluggin. That
fetch and install all needed blocks in the webapp one i developing.
Maybe wiring.xml could even be expressed as a POM for this pluggin?
Hmm, have to think more about this.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
