The patch that targets 3.8 API uses a provisional API instead of the
internal interface. But breaking compatibility with 3.7 is the
trade off.
Cheers,
Pawel
On 12/12/2011 01:01 PM, Schaefer, Doug wrote:
Thanks, Eugene.
I notice the patch still uses internals. It would be nice if
we could avoid that, if possible.
Doug.
I'll
have a look and commit the fix.
Thanks,
Eugene
From:
tcf-dev-bounces@xxxxxxxxxxx
[mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf
Of Pawel Piech
Sent: Monday, December 12, 2011 11:49 AM
To: TCF Development
Subject: Re: [tcf-dev] Build errors in master -
ITreeModelContentProviderTarget
Done,
Of course someone will need to commit the fix.
Cheers,
Pawel
On 12/12/2011 11:05 AM, Schaefer, Doug wrote:
I think that
would help the TCF adopters, at least in the short term.
Thanks!
The patch that i included will work
only against 3.8/4.2, but I suggested another option that
would work against both. I can make a patch for the
latter if that's what's required.
-Pawel
On 12/12/2011 10:56 AM, Schaefer, Doug wrote:
Thanks,
Pawel. Will the fix for TCF also work against 3.7 or are
we forced to move to 3.8/4.2?
Hi Doug,
The breakage is a result of a refactoring I did in the
flexible hierarchy viewers. While we've come a long way
in avoiding use of platform internals there were a few
things in the debug views which we could not yet do with
public APIs and this refactoring should fix that.
I filed bug
366124 last week to address the break in TCF, and
I filed
bug
366446 just now to address the tests bug. The
tests plugin is not included in the nightly build, so it
shouldn't hold up M4, but I have a fix for it and I'll
commit it now that Platform M4 is out.
-Pawel
On 12/12/2011 10:08 AM, Schaefer, Doug wrote:
Hey gang,
I’ve attempted our first build of CDT
and TCF masters against Eclipse 4.2 and found a number
of build errors.
ITreeModelContentProviderTarget
appears to be gone (or did it move?). I see lots of
references on the cdt.tests.dsf plug-in. I also see it
being used in the tcf.debug.ui plugin which is a bit
more concerning. And either way, this was an internal
class we should never have been using to begin with.
Does anyone have an idea on how to
address this?
Thanks,
Doug.
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev
|
