Re: Update of properties

Hallo Jeffrey,

I have read your guide and I have looked into CruiseControl code. I am not 
sure if have caught your idea, but if so, it does not seem so hard to me.

So, I will write what I must to, as I understand it. Please, correct me, if I 
an wrong (to avoid useless coding):

1) create new interface FileResolver with method like addFile(String file)

2) extend the implementation of XmlConfigManager.Resolver to implement this 
interface (the file will be added to the resolvedFiles set)

3) Pass the instance of FileResolver into ProjectXMLHelper.configurePlugin() 
method (or to set it in ProjectXMLHelper constructor?). The 
ProjectXMLHelper.configurePlugin() method will pass it to the particular 
plugin just created (if it contains method public void 
setFileResolver(FileResolver))

4) Every plugin may then call FileResolver.addFile(file_to_monitor), if 
interested.

5) Implement the method in DefaultPropertiesPlugin and let the files to be 
monitored.


Is it what you thought? If you agree, I can start coding, if I missed 
something, please, explain it to me again.

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