cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Wyles <>
Subject Re: Repository block and C2.2
Date Sat, 05 Jan 2008 12:18:47 GMT

On 4 Jan 2008, at 04:03, Joerg Heinicke wrote:

> On 02.01.2008 11:26 Uhr, Robin Wyles wrote:
>> Looking at the pom I don't see any version numbers, but the  
>> dependencies seem to be:
>> cocoon-core
>> cocoon-eventcache-impl
>> excalibur-datasource
>> servlet-api
> From what I know in this case these versions are in the parent POM.  
> And all these dependencies should be releases. You might need to  
> convert cocoon-eventcache-impl first though - or get rid of the  
> dependency. It was always quite big dependency tree for repository  
> block if I remember correctly. See 2.1 [1].

The dependency on cocoon-eventcache-impl is from  
SimpleJdbcSourceDescriptor [1] which itself needs cocoon-database- 
impl if it is to be used [2]. As you say the dependency tree is quite  
large, and the following may be tricky...

cocoon-repository-impl -> cocoon-eventcache-impl -> cocoon-jms-impl - 
 > cocoon-cron-impl

... as cocoon-cron-impl is apparently deprecated. I haven't looked  
into cocoon-jms-impl to see where the dependencies on cocoon-cron- 
impl are, so I'm not sure what the best course of action is here, any  
advice would be welcome.

>>> For final I would like to see some samples (repository block  
>>> lacks any) and at least minimal coverage by tests.
> Grek is really pushing hard for getting better test coverage :)

Well, if you aim for the stars you might reach the moon :)

>> Me too, after going through your points below my plan is to write  
>> initial tests for SourceRepository to test all repository  
>> operations using a local file:// based repository.
>> Ultimately I would like to see this block springified (sprung?)  
>> too - I envisage us creating our own Repository implementations  
>> and would much prefer to do this using Spring.
> I wonder if we are going the same way as for forms block: 1.0 for  
> the 2.2-converted block, 1.1 for the next step, the  
> springification. This means we should do this migration in 2 steps.


>>> I think that the best strategy would be to create configuration  
>>> of sitemap components in order to
>>> get them running then try to run rest of components.
>> Will do this and set up some tests for these components - I'm  
>> still figuring out how some of the other components in this block  
>> are used and so how they can be tested.
>>> I guess it's not that much work left in order to prepare first  
>>> milestone release of repository block
>>> but having even few samples would be highly appreciated.
>> I'll report back after I've taken a look at the above and will  
>> hopefully have an idea of what the samples could contain.
> Maybe it does not make much sense to have samples for this block,  
> especially if it does only provide basic functionality. I don't  
> know the scope of the repository block though. But maybe it's up to  
> blocks like webdav to provide the actual samples. The test coverage  
> is probably more important.

There are a couple of sitemap components,  
TraversableSourceDescriptionGenerator and  
SourcePropsWritingTransformer, that could be used for samples.  
Although the latter needs a suitable SourceDescriptor - the only one  
present is SimpleJdbcSourceDescriptor which has the dependency issues  
outlined above.

I'm not quite sure how tests for SourcePropsWritingTransformer can be  
written though - used in conjunction with SimpleJdbcSourceDescriptor  
it will need a test database.

I think SourceRepository might also be worthy of a sample - this  
could be wrapped around a FileSource repository and show basic  
manipulation of repository content. I'll certainly be writing tests  
for this component as it's the one which will be using first. If  
anyone more familiar with the repository block can provide more info  
on what else should be covered by tests then please let me know.




> Joerg
> [1] 

View raw message