[wpkg-users] [Bug 79] New: Major WPKG enhancements, remote logging, doc, internal restructuring

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=79

           Summary: Major WPKG enhancements, remote logging, doc, internal
                    restructuring
           Product: WPKG
           Version: other
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: wpkg.js
        AssignedTo: mangoo at wpkg.org
        ReportedBy: skybeam at users.sourceforge.net
         QAContact: wpkg-users at lists.wpkg.org


Created an attachment (id=46)
 --> (http://bugzilla.wpkg.org/attachment.cgi?id=46)
Diff between version 0.9.12-test2 and my enhancements

Hi all,

I know some of you will probably hate me for what I am going to do now but I
still hope we can focus on a objective discussion here.

I just finished developing of a major redesign of the wpkg.js script. As you
might know I recently opened Bug 77 where I introduced an enhancement to handle
zombie packages (forced removal in case of failed uninstall attempt).

Already then I was not really happy with some internal structures. Some code
seemed to be duplicated and XML/XPATH handling was spread all over the code
where I felt it would be nice to encapsulate reading of XML nodes to helper
functions.
Well I introduced this functions now. The result was that almost the full
script was redesigned and unified. I also found that it was clearly visible
from different code parts that some parts have been written by different
people. While I think that's perfectly fine I think it improves readability to
have a common code style. Additionally this eases re-usage of code-fragments.
So I tried to apply the sun coding guidelines for Java where possible.
Additionally I introduced lots of JavaDoc style comments to describe function
purposes, input and output parameters as well as return values and their types.

Apart of this "cosmetic" changes I did lots of internal re-structuring. For
example I totally got rid of the executeOnce() and upgradePackage() code which
was widely identical. I gave the installPackage() function some more
intelligence so it can now decide on itself if a package needs to be installed,
upgraded or skipped. So synchronize just needs to pass all packages to be
checked to the installPackage() function.

Another enhancement which is worth mentioning here is a new feature: Log file
writing.
My enhancements allow to specify a path, a log level and a log file pattern
where it writes an activity log. This is even configurable by the administrator
within config.xml at any time. However this needs extending of config.xml. Old
config.xml is still compatible since wpkg.js now comes along with default
values for every config flag/option. In fact config.xml could now be entirely
optional.

Well here's my change log I wrote (you will find this also within the header of
wpkg.js):

 * FIX: Fixed package query. Compares package ID now to get installed status
 *      instead of comparing references (which returns false when comparing
 *      node from pacakge database and node from settings).
 * NEW: Introduced new set*(), is*() and get*() methods to query script
 *      parameters. Direct field access should be avoided.
 * NEW: Introduced ability to write a log file to a specified directory. This
 *      allows administrator to have clients writing a log file to a shared
 *      directory to trace client execution.
 * NEW: Log-file naming pattern is configurable in order to allow having one
 *      log file per client, one log file per day/hour/minute...
 * NEW: Configurable log level allows administrators to change level of log
 *      detail within config.xml (or overridden by command line switch).
 * NEW: Zombie packages will be removed from the local package database even if
 *      locally stored uninstall string fails. Except if the package is still
 *      referenced in the applying profile. In such a case a message about
 *      message about inconsitency between profiles and the package database is
 *      printed. This makes sure that a package does not generate a recurring
 *      error on each boot (when using wpkg-service) in case the package has
 *      been completely removed from the server.
 *      In case you like to disable this have a look at the /noforcedremove
 *      switch.
 * NEW: Using versionCompare() now to compare versions of packages. This allows
 *      usage of string representation of revision attribute on each package.
 *      Currently wpkg_web supports just integer values but this could be
 *      changed.
 * MOD: Removed some redundant code.
 * MOD: Removed all XML node handling to get* methods to simplify XML handling.
 * MOD: Saving settings XML file just once (on exit) instead of several times.
 * MOD: Unified logging, info(), dinfo(), warning() and error() use the log()
 *      method now which can handle the output in one single place.
 * MOD: query*() methods now rely on the same code. Unifies output formatting
 *      and siplifies maintenance.
 * MOD: Does not stop execution in case a package fails installation except if
 *      /quitonerror flag is set.
 * MOD: installPackage() (package installation) makes sure all dependencies are
 *      installed first. In case a dependency failed the package installation
 *      fails as well.
 * MOD: installPackage() now acts more intelligent and detects if a package
 *      needs to be installed, upgraded or skipped. It also takes into account
 *      the package execution flag ("always" or "once"). Therefore the
 *      upgradePackage() and executeOnce() methods which mainly contained
 *      duplicated code are removed. Just call installPackage() for each
 *      package which applies to the system no matter if it is already
 *      installed or not.
 * MOD: Splitted script parameter evaluation and initialization.
 * MOD: Added lots of comments and documentation.
 * MOD: Some code reformating.


NOTE: The new synchronization and remove algorithm takes Bug 22 and Bug 77 into
account. This means that a package which is removed from packages.xml but still
referenced within profiles.xml is not removed. In case it is removed from
profiles.xml it tries to uninstall it. If it fails it checks if the package is
a zombie (not within packages.xml). The local wpkg.xml entry is removed if the
package is NOT referenced within profiles.xml AND does not exist within
packages.xml. If it is either referenced by profiles.xml or existing within
packages.xml it is not forced to be removed from wpkg.xml.
This complies with the description within Bug 22 and also allows system
administrators to force a package to be cleaned up even if the locally stored
uninstall string fails.

TEST STATUS:
I quickly verified installation/upgrade and removal of a package as well as
every query* functionality. It worked well but I cannot give warranty that
everything will work right from the beginning as expected. Especially since I
removed quite a lot of unneded code and changed some algorithms.

I would be glad if some of you could verify it and report bugs.


-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


wpkg-users mailing list
wpkg-users at lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users