Re: [cdt-dev] Package visibility

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

Since there was no opposition and one supportive answer (thanks Sergey :)),

I'll be making the o.e.cdt.dsf.gdb.multicorevisualizer packages internal, and

putting a bunch of API filters.  I will document this on the N&N to explain

that although we're releasing CDT 8.2, this change is not backwards compatible.

As mentioned before, the Visualizer is very young and I don't expect that

anyone is extending it yet.  We plan on evolving it a lot, and having it as

API would be very limiting.

 

For the curious, the Gerrit review is at:

https://git.eclipse.org/r/10255

 

Thanks

 

Marc

---

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sergey Prigogin
Sent: Wednesday, January 16, 2013 1:18 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Package visibility

+1 for making an exception.

-sergey

On Wed, Jan 16, 2013 at 10:15 AM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Dumais
> Sent: Wednesday, January 16, 2013 1:11 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] Package visibility
>
> Hi,
>
> While working on adding CPU load information to the multicore
> visualizer
> (396268), I had to add a method to the interface
> org.eclipse.cdt.dsf.gdb.multicorevisualizer.internal.utils.DSF
> DebugModelListener.
>
>
> When I did, I got an error in Eclipse that the interface is
> an API that
> intends to be implemented.   Looking in the plugin.xml, it seems that
> even if the package
> "org.eclipse.cdt.dsf.gdb.multicorevisualizer.internal.utils" has
> "internal" in its name, the package visibility doesn't
> reflect that. So
> technically I am breaking the API by adding a method to
> DSFDebugModelListener.
>
> Any ideas/suggestions on how best to proceed?

Doh!  When we created this package I didn't realize that we had
to set the visibility to hidden.  I just thought using the string
"internal" was the trigger for making the package internal.

This was meant to be internal from the start.  Are we stuck
with it as API, or can we get away with marking it hidden now?
I don't expect anyone to be using this, but officially it would
break the API.

Any opinions for CDT 8.2?  Can we make an exception in the API
tooling or do we have to live with the mistake?

I vote for making an exception, but I may be biased ;)

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev