Re: [ecf-dev] ECF Feature Restructuring

[Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>]

On 12/04/2013 06:54 PM, Scott Lewis wrote:
> 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.

> 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).

Where is this discussion happening? p2-dev or on a bug?


> 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' :).


I'm fully aware that this is a breaking change. The bug I linked to
targets ECF 4.0.


> 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).

I'd say that pretty much all the code that has UI dependencies can be
deleted from master as well as all broken providers.

M.