Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> I hope we can find a solution which will not break current usage.
>> Maybe, a new XML element could be defined which explicitly defines the
>> class path, and which, if present, would stop the lib directories from
>> being scanned for jars to add to the classpath.
>>
>
> I hope nobody is relying on this behavior. It's not documented,
>
I think it may be: see section 7.1.2.2 - where it says:
Required Environment variable settings. This is where you specify
special CLASSPATH paths.
You do not need to specify this for any Jar that is listed in the your
eclipse project classpath settings; those are automatically put into the
generated CLASSPATH.
> and I think it's just a bug. There is an xml element defining
> the classpath, which is always present. That's what makes this
> behavior so confusing!
>
I could not find a simple XML element in the pear descriptor for setting
the class path. The docs say to set this using an environment variable
setting, for the environment variable CLASSPATH. The XML I think for
this would look like:
<INSTALLATION>
<PROCESS>
<ACTION>set_env_variable</ACTION>
<PARAMETERS>
<VAR_VALUE>$main_root/bin;</VAR_VALUE>
<VAR_NAME>CLASSPATH</VAR_NAME>
</PARAMETERS>
</PROCESS>
</INSTALLATION>
What I was suggesting is to avoid having an issue, by defining a new XML
element, called <CLASSPATH> or something similarly simple and obvious; e.g.:
<CLASSPATH>$main_root/bin;</CLASSPATH>
from the example above.
-Marshall
> --Thilo
>
>
>> -Marshall
>>
>> Thilo Goetz (JIRA) wrote:
>>
>>> Pear runtime pulls in all jar files in pear lib directory, no matter if
>>> they're on the classpath or not
>>> -------------------------------------------------------------------------------------------------------
>>>
>>> Key: UIMA-1273
>>> URL: https://issues.apache.org/jira/browse/UIMA-1273
>>> Project: UIMA
>>> Issue Type: Bug
>>> Components: Core Java Framework
>>> Affects Versions: 2.2.2
>>> Reporter: Thilo Goetz
>>> Fix For: 2.3
>>>
>>>
>>> The pear runtime will not only use the classpath as defined in
>>> metadata/install.xml, it will also pick up any jar in the lib directory.
>>> It even recurses down into subdirectories. This is undocumented, and most
>>> unexpected.
>>>
>>> I chatted with Michael about this. He thinks it may be because the same
>>> code that creates the classpath in the pear packager is used in the
>>> runtime. The packager does collect all jar files it can find and puts them
>>> in the classpath, and the pear file. That's fine for the packager, but not
>>> the runtime. We should *either* have an explicit classpath, *or* use all
>>> jar files in the lib dir, but not both.
>>>
>>>
>>>
>
>
>
>
