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