Skip to main content

[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




Back to the top