Re: AE Launcher Plugin

[Jörn Kottmann <ko...@gmail.com>]

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

Re: AE Launcher Plugin

[Marshall Schor <ms...@schor.com>]

Just in case you were "copying" the (buggy) fix I did for the AE Launcher plugin
- It's now fixed (better) - see the Jira.   (Wasn't working if the launch was
via development-mode, and I added the arguments and source tabs).

-Marshall

On 8/1/2013 8:10 AM, Peter Klügl wrote:
> On 01.08.2013 10:09, Jörn Kottmann wrote:
>> 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.
>>
> +1
>
> The Ruta Workbench does not support CPEs yet, but that would be history
> if the AE launcher does :-)
>
> Peter
>
>> 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
>>>>>>>
>

Re: AE Launcher Plugin

[Peter Klügl <pk...@uni-wuerzburg.de>]

On 01.08.2013 10:09, Jörn Kottmann wrote:
> 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.
>

+1

The Ruta Workbench does not support CPEs yet, but that would be history
if the AE launcher does :-)

Peter

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