Embed the required StateFactory implementations #455
Conversation
|
Beside the zip packaging problem this seem to not break anything @merks do you want to give it a try with Ooomph? @tjwatson what do you think? I know it is not nice to copy the code, but it seems unlikely P2 will ever be able to move away from the API interface and at least we can strip down everything to the bare minimum P2 is actually using here (e.g. it never uses a It seems without a state this always operates in "nonstrict mode" and we can even remove all code pathes that work on "strict" checks. |
|
It appears to cause no breakage for Oomph... |
|
One option would be if we move the fragment to P2 instead of copy one can simply link the sources here, see |
laeubi
force-pushed
the
do_not_require_compat
branch
from
5dd7e82 to
cc618f7
Compare
laeubi
force-pushed
the
do_not_require_compat
branch
from
cc618f7 to
062505f
Compare
| @@ -33,12 +33,15 @@ Import-Package: org.eclipse.equinox.app;version="[1.0.0,2.0.0)", | |||
| org.eclipse.equinox.simpleconfigurator.manipulator;version="[2.0.0,3.0.0)", | |||
| org.eclipse.equinox.spi.p2.publisher, | |||
| org.eclipse.osgi.framework.util, | |||
| org.eclipse.osgi.internal.framework, | |||
There was a problem hiding this comment.
Importing of internal packages should not be done for this.
|
I'm not convinced making a copy here helps much with anything vs. using the APIs and implementation fragment as they are today. |
The API will still be used (as we can't change this much) but the implementation (compatibility fragment) will not be required anymore as P2 don't really wants the "real" implementation, in fact is only uses that to parse the MANIFEST and provides that as a structured way to access the information. So one can also reimplement that, but copy whats already there seems to be a faster approach. |
Currently P2 has the BundleDescription in its API where the only implementation is in the discouraged osgi.compatibility fragment, but actually P2 does not really need a full implementation, it is just using that to parse manifest headers and generate metadata from it. This embeds a stripped down version of the actual implementation in the p2.publisher.eclipse that allows to create implementation objects without rely on the compatibility fragment anymore.
laeubi
force-pushed
the
do_not_require_compat
branch
from
062505f to
f74d051
Compare
|
|
||
| import java.lang.reflect.Constructor; | ||
| import java.util.*; | ||
| import org.eclipse.osgi.internal.framework.EquinoxContainer; |
There was a problem hiding this comment.
Should not import this internal for the constant. And you seem to have an EquinoxContainer class in this statefactory you can use.
| import java.util.*; | ||
| import org.eclipse.osgi.internal.framework.EquinoxContainer; | ||
| import org.eclipse.osgi.internal.framework.FilterImpl; | ||
| import org.eclipse.osgi.internal.messages.Msg; |
There was a problem hiding this comment.
Should not use the frameworks internal NLS classs Msg
| import java.util.Collections; | ||
| import java.util.HashMap; | ||
| import java.util.Map; | ||
| import org.eclipse.osgi.internal.framework.FilterImpl; |
There was a problem hiding this comment.
Should use FrameworkUtil.createFilter instead of using the internal FilterImpl of the framework.
Currently P2 has the BundleDescription in its API where the only implementation is in the discouraged osgi.compatibility fragment, but actually P2 does not really need a full implementation, it is just using that to parse manifest headers and generate metadata from it.
This embeds a stripped down version of the actual implementation in the p2.publisher.eclipse that allows to create implementation objects without rely on the compatibility fragment anymore.
This is currently work in progress and a way to track progress, the classes can most probably stripped down even more and currently depends on some equinox framework internals that probably should either be inline as well or an alternative should be chosen.