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: svn commit: r609282 [1/2] - in /cocoon/trunk: blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/ blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/a/ blocks/cocoon-core-sample/cocoon...
Date Wed, 09 Jan 2008 00:26:02 GMT
Come to think of it, although it is a pretty lame excuse, the reason I 
ran with tests disabled is I just cut and pasted the command line from 
the README - I can never remember the format since -P allblocks isn't 
something you normally do with maven.  Perhaps the README should be 
changed? It should only be for developers after all.

Ralph Goers wrote:
> Rats. Sorry. I was trying to squeeze that in when I had free time and 
> I just get so used to skipping the tests since every time I've tried 
> to run them my build has failed. I shouldn't have assumed they were 
> still not working.
>
> To be honest when I was working on this I was just very frustrated at 
> how much more complicated 2.2 is and was just looking for the simplest 
> way to get VariableResolvers working everywhere like it does in 2.1. I 
> spent hours over the weekend trying to get all this working. I should 
> have raised some of these issues on the list before I checked it in:
> 1. Why on earth is VariableResolverFactory doing a lookup on 
> StringTemplateParserVariableResolver.ROLE? Spring is supposed to free 
> you to allow any implementation of an interface - or is 
> StringTemplateParserVariableResolver the only acceptable 
> implementation? (In which case, why is it even configurable via 
> Spring?). It seems to me this should be replaced with 
> VariableResolver.ROLE.
> 2. Does PreparedVariableResolver (the resolver in 2.1) still work?  If 
> it does I can have BridgeElementParser register it and then have 
> SitemapElementParser replace the VariableResolver bean with 
> StringTemplateParserVariableResolver. I'll give this a try and see 
> what happens. Of course, it may have the same dependency problems.
>
> BTW - I couldn't find a reference to LegacyVariableResolver anywhere. 
> Did you really mean LegacySitemapStringTemplateParser?
>
> Ralph
>
> Grzegorz Kossakowski wrote:
>> rgoers@apache.org pisze:
>>  
>>> Author: rgoers Date: Sun Jan  6 01:35:48 2008 New Revision: 609282
>>>
>>> URL: http://svn.apache.org/viewvc?rev=609282&view=rev Log: Created 
>>> XPathXMLFileModule to fix
>>> problems with XMLFileModule. Added getAttributeValue to JXPathHelper 
>>> and changed all references
>>> to getAttribute to use it instead. Moved registration of 
>>> VariableResolver to BridgeElementParser
>>> from SitemapElementParser to make it available to all Avalon 
>>> components (i.e. input modules).
>>>     
>>
>> Ralph, move of registration of VariableResolver broke[1] our testing 
>> environment because now
>> LegacyVariableResolver is added to the environment for every test 
>> execution but its dependencies
>> (referenced beans) are not. I'm not sure how to fix this at the 
>> moment but I will try to have a look
>> in upcomming days.
>>
>> Anyway, I have a request to all committers: please test your changes 
>> before committing anything.
>> It's just as simple as executing mvn clean install from root directory.
>>
>> [1] 
>> http://vmbuild.apache.org/continuum/buildResult.action?buildId=35020&projectId=51

>>
>>
>>   

Mime
View raw message