cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Wyles <...@robinwyles.com>
Subject Re: Repository block and C2.2
Date Mon, 14 Jan 2008 09:10:55 GMT
Hi...

On 5 Jan 2008, at 13:18, Robin Wyles wrote:

>
> 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 blocks.properties [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.


After looking a bit deeper into this I can't see why the following  
dependencies exist:

  cocoon-eventcache-impl -> cocoon-jms-impl

cocoon-jms-impl -> cocoon-cron-impl

Removing these dependencies from the block POMs doesn't cause any  
build errors. Could someone with more knowledge of the eventcache and  
jms blocks tell me if these dependencies are still valid?


Thanks,

Robin

>
>>
>>>> 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.
>
> Agreed.
>
>>
>>>> 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.
>
> Robin
>
> [1] http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon- 
> repository/cocoon-repository-impl/src/main/java/org/apache/cocoon/ 
> components/source/impl/SimpleJdbcSourceDescriptor.java? 
> revision=587761&view=markup
>
> [2] http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon- 
> repository/cocoon-repository-impl/src/main/resources/META-INF/ 
> cocoon/avalon/cocoon-repository.xconf?revision=588098&view=markup
>
>
>>
>> Joerg
>>
>> [1] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/ 
>> blocks.properties?revision=488038&view=markup
>>
>
>
>


Mime
View raw message