radiology module: extract legacy-ui into own module

Development
,
1

Dear @sunbiz, @judy and everyone else interested in the radiology module,

as part of https://issues.openmrs.org/browse/RAD-59

I want to upgrade the radiology module dependency to the openmrs platform 2.0. So I can take advantage of features of updated versions of hibernate/spring and also build the module only for java8.

Now @sunbiz already agreed on the above issue.

The only thing that is left for debate is that I would like to extract the legacy UI webapp of the radiology module into a separate module which then has a dependency to the OpenMRS legacy UI module

My reason behind it is that I want to spare implementers from having to deploy the legacy UI if they do not want to use it. Same reason I guess why OpenMRS created the platform and extracted the legacy UI into a separate module.

Please let me know what you think, so I can start working on the issue :slight_smile:

2

My concern has always been the dependencies of the RefApp are so many and require a complicated workflow

No one should have to install the whole EMR to use the radiology module functionality

Significant work needs to be made to make the radiology module work with minimal effort from implementers

Just my 2 cents . I seem to be the only one not agreeable so we can go ahead with the platform despite my reservations

Judy

1 Like
3

I understand your concern, but the dependency on the EMR module is not related to this issue which is changing the openmrs-core dependency from OpenMRS core 1.11 to Platform 2.0. Dependency to EMR is a separate discussion. We can definitely talk about that and still revoke this decision.

Now for changing the openmrs-core dependency from OpenMRS core 1.11 to Platform 2.0:

To my knowledge, please correct me if I am wrong, Platform 2.0 is like OpenMRS core 1.12 but without the legacy UI. So it does not bring more dependencies.

So first the implementer installs the OpenMRS platform + the radiology module (the actual java api and in the future rest services). Then he decides on the UI he likes legacy, new OpenMRS ui framework or even a JavaScript based webapp. This freedom of picking the UI depending on the need is the goal.

To me having the legacy UI in the same project as the java+rest API just feels wrong since it mixes dependencies going forward. Since if you do not want to use the legacy UI, you should not be forced to install it.

4

I am 100 % in agreement . This is an excellent idea. I mistook the platform to mean the RefApp which i disagreed with initially

Judy

5

@sunbiz I would also like your blessing on this. please :slight_smile:

And if so could you also create an announcement like you did with renaming of the repo?

6

Sure, I think this is an excellent idea, now that Platform 2.0 is in beta. It is an ideal time to plan the move to depend on it and do future development of the module for platform 2.x

…and I do agree with @judy that the radiology module shouldn’t depend on the groovy gsp framework or the RefApp. I think it should be an OWA, with minimalistic design, with use of the Radiology REST APIs

1 Like
7

Perfect, should we call the repo for the radiology legacy ui: https://github.com/openmrs/openmrs-module-radiology-legacyui

? And should I create a ticket at the openmrs helpdesk for it?

8

yea, I like that name for the repo… Once the repo has been created, we can move the jsps and its related controller code out to that repo.

9

You would need to make your request in the Repo Management category; the OpenMRS.org Help Desk doesn’t manage GitHub repos. :slight_smile:

10

sorry. will do! thanks :slight_smile:

1 Like