Am 14.11.2012 01:30, schrieb Neil Bartlett:
> I really feel that the problem is in the launcher, so that's where it
> needs to be fixed, i.e. by setting the osgi.parentClassloader=app system
> property.
I agree. So the wrong property is only used if the Equinox is launched
using the binary executa
equinox-dev,
IPZilla records show that one or more of the projects on which you are
developer are in need of attention. The following CQs have been in the
'awaiting_project' status for over 3 weeks and need your team to take
action.
rt.equinox:
6484 Apache Felix Resolver -- checkintocvs,
I agree with BJ that it would be better to use an Equinox-specific
directive for this Equinox-specific functionality. I believe that Felix
should work fine today with the following:
Fragment-Host: system.bundle;x-appclasspath:=ext
because it would ignore the unknown directive, and would provi
Am 13.11.12 23:42, schrieb BJ Hargrave:
>> > Fragment-Host: system.bundle; extension:=extclasspath
>>
>> Would this extension:=extclasspath cause problems to other
>> OSGi-Implementations like e.g. felix?
>
> A compliant framework should reject this manifest since the standard
> directive does not
> > Fragment-Host: system.bundle; extension:=extclasspath
>
> Would this extension:=extclasspath cause problems to other
> OSGi-Implementations like e.g. felix?
A compliant framework should reject this manifest since the standard
directive does not specify a valid value.
If you are thinking of
Hi,
Following up my last mail on all this stuff. I had a meeting on IRC with
Tom Watson, discussing how one could make use of none public packages.
Normally I'd say to anyone that they should not use them because they
are an implementation detail of your JRE. The problem as it looks like
today is
