Kepler

A user can now create different types of KARs from within Kepler, and upload them to the repository via context menu from the component library. KARs can contain:
a) workflow
b) workflow, roml
c) workflow, roml, rio
d) workflow, workflowRun
e) workflow, roml, rio, workflowRun
f) actor

A user can't make these anymore, but this may be re-enabled at some point:
g) workflow 1, workflowRun 1, workflowRun 2
h) workflow 1, workflowRun 1, workflow 2, workflowRun 2
i) workflow 1, roml 1, rio 1, workflowRun 1, roml 2, rio 2, workflowRun 2
j) workflow 1, roml 1, rio 1, workflowRun 1, workflow 2, roml 2, rio 2, workflowRun 2
etc.

When uploading a KAR to Metacat, we upload the KAR as data, and any contained workflows and workflowRuns are also uploaded as metadata pointing to the KAR. This means that the component library upload code, which is in the gui module, needs a way to know what items serve as metadata for a KAR (and of course the other classes that do uploading need to know this as well). This leads me to think that karEntryHandlers should probably be putting an attribute into the Manifest like isMetadata: true.

Thoughts?

oh, I like that - then the gui code never needs to "know" all the different kinds of metadata entry types, just that they are indeed this metadata type.

This bug is a more of request for refactoring and an RFE (when a remote repository is check-marked, don't always prompt to upload on a Save Archive).

The suggestion in comment#1 is no longer relevant since the KAR system's been redone and we're moving to kar-xml.

Retargeting to post 2.0.

Original Bugzilla ID was 4577