cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: [RT] The impact of using OSGi
Date Mon, 25 Jul 2005 15:26:42 GMT
Carsten Ziegeler wrote:

>Bertrand Delacretaz wrote:
>  
>
>>Apart from that, my impression is that the biggest impact might be on 
>>the build system and on the directory structure of our code: separating 
>>the code in a way that makes sense for bundles (separate interfaces 
>>from implementations, separate units of functionality) would make the 
>>mapping to OSGI bundles much easier, and may make the core code easier 
>>to understand.
>>
>>BTW this maps nicely to the Maven concept of smaller projects organized 
>>in a hierarchy, and people are working on a Maven 2 plugin to create 
>>OSGI bundles, so we have some hints here ;-)
>>
>>I won't be able to help much this month due to more holidays, and as 
>>usual whoever does the work decides, but I just wanted to expose the 
>>mental connections that I've been making last week: if we consider 
>>moving to Maven, this might be the right time to do it, or at least 
>>try.
>>
>>    
>>
>Yes, definitly, +5 - has anyone already done some steps towards this?
>I'm planning to have a look at it in the next days.
>
>Carsten
>
>  
>
Since I've had to look over how to build a block in the last few days 
and have quite a bit of experience with Maven 1 I've had a chance to 
think about the problems here:
1.   gump.xml has all the dependencies for everything.  This has to 
change with a move to maven.  Each block needs its own project.xml with 
its own dependencies.
2.   The "main" project directory needs its own project.xml.
3.   Currently we allow building blocks to be controlled by propery 
settings. This should actually stop.  Instead, the main project 
properties should contain a pattern to cause all the blocks to be built.
4.  The individual artificts constructed by maven should be placed in a 
repository (i.e. the core and all the blocks).
5.  The Cocoon download should consist of downloading the core (or maybe 
just a project.xml that depends on the core). The customer should (or 
could) modify/create a project.xml that identifies which blocks they 
want. Running maven would then download them all.
6.  The sample site needs to be broken into its own block that depends 
on all the cocoon blocks.

Basically, this is a major pain but, IMO, would result in a cleaner 
build system and would be easier for end users as they would not have to 
download the source any more.


Mime
View raw message