Kepler

Proposed solution:

(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.

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.

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...

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.

Changing the "documentation" folder to "docs." Also, putting it at the top level of a module, rather than within the "resources" directory.

(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.

Hey David,
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/.

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.

Closing this bug. We may need to re-open this bug or a new bug in order to deal with the change in location of documentation from resources/documentation to docs/.

Why was this closed? From what I can tell Help => Modules Documentation is still broken because the files haven't been moved into docs/ yet. I'll move them. Let me know if these were intentionally not moved or I've misunderstood something.

The files had been moved in 2.0 but not trunk. I moved the ones in trunk.

Original Bugzilla ID was 5034