-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
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. |
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. |
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. |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: