Kepler

Actually, the library should be able to store copies of the actors, but when one attempts to load it, Kepler should tell the user that they already have that actor and so there is no need to reload it. This is a more graceful way to handle the problem, and allows us to use the repository as a place to store old versions of actors.

I thought the kepler repository was originally supposed to house all actors so that we could distribute a light version of kepler with no actors and the user could just download the actors he/she wanted from the repository.

I've gotten the repository working again, and I cleaned it out of all the stuff that was in there. We need to decide how we want to build it up from scratch.

I'm not sure how to fix the filename issue. It probably needs to be set on the serverside somehow, but I don't think that metacat has that capability.

set the mime name on upload so that the filename will be correct on upload.

This bug is currently blocked by 3084. Metacat and the grid interfaces need to be updated before this bug can be fixed. I'm pushing this to 1.1 because of this.

the PutService for ecogrid-1.0.0 will include support for filenames. Metacat already handles this, so the download should work without need for metacat changes.

I just played with the library page a bit, and had some problems. I can open separate bugs if you like:

- Repository Home link gives a 404 error
    For Browse existing Kepler analytical components:
        - Download (picture) button not working
        - component names are not showing up
        On View Documentation pages:
            - pictures are broken
            - download of component always returns files called "data.jar" (shouldn't it be actorName.kar ?)

personal opinions:
- I think 10 results per page is not enough for the browse section, I'd rather see 50 or 100.
- pictures of actors in browse section would be useful, you could immediately grok category

The repository should be re-worked for the 2.0 release if we are going to include modules in it.

I'm starting to upload KARs, sets of metadata docs that point at them (workflows and workflow runs) and sets of access documents, but am bumping into issues, like being unable to see my uploads on the kepler library site. Chad, can you and I and Aaron chat about this bug?

I started working on this yesterday. I found major problems with how lsids are assigned when uploading to the repository. after talking to aaron, the way to approach this is to first add the actor to the localRepository which will give it a new unique lsid (if needed), then upload it to the remote repository. The user needs to be asked if their actor is a new revision or a new object so that the appropriate id can be generated.

this isn't just for Actors - this is for Workflows. Just want to make sure we're all keeping that in mind.
The same "upload to repository" function will be used for KARs that contain workflows, runs, and reports - everything is possible.

We're now using the "repository" for many different things:
-actors
-workflows
-workflow runs
-kars (which might contain those above and more)

We're also supporting upload to multiple Repositories (user choice).

The use we're focused on currently is the repository-as-workflow-and-workflow-run-archive for sanparks.

in response to comment #9, I fixed the issues with the LSID conflicts on upload (using the uploadToRepository method). uploadToRepository still needs to be changed to upload to the local repository first though.

The stuff needed for sanparks is done. pushing to 2.0 release.

Need to verify that saving to the repository is working seamlessly for both Uploading components and workflows, as well as other artifacts like run archives.

adding dependencies...

All dependencies are done. closing.

Original Bugzilla ID was 2493