Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro TicketQuery(summary=PLATFORM_DEPLOYMENT_TARGET_JWS_R1, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed

current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

JWS is broken, incomplete and outdated. Fix it.

Task requirements

• ​http://asteasolutions.net/~jordan/ exists no more. JWS demo lived there, now it's gone. Put it somewhere on sophie2.org and fix it.
• Before, http://sophie2.org/jws has been used for the above. It's also broken and outdated. Fix it.
  • currently, a JWS launch configuration exists only for the Author application. Create such also for Reader.
  • update content of this dir - launchers, jars, etc..
  • identify and fix other related settings.
• Fix org.sophie2.launcher.JavaWebStartMain if needed.

Task result

• Nice and tidy place on sophie2.org with all JWS related files.
• Working Author and Reader jnlps.

Implementation idea

• Go through the mentioned locations, locate and fix any errors and/or update any outdated code.

Related

• PLATFORM_DEPLOYMENT_TARGET_JWS_R0

How to demo

• Successfully run Author and Reader through JWS.

Design

• I'll use ​http://sophie.org/jws to store the following:
  • keystore
  • all needed jars
  • config files
  • jnlps
  • readme
  • ...
• I'll create a new keystore with keytool and put it in http://sophie2.org/jws
  • it will be still non-official though we should create an official one at a given point. We're not Al-Kaida, we're Astea for Meddle's sake!! We should have our official keystore!!
• I'll sign all jars which need to be signed with jarsigner
• I'll refactor JavaWebStartMain class to System.setProperty("editor", ...) to whatever is actually run, either "author", "reader" or "server". JavaWebStartMain.main() will receive this as a 3rd parameter from the jnlps.

There are some new issues which need to be fixed:

• FileEntryManager.getRoRoots() currently searches for a "modules" dir from the current working directory to the root of the filesystem tree which is not cool because with JWS no such directory exists and the initial current working directory can be unpredictable. FileEntryManager needs this dir to find all .jars which correspond to Sophie modules and be able to look up inside them for resources, such as icons etc.
  In order to fix it, FileEntryManager will access the new ListProp<ModuleInfo>startedModules() of the running ModuleRegistry.
  Thus, FileEntryManager.findModulesDir() will be deleted because FileEntryManager.getRoRoots() won't use it anymore. Hellyeah!
• Both FakeModuleRegistry and TrueModuleRegistry will need to implement ListProp<ModuleInfo>startedModules():
  • TrueModuleRegistry will implement it by getting a BundleContext and use it to get all the started Bundles and their URLs (in the case that a given URL is a local file path, it will be converted to absolute file path). Then it will create respective ModuleInfos and fill startedModules() with them.
  • FakeModuleRegistry will implement it by parsing the System.getProperty("java.class.path"), filter out "org.sophie2.<module-name>/target/*" entries and constructing URLs to the jars inside these locations, then respectively construct ModuleInfos and fill startedModules() with them.
• The above mentioned BundleContext will be gotten from a newly created CoreModularityModule. As specified by the docs, a created BundleContext is passed to the start() and stop() methods of a Bundle, so that's where well save this BundleContext and expose it for public usage. This is ugly and according to the docs, a BundleContext instance is responsible only for the Bundle it's associated with, though we can access all started Bundles through any given BundleContext produced by the same Felix instance, so we'll exploit this "feature" and suit it for our needs (:

These modifications will fix the above mentioned problem with the FileEntryManager, so JWS will be implementable, and also they'll be synchronized with Pav's new modifications so no new refactoring is expected to be done to accomplish this task.

There won't be any tests introduced (see Comments section for details).

Implementation

There are a lot of problems with batik library and some other dependencies but they are fixed now, cleaning the unused dependencies and added only the needed ones:

• URL with java web start version of the application: http://sophie2.org/jws/
• Revisions: [4236], and revisions from GROUP_PLUGINS_ENABLE_DISABLE_R0 tasks, connected with the FileEntryManager.

Testing

As a result, no tests for this task (:

Comments

​http://www-ab.informatik.uni-tuebingen.de/software/crosslink/doc/WebStartGuide.pdf, page 11 shows how to turn on a separate Java Console window. Useful for debugging when starting javaws from the terminal doesn't provide output.

About testing:

• FileEntryManager will produce the same results as before, so no new functionality, no new tests for it.
• Pav's task introduces the new startedModules() property so tests regarding it could be done there, not in this task.
• In our case, running javaws with the fixed jnlp is not something that could be tested automatically, only manually, so no test for this.
• New CoreModularityModule won't introduce any new functionality, so no new test.