Tool-deployer upgrade, checks the db for tool_signature and tool_version, stops if current tool is up to date, installs entire tool if the signature is not present in the dbTODO: update db and jar and war files if tool exists, but is not the newest version
Skeleton for a new ToolDBUpdater classIt will: * Check if the tool exists in the db * Check if the tool to be installed is newer than the current * Update the db with the current tool information
Completed linking of a language file to a complex activity. The last check in of code was missing setting the language file in the database - it only copied the file.On doing this second part, I found that I hadn't passed data around in the same manner as Chris originally designed. So I removed the Maps returned by the tasks and went over to Chris' way of just calling the tasks to get any necessary cross-task information.
Added greater flexibility to the language files for the tool deployment - the deployment configuration now specfies the package into which the file(s) shoul be placed. For tools this may be their normal package, or a tool signature directory. For non-tool activities this will be a artificial name.
Copies specified language files from tool directories to the lams-dictionary.jar in the ear. Added a fileset to the ant tag - couldn't do it as nicely as I would have wanted as I couldn't get nested tags working.
CreatePackageTask is now the parent class for creating tool/library packages. It follows the same logic as the original CreatePackageTask, just the some commonality between library and tool package task is extracted
Rationalised jars to match the common jar libraries, but left in project. Setup tool_deploy so that it can be built and loaded into lams_build project, the properties file generated from a build script and the deployment run from a built script. This was done to make a usuable development tool deploy task as well as make it easier to build the deployment package.