Hello,
thanks for pointing this out. I don't think its a big deal for
most users, but we should of course fix it for the next release.
The issue UIMA-3133 Marshall created describes the problem nicely.
There are a couple of other issues that need to be fixed, like UIMA-3134
(was reported already some time ago) and we probably also want to add
support
for CPE descriptors. The people over at cTAKES use them for their
pipelines, I think
it might be more convenient for them if they could launch and debug them
directly
from eclipse without using our old tools.
Jörn
On 07/31/2013 05:25 PM, Peter Klügl wrote:
Hi,
I can apply my changes to the launcher plugin, but I really like to know
Jörn's opinion on this. I think he implemented the plugin and maybe I
missed something.
Best,
Peter
On 31.07.2013 17:03, Marshall Schor wrote:
Hi,
Thanks for that clear explanation.
I think the reason I don't see the issue when running in my test scenario, is
that the AE Descriptor under test was in a project which already included a
build-path dependency on uimaj-core. So, the launcher had already added
uimaj-core to the class path :-).
I think your analysis is correct. I think that the launcher will need just the
uimaj-core jar from the uimaj-ep-runtime plugin, so I might just add that. Any
other parts of the uima framework that the "launched" thing might need, would be
the-launched-thing's own responsibility to include on Eclipse build path (which
the launcher makes part of the launched process's classpath).
-Marshall
On 7/31/2013 10:17 AM, Peter Klügl wrote:
Hi,
nope, there is no other posting.
I haven't had the time yet to investigate my assumption, especially
because I have no ready to use example.
Let me explain my assumption:
- I had a problem with the new layout (inlined jars) of the runtime
plugin in the Ruta Workbench, to be more precise, with the classpath
generated by the launch delegate
- the new Ruta launcher was strongly inspired by the AE Launcher plugin
concerning how the classpath of the new vm is generated
- I fixed the problem for the Ruta launcher
- the AE launcher code hasn't changed, therefore there might still occur
the same problem
About the problem in
AnalysisEngineLaunchConfigurationDelegate.getClasspath():
If not in development mode, the classpath is expanded by adding the jar
of the bundles (e.g., runtime):
extendedClasspath.add(pluginIdToJarPath("org.apache.uima.runtime"));
I suppose that this does not work for inlined jars (e.g.,
uimaj-core.jar) and causes ClassNotFoundExceptions or similar.
If in development mode, the classpath is expanded by adding the jar entries:
Bundle bundle =
LauncherPlugin.getDefault().getBundle("org.apache.uima.runtime");
if (bundle != null) {
Enumeration<?> jarEnum = bundle.findEntries("/", "*.jar", true);
while (jarEnum != null && jarEnum.hasMoreElements()) {
URL element = (URL) jarEnum.nextElement();
extendedClasspath.add(FileLocator.toFileURL(element).getFile());
}
}
I solved the problem in the Ruta launcher by simply adding the second
code part to the first one. This actually resolves the jars within the
bundle and add them to the classpath.
Overall, the question is whether jars within jars that are listed in the
classpath are correctly resolved by the vm.
Best,
Peter
On 31.07.2013 15:05, Marshall Schor wrote:
Hi,
Sorry if I missed a posting elsewhere about what the issue was; can you point me
to it, or describe it (and the fix :-) ) in a reply?
-Marshall
On 7/29/2013 7:07 AM, Peter Klügl wrote:
Hi,
I would assume that the launcher plugin does not work with the new
layout of the runtime plugin, to be more precise, with an installed
version of the runtime plugin. However, I haven't tested it yet and my
concerns are only grounded on the problems with the ruta launcher.
Best,
Peter
