openminted / omtd-share-annotations

Java annotations and a Maven plugin to automatically generate OMTD-SHARE metadata.
https://openminted.github.io/releases/omtd-share-annotations/
0 stars 1 forks source link

Remove Framework Dependencies #5

Open greenwoodma opened 7 years ago

greenwoodma commented 7 years ago

I think it is a mistake for this code to depend on any of the frameworks it supports (i.e. GATE, UIMA etc.). The issue is that we would tie this code to a given version of each framework which would make it difficult (maybe impossible) to process components from different versions of a framework within a single JVM instance.

The GATE based code in this project doesn't depend on GATE but simply parses the standalone creole.xml file as an XML file. I feel the UIMA based analyser should take the same approach.

This suggestion actually matches nicely with the OMTD recommendations to have fully specified but separate component metadata that can be used without access to the framework.

reckart commented 7 years ago

So what I wanted to do was moving the framework-specific parts into separate modules. Thus, it would also be possible to have e.g. a module for "gate2", "uima5", etc. And if somebody runs the plugin, the user would add the specific modules as dependencies to the plugin declaration.

But atm, that is not my priority - first stuff has to be working.

greenwoodma commented 7 years ago

Yes, certainly not a priority, more of a brain dump from me. Having said that I still think the approach is dangerous. It would work for the case where this is all run just as part of a Maven build, but as soon as we want to use the code outside of that context (inside the registry for instance) then it falls apart as trying to have multiple versions of each framework on the classpath will be impossible.

reckart commented 7 years ago

Btw. have a similar problem with the JAXB classes from the omtd-registry-api. E.g. there is no way to support OMTD-SHARE 1 and 2 at the same time.

Juggling with XML in Java is hellishly verbose. It could be an option going to Groovy again for this.

reckart commented 7 years ago

Some additional things to consider:

Maybe a JAXB-based parsing would be a suitable option. At least some validation and type safety. Also probably don't need much changes to the code after the first implementation since the descriptors hardly ever change.

reckart commented 7 years ago

Since it is more of a brain-dump than a prio, I'll make this an enhancement. After all, it works as desired - although could be improved.