Removing groovy jar from core

Development
1

As part of

we had removed the groovy jar from core, we do realize that several modules possibly have a transitive dependency on groovy through core, what is your opinion on removing it vs keeping it in core?

2

I know that Groovy is used in at least:

  • reporting
  • uiframework
  • htmlformentry
  • groovy
  • hl7query
  • providermanagement
  • patientflags

Four of these are in the Reference Application.

It seems wasteful to force each of these modules to include groovy individually and make their OMOD files 6.7MB larger each, not to mention the increased memory requirements it would bring to OpenMRS if we’re loading a separate copy of all the groovy classes and engines for each module.

One option would be to have a “groovy dependency” module which provides (only) the groovy-all.jar (and this module can be versioned with the groovy version it contains). Thus other modules could rely on this one. (This is a more OSGi-like approach, and not what OpenMRS has typically done.

That said, we’ve done fine having a single (old) Groovy version in (first) the logic modules, and (then) openmrs-core, for many years, so my vote is to do it the easy way and just leave it in openmrs-core (but upgrade it to a modern version).

3

I was also initially inclined to want to keep this in core.

On the other hand, the groovy module itself is pretty lightweight and incredibly useful. If we were to create a groovy dependency module, I would vote on just making it this one and including the groovy jar in there.

An additional benefit of using the groovy module in this way is that groovy script editor fragments and service/utility methods for evaluating groovy snippets could be consolidated into a common library of components and best practice tools. That might be reason enough to move to this approach.

Thoughts?

4

Interesting idea. But actually now that I look on github I see that HFE, Reporting, and App Framework all use javax.script.ScriptEngine rather than Groovy directly. So doing what you literally suggest would actually tend to make things less clean.

The better route (though a bit more work) would be to make a Scripting module or function in core, that supports storing and evaluating any kind of scripting language that Java supports, using javax.script.ScriptEngine, and make the Groovy module just be an implementation of this.

5

+1 for keeping it in core for now… :slightly_smiling:

6

This was the direction I wanted to go with the Groovy module – i.e., create a “scripting” module that would be a headless service supporting JSR 223 that would allow various scripting engines to be installed, provide an easy scripting interface for other modules to register & run scripts, make it easy to run scripts with useful bindings (like the Groovy module does), and manage running scripts (e.g., an admin view to see running or recently run scripts, control their memory/CPU usage, kill runaway scripts, etc.). Unfortunately, I didn’t see ways in javax.script.* to manage these things (interrupting scripts, controlling script resource usage, etc.).

I’d favor either of these approaches:

  • Put groovy-all jar back into the Platform. (easiest option)

  • Make a scripting module that just includes the groovy-all jar and then have other modules depend on this. (would require adding a dependency to modules needing groovy)

I’d be less excited about making modules depend on the groovy module.

1 Like
7

Looks like more people are in for keeping it in core

8

Following up on this, since no one has responded to my previous reply, i will assume everyone is okay with adding back groovy in core, in any case it’s the best option given we are not far away from a 2.0.0 release

1 Like