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

[Simon Bernard <sbernard@xxxxxxxxxxxxxxxxxx>]

I think you're partially right.
I know this is not so black and white, but we could imagine there is people which are familiar with open source and people which are not.
The first one will use the internal API but they will report the issue to project developer too, the other will probably use the internal API in silence. But if the internal API is not accessible at all  they will probably go in a lot of duplicated code to workaround this, and you still not have your feedback :/.
There is also the case where the project is not so active as this was the case for DLTK few years ago. In this case you could report the issue to the community about the API issue, nobody will fix that.

All of this was just thought, I let you choose what you prefer, I just share my mind ;)

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

Hi Simon,

My only objection against x-internal is that people just use them without getting involved with the project to help getting proper API exposed and etc. And this is not good for the liveliness of a project.

Regards,

Alex

On Thu, Oct 1, 2015 at 3:49 PM, Simon Bernard <sbernard@xxxxxxxxxxxxxxxxxx> wrote:

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

_______________________________________________
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