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
>>>
>
