Re: [Dltk-dev] Internal packages, API and rules

[Simon Bernard <sbernard@xxxxxxxxxxxxxxxxxx>]

Hi,
  I'm not directly involve in DLTK development, but personally I prefer the x-internal package solution.
  I know in perfect world clients of your API should not need to access to internal package, but sometime in real world this could help.
  People we will do that know that this is not "clean" because of warning. They know they are exposed to internal API break. Let them choose if it's ok or not in function of their situation.
Simon

Le 01/10/2015 14:35, akurtakov a écrit :

Good, that's what I thought too but decided to check just to be sure.

Regards,

Alex

On Thu, Oct 1, 2015 at 3:31 PM, Alexey Panchenko <alex.panchenko@xxxxxxxxx> wrote:

Hi,

There must be standard Eclipse rules somewhere in wiki.

Exporting internal packages was probably not a feature, but an easy workaround without doing lots of changes to the whole codebase. Most of those happened long ago in CVS, which doesn't support moving files, so exporting some internals was easier, as history of those files wasn't lost.

In the new project it would make sense to stricter follow the rules and export only public packages. If something needs to be exposed to users, then it should be moved our of internal package then.

Regards,

Alex

On Thu, Oct 1, 2015 at 5:29 PM, akurtakov <akurtakov@xxxxxxxxx> wrote:

Hi,

Sh module is finally in, hooked in the builds, first round of sonar issues reviewed and etc.

Now it's time to think of API. Are there any written rules how DLTK project handles that?

From my observations current state is keep internal packages exported in the manifest without a clear preference whether they should be marked as x-internal or not.

For the SH module I would like to not even export internal packages (there aren't any currently but I plan to hide most of them and open on case by case analysis). Fine with that?
If not I'm going to mark all org.eclipse.dltk.sh.internal.* packages as x-internal to keep warnings on for people that would decide to use them.

Regards,

Alex

_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/dltk-dev

_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/dltk-dev