Project

General

Profile

Actions

Bug #4938

closed

Reporting suite no longer works on its own

Added by Derik Barseghian over 14 years ago. Updated over 14 years ago.

Status:
Resolved
Priority:
Normal
Category:
reporting
Target version:
Start date:
04/15/2010
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
4938

Description

If you ant change-to -Dsuite=reporting, the View drop-down doesn't show up, so you can't use Reporting. This used to work, anyone know what happened?

Actions #1

Updated by debi staggs over 14 years ago

I have been working out of only wrp for quite some time now. I don't think that reporting is meant to run on it's own at this point, since to the best of my knowledge it requires Provenance and the workflow run manager in order to be used.

Actions #2

Updated by Derik Barseghian over 14 years ago

I started looking into this. It looks like reporting's Initialize class should have an updateFrameComponents that's the essentially the same as WRP's. But this requires importing ReportingListener, which actually resides in wrp. I forget why we put it in wrp, I'll try to look into this more next week...

Actions #3

Updated by Derik Barseghian over 14 years ago

Ah right, ReportingListener is in wrp because it uses ExportRunsToKar, which needs to be in either wrp or workflow-run-manager. ReportingListener calls ExportRunsToKar to auto-generate a kar after execution is complete. We added this mainly for the benefit of headless kepler users. Since this bug is not on the wrp target I'm going to leave it alone for now. I think the solution is to move ReportingListener into reporting, and move the the kar creation and potential upload out of ReportingListener's wrapup() and into workflow-run-manager. While we're at it, it would be nice to drive this generation and upload of a kar for headless kepler off a user-given parameter. It should probably also be possible for reporting to generate and upload a kar for headless kepler as well, independent of wrm (i.e. a kar with a workflow and reporting artifacts, but no run).

Actions #4

Updated by debi staggs over 14 years ago

Hi Derik,

I see that you were working on this, are we intending to do take the steps you described in your last comment before the WRP release ?

Actions #5

Updated by Derik Barseghian over 14 years ago

I think it would be really optimal to have Reporting work on its own when we release wrp-2.0. This would be more consistent. A user could change to any suite that wrp utilizes, instead of having to know wrp utilizes 1 suite that they can't change to. If it's possible to not show reporting as a suite that can be changed to in the module manager (?), this would be much less unsavory, though still unfortunate and confusing. We can move this to the wrp 2.0 target and attempt to fix this if the group thinks it's worthwhile -- during a past reap call I got the impression we decided to delay.

Actions #6

Updated by David Welker over 14 years ago

If reporting is no longer working independently, it should be converted from a suite to an ordinary module. That involves doing nothing more than deleting modules.txt and editing any modules.txt that refer to it as a suite to refer to it as a module and also incorporating whatever modules this points to.

As far as the module manager goes, it is possible to release it as a module, even if it is a suite. In this case, it would not show up as a suite in the module manager.

Overall, it is desirable to convert suites to modules. A suite should be something that is desirable to change-to. All the choices of suites in the module manager should be meaningful as well as desirable to switch to. This goes as well for the ant list-suites command. So, if one once had something as a suite for development purposes, but overtime it evolves into something that is just a helper module for another suite, one should not hesitate to convert that suite to a module.

If wrp developers agree, I would be glad to do this conversion for you.

Actions #7

Updated by Derik Barseghian over 14 years ago

Thanks for the offer David, but I'm going to try to get Reporting working on its own again hopefully doing away with the need for the WRP suite altogether in the process (the user who wants the functionality represented by wrp will just select both reporting and workflow-run-manager w/ the module manager) by trying to refactor as described in comment#3.

Actions #8

Updated by Derik Barseghian over 14 years ago

Thanks for the offer David, but I'm going to try to get Reporting working on its own again hopefully doing away with the need for the WRP suite altogether in the process (the user who wants the functionality represented by wrp will just select both reporting and workflow-run-manager w/ the module manager) by trying to refactor as described in comment#3.

Actions #9

Updated by Derik Barseghian over 14 years ago

should be fixed in trunk and 2.0.

reporting is the "new wrp" and depends on workflow-run-manager now, and the wrp suite has been deleted in trunk and 2.0 branch.

It wasn't going to be easy/quick to keep Reporting and Workflow Run Manager independent because ReportingListener writes its files into provenance during wrapUp, and then ExportRunsToKAR (which would have to be moved into WRM) would want to export the kar, similarly probably invoked from a wrapUp in WRM, but I couldn't find an easy way to guarantee WRM's wrapUp would be called after RL's in both the gui and headless -- these are called in the order in which the initializables are added to the list. So I made reporting depend on workflow-run-manager, which I believe everyone is ok with anyways.

Actions #10

Updated by Redmine Admin over 11 years ago

Original Bugzilla ID was 4938

Actions

Also available in: Atom PDF