Re: Update of properties

Hallo Jeffrey,

thank you for reply. I didn't read it carefully now, but I plan to do it so 
soon. Then I will try to make the modifications you suggest and eventually 
ask to what I do not understand. When a code emerges, I will send a patch for 
revision.

Best regards,
Dan


On Saturday 08 of August 2009 18:35:10 Jeffrey Fredrick wrote:
> Hi Dan.
>
> > I would like to code patch for cruise control sources, if the idea
> > is accepted by CC developpers
>
> If you're interested in creating a patch I'm happy to provide guidance.
>
> The change is going to involved XmlResolver and the implementation class
> XmlConfigManager.Resolver. These are the classes that make sure that the
> MD5 is different when the config.xml *or any included config.xml files*
> have changed. You just need to extend the concept to other file types.
>
> You can understand the change that's needed by looking at
> XmlConfigManager.calculateMD5(). The XmlConfigManager creates the Resolver
> class and passes it to CruiseControlConfig. When there's an included
> config.xml file CruiseControlConfig gets the contents via the instance of
> Resolver that was passed to it. The Resolver class keeps track of all the
> files it returned and when it is time to calculate the MD5 the sum of all
> the file MD5s are used.
>
> So the basic idea would be to extend this concept to property files. But
> there's a hitch... (or I would have done this long ago!)
>
> Unlike other plugins, the IncludeProjectsPlugin is a bit of shell. The only
> purpose it serves is to return the file path to CruiseControlConfig which
> will then does the real work of creating the nested configuration. By
> contrast ProperitesPlugin (actually DefaultPropertiesPlugin), like every
> other plugin, is configured by ProjectXMLHelper.configurePlugin(), and it
> is the plugin itself that does the file loading.
>
> So how to solve the problem?
>
> The best idea I have is to extend the idea behind the XmlResolver to a more
> generic FileResolver and then pass the file resolver into the
> ProjectXMLHelper which in turn would pass it (via reflection) to plugins
> that have the method:
>
>   public void setFileResolver(FileResolver)
>
> This would allow *any* plugin to have file they depend on monitored for
> changes and to have the configuration reloaded as needed. (This would also
> allow the work with XmlResolver currently done in CruiseControlConfig to be
> moved into the IncludedProjectsPlugin.)
>
> That all make sense?
>
> Thoughts?
>
> Jtf



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july