I think they’re placed into that state if they are lazily started, i.e. they
have a BundleActivationPolicy of ‘lazy’.
http://www.osgi.org/Design/LazyStart
http://wiki.osgi.org/wiki/Bundle-ActivationPolicy
I think it goes from ‘starting’ to ‘started’ when classes have been loaded from
the bundl
Hi,
I frequently see lots of bundles remaining in the life cyle status
"Starting". Is this expected? I would assume that "Starting" is a temporary
status and that once a bundle has finished starting, it becomes "Active".
Best regards, Lars
--
Eclipse Platform and e4 project co-lead
vogella Gmb
Hi,
[...]
> But you mention that using the boot class loader as the parent class
> loader for bundle class loaders causes problems for Nashorn. I fail to
> see why that is.
I don't know the inner details but if you run this app
> package samplenashornosgi;
>
> import javax.script.ScriptEngi
I think you miss-interpret what I am saying. The framework, Equinox or Felix have no control over what class loader is used to load the framework implementation. That is up to the launcher. Forever the Eclipse launcher has set the default parent class loader of the class loader used to load the
I think we had the same discussion about a year ago:
Bug 436469: Declare compile-time (build-time) dependencies in manifest
Bug 434243: Import org.eclipse.osgi[.services] as source => compile errors
for missing @ConsumerType
The problem is still the same: Stephan and I think that builds
a) shoul
This is not helping.
On 05/07/2015 05:21 PM, BJ Hargrave wrote:
> User has an arbitrary plugin project which obviously depends on o.e.osgi.
Well I would say that no one should depend upon org.eclipse.osgi. It is an
implementation of the OSGi core spec. If you are writing
bundles, then you are
> From: Stephan Herrmann
> I was asking about the following scenario:
>
> User has an arbitrary plugin project which obviously depends on
o.e.osgi.
Well I would say that no one should depend upon org.eclipse.osgi. It is an
implementation of the OSGi core spec. If you are writing bundles, then
I was asking about the following scenario:
User has an arbitrary plugin project which obviously depends on o.e.osgi.
I'm not speaking of building o.e.osgi, but about consuming.
In the workspace s/he has references to o.e.osgi as jar with source attachment.
When the user browses / inspects types
> From: Stephan Herrmann
> I've observed, that JDT has problems working with class file
> plus source attachment of org.osgi.framework.Bundle et al.
> Reason: when compiling the attached sources we can't find
> the annotation type org.osgi.annotation.versioning.ProviderType.
> I see that Equinox
Hi,
On 05.05.15 16:05, Thomas Watson wrote:
> Please open a bug to track the issues. I assume you are having to set
> the configuration property osgi.frameworkParentClassloader=ext to get
> this to work on Java 9?
Yes
>
> I still believe the default 'parent' class loader for bundles should be
https://bugs.eclipse.org/bugs/show_bug.cgi?id=466683
Tom
On 06.05.15 15:14, Daniel Megert wrote:
>> Please open a bug to track the issues.
>
> Tom, please post the bug here.
>
> Thanks,
> Dani
>
>
>
> From:Thomas Watson
> To:Equinox development mailing list
> Date:0
11 matches
Mail list logo
