Re: Update of properties

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

-- 
CITCON
Continuous Integration and Testing Conference
http://www.citconf.com/


On Thu, Aug 6, 2009 at 4:09 AM, Daniel Tihelka <[email protected]> wrote:

> Hallo everybody.
>
> Temporarily I have solved it by this UGGLY HACK:
>
> I have pre-defined the 'onsuccess' publisher plugin as follows (together
> with
> the comment which is VERY important):
>
>  <!-- !!! UGGLY HACK !!!
>       free to change: . :egnahc ot eerf
>    -->
>  <plugin name="forceconfigreread"
> classname="net.sourceforge.cruisecontrol.publishers.OnSuccessPublisher" >
>      <execute command="sed -r -i 's|^(\s*free to change:) ([^\s]*) (:egnahc
> ot eerf\s*)$|\1 \2. \3|' ${cruise.projects.dir}/config.allprojects.cruise"
> />
>  </plugin>
>
> and in each related "secondary" project I have add
>
>    <publishers>
>       ....
>       <forceconfigreread/>
>    </publishers>
>
> among publishers. Each succesfull build causes the addition of one dot into
> the moddle of "free to change: ...... :egnahc ot eerf"; it actually changes
> md5sum of the config file, which is detected by cruisecontrol and resulting
> in the re-reading of the configuration again.
>
> It seems to be working, however I would like to replace it by something
> more
> robust in a future. If you have any suggestion or concepts, please write it
> to me. I would like to code patch for cruise control sources, if the idea
> is
> accepted by CC developpers ...
>
> Best regards
> Dan T.
>
>
>
> On Wednesday 05 of August 2009, Daniel Tihelka wrote:
> > Dear CruiseControl comunity,
> >
> > I am creating an quite complicated CruiseControl (CC) project (let's call
> > it "primary"), where a build uses results of other "secondary" CC
> projects.
> > Among others, I need some properties which are DYNAMICALLY defined by
> > the "secondary" builds (stored into property files). There is no problem
> to
> > create/update the properties in a defined file/s each time any of
> > "secondary" projects is built.
> >
> > What I need to help with is how to tell CC that it should update
> properties
> > when the "primary" project is built. I use  definitions like:
> >
> >     <property
> > file="${cruise.buildutils.dir}/utils-current/utils.properties"  />
> >     <property
> > file="${cruise.buildutils.dir}/imgbuilder-current/imgbuilder.properties"
> > /> <property file="${cruise.builddata.dir}/${spkr.id}/data.properties"
>  />
> >
> > in the "primary" poject definition, which reads the properties from the
> > defined files being generated by "secondary" projects (*-current is the
> > automatically created link to the latest build of the "secondary"
> project).
> >
> > Therefore, is there a way ho to force the update of properties (defined
> in
> > a file) when a project is built? Note that I do not want to build the
> > project when a property file is changed (I could use <modificationset
> > <filesyste/> /> to achive this), the the trigger of build must be a SVN
> > change (as it is usual).
> >
> > Thank you very much for your help.
> > Best regards,
> > Dan T.
>
>
>

------------------------------------------------------------------------------
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

_______________________________________________
Cruisecontrol-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cruisecontrol-user