Need to generalize copying workflow demos from areas other than outreach.
Lei Dou at UC Davis is working on a module that extends Kepler functionality. It, like many other modules, has workflow demos. The problem is this. These demos should not go into the outreach module, which is part of Kepler/CORE. But, since on the Mac when things are installed, the modules are in the Kepler.app, the demos are not available.
The solution is to have demos that are contributed by a module be copied to KeplerData/Kepler-2.0-Demos/demos upon start up if they are not already present upon start-up.
This should be done before the 2.0 release. It will be necessary to make a 4th release candidate before doing the 2.0.0 release.
#1 Updated by David Welker about 11 years ago
(1) For each module in the current set:
-- Check if there is a demo directory. (This should be determined based on a getter method in Module.java. If it doesn't exist, create it.) If there is a demo directory, check to see if KeplerData/demos/<module-including-version> exists. If it doesn't exist, copy the demo directory over.
For data, data should be a subdirectory of the demo directory.
(2) For each module in the current set:
Set a system property as follows:
The stem name of the module plus the string ".demodir" is the name of the property. The demo directory of the module is the value of the property.
#2 Updated by David Welker about 11 years ago
Oh, I nearly forgot. We need a docs directory to.
(3) For each module in the current set:
-- Check if there is a docs directory for the module. (This should be determined based on a
getter method in Module.java. If such a method does not does not exist, create it.) If there is a
docs directory, check to see if KeplerData/docs/<module-including-version>
exists. If it doesn't exist, copy the demo directory over.
#3 Updated by Derik Barseghian about 11 years ago
Not mentioned in the bug but the idea was to copy all modules' module/resources/demos dirs. But we've changed the plan a bit: we'll copy from module/workflows/demos instead. Anything in resources goes on the classpath, and we didn't see a need for workflows to be on the classpath. Also, a module dev may want to maintain workflows that aren't demos. Modules keep their workflows in a few different locations currently, I'll try to organize appropriately. Objections? I'll try fix any path problems I notice inside the workflows I move...
#4 Updated by Derik Barseghian about 11 years ago
This is mostly done now in trunk and 2.0.
After futher discussion w/ David and Sean, we decided to change to copy all <module>/workflows into KeplerData/workflows<module>/ .
The user folder ("default local repository") is now KeplerData/workflows/MyItems. I'm happy to rename this if people don't like it, but I thought continuing to call it Workflows when it's actually just a subdir of workflows might be confusing.
<module>/documentation/ is now copied into KeplerData/documentation/<module>/
I've moved all the workflows I found into the appropriate locations. I now need to open and fix all workflows that use old system properties to change to the new <moduleStemName>.demodir properties. I tested this on a number of workflows and it worked.
#6 Updated by Derik Barseghian about 11 years ago
(In reply to comment #5)
Changing the "documentation" folder to "docs." Also, putting it at the top
level of a module, rather than within the "resources" directory.
Having made this change, you'll now need to move reporting, workflow-run-manager, and tagging documents found in <module>/documentation/ into respective docs dir, and figure out what to do with the tagging design documents currently found in tagging/docs. You'll then need to fix the Kepler gui Help=> Documentation code that looks for documents in documentation/.
#7 Updated by Derik Barseghian about 11 years ago
Typo in Comment#4, the new properties are not <modulename>.demodir, but <modulename>.workflowdir.
I've updated all the paths I found in our workflows to use <modulename>.workflowdir instead of DEMODIR. It will be good to ensure these work in the next installer version.
After Comment#6 is fixed, we should be able to close this bug.