Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Framework Dependencies #5

Open
greenwoodma opened this issue Jun 13, 2017 · 5 comments
Open

Remove Framework Dependencies #5

greenwoodma opened this issue Jun 13, 2017 · 5 comments

Comments

@greenwoodma
Copy link
Member

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
Copy link
Member

reckart commented Jun 13, 2017

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
Copy link
Member Author

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
Copy link
Member

reckart commented Jun 13, 2017

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
Copy link
Member

reckart commented Jun 13, 2017

Some additional things to consider:

  • the native APIs (e.g. UIMA) provide type safety and a certain degree of validation of the descriptors being read - something we don't have with Groovy or simple XML parsing
  • I believe that neither GATE nor UIMA descriptors have changed incompatibly in the last 10 or more years

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 reckart added enhancement and removed bug labels Jun 13, 2017
@reckart
Copy link
Member

reckart commented Jun 13, 2017

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.

@reckart reckart modified the milestone: 0.1.0 Sep 3, 2017
@reckart reckart modified the milestones: 2.0.2.0, 3.0.2.0 Jan 9, 2018
@reckart reckart removed this from the 3.0.2.0 milestone Mar 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants