2:19 a.m.
http://jira.rhq-project.org/browse/RHQ-2097
I enhanced our plugin update stuff on the server side so it supports things reconciling
what happens when a plugin is in the database and on the file system and what to do based
on the plugin's version, md5, timestamp.
I wrote a bucket of unit tests to confirm the different scenarios actually work. All tests
pass on my box repeatedly.
The tests are here:
http://svn.rhq-project.org/repos/rhq/trunk/modules/enterprise/server/jar/...
The test matrix defining what scenarios I test and how each scenario will play out is
here:
I have four dummy plugins - version 1.0 with a JUNE timestamp, 1.0 with FEBRUARY timestamp
and same with version 1.1 (one with JUNE and one with FEBRUARY timestamp). Our stuff now
looks at the plugin version to determine which is the latest or not - only if the version
is the same (and md5 is different) do we look at timestamp of the plugin. When we release
plugin pack updates and patches, we should update their version strings (which is what we
should have done before but couldn't because our plugin update implementation
didn't deal with that).
Let me know if you see any holes in the test coverage (any scenario I missed?)...
// Here is a matrix of scenarios we are going to test.
// "Winning Plugin" means the plugin considered the most up-to-date (not
obsolete).
// "Reason" == "exists" means the winning plugin was the only one
that existed
// "Reason" == "version" means the winning plugin had the newer
version
// "Reason" == "time" means the winning plugin had the newer/later
timestamp
// ==========================================================================
// | Plugins Deployed In: | Winning | Reason | Side
// # | Filesystem | Database | Plugin | | Effects
// ==========================================================================
// 0 | 1.0-feb | 1.0-feb | N/A | N/A | steady state - all up-to-date
// 1 | 1.0-feb | N/A | Filesystem | exists | DB row created
// 2 | N/A | 1.0-feb | Database | exists | file created
// 3 | 1.0-jun | 1.0-feb | Filesystem | time | DB row updated
// 4 | 1.0-feb | 1.0-jun | Database | time | file 1.0-feb deleted, file
1.0-jun created
// 5 | 1.1-jun | 1.0-jun | Filesystem | version | DB row updated
// 6 | 1.0-jun | 1.1-jun | Database | version | file 1.0-jun deleted, file
1.1-jun created
// 7 | 1.1-feb | 1.0-jun | Filesystem | version | DB row updated
// 8 | 1.0-jun | 1.1-feb | Database | version | file 1.0-jun deleted, file
1.1-feb created
// ------ the tests below have two plugins deployed on the file system ------
// 9 | 1.0-feb | 1.0-feb | Filesystem | time | file 1.0-feb deleted,
// | 1.0-jun | | | | DB row updated
// --------------------------------------------------------------------------
// 10| 1.0-feb | 1.0-jun | None | N/A | file 1.0-feb deleted,
// | 1.0-jun | | | |
// --------------------------------------------------------------------------
// 11| 1.0-feb | 1.1-feb | Database | version | files 1.0-feb/jun deleted,
// | 1.0-jun | | | | file 1.1-feb created
// --------------------------------------------------------------------------
// 12| 1.0-feb | 1.0-feb | Filesystem | version | file 1.0-feb deleted,
// | 1.1-jun | | | | DB row updated
// --------------------------------------------------------------------------
// 13| 1.0-feb | 1.1-feb | Filesystem | time | file 1.0-feb deleted,
// | 1.1-jun | | | | DB row updated
// --------------------------------------------------------------------------
// 14| 1.0-feb | 1.0-feb | None | N/A | all files are the same but
// | 1.0-feb-2 | | | | one of the files gets deleted
// --------------------------------------------------------------------------