cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [2.2] Past, present and future of the maven build
Date Wed, 31 Aug 2005 08:27:38 GMT
Carsten Ziegeler wrote:

>Daniel Fagerstrom wrote:

>>>blockx + core - the real block
>>>      + webapp - required webapp part like configuration etc.)
>>>      + samples - the samples
>>Factoring out the samples is good but I don't understand the split into
>>core and samples, care to explain?
>Sure, core is perhaps a misleading nome, it's the java code, or perhaps
>we have like Ralph suggested:
>blockx - api
>       - impl
>       - test
>       - webapp
>       - samples
While I agree in principle we must understand that this will create 
around 250 blocks, which require very regular structure and scripted 
update and maintainance operations. While we might get problems with 
circular dependencies, that must be solved with split in api and impl 
when we split core I don't think there are any such problems for the 
current blocks. So we can take one step at a time.

Also we should take, at least to some degree, take real blocks and OSGi 
into account.In OSGi bundles you describe what is the api by exporting 
the api packages in the manifest. Non exported packages are then 
implici┬┤tely regarded as implementation. For unit tests I'm not certain 
what is the best solution, if one put the test into a separate bundle, 
the implementation bundle must export all packages that are tested. So 
probably it is better to put the unit tests in the implementation 
bundle, it can still be in a separtate directory hierarchy and jar if we 
want to. For the webapp stuff, I assume that you mean such things that 
we are going to put in COB-INF/block.xml.

Now, we don't have to take all future requirements into account, it is 
of course better to do something that works now and modify it when 
needed. My main message, I guess, is that we shouldn't do splits like 
the one suggested above, until we know that we need it.

>>>Splitting up the current code base into a structure like this is just
>>>moving directories and files. So that's really easy.
>>>I think we should then write a little m2 plugin that deploys a block
>>>into a build webapp:
>>>- jars are copied to WEB-INF/lib
>>>- configuration to WEB-INF/xconf
>>>- other resources are copied as well
>>>- new sitemap components are added to the main sitemap
>>Can't this be handled by wildcard inclusion from component 
>>configurations in some catalog, so that we get rid of the snippet 
>Currently we only need patching the main sitemap and the web.xml - we
>can't do anything about web.xml for some stuff. 2.2 can read it's
>configuration from property files instead of parameters in web.xml, so
>we can remove most from web.xml.
>We can use wildcard inclusion in the main sitemap as well.

>>>Anyway, if we split up the core into several parts,
>>>this will break the Ant build script. Of course we could now change the
>>>ant script as well, but that's imho
>>>to much energy put at the wrong place.
>>What about starting to get the blocks compiling with m2 before starting 
>>to split the core, then we minimaize the time when not the complete 
>>Cocoon compile.
>I think compiling a block with m2 is not a problem at all, just define a
>pom with all dependencies and invoke "m2 install" :) Now, it would be
>great if someone would start adding poms with dependencies to the blocks...
Ok, get the message ;)

Some thinking and planning is IMO needed though. We allready have all 
(or most) dependency info for blocks in gump.xml. Keeping a global 
gump.xml and block local POMs in synch doesn't sound like that much fun.

So, could we move the block parts of the global gump.xml into the 
blocks, so that we have the POMs and gump.xml at the same place. Or 
better, can we generate the gump.xml from the POMs. Or even better, is 
there some integration between gump and Maven, so that Gump can use the 


View raw message