[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] ECF Feature Restructuring
|
On 12/4/2013 9:23 AM, Markus Alexander Kuppe wrote:
On 12/03/2013 08:35 PM, Scott Lewis wrote:
4) Make it possible for people to consumer/use all necessary parts of
ECF without conflict from Eclipse (i.e. because of ECF's usage as part
of p2)
Hi,
I find this to be the hardest part to accomplish and I'm unsure of what
the possible fix is (might wanna get platform into this discussion?).
Well, I have involved the folks on p2-dev...and now David Williams is
involved as well (simultaneous release master). So we'll probably find
the right people eventually. :)
One of the fundamental problems I see is the fact that the platform
ships two of our most basic bundles
(org.eclipse.ecf/org.eclipse.ecf.identity) essentially controlling the
release cycles of these two. Unless platform/p2 completely overhauls
their current build and feature structuring along to the contribution
process (which I'm skeptical about due to too many stakeholders
involved)
Yes, this is a fundamental problem with the way that ECF is
consumed...but given what the p2ers have said, I think that they may
indeed overhaul the ECF contribution piece. Particularly since the
platform build was recently overhauled already...i.e. to move to using
Tycho/Maven to build (I believe).
I personally think we have to find a way to run multiple
version of o.e.ecf and o.e.ecf.identity in a single OSGi runtime. Then,
we can simply install whatever version of o.e.ecf/.identity ECF proper
needs and co-exist with platform's version.
For that though, we have to remove all Extensions and ExtensionPoint
from ECF [1]
I don't really think this will be doable without a major (API breaking)
release from ECF (i.e. 4.0.0). And WRT the p2/releng process
specifically...it seems like overkill to me.
I accept that it will have some advantages as you describe below
(although I don't see 1 and 3 as that problematic anymore...i.e. I think
that Easier support for non-Equinox frameworks is the driving use
case). But again...I'm doubtful (even with a lot of work), that it can
be accomplished without API breaking changes and so don't think it can
be done for 3.8. And truthfully, it will involve a lot of work from me
to accomplish this...without sponsorship I don't think I'm going to have
the bandwidth for it over the next few months...especially since I'm
going to be working on the feature restructuring, remote services
tutorials, docs, papers, examples...as well as OSGi standards/rfc
compliance...in addition to 'paying work' :).
(a technology that is super-seeded by OSGi services
anyway). We then also get for free:
- No singleton directive in any of ECF's bundles
- Easier out-of-the-box support for ECF on non-Equinox frameworks (no
supplement bundle necessary)
- No obscure ClassCircularityErrors caused by cyclic classloading
trigger by both the ExtensionPointRegistry and OSGi services
Initially this might cause a lot of work, but the benefits will IMO
out-weight the efforts.
To get started, we should also remove/move away all old parts of ECF
that are no longer maintained (this will also lower the barrier to
entry). Then we get a better picture of what actually uses EPs.
I don't have any objections to moving things out...or perhaps rather
moving to distinct features...since in some cases we can't really know
what's being used or not. And for things that truly are no longer
maintained...yes, removal...but I'm not aware of that much that is
really no longer maintained (at Eclipse.org anyway).
Another consideration that we should discuss: The
interaction/coordination of our EF releases with releases of parts of
ECF (e.g. JMS-based providers, etc) currently hosted in our github repos
[1].
Scott
[1] http://github.com/ECF
