cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Cocoon 2.2 - Build and deployment with Maven2
Date Tue, 13 Dec 2005 08:03:38 GMT
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
--------------------------------------------------------------------


Mime
View raw message