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,
Now that Martin has gotten the Equinox weaving hooks back to a functional
state on the new Equinox framework I want to go back to my original
question:
For Luna will it be very disruptive if we introduce a breaking API change
for the implementers of the
org.eclipse.equinox.service.weaving.IWeavin
> From: Martin Lippert
> Hey Tom!
[stuff deleted]
> > If this proves to be an issue moving forward we can consider trying to
> > get BundleWiring.findEntries not to aggressively create a class loader.
> > But this is the kind of complication I am really trying to avoid in
> > the new impleme
Hey Tom!
I think I found the change in behavior here. I re-based the
implementation of Bundle.getHeaders() to be implemented using the OSGi
API BundleWiring.findEntries which ultimately uses the class loader of
the bundle if the bundle is resolved (and most all bundles better be
resolved). In
This is just a heads up that as part of the M7, I will be making API changes.
Here are the two things that I have in mind, which from my point of view are
completely transparent to the user
- Review the necessity of some of the constants I introduced on
IProfileRegistry - https://bugs.e
> From: Martin Lippert
> Hey Tom!
>
> I worked on your branch yesterday and today and got Equinox Weaving to
> work - which is great. So thanks a lot for making all those old hooks
> available!!!
Great, glad you got it working!
>
> I had to change a few things inside the equinox weaving hook fr
