You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Laszlo Kishalmi <la...@gmail.com> on 2018/09/22 00:01:24 UTC
Public vs. Friend API Reloaded (Summary)
Dear all,
I'd like to summarize whet happened on the "API Friendliness" issue:
We collected a number of possible options on our previous discussions at:
https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
Commenting these options remained really silent though. This means our
Friend APIs most likely stay as they are now.
I must acknowledge that adding new friends to an existing API is easier
than ever having NetBeans under Apache umbrella.
I plan not to give up on making some APIs public though. Regarding the
low interest of making something big around this area, I think the most
viable solution is:
Option 4: Make Module Public when There is more than a Certain Number of
Friend Dependencies.
So sometime in the future I'm going to create a list of how many friends
a module does have and share the list with you.
Thank you all who participated in this effort!
Laszlo Kishalmi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API Reloaded (Summary)
Posted by Neil C Smith <ne...@apache.org>.
On Sat, 22 Sep 2018 at 01:01, Laszlo Kishalmi <la...@gmail.com> wrote:
>
> I think the most
> viable solution is:
>
> Option 4: Make Module Public when There is more than a Certain Number of
> Friend Dependencies.
>
Slowly catching up on email post-holiday, so apologies for delayed response.
Firstly, I'm disappointed, but not surprised, there's not much impetus
and energy for really reviewing how module dependencies work per Jesse
Glick's proposal - there's a lot of work in there!
But, if we are sticking primarily with the status quo, with my
platform developer's hat on can I request we consider two minor
updates to Option 4 (or whatever we go with)
1. Remove the use of Friend APIs on all third-party modules. I kind
of understand why this was done, but it's a real PITA sometimes!
Perhaps wider discussion when introducing outside dependencies.
2. An opt-in switch to override friend dependencies externally, with
perhaps in the case of NBM's a corresponding manifest flag (unstable /
incubating) for plugins that do this? If we want people to contribute
to stablising APIs and documentation, it's cart before horse to expect
them to request a friend listing as the first step in utilising the
module. Opt-in for incubating features is good, no?! ;-)
http://openjdk.java.net/jeps/11
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API Reloaded (Summary)
Posted by Sven Reimers <sv...@gmail.com>.
I completely agree... (with my Groovy support hat on)
-Sven
Svata Dedic <sv...@gmail.com> schrieb am Sa., 22. Sep. 2018,
10:41:
> Hi,
>
> Sorry to disagree, but CSL APIs are bad example, but for another reason.
> The CSL API design is (IMHO) bad at its core: Language provides a great
> way for a new language support to start, but then it is almost
> impossible to plug in a new functionality from a 3rd party extension.
> Just try to plug in a supplemental completion handler, or add some
> addition things into structure view.
>
> Before CSL is stable/public API, it needs to be thoroughly reviewed,
> with focus on a clean and extensible design.
>
> -S.
>
> Dne 22.9.2018 v 10:10 Sven Reimers napsal(a):
> > Hi,
> >
> > csl is a good example. It is the backbone of most of the language
> supports
> > in NetBeans and could benefit from a stable API to make implementing
> > support for other languages easier - maybe something to pick up for
> > NetBeans 11?
> >
> > -Sven
> >
> > Geertjan Wielenga <ge...@googlemail.com.invalid> schrieb am
> > Sa., 22. Sep. 2018, 09:54:
> >
> >> On Sat, Sep 22, 2018 at 2:01 AM, Laszlo Kishalmi <
> >> laszlo.kishalmi@gmail.com>
> >> wrote:
> >>
> >>>
> >>>
> >>> Option 4: Make Module Public when There is more than a Certain Number
> of
> >>> Friend Dependencies.
> >>>
> >>> So sometime in the future I'm going to create a list of how many
> friends
> >> a
> >>> module does have and share the list with you.
> >>>
> >>
> >>
> >> That is a very good solution, I think.
> >>
> >> Gj
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>> Thank you all who participated in this effort!
> >>>
> >>> Laszlo Kishalmi
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> >>> For additional commands, e-mail:
> dev-help@netbeans.incubator.apache.org
> >>>
> >>> For further information about the NetBeans mailing lists, visit:
> >>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>>
> >>>
> >>>
> >>>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Public vs. Friend API Reloaded (Summary)
Posted by Tim Boudreau <ni...@gmail.com>.
An extension API is something that could be bolted on top of CSL pretty
simply as another layer. For example, an implementation of the semantic
highlighting interface that delegates to instances it finds in some lookup.
And repeat that pattern for everything else.
That would be straightforward to do, just a layer on top of it.
I was thinking about that last night, as I've written several things that
use Antlr 4 grammars with it, and have written a bunch of generic things
for, for example, generating TokenIds from an Antlr Vocabulary instance
(one problem for anyone extending a language is that someone has to expose
an API for their TokenIds - but you're better off looking them up by rule
name if the grammar ever changes). You could also do some things like
supplying pairs of delimiter tokens to a generic braces matcher.
Are there any cases a layer on top of CSL would not solve? If so, I don't
think that needs to be implemented as a part of the CSL api, though it does
need to be implemented.
I do think CSL is one of the big ones in terms of widely used friend APIs.
I'd rather have a plan to add an extensible layer on top of it than delay
until CSL reaches extensibility nirvana.
-Tim
On Sat, Sep 22, 2018 at 4:41 AM Svata Dedic <sv...@gmail.com>
wrote:
> Hi,
>
> Sorry to disagree, but CSL APIs are bad example, but for another reason.
> The CSL API design is (IMHO) bad at its core: Language provides a great
> way for a new language support to start, but then it is almost
> impossible to plug in a new functionality from a 3rd party extension.
> Just try to plug in a supplemental completion handler, or add some
> addition things into structure view.
>
> Before CSL is stable/public API, it needs to be thoroughly reviewed,
> with focus on a clean and extensible design.
>
> -S.
>
> Dne 22.9.2018 v 10:10 Sven Reimers napsal(a):
> > Hi,
> >
> > csl is a good example. It is the backbone of most of the language
> supports
> > in NetBeans and could benefit from a stable API to make implementing
> > support for other languages easier - maybe something to pick up for
> > NetBeans 11?
> >
> > -Sven
> >
> > Geertjan Wielenga <ge...@googlemail.com.invalid> schrieb am
> > Sa., 22. Sep. 2018, 09:54:
> >
> >> On Sat, Sep 22, 2018 at 2:01 AM, Laszlo Kishalmi <
> >> laszlo.kishalmi@gmail.com>
> >> wrote:
> >>
> >>>
> >>>
> >>> Option 4: Make Module Public when There is more than a Certain Number
> of
> >>> Friend Dependencies.
> >>>
> >>> So sometime in the future I'm going to create a list of how many
> friends
> >> a
> >>> module does have and share the list with you.
> >>>
> >>
> >>
> >> That is a very good solution, I think.
> >>
> >> Gj
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>> Thank you all who participated in this effort!
> >>>
> >>> Laszlo Kishalmi
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> >>> For additional commands, e-mail:
> dev-help@netbeans.incubator.apache.org
> >>>
> >>> For further information about the NetBeans mailing lists, visit:
> >>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>>
> >>>
> >>>
> >>>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com
Re: Public vs. Friend API Reloaded (Summary)
Posted by Svata Dedic <sv...@gmail.com>.
Hi,
Sorry to disagree, but CSL APIs are bad example, but for another reason.
The CSL API design is (IMHO) bad at its core: Language provides a great
way for a new language support to start, but then it is almost
impossible to plug in a new functionality from a 3rd party extension.
Just try to plug in a supplemental completion handler, or add some
addition things into structure view.
Before CSL is stable/public API, it needs to be thoroughly reviewed,
with focus on a clean and extensible design.
-S.
Dne 22.9.2018 v 10:10 Sven Reimers napsal(a):
> Hi,
>
> csl is a good example. It is the backbone of most of the language supports
> in NetBeans and could benefit from a stable API to make implementing
> support for other languages easier - maybe something to pick up for
> NetBeans 11?
>
> -Sven
>
> Geertjan Wielenga <ge...@googlemail.com.invalid> schrieb am
> Sa., 22. Sep. 2018, 09:54:
>
>> On Sat, Sep 22, 2018 at 2:01 AM, Laszlo Kishalmi <
>> laszlo.kishalmi@gmail.com>
>> wrote:
>>
>>>
>>>
>>> Option 4: Make Module Public when There is more than a Certain Number of
>>> Friend Dependencies.
>>>
>>> So sometime in the future I'm going to create a list of how many friends
>> a
>>> module does have and share the list with you.
>>>
>>
>>
>> That is a very good solution, I think.
>>
>> Gj
>>
>>
>>
>>
>>>
>>>
>>> Thank you all who participated in this effort!
>>>
>>> Laszlo Kishalmi
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>>> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>>>
>>> For further information about the NetBeans mailing lists, visit:
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>
>>>
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API Reloaded (Summary)
Posted by Sven Reimers <sv...@gmail.com>.
Hi,
csl is a good example. It is the backbone of most of the language supports
in NetBeans and could benefit from a stable API to make implementing
support for other languages easier - maybe something to pick up for
NetBeans 11?
-Sven
Geertjan Wielenga <ge...@googlemail.com.invalid> schrieb am
Sa., 22. Sep. 2018, 09:54:
> On Sat, Sep 22, 2018 at 2:01 AM, Laszlo Kishalmi <
> laszlo.kishalmi@gmail.com>
> wrote:
>
> >
> >
> > Option 4: Make Module Public when There is more than a Certain Number of
> > Friend Dependencies.
> >
> > So sometime in the future I'm going to create a list of how many friends
> a
> > module does have and share the list with you.
> >
>
>
> That is a very good solution, I think.
>
> Gj
>
>
>
>
> >
> >
> > Thank you all who participated in this effort!
> >
> > Laszlo Kishalmi
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> > For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>
Re: Public vs. Friend API Reloaded (Summary)
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
On Sat, Sep 22, 2018 at 2:01 AM, Laszlo Kishalmi <la...@gmail.com>
wrote:
>
>
> Option 4: Make Module Public when There is more than a Certain Number of
> Friend Dependencies.
>
> So sometime in the future I'm going to create a list of how many friends a
> module does have and share the list with you.
>
That is a very good solution, I think.
Gj
>
>
> Thank you all who participated in this effort!
>
> Laszlo Kishalmi
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Public vs. Friend API Reloaded (Summary)
Posted by Peter Nabbefeld <pe...@gmx.de>.
Am 23.09.18 um 19:35 schrieb Matthias Bläsing:
> Hi,
>
> Am Sonntag, den 23.09.2018, 19:23 +0200 schrieb Peter Nabbefeld:
>>> I think that having a reasonable documentation was traditionally
>>> one of the
>>> requirements for a public API modules. (I doubt csl.api went
>>> through the
>>> API review process.)
>>>
>> (next sentence is meant to be sarcastic):
>> So, if I'm too lazy to write some documentation, I get the benefit to
>> never need to think about how to do some changes, as nobody will get the
>> chance to use it.
> no - the USER of the code is to lazy to take part in the creation of
> documentation and stabilization of the API.
>
> Seriously - often the most vocal people do the least work and then
> complain, that the people doing the work don't follow their reasoning.
>
> Greetings
>
> Matthias
That's not the point, and You removed important context.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API Reloaded (Summary)
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
Am Sonntag, den 23.09.2018, 19:23 +0200 schrieb Peter Nabbefeld:
> > I think that having a reasonable documentation was traditionally
> > one of the
> > requirements for a public API modules. (I doubt csl.api went
> > through the
> > API review process.)
> >
>
> (next sentence is meant to be sarcastic):
> So, if I'm too lazy to write some documentation, I get the benefit to
> never need to think about how to do some changes, as nobody will get the
> chance to use it.
no - the USER of the code is to lazy to take part in the creation of
documentation and stabilization of the API.
Seriously - often the most vocal people do the least work and then
complain, that the people doing the work don't follow their reasoning.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API Reloaded (Summary)
Posted by Peter Nabbefeld <pe...@gmx.de>.
Currently, I'm "fighting" with some other problems, but I'll try to do
so ASAP. Currently it seems, I'll probably not have enough time to do so
before winter. :-(
Regards
Peter
Am 24.09.18 um 09:00 schrieb Jan Lahoda:
> I guess it's all about resources/time - if folks can make better
> documentation for an implementation (or friend) stuff, or add feature X and
> Y, but not both, they choose to do something, based on some criteria. Of
> course, someone may agree with the choice and other may not - but the best
> way to ensure things you consider important are done is to help to do them.
>
> So, I wonder, if you could document html.editor.lib, first because you may
> be the most knowledgeable of it here anyway, and also to set an example.
>
> Thanks,
> Jan
>
> On Mon, Sep 24, 2018 at 7:13 AM Peter Nabbefeld <pe...@gmx.de>
> wrote:
>
>> Too many nested comments inline already, sorry, so I try to summarize.
>> Please feel free to remove the discussion at the bottom, if You agree it
>> is not needed anymore.
>>
>> 1. I don't like documentation handled differently based on friend-state.
>> There should always be sufficient information on every module.
>>
>> 2. Most people will not be able to use a module with insufficient
>> information. As a result, information will be extended for public
>> modules only, because people start to try using them and ask for
>> information on points they don't understand. Friend-only modules will
>> not have any more support. So, many jewels will never be officially
>> become usable by the community.
>>
>> 3. I don't like to make the available documentation a criteria of the
>> friend-state. Just because I'd like to see more of the modules and even
>> the start phase of NetBeans documented. It would be great, if the
>> original authors would have done that, all the others need to look at
>> the often poorly documented code and find out, what the original author
>> wanted to do with it. In some cases this is far from being obvious. In
>> this case, it doesn't help much, that the code is open-source - You'll
>> also be unable to read some old texts, just because You cannot read the
>> letters.
>>
>> 4. Yes, the main stability criterium for APIs for me is no changes for
>> some time - it's usually an indicator, that it has been used
>> sufficiently. But, of course, if I want to use some API, I'll probably
>> find some problems.
>>
>> 5. Thinking about [4], the friend-state could probably be managed
>> easier-to-use, as a first step, e.g. adding sth. like
>> "personal.friends=module(s)-to-be-used-as-friend" in user.properties.
>> This could take the burden of cloning and building the whole NetBeans
>> for just trying some friend-only API. Probably, in this case don't build
>> nbm files but only install locally (deploy in running IDE or run a
>> separate IDE), so it cannot be pushed to plugin repository by accident.
>> Just an idea.
>>
>> 6. The possibility to extend HTML syntax using html.editor.lib is only
>> one of its possibilities, but that's only one of the affected modules,
>> so if we want to discuss that, we should use another thread.
>>
>> 7. Same for CSL/GSF/etc. - my fault. Thought You could help me with
>> these. Should have opened new thread.
>>
>> Kind regards
>>
>> Peter
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API Reloaded (Summary)
Posted by Jan Lahoda <la...@gmail.com>.
I guess it's all about resources/time - if folks can make better
documentation for an implementation (or friend) stuff, or add feature X and
Y, but not both, they choose to do something, based on some criteria. Of
course, someone may agree with the choice and other may not - but the best
way to ensure things you consider important are done is to help to do them.
So, I wonder, if you could document html.editor.lib, first because you may
be the most knowledgeable of it here anyway, and also to set an example.
Thanks,
Jan
On Mon, Sep 24, 2018 at 7:13 AM Peter Nabbefeld <pe...@gmx.de>
wrote:
> Too many nested comments inline already, sorry, so I try to summarize.
> Please feel free to remove the discussion at the bottom, if You agree it
> is not needed anymore.
>
> 1. I don't like documentation handled differently based on friend-state.
> There should always be sufficient information on every module.
>
> 2. Most people will not be able to use a module with insufficient
> information. As a result, information will be extended for public
> modules only, because people start to try using them and ask for
> information on points they don't understand. Friend-only modules will
> not have any more support. So, many jewels will never be officially
> become usable by the community.
>
> 3. I don't like to make the available documentation a criteria of the
> friend-state. Just because I'd like to see more of the modules and even
> the start phase of NetBeans documented. It would be great, if the
> original authors would have done that, all the others need to look at
> the often poorly documented code and find out, what the original author
> wanted to do with it. In some cases this is far from being obvious. In
> this case, it doesn't help much, that the code is open-source - You'll
> also be unable to read some old texts, just because You cannot read the
> letters.
>
> 4. Yes, the main stability criterium for APIs for me is no changes for
> some time - it's usually an indicator, that it has been used
> sufficiently. But, of course, if I want to use some API, I'll probably
> find some problems.
>
> 5. Thinking about [4], the friend-state could probably be managed
> easier-to-use, as a first step, e.g. adding sth. like
> "personal.friends=module(s)-to-be-used-as-friend" in user.properties.
> This could take the burden of cloning and building the whole NetBeans
> for just trying some friend-only API. Probably, in this case don't build
> nbm files but only install locally (deploy in running IDE or run a
> separate IDE), so it cannot be pushed to plugin repository by accident.
> Just an idea.
>
> 6. The possibility to extend HTML syntax using html.editor.lib is only
> one of its possibilities, but that's only one of the affected modules,
> so if we want to discuss that, we should use another thread.
>
> 7. Same for CSL/GSF/etc. - my fault. Thought You could help me with
> these. Should have opened new thread.
>
> Kind regards
>
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Public vs. Friend API Reloaded (Summary)
Posted by Peter Nabbefeld <pe...@gmx.de>.
Too many nested comments inline already, sorry, so I try to summarize.
Please feel free to remove the discussion at the bottom, if You agree it
is not needed anymore.
1. I don't like documentation handled differently based on friend-state.
There should always be sufficient information on every module.
2. Most people will not be able to use a module with insufficient
information. As a result, information will be extended for public
modules only, because people start to try using them and ask for
information on points they don't understand. Friend-only modules will
not have any more support. So, many jewels will never be officially
become usable by the community.
3. I don't like to make the available documentation a criteria of the
friend-state. Just because I'd like to see more of the modules and even
the start phase of NetBeans documented. It would be great, if the
original authors would have done that, all the others need to look at
the often poorly documented code and find out, what the original author
wanted to do with it. In some cases this is far from being obvious. In
this case, it doesn't help much, that the code is open-source - You'll
also be unable to read some old texts, just because You cannot read the
letters.
4. Yes, the main stability criterium for APIs for me is no changes for
some time - it's usually an indicator, that it has been used
sufficiently. But, of course, if I want to use some API, I'll probably
find some problems.
5. Thinking about [4], the friend-state could probably be managed
easier-to-use, as a first step, e.g. adding sth. like
"personal.friends=module(s)-to-be-used-as-friend" in user.properties.
This could take the burden of cloning and building the whole NetBeans
for just trying some friend-only API. Probably, in this case don't build
nbm files but only install locally (deploy in running IDE or run a
separate IDE), so it cannot be pushed to plugin repository by accident.
Just an idea.
6. The possibility to extend HTML syntax using html.editor.lib is only
one of its possibilities, but that's only one of the affected modules,
so if we want to discuss that, we should use another thread.
7. Same for CSL/GSF/etc. - my fault. Thought You could help me with
these. Should have opened new thread.
Kind regards
Peter
Am 23.09.18 um 21:16 schrieb Jan Lahoda:
> On Sun, Sep 23, 2018 at 7:23 PM Peter Nabbefeld <pe...@gmx.de>
> wrote:
>
>>
>> Am 23.09.18 um 18:17 schrieb Jan Lahoda:
>>> [...]
>>>
>>> I think that having a reasonable documentation was traditionally one of
>> the
>>> requirements for a public API modules. (I doubt csl.api went through the
>>> API review process.)
>>>
>> (next sentence is meant to be sarcastic):
>> So, if I'm too lazy to write some documentation, I get the benefit to
>> never need to think about how to do some changes, as nobody will get the
>> chance to use it.
>>
>> Okay, that's just to make clear this requirement may be misleading. And
>>
> Not sure what's misleading here. Traditionally, public API always had to be
> documented. Friend API not so much (because it was supposed to only be used
> by "friends".) So if we want to keep the traditional quality (of public
> APIs), friend APIs that are converted to Public APIs should be (among
> others) documented.
>
>
>> what about the colleages - they shouldn't be able to understand the
>> code, either? Sufficient documentation should not be a requirement for a
>> public API, but for every API - otherwise the functionality should be
>> considered not to be integrated into NetBeans at all.
>>
>>> [...]
>>>> I don't see two major NetBeans releases within 6 months, currently. But,
>>>> depending on the size of some module, IMHO, two or three major releases
>>>> of NetBeans should show most weaknesses of an API to stabilize it. If a
>>>> distinct functionality does not (yet) work as expected, declare it as
>>>> such, and make this part "private" (i.e. a friend-only module only
>>>> accessible from the API to be made public). There're many well-designed
>>>>
>>> Looking at html.editor.lib (another module mentioned in this context), I
>>> wonder if that's considered to work "as expected", or if there are parts
>>> that should be "private". Looking at the module, I am frankly a bit lost
>> on
>>> where should I begin to use it. (I assume I'd add a task using
>> parsing.api
>>> to "text/html", and then see if the Parser.Result I get is
>>> HtmlParsingResult, but why are there 4 more classes with ParseResult in
>>> name?)
>> Concerning the html.editor.lib module there's an API to extend the HTML
>> syntax, e.g. adding tags used by some of the JavaScript frameworks,
>> which is important for me.
>>
> I didn't spot this in the module (by which I don't mean it is not there),
> but it sounds like a small part of the module. So, is there a particular
> reason why there can't be a module, e.g. html.api or html.source,
> containing reviewed APIs, rather than opening everything? As an example.
>
>
>>> After thinking of this for a little, I guess the ideal approach for
>>> changing a friend module to public API module would be if folks
>> interested
>>> in the given API would get together, reviewed the API, improved it as
>>> needed (and as possible, because with 20+ friends, it may be unrealistic
>> to
>>> do certain changes), added documentation, etc. and proposed to make the
>>> updated version public.
>>>
>>> It is of course possible to simply remove the "for friends only" flag,
>> but
>>> that's not going to improve the API and documentation.
>>>
>>> Jan
>>>
>>> [...]
>>>
>> And, yes, all the APIs should be reviewed, as already mentioned above.
>>
> Good to hear that!
>
> As NetBeans is located at Apache now (i.e. no double-license anymore),
>> IMHO everybody should be able to understand even the most internal
>> functionality. As a result, this can no more be used as an argument for
>>
> Not sure what was the problem before - the source code was for one and a
> half decade open even before Apache, anyone could have understand anything
> they wanted?
>
> friend-only state. As a result, I see the only criteria being stability.
> Less sure about this - if the "stability" means "didn't change in last X
> years", then e.g. html.editor.lib might pass that criterion, which by
> itself would not make the API better, more maintainable or more documented.
>
>
>> Could You probably help to document CSL and GSF? Probably by giving an
>>
> Sorry, but probably no. There are a few reasons for that:
> a) my time on this project is severely limited (we are talking about my
> personal spare time only), so this task would compete with many other tasks
> for my time.
> b) I know very little about CSL (there may be my name on some classes in
> that module - that does not mean I wrote them for this module. It typically
> means I wrote them for java.editor/java.hints/java.source, and the classes
> were copied including the author tag and severely modified.)
> c) I was personally never convinced the CSL is the right approach - there
> are "low level" APIs for implementing the language features, and CSL is
> built on top of them - some consider it easier to use. I would probably be
> tempted to redesign the approach.
>
> So, I guess it would be better if someone more knowledgeable and
> enthusiastic about CSL documented that.
>
> overview how to do sth. like integrating JavaScript and HTML (without
>> the exact details, it's not required to rewrite the modules, but enough
>> detail, one could do it if possible)? E.g. how to detect and instantiate
>> embeddings and how to process them - this is sth. I couldn't find
>> sufficient information for. Further, existing examples, tutorials etc.
>> have to be checked for how up-to-date they're. Some UML diagrams may be
>> needed, too, or just some examples for how to do lexing and parsing with
>> the following tools:
>>
>> 1. Write lexer and parser manually (short example, just for
>> demonstration, how this could be done).
>>
> If we are talking about the "standard" APIs here (modules parsing.api,
> lexer, etc.), then I'll think about that.
>
> Jan
>
>
>> 2. Usage of JavaCC (with an existing grammar). JavaCC is badly
>> documented, so some pointers plus additional inf would be great.
>>
>> 3. Usage of Antlr3 (with an existing grammar).
>>
>> 4. Probably also usage of Antlr4.
>>
>> I'll try to comment on or extend these.
>>
>> Other issues are Code Folding, Error Hinting, Guarded Blocks etc. -
>> there's only very poor information available.
>>
>> Kind regards
>>
>> Peter
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API Reloaded (Summary)
Posted by Jan Lahoda <la...@gmail.com>.
On Sun, Sep 23, 2018 at 7:23 PM Peter Nabbefeld <pe...@gmx.de>
wrote:
>
>
> Am 23.09.18 um 18:17 schrieb Jan Lahoda:
> > [...]
> >
> > I think that having a reasonable documentation was traditionally one of
> the
> > requirements for a public API modules. (I doubt csl.api went through the
> > API review process.)
> >
> (next sentence is meant to be sarcastic):
> So, if I'm too lazy to write some documentation, I get the benefit to
> never need to think about how to do some changes, as nobody will get the
> chance to use it.
>
> Okay, that's just to make clear this requirement may be misleading. And
>
Not sure what's misleading here. Traditionally, public API always had to be
documented. Friend API not so much (because it was supposed to only be used
by "friends".) So if we want to keep the traditional quality (of public
APIs), friend APIs that are converted to Public APIs should be (among
others) documented.
> what about the colleages - they shouldn't be able to understand the
> code, either? Sufficient documentation should not be a requirement for a
> public API, but for every API - otherwise the functionality should be
> considered not to be integrated into NetBeans at all.
>
> > [...]
> >> I don't see two major NetBeans releases within 6 months, currently. But,
> >> depending on the size of some module, IMHO, two or three major releases
> >> of NetBeans should show most weaknesses of an API to stabilize it. If a
> >> distinct functionality does not (yet) work as expected, declare it as
> >> such, and make this part "private" (i.e. a friend-only module only
> >> accessible from the API to be made public). There're many well-designed
> >>
> > Looking at html.editor.lib (another module mentioned in this context), I
> > wonder if that's considered to work "as expected", or if there are parts
> > that should be "private". Looking at the module, I am frankly a bit lost
> on
> > where should I begin to use it. (I assume I'd add a task using
> parsing.api
> > to "text/html", and then see if the Parser.Result I get is
> > HtmlParsingResult, but why are there 4 more classes with ParseResult in
> > name?)
>
> Concerning the html.editor.lib module there's an API to extend the HTML
> syntax, e.g. adding tags used by some of the JavaScript frameworks,
> which is important for me.
>
I didn't spot this in the module (by which I don't mean it is not there),
but it sounds like a small part of the module. So, is there a particular
reason why there can't be a module, e.g. html.api or html.source,
containing reviewed APIs, rather than opening everything? As an example.
> >
> > After thinking of this for a little, I guess the ideal approach for
> > changing a friend module to public API module would be if folks
> interested
> > in the given API would get together, reviewed the API, improved it as
> > needed (and as possible, because with 20+ friends, it may be unrealistic
> to
> > do certain changes), added documentation, etc. and proposed to make the
> > updated version public.
> >
> > It is of course possible to simply remove the "for friends only" flag,
> but
> > that's not going to improve the API and documentation.
> >
> > Jan
> >
> > [...]
> >
>
> And, yes, all the APIs should be reviewed, as already mentioned above.
>
Good to hear that!
As NetBeans is located at Apache now (i.e. no double-license anymore),
> IMHO everybody should be able to understand even the most internal
> functionality. As a result, this can no more be used as an argument for
>
Not sure what was the problem before - the source code was for one and a
half decade open even before Apache, anyone could have understand anything
they wanted?
friend-only state. As a result, I see the only criteria being stability.
>
Less sure about this - if the "stability" means "didn't change in last X
years", then e.g. html.editor.lib might pass that criterion, which by
itself would not make the API better, more maintainable or more documented.
>
> Could You probably help to document CSL and GSF? Probably by giving an
>
Sorry, but probably no. There are a few reasons for that:
a) my time on this project is severely limited (we are talking about my
personal spare time only), so this task would compete with many other tasks
for my time.
b) I know very little about CSL (there may be my name on some classes in
that module - that does not mean I wrote them for this module. It typically
means I wrote them for java.editor/java.hints/java.source, and the classes
were copied including the author tag and severely modified.)
c) I was personally never convinced the CSL is the right approach - there
are "low level" APIs for implementing the language features, and CSL is
built on top of them - some consider it easier to use. I would probably be
tempted to redesign the approach.
So, I guess it would be better if someone more knowledgeable and
enthusiastic about CSL documented that.
overview how to do sth. like integrating JavaScript and HTML (without
> the exact details, it's not required to rewrite the modules, but enough
> detail, one could do it if possible)? E.g. how to detect and instantiate
> embeddings and how to process them - this is sth. I couldn't find
> sufficient information for. Further, existing examples, tutorials etc.
> have to be checked for how up-to-date they're. Some UML diagrams may be
> needed, too, or just some examples for how to do lexing and parsing with
> the following tools:
>
> 1. Write lexer and parser manually (short example, just for
> demonstration, how this could be done).
>
If we are talking about the "standard" APIs here (modules parsing.api,
lexer, etc.), then I'll think about that.
Jan
> 2. Usage of JavaCC (with an existing grammar). JavaCC is badly
> documented, so some pointers plus additional inf would be great.
>
> 3. Usage of Antlr3 (with an existing grammar).
>
> 4. Probably also usage of Antlr4.
>
> I'll try to comment on or extend these.
>
> Other issues are Code Folding, Error Hinting, Guarded Blocks etc. -
> there's only very poor information available.
>
> Kind regards
>
> Peter
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Public vs. Friend API Reloaded (Summary)
Posted by Peter Nabbefeld <pe...@gmx.de>.
Am 23.09.18 um 18:17 schrieb Jan Lahoda:
> [...]
>
> I think that having a reasonable documentation was traditionally one of the
> requirements for a public API modules. (I doubt csl.api went through the
> API review process.)
>
(next sentence is meant to be sarcastic):
So, if I'm too lazy to write some documentation, I get the benefit to
never need to think about how to do some changes, as nobody will get the
chance to use it.
Okay, that's just to make clear this requirement may be misleading. And
what about the colleages - they shouldn't be able to understand the
code, either? Sufficient documentation should not be a requirement for a
public API, but for every API - otherwise the functionality should be
considered not to be integrated into NetBeans at all.
> [...]
>> I don't see two major NetBeans releases within 6 months, currently. But,
>> depending on the size of some module, IMHO, two or three major releases
>> of NetBeans should show most weaknesses of an API to stabilize it. If a
>> distinct functionality does not (yet) work as expected, declare it as
>> such, and make this part "private" (i.e. a friend-only module only
>> accessible from the API to be made public). There're many well-designed
>>
> Looking at html.editor.lib (another module mentioned in this context), I
> wonder if that's considered to work "as expected", or if there are parts
> that should be "private". Looking at the module, I am frankly a bit lost on
> where should I begin to use it. (I assume I'd add a task using parsing.api
> to "text/html", and then see if the Parser.Result I get is
> HtmlParsingResult, but why are there 4 more classes with ParseResult in
> name?)
Concerning the html.editor.lib module there's an API to extend the HTML
syntax, e.g. adding tags used by some of the JavaScript frameworks,
which is important for me.
>
> After thinking of this for a little, I guess the ideal approach for
> changing a friend module to public API module would be if folks interested
> in the given API would get together, reviewed the API, improved it as
> needed (and as possible, because with 20+ friends, it may be unrealistic to
> do certain changes), added documentation, etc. and proposed to make the
> updated version public.
>
> It is of course possible to simply remove the "for friends only" flag, but
> that's not going to improve the API and documentation.
>
> Jan
>
> [...]
>
And, yes, all the APIs should be reviewed, as already mentioned above.
As NetBeans is located at Apache now (i.e. no double-license anymore),
IMHO everybody should be able to understand even the most internal
functionality. As a result, this can no more be used as an argument for
friend-only state. As a result, I see the only criteria being stability.
Could You probably help to document CSL and GSF? Probably by giving an
overview how to do sth. like integrating JavaScript and HTML (without
the exact details, it's not required to rewrite the modules, but enough
detail, one could do it if possible)? E.g. how to detect and instantiate
embeddings and how to process them - this is sth. I couldn't find
sufficient information for. Further, existing examples, tutorials etc.
have to be checked for how up-to-date they're. Some UML diagrams may be
needed, too, or just some examples for how to do lexing and parsing with
the following tools:
1. Write lexer and parser manually (short example, just for
demonstration, how this could be done).
2. Usage of JavaCC (with an existing grammar). JavaCC is badly
documented, so some pointers plus additional inf would be great.
3. Usage of Antlr3 (with an existing grammar).
4. Probably also usage of Antlr4.
I'll try to comment on or extend these.
Other issues are Code Folding, Error Hinting, Guarded Blocks etc. -
there's only very poor information available.
Kind regards
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API Reloaded (Summary)
Posted by Jan Lahoda <la...@gmail.com>.
On Sun, Sep 23, 2018 at 5:40 PM Peter Nabbefeld <pe...@gmx.de>
wrote:
>
>
> Am 23.09.18 um 17:02 schrieb Jan Lahoda:
> > On Sun, Sep 23, 2018 at 3:22 PM Peter Nabbefeld <pe...@gmx.de>
> > wrote:
> >
> >> 1) Yes, usually the API is reasonably stable in most areas after being
> >> used as a friend-only API for some releases, so if it is difficult to
> >> change, this will be a rare event. So, You'll have rarely to do many
> >> changes and can do some effort in these rare cases, if really necessary.
> >> IMHO that should be fine.
> >>
> > So, I thought one of the modules we are talking about here is csl.api,
> but
> > it turned out that *is* a public API currently (which, frankly, scares
> me a
> > little bit). So I took a look at gsf.testrunner and the last API change
> > appears to be from 2015 (according to apichanges.xml), which does not
> seem
> > to be *that* long ago.
>
> CSL and GSF are sth. I've not quite well understood:
> There's some information available how to start, but if it comes to
> details, I'm quickly lost. I'm also not sure, if these are different
>
I think that having a reasonable documentation was traditionally one of the
requirements for a public API modules. (I doubt csl.api went through the
API review process.)
> kinds of language tools or if they're building one on the top of the other.
>
> Probably that's some kind of "implied friend-only" by organization, i.e.
> the lack of information causes it not to be used, though publicly
> available.
> >
> >> 2) About Your inline comment: Well, it may happen, that functionality
> >> will be weighted more than API design. OTOH, I'd see this as an issue
> >> for a compatibility layer: Let the old API stay alive, while creating a
> >> new one. Then deprecate it, and remove the compatibility layer one or
> >> two major releases of NB later.
> >>
> > This way I'd expect modules to be stable, but also more usable by the
> >> community.
> >>
> > Given two major release may be 6 months in our current scheme, this
> sounds
> > neither particularly stable, nor particularly convenient for someone
> doing
> > the change (creating a compatibility layer is likely to have a fairly
> high
> > cost).
>
> I don't see two major NetBeans releases within 6 months, currently. But,
> depending on the size of some module, IMHO, two or three major releases
> of NetBeans should show most weaknesses of an API to stabilize it. If a
> distinct functionality does not (yet) work as expected, declare it as
> such, and make this part "private" (i.e. a friend-only module only
> accessible from the API to be made public). There're many well-designed
>
Looking at html.editor.lib (another module mentioned in this context), I
wonder if that's considered to work "as expected", or if there are parts
that should be "private". Looking at the module, I am frankly a bit lost on
where should I begin to use it. (I assume I'd add a task using parsing.api
to "text/html", and then see if the Parser.Result I get is
HtmlParsingResult, but why are there 4 more classes with ParseResult in
name?)
After thinking of this for a little, I guess the ideal approach for
changing a friend module to public API module would be if folks interested
in the given API would get together, reviewed the API, improved it as
needed (and as possible, because with 20+ friends, it may be unrealistic to
do certain changes), added documentation, etc. and proposed to make the
updated version public.
It is of course possible to simply remove the "for friends only" flag, but
that's not going to improve the API and documentation.
Jan
APIs in NetBeans, some even integrated twice or more times, just because
> they are managed like the "Holy Gral". One example may be the hinting
> system, which is differently implemented e.g. for Java and HTML. Some
> rules will have to be specified language-specific, but probably some
> parts could be unified.
>
> Regards
> Peter
>
>
> >
> > Jan
> >
> >
> >> Kind regards
> >>
> >> Peter
> >>
> >>
> >> Am 23.09.18 um 13:49 schrieb Jan Lahoda:
> >>> So, if I understand correctly, the view is a combination of c) ("it is
> OK
> >>> if doing changes to the API is difficult", like writing compatibility
> >>> layers, more elaborate migration tutorials, updating existing plugins
> >> etc.)
> >>> and b) (making an occasional incompatible change).
> >>>
> >>> I think I am fine with that, I just want to ensure the consequences are
> >>> understood. It is of course absolutely possible that a specific API
> won't
> >>> need any enhancements, and so will be fine.
> >>>
> >>> One more comment inline.
> >>>
> >>> On Sun, Sep 23, 2018 at 12:55 PM Peter Nabbefeld <
> peter.nabbefeld@gmx.de
> >>>
> >>> wrote:
> >>>
> >>>> The problem here is:
> >>>>
> >>>> 1. If every API is friend-only, nobody will be able to depend on those
> >>>> without first becoming a friend. Or You have to depend on
> implementation
> >>>> version. So, these APIs will never be reviewed by the broader
> community
> >>>> and will never be ready for usage.
> >>>>
> >>>> 2. If the API is public, You may break other implementors plugins.
> >>>> You'll usually never do that to just annoy them, but because You've
> got
> >>>> some serious problem without changing it. As a result, the API should
> >>>> become more stable, more usable, and of better quality in general.
> >>>>
> >>> Not sure about this: when an API is not designed to be enhancible
> >>> compatibly, and is not sufficient (i.e. needs to be enhanced), I
> suspect
> >>> preference will be given to making the change compatibly, even at the
> >> cost
> >>> of making the API less nice. So, over time, the API will probably be
> more
> >>> complete, but possibly less clean.
> >>>
> >>> Thanks,
> >>> Jan
> >>>
> >>> Probably, for the time the major version of NB doesn't change, there
> >>>> should be a compatibility layer, if possible.
> >>>>
> >>>> 3. If the API changes, there needs of course to be a migration
> tutorial,
> >>>> which must be upgraded if there are still any questions around about
> how
> >>>> to upgrade the plugin.
> >>>>
> >>>> 4. Plugin developers are: plugin developers, so it should not be a big
> >>>> issue for them to update their dependent module, if there's a
> tutorial.
> >>>>
> >>>> 5. As sometimes developers loose interest in further maintaining their
> >>>> plugin, there should be the source available somewhere, so other
> >>>> developers could take care of those. Ideally, the plugins should also
> be
> >>>> licensed under AL2.0, so they could be supplied in some Apache contrib
> >>>> repository.
> >>>>
> >>>> So, IMHO modules should be friend-only for a maximum of 2 or 3
> releases.
> >>>> After this, I'd expect them to be reasonable stable to make them
> public,
> >>>> so the community could experiment with those and probably make
> proposals
> >>>> for a better API. If the API changes then, most developers depending
> on
> >>>> the module will even be happy about the new possibilities. But they
> >>>> should also tell, if some change may make their usage of the module
> >>>> impossible, of course, so the problems could be considered early.
> >>>>
> >>>> Kind regards
> >>>>
> >>>> Peter
> >>>>
> >>>>
> >>>>
> >>>> Am 23.09.18 um 12:04 schrieb Jan Lahoda:
> >>>>> On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz <
> >> christian.lenz@gmx.net>
> >>>>> wrote:
> >>>>>
> >>>>>> Hey guys,
> >>>>>>
> >>>>>> please see my last 3 comments of this ticket. It explains, why it is
> >>>>>> important to have public APIs instead of Friends:
> >>>>>>
> >>
> https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
> >>>>> My personal opinion only.
> >>>>>
> >>>>> I think noone doubts the a public API is better for plugins.
> However, I
> >>>>> think that it is necessary that at least one of the following is
> true:
> >>>>> a) someone signs up to make a proper public API, that we will be able
> >> to
> >>>>> enhance compatibly
> >>>>> b) we accept that there are smaller or bigger incompatible API
> changes
> >>>>> (size of the incompatible change depends on the nature of the change
> >> and
> >>>> of
> >>>>> the existing API)
> >>>>> c) we accept that some changes to the API will be very difficult to
> do
> >>>>> (compatibly), maybe even so difficult that they won't be made (so
> >>>> difficult
> >>>>> that noone will sign up to do the change)
> >>>>>
> >>>>> So, I wonder what are the views of others on these.
> >>>>>
> >>>>> Thanks,
> >>>>> Jan
> >>>>>
> >>>>>
> >>>>>> The Thing is, no one know, what other nice Plugins will come in the
> >>>>>> future, but everytime, someone creates a Plugin which Needs to be
> >>>> friend,
> >>>>>> depends on only the next release that someone adds it. That means,
> >> that
> >>>>>> this Plugin will first work only for the next release, if someone
> >>>> decided
> >>>>>> to add this Plugin as a friend. Same happens for every other Plugins
> >>>> that
> >>>>>> Comes later.
> >>>>>>
> >>>>>> It is not that everytime a user want to use the newest IDE, often
> >>>> someone
> >>>>>> stays at the IDE if there is Nothing really new for him/her to
> Change
> >>>>>> update. That means, that he/she could miss the Plugin, if it is
> >> relevant
> >>>>>> for him. In this release.
> >>>>>>
> >>>>>> And what happens, if someone removes the Plugin as a friend? That
> >>>> happens
> >>>>>> for Geertjans KendoUI Plugin. The Plugin worked some versions
> before,
> >>>> not
> >>>>>> now anymore, because it was removed from being a friend.
> >>>>>>
> >>>>>> Making APIs public makes much more sense for 3rd-party Plugin
> >>>> developers.
> >>>>>> I think HTML, JS, CSS, C/C++ PHP and whatever is there is stable
> >> enough
> >>>> for
> >>>>>> years to say: yes, make them public. And will there some exceptions,
> >>>> that
> >>>>>> the devs figure out, someone can fix it Maybe as a patch or for the
> >> next
> >>>>>> release, which is acceptable.
> >>>>>>
> >>>>>>
> >>>>>> Cheers
> >>>>>>
> >>>>>> Chris
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Von: Laszlo Kishalmi
> >>>>>> Gesendet: Sonntag, 23. September 2018 04:45
> >>>>>> An: dev@netbeans.incubator.apache.org
> >>>>>> Betreff: Re: Public vs. Friend API Reloaded (Summary)
> >>>>>>
> >>>>>> Hi all,
> >>>>>> This list is what we have inside the current codebase (Without Yenta
> >> on
> >>>>>> other locations.)
> >>>>>> I put those here which have 10+ friend marked. (The complete list is
> >>>>>> attached)
> >>>>>> Upon this list it could be a good choice to try make the following
> >>>> public
> >>>>>> (maybe for NetBeans 10):
> >>>>>> • gsf.testrunner
> >>>>>> • gsf.testrunner.ui
> >>>>>> I know that a few external language plugins are using those as well,
> >> and
> >>>>>> the API is quite a good shape anyway.
> >>>>>> What do you think?
> >>>>>> Generated using: find . -name project.xml -exec grep -H -c friend\>
> {}
> >>>>>> \;|sort -r -gt : -k 2 |grep -v :0
> >>>>>> ./ide/dlight.nativeexecution/nbproject/project.xml:147
> >>>>>> ./ide/dlight.nativeexecution.nb/nbproject/project.xml:145
> >>>>>> ./ide/web.common/nbproject/project.xml:68
> >>>>>> ./ide/gsf.testrunner/nbproject/project.xml:40
> >>>>>> ./php/php.api.phpmodule/nbproject/project.xml:39
> >>>>>> ./java/java.api.common/nbproject/project.xml:39
> >>>>>> ./ide/options.editor/nbproject/project.xml:39
> >>>>>> ./java/maven/nbproject/project.xml:37
> >>>>>> ./enterprise/j2ee.common/nbproject/project.xml:34
> >>>>>> ./profiler/profiler.api/nbproject/project.xml:32
> >>>>>> ./profiler/lib.profiler/nbproject/project.xml:32
> >>>>>> ./java/maven.embedder/nbproject/project.xml:31
> >>>>>> ./webcommon/web.clientproject.api/nbproject/project.xml:29
> >>>>>> ./profiler/lib.profiler.common/nbproject/project.xml:29
> >>>>>> ./ide/gsf.testrunner.ui/nbproject/project.xml:28
> >>>>>> ./php/php.api.executable/nbproject/project.xml:27
> >>>>>> ./ide/html.editor.lib/nbproject/project.xml:26
> >>>>>> ./enterprise/j2ee.api.ejbmodule/nbproject/project.xml:25
> >>>>>> ./ide/web.browser.api/nbproject/project.xml:24
> >>>>>> ./ide/lib.terminalemulator/nbproject/project.xml:24
> >>>>>> ./profiler/lib.profiler.ui/nbproject/project.xml:23
> >>>>>> ./java/maven.model/nbproject/project.xml:23
> >>>>>> ./java/j2ee.core.utilities/nbproject/project.xml:23
> >>>>>> ./enterprise/websvc.jaxwsmodel/nbproject/project.xml:23
> >>>>>> ./ide/team.commons/nbproject/project.xml:22
> >>>>>> ./ide/html.editor/nbproject/project.xml:22
> >>>>>> ./profiler/profiler/nbproject/project.xml:21
> >>>>>> ./platform/libs.jna/nbproject/project.xml:21
> >>>>>> ./php/php.api.editor/nbproject/project.xml:21
> >>>>>> ./java/java.preprocessorbridge/nbproject/project.xml:20
> >>>>>> ./ide/web.common.ui/nbproject/project.xml:20
> >>>>>> ./ide/terminal/nbproject/project.xml:20
> >>>>>> ./ide/terminal.nb/nbproject/project.xml:20
> >>>>>> ./java/j2ee.persistenceapi/nbproject/project.xml:19
> >>>>>> ./enterprise/javaee.specs.support/nbproject/project.xml:19
> >>>>>> ./webcommon/javascript2.lexer/nbproject/project.xml:17
> >>>>>> ./ide/xml.multiview/nbproject/project.xml:17
> >>>>>> ./ide/versioning.util/nbproject/project.xml:17
> >>>>>> ./ide/code.analysis/nbproject/project.xml:17
> >>>>>> ./php/php.api.framework/nbproject/project.xml:16
> >>>>>> ./ide/xml.text/nbproject/project.xml:16
> >>>>>> ./ide/versioning.core/nbproject/project.xml:16
> >>>>>> ./webcommon/javascript2.types/nbproject/project.xml:15
> >>>>>> ./platform/core.startup.base/nbproject/project.xml:15
> >>>>>> ./ide/editor.settings.storage/nbproject/project.xml:15
> >>>>>> ./enterprise/websvc.clientapi/nbproject/project.xml:15
> >>>>>> ./enterprise/web.project/nbproject/project.xml:15
> >>>>>> ./websvccommon/websvc.jaxwsmodelapi/nbproject/project.xml:14
> >>>>>> ./webcommon/javascript2.editor/nbproject/project.xml:14
> >>>>>> ./platform/core.startup/nbproject/project.xml:14
> >>>>>> ./java/j2ee.persistence/nbproject/project.xml:14
> >>>>>> ./ide/xml.axi/nbproject/project.xml:14
> >>>>>> ./enterprise/websvc.jaxwsapi/nbproject/project.xml:14
> >>>>>> ./websvccommon/websvc.saas.api/nbproject/project.xml:13
> >>>>>> ./java/whitelist/nbproject/project.xml:13
> >>>>>> ./enterprise/websvc.core/nbproject/project.xml:13
> >>>>>> ./platform/o.n.core/nbproject/project.xml:12
> >>>>>> ./ide/web.webkit.debugging/nbproject/project.xml:12
> >>>>>> ./ide/dlight.terminal/nbproject/project.xml:12
> >>>>>> ./webcommon/javascript2.model/nbproject/project.xml:11
> >>>>>> ./php/php.api.annotation/nbproject/project.xml:11
> >>>>>> ./java/maven.indexer/nbproject/project.xml:11
> >>>>>> ./java/javaee.injection/nbproject/project.xml:11
> >>>>>> ./java/j2ee.metadata.model.support/nbproject/project.xml:11
> >>>>>> ./ide/hudson/nbproject/project.xml:11
> >>>>>> ./extide/options.java/nbproject/project.xml:11
> >>>>>> ./enterprise/j2ee.sun.dd/nbproject/project.xml:11
> >>>>>> ./enterprise/glassfish.common/nbproject/project.xml:11
> >>>>>> ./platform/o.n.bootstrap/nbproject/project.xml:10
> >>>>>> ./java/java.testrunner/nbproject/project.xml:10
> >>>>>> ./java/java.j2seproject/nbproject/project.xml:10
> >>>>>>
> >>>>>>
> >>
> ./ide/xml.schema.completion/test/unit/src/org/netbeans/modules/xml/schema/completion/resources/project.xml:10
> >>>>>> ./ide/jumpto/nbproject/project.xml:10
> >>>>>> ./enterprise/web.jsf/nbproject/project.xml:10
> >>>>>> ./enterprise/web.jsfapi/nbproject/project.xml:10
> >>>>>>
> >>>>>> On 09/21/2018 05:26 PM, Tim Boudreau wrote:
> >>>>>> You may want to survey modules on Github that use implementation
> >>>>>> dependencies or use Uenta to bypass them. For example, I've been
> >>>> tweaking
> >>>>>> the rust module from github, which does tag with a couple of csl
> >>>> modules.
> >>>>>> Those should count toward "friends".
> >>>>>>
> >>>>>> -Tim
> >>>>>>
> >>>>>> On Fri, Sep 21, 2018 at 8:01 PM Laszlo Kishalmi <
> >>>> laszlo.kishalmi@gmail.com
> >>>>>> wrote:
> >>>>>>
> >>>>>> Dear all,
> >>>>>>
> >>>>>> I'd like to summarize whet happened on the "API Friendliness" issue:
> >>>>>>
> >>>>>> We collected a number of possible options on our previous
> discussions
> >>>> at:
> >>
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
> >>>>>> Commenting these options remained really silent though. This means
> our
> >>>>>> Friend APIs most likely stay as they are now.
> >>>>>>
> >>>>>> I must acknowledge that adding new friends to an existing API is
> >> easier
> >>>>>> than ever having NetBeans under Apache umbrella.
> >>>>>>
> >>>>>> I plan not to give up on making some APIs public though. Regarding
> the
> >>>>>> low interest of making something big around this area, I think the
> >> most
> >>>>>> viable solution is:
> >>>>>>
> >>>>>> Option 4: Make Module Public when There is more than a Certain
> Number
> >> of
> >>>>>> Friend Dependencies.
> >>>>>>
> >>>>>> So sometime in the future I'm going to create a list of how many
> >> friends
> >>>>>> a module does have and share the list with you.
> >>>>>>
> >>>>>>
> >>>>>> Thank you all who participated in this effort!
> >>>>>>
> >>>>>> Laszlo Kishalmi
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail:
> dev-unsubscribe@netbeans.incubator.apache.org
> >>>>>> For additional commands, e-mail:
> >> dev-help@netbeans.incubator.apache.org
> >>>>>> For further information about the NetBeans mailing lists, visit:
> >>>>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> http://timboudreau.com
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> >>>> For additional commands, e-mail:
> dev-help@netbeans.incubator.apache.org
> >>>>
> >>>> For further information about the NetBeans mailing lists, visit:
> >>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> >> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> >>
> >> For further information about the NetBeans mailing lists, visit:
> >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>
> >>
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Public vs. Friend API Reloaded (Summary)
Posted by Peter Nabbefeld <pe...@gmx.de>.
Am 23.09.18 um 17:02 schrieb Jan Lahoda:
> On Sun, Sep 23, 2018 at 3:22 PM Peter Nabbefeld <pe...@gmx.de>
> wrote:
>
>> 1) Yes, usually the API is reasonably stable in most areas after being
>> used as a friend-only API for some releases, so if it is difficult to
>> change, this will be a rare event. So, You'll have rarely to do many
>> changes and can do some effort in these rare cases, if really necessary.
>> IMHO that should be fine.
>>
> So, I thought one of the modules we are talking about here is csl.api, but
> it turned out that *is* a public API currently (which, frankly, scares me a
> little bit). So I took a look at gsf.testrunner and the last API change
> appears to be from 2015 (according to apichanges.xml), which does not seem
> to be *that* long ago.
CSL and GSF are sth. I've not quite well understood:
There's some information available how to start, but if it comes to
details, I'm quickly lost. I'm also not sure, if these are different
kinds of language tools or if they're building one on the top of the other.
Probably that's some kind of "implied friend-only" by organization, i.e.
the lack of information causes it not to be used, though publicly available.
>
>> 2) About Your inline comment: Well, it may happen, that functionality
>> will be weighted more than API design. OTOH, I'd see this as an issue
>> for a compatibility layer: Let the old API stay alive, while creating a
>> new one. Then deprecate it, and remove the compatibility layer one or
>> two major releases of NB later.
>>
> This way I'd expect modules to be stable, but also more usable by the
>> community.
>>
> Given two major release may be 6 months in our current scheme, this sounds
> neither particularly stable, nor particularly convenient for someone doing
> the change (creating a compatibility layer is likely to have a fairly high
> cost).
I don't see two major NetBeans releases within 6 months, currently. But,
depending on the size of some module, IMHO, two or three major releases
of NetBeans should show most weaknesses of an API to stabilize it. If a
distinct functionality does not (yet) work as expected, declare it as
such, and make this part "private" (i.e. a friend-only module only
accessible from the API to be made public). There're many well-designed
APIs in NetBeans, some even integrated twice or more times, just because
they are managed like the "Holy Gral". One example may be the hinting
system, which is differently implemented e.g. for Java and HTML. Some
rules will have to be specified language-specific, but probably some
parts could be unified.
Regards
Peter
>
> Jan
>
>
>> Kind regards
>>
>> Peter
>>
>>
>> Am 23.09.18 um 13:49 schrieb Jan Lahoda:
>>> So, if I understand correctly, the view is a combination of c) ("it is OK
>>> if doing changes to the API is difficult", like writing compatibility
>>> layers, more elaborate migration tutorials, updating existing plugins
>> etc.)
>>> and b) (making an occasional incompatible change).
>>>
>>> I think I am fine with that, I just want to ensure the consequences are
>>> understood. It is of course absolutely possible that a specific API won't
>>> need any enhancements, and so will be fine.
>>>
>>> One more comment inline.
>>>
>>> On Sun, Sep 23, 2018 at 12:55 PM Peter Nabbefeld <peter.nabbefeld@gmx.de
>>>
>>> wrote:
>>>
>>>> The problem here is:
>>>>
>>>> 1. If every API is friend-only, nobody will be able to depend on those
>>>> without first becoming a friend. Or You have to depend on implementation
>>>> version. So, these APIs will never be reviewed by the broader community
>>>> and will never be ready for usage.
>>>>
>>>> 2. If the API is public, You may break other implementors plugins.
>>>> You'll usually never do that to just annoy them, but because You've got
>>>> some serious problem without changing it. As a result, the API should
>>>> become more stable, more usable, and of better quality in general.
>>>>
>>> Not sure about this: when an API is not designed to be enhancible
>>> compatibly, and is not sufficient (i.e. needs to be enhanced), I suspect
>>> preference will be given to making the change compatibly, even at the
>> cost
>>> of making the API less nice. So, over time, the API will probably be more
>>> complete, but possibly less clean.
>>>
>>> Thanks,
>>> Jan
>>>
>>> Probably, for the time the major version of NB doesn't change, there
>>>> should be a compatibility layer, if possible.
>>>>
>>>> 3. If the API changes, there needs of course to be a migration tutorial,
>>>> which must be upgraded if there are still any questions around about how
>>>> to upgrade the plugin.
>>>>
>>>> 4. Plugin developers are: plugin developers, so it should not be a big
>>>> issue for them to update their dependent module, if there's a tutorial.
>>>>
>>>> 5. As sometimes developers loose interest in further maintaining their
>>>> plugin, there should be the source available somewhere, so other
>>>> developers could take care of those. Ideally, the plugins should also be
>>>> licensed under AL2.0, so they could be supplied in some Apache contrib
>>>> repository.
>>>>
>>>> So, IMHO modules should be friend-only for a maximum of 2 or 3 releases.
>>>> After this, I'd expect them to be reasonable stable to make them public,
>>>> so the community could experiment with those and probably make proposals
>>>> for a better API. If the API changes then, most developers depending on
>>>> the module will even be happy about the new possibilities. But they
>>>> should also tell, if some change may make their usage of the module
>>>> impossible, of course, so the problems could be considered early.
>>>>
>>>> Kind regards
>>>>
>>>> Peter
>>>>
>>>>
>>>>
>>>> Am 23.09.18 um 12:04 schrieb Jan Lahoda:
>>>>> On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz <
>> christian.lenz@gmx.net>
>>>>> wrote:
>>>>>
>>>>>> Hey guys,
>>>>>>
>>>>>> please see my last 3 comments of this ticket. It explains, why it is
>>>>>> important to have public APIs instead of Friends:
>>>>>>
>> https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
>>>>> My personal opinion only.
>>>>>
>>>>> I think noone doubts the a public API is better for plugins. However, I
>>>>> think that it is necessary that at least one of the following is true:
>>>>> a) someone signs up to make a proper public API, that we will be able
>> to
>>>>> enhance compatibly
>>>>> b) we accept that there are smaller or bigger incompatible API changes
>>>>> (size of the incompatible change depends on the nature of the change
>> and
>>>> of
>>>>> the existing API)
>>>>> c) we accept that some changes to the API will be very difficult to do
>>>>> (compatibly), maybe even so difficult that they won't be made (so
>>>> difficult
>>>>> that noone will sign up to do the change)
>>>>>
>>>>> So, I wonder what are the views of others on these.
>>>>>
>>>>> Thanks,
>>>>> Jan
>>>>>
>>>>>
>>>>>> The Thing is, no one know, what other nice Plugins will come in the
>>>>>> future, but everytime, someone creates a Plugin which Needs to be
>>>> friend,
>>>>>> depends on only the next release that someone adds it. That means,
>> that
>>>>>> this Plugin will first work only for the next release, if someone
>>>> decided
>>>>>> to add this Plugin as a friend. Same happens for every other Plugins
>>>> that
>>>>>> Comes later.
>>>>>>
>>>>>> It is not that everytime a user want to use the newest IDE, often
>>>> someone
>>>>>> stays at the IDE if there is Nothing really new for him/her to Change
>>>>>> update. That means, that he/she could miss the Plugin, if it is
>> relevant
>>>>>> for him. In this release.
>>>>>>
>>>>>> And what happens, if someone removes the Plugin as a friend? That
>>>> happens
>>>>>> for Geertjans KendoUI Plugin. The Plugin worked some versions before,
>>>> not
>>>>>> now anymore, because it was removed from being a friend.
>>>>>>
>>>>>> Making APIs public makes much more sense for 3rd-party Plugin
>>>> developers.
>>>>>> I think HTML, JS, CSS, C/C++ PHP and whatever is there is stable
>> enough
>>>> for
>>>>>> years to say: yes, make them public. And will there some exceptions,
>>>> that
>>>>>> the devs figure out, someone can fix it Maybe as a patch or for the
>> next
>>>>>> release, which is acceptable.
>>>>>>
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>> Von: Laszlo Kishalmi
>>>>>> Gesendet: Sonntag, 23. September 2018 04:45
>>>>>> An: dev@netbeans.incubator.apache.org
>>>>>> Betreff: Re: Public vs. Friend API Reloaded (Summary)
>>>>>>
>>>>>> Hi all,
>>>>>> This list is what we have inside the current codebase (Without Yenta
>> on
>>>>>> other locations.)
>>>>>> I put those here which have 10+ friend marked. (The complete list is
>>>>>> attached)
>>>>>> Upon this list it could be a good choice to try make the following
>>>> public
>>>>>> (maybe for NetBeans 10):
>>>>>> • gsf.testrunner
>>>>>> • gsf.testrunner.ui
>>>>>> I know that a few external language plugins are using those as well,
>> and
>>>>>> the API is quite a good shape anyway.
>>>>>> What do you think?
>>>>>> Generated using: find . -name project.xml -exec grep -H -c friend\> {}
>>>>>> \;|sort -r -gt : -k 2 |grep -v :0
>>>>>> ./ide/dlight.nativeexecution/nbproject/project.xml:147
>>>>>> ./ide/dlight.nativeexecution.nb/nbproject/project.xml:145
>>>>>> ./ide/web.common/nbproject/project.xml:68
>>>>>> ./ide/gsf.testrunner/nbproject/project.xml:40
>>>>>> ./php/php.api.phpmodule/nbproject/project.xml:39
>>>>>> ./java/java.api.common/nbproject/project.xml:39
>>>>>> ./ide/options.editor/nbproject/project.xml:39
>>>>>> ./java/maven/nbproject/project.xml:37
>>>>>> ./enterprise/j2ee.common/nbproject/project.xml:34
>>>>>> ./profiler/profiler.api/nbproject/project.xml:32
>>>>>> ./profiler/lib.profiler/nbproject/project.xml:32
>>>>>> ./java/maven.embedder/nbproject/project.xml:31
>>>>>> ./webcommon/web.clientproject.api/nbproject/project.xml:29
>>>>>> ./profiler/lib.profiler.common/nbproject/project.xml:29
>>>>>> ./ide/gsf.testrunner.ui/nbproject/project.xml:28
>>>>>> ./php/php.api.executable/nbproject/project.xml:27
>>>>>> ./ide/html.editor.lib/nbproject/project.xml:26
>>>>>> ./enterprise/j2ee.api.ejbmodule/nbproject/project.xml:25
>>>>>> ./ide/web.browser.api/nbproject/project.xml:24
>>>>>> ./ide/lib.terminalemulator/nbproject/project.xml:24
>>>>>> ./profiler/lib.profiler.ui/nbproject/project.xml:23
>>>>>> ./java/maven.model/nbproject/project.xml:23
>>>>>> ./java/j2ee.core.utilities/nbproject/project.xml:23
>>>>>> ./enterprise/websvc.jaxwsmodel/nbproject/project.xml:23
>>>>>> ./ide/team.commons/nbproject/project.xml:22
>>>>>> ./ide/html.editor/nbproject/project.xml:22
>>>>>> ./profiler/profiler/nbproject/project.xml:21
>>>>>> ./platform/libs.jna/nbproject/project.xml:21
>>>>>> ./php/php.api.editor/nbproject/project.xml:21
>>>>>> ./java/java.preprocessorbridge/nbproject/project.xml:20
>>>>>> ./ide/web.common.ui/nbproject/project.xml:20
>>>>>> ./ide/terminal/nbproject/project.xml:20
>>>>>> ./ide/terminal.nb/nbproject/project.xml:20
>>>>>> ./java/j2ee.persistenceapi/nbproject/project.xml:19
>>>>>> ./enterprise/javaee.specs.support/nbproject/project.xml:19
>>>>>> ./webcommon/javascript2.lexer/nbproject/project.xml:17
>>>>>> ./ide/xml.multiview/nbproject/project.xml:17
>>>>>> ./ide/versioning.util/nbproject/project.xml:17
>>>>>> ./ide/code.analysis/nbproject/project.xml:17
>>>>>> ./php/php.api.framework/nbproject/project.xml:16
>>>>>> ./ide/xml.text/nbproject/project.xml:16
>>>>>> ./ide/versioning.core/nbproject/project.xml:16
>>>>>> ./webcommon/javascript2.types/nbproject/project.xml:15
>>>>>> ./platform/core.startup.base/nbproject/project.xml:15
>>>>>> ./ide/editor.settings.storage/nbproject/project.xml:15
>>>>>> ./enterprise/websvc.clientapi/nbproject/project.xml:15
>>>>>> ./enterprise/web.project/nbproject/project.xml:15
>>>>>> ./websvccommon/websvc.jaxwsmodelapi/nbproject/project.xml:14
>>>>>> ./webcommon/javascript2.editor/nbproject/project.xml:14
>>>>>> ./platform/core.startup/nbproject/project.xml:14
>>>>>> ./java/j2ee.persistence/nbproject/project.xml:14
>>>>>> ./ide/xml.axi/nbproject/project.xml:14
>>>>>> ./enterprise/websvc.jaxwsapi/nbproject/project.xml:14
>>>>>> ./websvccommon/websvc.saas.api/nbproject/project.xml:13
>>>>>> ./java/whitelist/nbproject/project.xml:13
>>>>>> ./enterprise/websvc.core/nbproject/project.xml:13
>>>>>> ./platform/o.n.core/nbproject/project.xml:12
>>>>>> ./ide/web.webkit.debugging/nbproject/project.xml:12
>>>>>> ./ide/dlight.terminal/nbproject/project.xml:12
>>>>>> ./webcommon/javascript2.model/nbproject/project.xml:11
>>>>>> ./php/php.api.annotation/nbproject/project.xml:11
>>>>>> ./java/maven.indexer/nbproject/project.xml:11
>>>>>> ./java/javaee.injection/nbproject/project.xml:11
>>>>>> ./java/j2ee.metadata.model.support/nbproject/project.xml:11
>>>>>> ./ide/hudson/nbproject/project.xml:11
>>>>>> ./extide/options.java/nbproject/project.xml:11
>>>>>> ./enterprise/j2ee.sun.dd/nbproject/project.xml:11
>>>>>> ./enterprise/glassfish.common/nbproject/project.xml:11
>>>>>> ./platform/o.n.bootstrap/nbproject/project.xml:10
>>>>>> ./java/java.testrunner/nbproject/project.xml:10
>>>>>> ./java/java.j2seproject/nbproject/project.xml:10
>>>>>>
>>>>>>
>> ./ide/xml.schema.completion/test/unit/src/org/netbeans/modules/xml/schema/completion/resources/project.xml:10
>>>>>> ./ide/jumpto/nbproject/project.xml:10
>>>>>> ./enterprise/web.jsf/nbproject/project.xml:10
>>>>>> ./enterprise/web.jsfapi/nbproject/project.xml:10
>>>>>>
>>>>>> On 09/21/2018 05:26 PM, Tim Boudreau wrote:
>>>>>> You may want to survey modules on Github that use implementation
>>>>>> dependencies or use Uenta to bypass them. For example, I've been
>>>> tweaking
>>>>>> the rust module from github, which does tag with a couple of csl
>>>> modules.
>>>>>> Those should count toward "friends".
>>>>>>
>>>>>> -Tim
>>>>>>
>>>>>> On Fri, Sep 21, 2018 at 8:01 PM Laszlo Kishalmi <
>>>> laszlo.kishalmi@gmail.com
>>>>>> wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> I'd like to summarize whet happened on the "API Friendliness" issue:
>>>>>>
>>>>>> We collected a number of possible options on our previous discussions
>>>> at:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
>>>>>> Commenting these options remained really silent though. This means our
>>>>>> Friend APIs most likely stay as they are now.
>>>>>>
>>>>>> I must acknowledge that adding new friends to an existing API is
>> easier
>>>>>> than ever having NetBeans under Apache umbrella.
>>>>>>
>>>>>> I plan not to give up on making some APIs public though. Regarding the
>>>>>> low interest of making something big around this area, I think the
>> most
>>>>>> viable solution is:
>>>>>>
>>>>>> Option 4: Make Module Public when There is more than a Certain Number
>> of
>>>>>> Friend Dependencies.
>>>>>>
>>>>>> So sometime in the future I'm going to create a list of how many
>> friends
>>>>>> a module does have and share the list with you.
>>>>>>
>>>>>>
>>>>>> Thank you all who participated in this effort!
>>>>>>
>>>>>> Laszlo Kishalmi
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>>>>>> For additional commands, e-mail:
>> dev-help@netbeans.incubator.apache.org
>>>>>> For further information about the NetBeans mailing lists, visit:
>>>>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://timboudreau.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>>>> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>>>>
>>>> For further information about the NetBeans mailing lists, visit:
>>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>>
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API Reloaded (Summary)
Posted by Jan Lahoda <la...@gmail.com>.
On Sun, Sep 23, 2018 at 3:22 PM Peter Nabbefeld <pe...@gmx.de>
wrote:
> 1) Yes, usually the API is reasonably stable in most areas after being
> used as a friend-only API for some releases, so if it is difficult to
> change, this will be a rare event. So, You'll have rarely to do many
> changes and can do some effort in these rare cases, if really necessary.
> IMHO that should be fine.
>
So, I thought one of the modules we are talking about here is csl.api, but
it turned out that *is* a public API currently (which, frankly, scares me a
little bit). So I took a look at gsf.testrunner and the last API change
appears to be from 2015 (according to apichanges.xml), which does not seem
to be *that* long ago.
>
> 2) About Your inline comment: Well, it may happen, that functionality
> will be weighted more than API design. OTOH, I'd see this as an issue
> for a compatibility layer: Let the old API stay alive, while creating a
> new one. Then deprecate it, and remove the compatibility layer one or
> two major releases of NB later.
>
This way I'd expect modules to be stable, but also more usable by the
> community.
>
Given two major release may be 6 months in our current scheme, this sounds
neither particularly stable, nor particularly convenient for someone doing
the change (creating a compatibility layer is likely to have a fairly high
cost).
Jan
>
> Kind regards
>
> Peter
>
>
> Am 23.09.18 um 13:49 schrieb Jan Lahoda:
> > So, if I understand correctly, the view is a combination of c) ("it is OK
> > if doing changes to the API is difficult", like writing compatibility
> > layers, more elaborate migration tutorials, updating existing plugins
> etc.)
> > and b) (making an occasional incompatible change).
> >
> > I think I am fine with that, I just want to ensure the consequences are
> > understood. It is of course absolutely possible that a specific API won't
> > need any enhancements, and so will be fine.
> >
> > One more comment inline.
> >
> > On Sun, Sep 23, 2018 at 12:55 PM Peter Nabbefeld <peter.nabbefeld@gmx.de
> >
> > wrote:
> >
> >> The problem here is:
> >>
> >> 1. If every API is friend-only, nobody will be able to depend on those
> >> without first becoming a friend. Or You have to depend on implementation
> >> version. So, these APIs will never be reviewed by the broader community
> >> and will never be ready for usage.
> >>
> >
> >> 2. If the API is public, You may break other implementors plugins.
> >> You'll usually never do that to just annoy them, but because You've got
> >> some serious problem without changing it. As a result, the API should
> >> become more stable, more usable, and of better quality in general.
> >>
> > Not sure about this: when an API is not designed to be enhancible
> > compatibly, and is not sufficient (i.e. needs to be enhanced), I suspect
> > preference will be given to making the change compatibly, even at the
> cost
> > of making the API less nice. So, over time, the API will probably be more
> > complete, but possibly less clean.
> >
> > Thanks,
> > Jan
> >
> > Probably, for the time the major version of NB doesn't change, there
> >> should be a compatibility layer, if possible.
> >>
> >> 3. If the API changes, there needs of course to be a migration tutorial,
> >> which must be upgraded if there are still any questions around about how
> >> to upgrade the plugin.
> >>
> >> 4. Plugin developers are: plugin developers, so it should not be a big
> >> issue for them to update their dependent module, if there's a tutorial.
> >>
> >> 5. As sometimes developers loose interest in further maintaining their
> >> plugin, there should be the source available somewhere, so other
> >> developers could take care of those. Ideally, the plugins should also be
> >> licensed under AL2.0, so they could be supplied in some Apache contrib
> >> repository.
> >>
> >> So, IMHO modules should be friend-only for a maximum of 2 or 3 releases.
> >> After this, I'd expect them to be reasonable stable to make them public,
> >> so the community could experiment with those and probably make proposals
> >> for a better API. If the API changes then, most developers depending on
> >> the module will even be happy about the new possibilities. But they
> >> should also tell, if some change may make their usage of the module
> >> impossible, of course, so the problems could be considered early.
> >>
> >> Kind regards
> >>
> >> Peter
> >>
> >>
> >>
> >> Am 23.09.18 um 12:04 schrieb Jan Lahoda:
> >>> On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz <
> christian.lenz@gmx.net>
> >>> wrote:
> >>>
> >>>> Hey guys,
> >>>>
> >>>> please see my last 3 comments of this ticket. It explains, why it is
> >>>> important to have public APIs instead of Friends:
> >>>>
> >>
> https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
> >>>>
> >>> My personal opinion only.
> >>>
> >>> I think noone doubts the a public API is better for plugins. However, I
> >>> think that it is necessary that at least one of the following is true:
> >>> a) someone signs up to make a proper public API, that we will be able
> to
> >>> enhance compatibly
> >>> b) we accept that there are smaller or bigger incompatible API changes
> >>> (size of the incompatible change depends on the nature of the change
> and
> >> of
> >>> the existing API)
> >>> c) we accept that some changes to the API will be very difficult to do
> >>> (compatibly), maybe even so difficult that they won't be made (so
> >> difficult
> >>> that noone will sign up to do the change)
> >>>
> >>> So, I wonder what are the views of others on these.
> >>>
> >>> Thanks,
> >>> Jan
> >>>
> >>>
> >>>> The Thing is, no one know, what other nice Plugins will come in the
> >>>> future, but everytime, someone creates a Plugin which Needs to be
> >> friend,
> >>>> depends on only the next release that someone adds it. That means,
> that
> >>>> this Plugin will first work only for the next release, if someone
> >> decided
> >>>> to add this Plugin as a friend. Same happens for every other Plugins
> >> that
> >>>> Comes later.
> >>>>
> >>>> It is not that everytime a user want to use the newest IDE, often
> >> someone
> >>>> stays at the IDE if there is Nothing really new for him/her to Change
> >>>> update. That means, that he/she could miss the Plugin, if it is
> relevant
> >>>> for him. In this release.
> >>>>
> >>>> And what happens, if someone removes the Plugin as a friend? That
> >> happens
> >>>> for Geertjans KendoUI Plugin. The Plugin worked some versions before,
> >> not
> >>>> now anymore, because it was removed from being a friend.
> >>>>
> >>>> Making APIs public makes much more sense for 3rd-party Plugin
> >> developers.
> >>>> I think HTML, JS, CSS, C/C++ PHP and whatever is there is stable
> enough
> >> for
> >>>> years to say: yes, make them public. And will there some exceptions,
> >> that
> >>>> the devs figure out, someone can fix it Maybe as a patch or for the
> next
> >>>> release, which is acceptable.
> >>>>
> >>>>
> >>>> Cheers
> >>>>
> >>>> Chris
> >>>>
> >>>>
> >>>>
> >>>> Von: Laszlo Kishalmi
> >>>> Gesendet: Sonntag, 23. September 2018 04:45
> >>>> An: dev@netbeans.incubator.apache.org
> >>>> Betreff: Re: Public vs. Friend API Reloaded (Summary)
> >>>>
> >>>> Hi all,
> >>>> This list is what we have inside the current codebase (Without Yenta
> on
> >>>> other locations.)
> >>>> I put those here which have 10+ friend marked. (The complete list is
> >>>> attached)
> >>>> Upon this list it could be a good choice to try make the following
> >> public
> >>>> (maybe for NetBeans 10):
> >>>> • gsf.testrunner
> >>>> • gsf.testrunner.ui
> >>>> I know that a few external language plugins are using those as well,
> and
> >>>> the API is quite a good shape anyway.
> >>>> What do you think?
> >>>> Generated using: find . -name project.xml -exec grep -H -c friend\> {}
> >>>> \;|sort -r -gt : -k 2 |grep -v :0
> >>>> ./ide/dlight.nativeexecution/nbproject/project.xml:147
> >>>> ./ide/dlight.nativeexecution.nb/nbproject/project.xml:145
> >>>> ./ide/web.common/nbproject/project.xml:68
> >>>> ./ide/gsf.testrunner/nbproject/project.xml:40
> >>>> ./php/php.api.phpmodule/nbproject/project.xml:39
> >>>> ./java/java.api.common/nbproject/project.xml:39
> >>>> ./ide/options.editor/nbproject/project.xml:39
> >>>> ./java/maven/nbproject/project.xml:37
> >>>> ./enterprise/j2ee.common/nbproject/project.xml:34
> >>>> ./profiler/profiler.api/nbproject/project.xml:32
> >>>> ./profiler/lib.profiler/nbproject/project.xml:32
> >>>> ./java/maven.embedder/nbproject/project.xml:31
> >>>> ./webcommon/web.clientproject.api/nbproject/project.xml:29
> >>>> ./profiler/lib.profiler.common/nbproject/project.xml:29
> >>>> ./ide/gsf.testrunner.ui/nbproject/project.xml:28
> >>>> ./php/php.api.executable/nbproject/project.xml:27
> >>>> ./ide/html.editor.lib/nbproject/project.xml:26
> >>>> ./enterprise/j2ee.api.ejbmodule/nbproject/project.xml:25
> >>>> ./ide/web.browser.api/nbproject/project.xml:24
> >>>> ./ide/lib.terminalemulator/nbproject/project.xml:24
> >>>> ./profiler/lib.profiler.ui/nbproject/project.xml:23
> >>>> ./java/maven.model/nbproject/project.xml:23
> >>>> ./java/j2ee.core.utilities/nbproject/project.xml:23
> >>>> ./enterprise/websvc.jaxwsmodel/nbproject/project.xml:23
> >>>> ./ide/team.commons/nbproject/project.xml:22
> >>>> ./ide/html.editor/nbproject/project.xml:22
> >>>> ./profiler/profiler/nbproject/project.xml:21
> >>>> ./platform/libs.jna/nbproject/project.xml:21
> >>>> ./php/php.api.editor/nbproject/project.xml:21
> >>>> ./java/java.preprocessorbridge/nbproject/project.xml:20
> >>>> ./ide/web.common.ui/nbproject/project.xml:20
> >>>> ./ide/terminal/nbproject/project.xml:20
> >>>> ./ide/terminal.nb/nbproject/project.xml:20
> >>>> ./java/j2ee.persistenceapi/nbproject/project.xml:19
> >>>> ./enterprise/javaee.specs.support/nbproject/project.xml:19
> >>>> ./webcommon/javascript2.lexer/nbproject/project.xml:17
> >>>> ./ide/xml.multiview/nbproject/project.xml:17
> >>>> ./ide/versioning.util/nbproject/project.xml:17
> >>>> ./ide/code.analysis/nbproject/project.xml:17
> >>>> ./php/php.api.framework/nbproject/project.xml:16
> >>>> ./ide/xml.text/nbproject/project.xml:16
> >>>> ./ide/versioning.core/nbproject/project.xml:16
> >>>> ./webcommon/javascript2.types/nbproject/project.xml:15
> >>>> ./platform/core.startup.base/nbproject/project.xml:15
> >>>> ./ide/editor.settings.storage/nbproject/project.xml:15
> >>>> ./enterprise/websvc.clientapi/nbproject/project.xml:15
> >>>> ./enterprise/web.project/nbproject/project.xml:15
> >>>> ./websvccommon/websvc.jaxwsmodelapi/nbproject/project.xml:14
> >>>> ./webcommon/javascript2.editor/nbproject/project.xml:14
> >>>> ./platform/core.startup/nbproject/project.xml:14
> >>>> ./java/j2ee.persistence/nbproject/project.xml:14
> >>>> ./ide/xml.axi/nbproject/project.xml:14
> >>>> ./enterprise/websvc.jaxwsapi/nbproject/project.xml:14
> >>>> ./websvccommon/websvc.saas.api/nbproject/project.xml:13
> >>>> ./java/whitelist/nbproject/project.xml:13
> >>>> ./enterprise/websvc.core/nbproject/project.xml:13
> >>>> ./platform/o.n.core/nbproject/project.xml:12
> >>>> ./ide/web.webkit.debugging/nbproject/project.xml:12
> >>>> ./ide/dlight.terminal/nbproject/project.xml:12
> >>>> ./webcommon/javascript2.model/nbproject/project.xml:11
> >>>> ./php/php.api.annotation/nbproject/project.xml:11
> >>>> ./java/maven.indexer/nbproject/project.xml:11
> >>>> ./java/javaee.injection/nbproject/project.xml:11
> >>>> ./java/j2ee.metadata.model.support/nbproject/project.xml:11
> >>>> ./ide/hudson/nbproject/project.xml:11
> >>>> ./extide/options.java/nbproject/project.xml:11
> >>>> ./enterprise/j2ee.sun.dd/nbproject/project.xml:11
> >>>> ./enterprise/glassfish.common/nbproject/project.xml:11
> >>>> ./platform/o.n.bootstrap/nbproject/project.xml:10
> >>>> ./java/java.testrunner/nbproject/project.xml:10
> >>>> ./java/java.j2seproject/nbproject/project.xml:10
> >>>>
> >>>>
> >>
> ./ide/xml.schema.completion/test/unit/src/org/netbeans/modules/xml/schema/completion/resources/project.xml:10
> >>>> ./ide/jumpto/nbproject/project.xml:10
> >>>> ./enterprise/web.jsf/nbproject/project.xml:10
> >>>> ./enterprise/web.jsfapi/nbproject/project.xml:10
> >>>>
> >>>> On 09/21/2018 05:26 PM, Tim Boudreau wrote:
> >>>> You may want to survey modules on Github that use implementation
> >>>> dependencies or use Uenta to bypass them. For example, I've been
> >> tweaking
> >>>> the rust module from github, which does tag with a couple of csl
> >> modules.
> >>>> Those should count toward "friends".
> >>>>
> >>>> -Tim
> >>>>
> >>>> On Fri, Sep 21, 2018 at 8:01 PM Laszlo Kishalmi <
> >> laszlo.kishalmi@gmail.com
> >>>> wrote:
> >>>>
> >>>> Dear all,
> >>>>
> >>>> I'd like to summarize whet happened on the "API Friendliness" issue:
> >>>>
> >>>> We collected a number of possible options on our previous discussions
> >> at:
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
> >>>> Commenting these options remained really silent though. This means our
> >>>> Friend APIs most likely stay as they are now.
> >>>>
> >>>> I must acknowledge that adding new friends to an existing API is
> easier
> >>>> than ever having NetBeans under Apache umbrella.
> >>>>
> >>>> I plan not to give up on making some APIs public though. Regarding the
> >>>> low interest of making something big around this area, I think the
> most
> >>>> viable solution is:
> >>>>
> >>>> Option 4: Make Module Public when There is more than a Certain Number
> of
> >>>> Friend Dependencies.
> >>>>
> >>>> So sometime in the future I'm going to create a list of how many
> friends
> >>>> a module does have and share the list with you.
> >>>>
> >>>>
> >>>> Thank you all who participated in this effort!
> >>>>
> >>>> Laszlo Kishalmi
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> >>>> For additional commands, e-mail:
> dev-help@netbeans.incubator.apache.org
> >>>>
> >>>> For further information about the NetBeans mailing lists, visit:
> >>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> http://timboudreau.com
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> >> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> >>
> >> For further information about the NetBeans mailing lists, visit:
> >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>
> >>
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Public vs. Friend API Reloaded (Summary)
Posted by Peter Nabbefeld <pe...@gmx.de>.
1) Yes, usually the API is reasonably stable in most areas after being
used as a friend-only API for some releases, so if it is difficult to
change, this will be a rare event. So, You'll have rarely to do many
changes and can do some effort in these rare cases, if really necessary.
IMHO that should be fine.
2) About Your inline comment: Well, it may happen, that functionality
will be weighted more than API design. OTOH, I'd see this as an issue
for a compatibility layer: Let the old API stay alive, while creating a
new one. Then deprecate it, and remove the compatibility layer one or
two major releases of NB later.
This way I'd expect modules to be stable, but also more usable by the
community.
Kind regards
Peter
Am 23.09.18 um 13:49 schrieb Jan Lahoda:
> So, if I understand correctly, the view is a combination of c) ("it is OK
> if doing changes to the API is difficult", like writing compatibility
> layers, more elaborate migration tutorials, updating existing plugins etc.)
> and b) (making an occasional incompatible change).
>
> I think I am fine with that, I just want to ensure the consequences are
> understood. It is of course absolutely possible that a specific API won't
> need any enhancements, and so will be fine.
>
> One more comment inline.
>
> On Sun, Sep 23, 2018 at 12:55 PM Peter Nabbefeld <pe...@gmx.de>
> wrote:
>
>> The problem here is:
>>
>> 1. If every API is friend-only, nobody will be able to depend on those
>> without first becoming a friend. Or You have to depend on implementation
>> version. So, these APIs will never be reviewed by the broader community
>> and will never be ready for usage.
>>
>
>> 2. If the API is public, You may break other implementors plugins.
>> You'll usually never do that to just annoy them, but because You've got
>> some serious problem without changing it. As a result, the API should
>> become more stable, more usable, and of better quality in general.
>>
> Not sure about this: when an API is not designed to be enhancible
> compatibly, and is not sufficient (i.e. needs to be enhanced), I suspect
> preference will be given to making the change compatibly, even at the cost
> of making the API less nice. So, over time, the API will probably be more
> complete, but possibly less clean.
>
> Thanks,
> Jan
>
> Probably, for the time the major version of NB doesn't change, there
>> should be a compatibility layer, if possible.
>>
>> 3. If the API changes, there needs of course to be a migration tutorial,
>> which must be upgraded if there are still any questions around about how
>> to upgrade the plugin.
>>
>> 4. Plugin developers are: plugin developers, so it should not be a big
>> issue for them to update their dependent module, if there's a tutorial.
>>
>> 5. As sometimes developers loose interest in further maintaining their
>> plugin, there should be the source available somewhere, so other
>> developers could take care of those. Ideally, the plugins should also be
>> licensed under AL2.0, so they could be supplied in some Apache contrib
>> repository.
>>
>> So, IMHO modules should be friend-only for a maximum of 2 or 3 releases.
>> After this, I'd expect them to be reasonable stable to make them public,
>> so the community could experiment with those and probably make proposals
>> for a better API. If the API changes then, most developers depending on
>> the module will even be happy about the new possibilities. But they
>> should also tell, if some change may make their usage of the module
>> impossible, of course, so the problems could be considered early.
>>
>> Kind regards
>>
>> Peter
>>
>>
>>
>> Am 23.09.18 um 12:04 schrieb Jan Lahoda:
>>> On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz <ch...@gmx.net>
>>> wrote:
>>>
>>>> Hey guys,
>>>>
>>>> please see my last 3 comments of this ticket. It explains, why it is
>>>> important to have public APIs instead of Friends:
>>>>
>> https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
>>>>
>>> My personal opinion only.
>>>
>>> I think noone doubts the a public API is better for plugins. However, I
>>> think that it is necessary that at least one of the following is true:
>>> a) someone signs up to make a proper public API, that we will be able to
>>> enhance compatibly
>>> b) we accept that there are smaller or bigger incompatible API changes
>>> (size of the incompatible change depends on the nature of the change and
>> of
>>> the existing API)
>>> c) we accept that some changes to the API will be very difficult to do
>>> (compatibly), maybe even so difficult that they won't be made (so
>> difficult
>>> that noone will sign up to do the change)
>>>
>>> So, I wonder what are the views of others on these.
>>>
>>> Thanks,
>>> Jan
>>>
>>>
>>>> The Thing is, no one know, what other nice Plugins will come in the
>>>> future, but everytime, someone creates a Plugin which Needs to be
>> friend,
>>>> depends on only the next release that someone adds it. That means, that
>>>> this Plugin will first work only for the next release, if someone
>> decided
>>>> to add this Plugin as a friend. Same happens for every other Plugins
>> that
>>>> Comes later.
>>>>
>>>> It is not that everytime a user want to use the newest IDE, often
>> someone
>>>> stays at the IDE if there is Nothing really new for him/her to Change
>>>> update. That means, that he/she could miss the Plugin, if it is relevant
>>>> for him. In this release.
>>>>
>>>> And what happens, if someone removes the Plugin as a friend? That
>> happens
>>>> for Geertjans KendoUI Plugin. The Plugin worked some versions before,
>> not
>>>> now anymore, because it was removed from being a friend.
>>>>
>>>> Making APIs public makes much more sense for 3rd-party Plugin
>> developers.
>>>> I think HTML, JS, CSS, C/C++ PHP and whatever is there is stable enough
>> for
>>>> years to say: yes, make them public. And will there some exceptions,
>> that
>>>> the devs figure out, someone can fix it Maybe as a patch or for the next
>>>> release, which is acceptable.
>>>>
>>>>
>>>> Cheers
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> Von: Laszlo Kishalmi
>>>> Gesendet: Sonntag, 23. September 2018 04:45
>>>> An: dev@netbeans.incubator.apache.org
>>>> Betreff: Re: Public vs. Friend API Reloaded (Summary)
>>>>
>>>> Hi all,
>>>> This list is what we have inside the current codebase (Without Yenta on
>>>> other locations.)
>>>> I put those here which have 10+ friend marked. (The complete list is
>>>> attached)
>>>> Upon this list it could be a good choice to try make the following
>> public
>>>> (maybe for NetBeans 10):
>>>> • gsf.testrunner
>>>> • gsf.testrunner.ui
>>>> I know that a few external language plugins are using those as well, and
>>>> the API is quite a good shape anyway.
>>>> What do you think?
>>>> Generated using: find . -name project.xml -exec grep -H -c friend\> {}
>>>> \;|sort -r -gt : -k 2 |grep -v :0
>>>> ./ide/dlight.nativeexecution/nbproject/project.xml:147
>>>> ./ide/dlight.nativeexecution.nb/nbproject/project.xml:145
>>>> ./ide/web.common/nbproject/project.xml:68
>>>> ./ide/gsf.testrunner/nbproject/project.xml:40
>>>> ./php/php.api.phpmodule/nbproject/project.xml:39
>>>> ./java/java.api.common/nbproject/project.xml:39
>>>> ./ide/options.editor/nbproject/project.xml:39
>>>> ./java/maven/nbproject/project.xml:37
>>>> ./enterprise/j2ee.common/nbproject/project.xml:34
>>>> ./profiler/profiler.api/nbproject/project.xml:32
>>>> ./profiler/lib.profiler/nbproject/project.xml:32
>>>> ./java/maven.embedder/nbproject/project.xml:31
>>>> ./webcommon/web.clientproject.api/nbproject/project.xml:29
>>>> ./profiler/lib.profiler.common/nbproject/project.xml:29
>>>> ./ide/gsf.testrunner.ui/nbproject/project.xml:28
>>>> ./php/php.api.executable/nbproject/project.xml:27
>>>> ./ide/html.editor.lib/nbproject/project.xml:26
>>>> ./enterprise/j2ee.api.ejbmodule/nbproject/project.xml:25
>>>> ./ide/web.browser.api/nbproject/project.xml:24
>>>> ./ide/lib.terminalemulator/nbproject/project.xml:24
>>>> ./profiler/lib.profiler.ui/nbproject/project.xml:23
>>>> ./java/maven.model/nbproject/project.xml:23
>>>> ./java/j2ee.core.utilities/nbproject/project.xml:23
>>>> ./enterprise/websvc.jaxwsmodel/nbproject/project.xml:23
>>>> ./ide/team.commons/nbproject/project.xml:22
>>>> ./ide/html.editor/nbproject/project.xml:22
>>>> ./profiler/profiler/nbproject/project.xml:21
>>>> ./platform/libs.jna/nbproject/project.xml:21
>>>> ./php/php.api.editor/nbproject/project.xml:21
>>>> ./java/java.preprocessorbridge/nbproject/project.xml:20
>>>> ./ide/web.common.ui/nbproject/project.xml:20
>>>> ./ide/terminal/nbproject/project.xml:20
>>>> ./ide/terminal.nb/nbproject/project.xml:20
>>>> ./java/j2ee.persistenceapi/nbproject/project.xml:19
>>>> ./enterprise/javaee.specs.support/nbproject/project.xml:19
>>>> ./webcommon/javascript2.lexer/nbproject/project.xml:17
>>>> ./ide/xml.multiview/nbproject/project.xml:17
>>>> ./ide/versioning.util/nbproject/project.xml:17
>>>> ./ide/code.analysis/nbproject/project.xml:17
>>>> ./php/php.api.framework/nbproject/project.xml:16
>>>> ./ide/xml.text/nbproject/project.xml:16
>>>> ./ide/versioning.core/nbproject/project.xml:16
>>>> ./webcommon/javascript2.types/nbproject/project.xml:15
>>>> ./platform/core.startup.base/nbproject/project.xml:15
>>>> ./ide/editor.settings.storage/nbproject/project.xml:15
>>>> ./enterprise/websvc.clientapi/nbproject/project.xml:15
>>>> ./enterprise/web.project/nbproject/project.xml:15
>>>> ./websvccommon/websvc.jaxwsmodelapi/nbproject/project.xml:14
>>>> ./webcommon/javascript2.editor/nbproject/project.xml:14
>>>> ./platform/core.startup/nbproject/project.xml:14
>>>> ./java/j2ee.persistence/nbproject/project.xml:14
>>>> ./ide/xml.axi/nbproject/project.xml:14
>>>> ./enterprise/websvc.jaxwsapi/nbproject/project.xml:14
>>>> ./websvccommon/websvc.saas.api/nbproject/project.xml:13
>>>> ./java/whitelist/nbproject/project.xml:13
>>>> ./enterprise/websvc.core/nbproject/project.xml:13
>>>> ./platform/o.n.core/nbproject/project.xml:12
>>>> ./ide/web.webkit.debugging/nbproject/project.xml:12
>>>> ./ide/dlight.terminal/nbproject/project.xml:12
>>>> ./webcommon/javascript2.model/nbproject/project.xml:11
>>>> ./php/php.api.annotation/nbproject/project.xml:11
>>>> ./java/maven.indexer/nbproject/project.xml:11
>>>> ./java/javaee.injection/nbproject/project.xml:11
>>>> ./java/j2ee.metadata.model.support/nbproject/project.xml:11
>>>> ./ide/hudson/nbproject/project.xml:11
>>>> ./extide/options.java/nbproject/project.xml:11
>>>> ./enterprise/j2ee.sun.dd/nbproject/project.xml:11
>>>> ./enterprise/glassfish.common/nbproject/project.xml:11
>>>> ./platform/o.n.bootstrap/nbproject/project.xml:10
>>>> ./java/java.testrunner/nbproject/project.xml:10
>>>> ./java/java.j2seproject/nbproject/project.xml:10
>>>>
>>>>
>> ./ide/xml.schema.completion/test/unit/src/org/netbeans/modules/xml/schema/completion/resources/project.xml:10
>>>> ./ide/jumpto/nbproject/project.xml:10
>>>> ./enterprise/web.jsf/nbproject/project.xml:10
>>>> ./enterprise/web.jsfapi/nbproject/project.xml:10
>>>>
>>>> On 09/21/2018 05:26 PM, Tim Boudreau wrote:
>>>> You may want to survey modules on Github that use implementation
>>>> dependencies or use Uenta to bypass them. For example, I've been
>> tweaking
>>>> the rust module from github, which does tag with a couple of csl
>> modules.
>>>> Those should count toward "friends".
>>>>
>>>> -Tim
>>>>
>>>> On Fri, Sep 21, 2018 at 8:01 PM Laszlo Kishalmi <
>> laszlo.kishalmi@gmail.com
>>>> wrote:
>>>>
>>>> Dear all,
>>>>
>>>> I'd like to summarize whet happened on the "API Friendliness" issue:
>>>>
>>>> We collected a number of possible options on our previous discussions
>> at:
>>>>
>> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
>>>> Commenting these options remained really silent though. This means our
>>>> Friend APIs most likely stay as they are now.
>>>>
>>>> I must acknowledge that adding new friends to an existing API is easier
>>>> than ever having NetBeans under Apache umbrella.
>>>>
>>>> I plan not to give up on making some APIs public though. Regarding the
>>>> low interest of making something big around this area, I think the most
>>>> viable solution is:
>>>>
>>>> Option 4: Make Module Public when There is more than a Certain Number of
>>>> Friend Dependencies.
>>>>
>>>> So sometime in the future I'm going to create a list of how many friends
>>>> a module does have and share the list with you.
>>>>
>>>>
>>>> Thank you all who participated in this effort!
>>>>
>>>> Laszlo Kishalmi
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>>>> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>>>>
>>>> For further information about the NetBeans mailing lists, visit:
>>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>>
>>>>
>>>>
>>>> --
>>>> http://timboudreau.com
>>>>
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API Reloaded (Summary)
Posted by Jan Lahoda <la...@gmail.com>.
So, if I understand correctly, the view is a combination of c) ("it is OK
if doing changes to the API is difficult", like writing compatibility
layers, more elaborate migration tutorials, updating existing plugins etc.)
and b) (making an occasional incompatible change).
I think I am fine with that, I just want to ensure the consequences are
understood. It is of course absolutely possible that a specific API won't
need any enhancements, and so will be fine.
One more comment inline.
On Sun, Sep 23, 2018 at 12:55 PM Peter Nabbefeld <pe...@gmx.de>
wrote:
> The problem here is:
>
> 1. If every API is friend-only, nobody will be able to depend on those
> without first becoming a friend. Or You have to depend on implementation
> version. So, these APIs will never be reviewed by the broader community
> and will never be ready for usage.
>
> 2. If the API is public, You may break other implementors plugins.
> You'll usually never do that to just annoy them, but because You've got
> some serious problem without changing it. As a result, the API should
> become more stable, more usable, and of better quality in general.
>
Not sure about this: when an API is not designed to be enhancible
compatibly, and is not sufficient (i.e. needs to be enhanced), I suspect
preference will be given to making the change compatibly, even at the cost
of making the API less nice. So, over time, the API will probably be more
complete, but possibly less clean.
Thanks,
Jan
Probably, for the time the major version of NB doesn't change, there
> should be a compatibility layer, if possible.
>
> 3. If the API changes, there needs of course to be a migration tutorial,
> which must be upgraded if there are still any questions around about how
> to upgrade the plugin.
>
> 4. Plugin developers are: plugin developers, so it should not be a big
> issue for them to update their dependent module, if there's a tutorial.
>
> 5. As sometimes developers loose interest in further maintaining their
> plugin, there should be the source available somewhere, so other
> developers could take care of those. Ideally, the plugins should also be
> licensed under AL2.0, so they could be supplied in some Apache contrib
> repository.
>
> So, IMHO modules should be friend-only for a maximum of 2 or 3 releases.
> After this, I'd expect them to be reasonable stable to make them public,
> so the community could experiment with those and probably make proposals
> for a better API. If the API changes then, most developers depending on
> the module will even be happy about the new possibilities. But they
> should also tell, if some change may make their usage of the module
> impossible, of course, so the problems could be considered early.
>
> Kind regards
>
> Peter
>
>
>
> Am 23.09.18 um 12:04 schrieb Jan Lahoda:
> > On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz <ch...@gmx.net>
> > wrote:
> >
> >> Hey guys,
> >>
> >> please see my last 3 comments of this ticket. It explains, why it is
> >> important to have public APIs instead of Friends:
> >>
> https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
> >>
> >>
> > My personal opinion only.
> >
> > I think noone doubts the a public API is better for plugins. However, I
> > think that it is necessary that at least one of the following is true:
> > a) someone signs up to make a proper public API, that we will be able to
> > enhance compatibly
> > b) we accept that there are smaller or bigger incompatible API changes
> > (size of the incompatible change depends on the nature of the change and
> of
> > the existing API)
> > c) we accept that some changes to the API will be very difficult to do
> > (compatibly), maybe even so difficult that they won't be made (so
> difficult
> > that noone will sign up to do the change)
> >
> > So, I wonder what are the views of others on these.
> >
> > Thanks,
> > Jan
> >
> >
> >> The Thing is, no one know, what other nice Plugins will come in the
> >> future, but everytime, someone creates a Plugin which Needs to be
> friend,
> >> depends on only the next release that someone adds it. That means, that
> >> this Plugin will first work only for the next release, if someone
> decided
> >> to add this Plugin as a friend. Same happens for every other Plugins
> that
> >> Comes later.
> >>
> >> It is not that everytime a user want to use the newest IDE, often
> someone
> >> stays at the IDE if there is Nothing really new for him/her to Change
> >> update. That means, that he/she could miss the Plugin, if it is relevant
> >> for him. In this release.
> >>
> >> And what happens, if someone removes the Plugin as a friend? That
> happens
> >> for Geertjans KendoUI Plugin. The Plugin worked some versions before,
> not
> >> now anymore, because it was removed from being a friend.
> >>
> >> Making APIs public makes much more sense for 3rd-party Plugin
> developers.
> >> I think HTML, JS, CSS, C/C++ PHP and whatever is there is stable enough
> for
> >> years to say: yes, make them public. And will there some exceptions,
> that
> >> the devs figure out, someone can fix it Maybe as a patch or for the next
> >> release, which is acceptable.
> >>
> >>
> >> Cheers
> >>
> >> Chris
> >>
> >>
> >>
> >> Von: Laszlo Kishalmi
> >> Gesendet: Sonntag, 23. September 2018 04:45
> >> An: dev@netbeans.incubator.apache.org
> >> Betreff: Re: Public vs. Friend API Reloaded (Summary)
> >>
> >> Hi all,
> >> This list is what we have inside the current codebase (Without Yenta on
> >> other locations.)
> >> I put those here which have 10+ friend marked. (The complete list is
> >> attached)
> >> Upon this list it could be a good choice to try make the following
> public
> >> (maybe for NetBeans 10):
> >> • gsf.testrunner
> >> • gsf.testrunner.ui
> >> I know that a few external language plugins are using those as well, and
> >> the API is quite a good shape anyway.
> >> What do you think?
> >> Generated using: find . -name project.xml -exec grep -H -c friend\> {}
> >> \;|sort -r -gt : -k 2 |grep -v :0
> >> ./ide/dlight.nativeexecution/nbproject/project.xml:147
> >> ./ide/dlight.nativeexecution.nb/nbproject/project.xml:145
> >> ./ide/web.common/nbproject/project.xml:68
> >> ./ide/gsf.testrunner/nbproject/project.xml:40
> >> ./php/php.api.phpmodule/nbproject/project.xml:39
> >> ./java/java.api.common/nbproject/project.xml:39
> >> ./ide/options.editor/nbproject/project.xml:39
> >> ./java/maven/nbproject/project.xml:37
> >> ./enterprise/j2ee.common/nbproject/project.xml:34
> >> ./profiler/profiler.api/nbproject/project.xml:32
> >> ./profiler/lib.profiler/nbproject/project.xml:32
> >> ./java/maven.embedder/nbproject/project.xml:31
> >> ./webcommon/web.clientproject.api/nbproject/project.xml:29
> >> ./profiler/lib.profiler.common/nbproject/project.xml:29
> >> ./ide/gsf.testrunner.ui/nbproject/project.xml:28
> >> ./php/php.api.executable/nbproject/project.xml:27
> >> ./ide/html.editor.lib/nbproject/project.xml:26
> >> ./enterprise/j2ee.api.ejbmodule/nbproject/project.xml:25
> >> ./ide/web.browser.api/nbproject/project.xml:24
> >> ./ide/lib.terminalemulator/nbproject/project.xml:24
> >> ./profiler/lib.profiler.ui/nbproject/project.xml:23
> >> ./java/maven.model/nbproject/project.xml:23
> >> ./java/j2ee.core.utilities/nbproject/project.xml:23
> >> ./enterprise/websvc.jaxwsmodel/nbproject/project.xml:23
> >> ./ide/team.commons/nbproject/project.xml:22
> >> ./ide/html.editor/nbproject/project.xml:22
> >> ./profiler/profiler/nbproject/project.xml:21
> >> ./platform/libs.jna/nbproject/project.xml:21
> >> ./php/php.api.editor/nbproject/project.xml:21
> >> ./java/java.preprocessorbridge/nbproject/project.xml:20
> >> ./ide/web.common.ui/nbproject/project.xml:20
> >> ./ide/terminal/nbproject/project.xml:20
> >> ./ide/terminal.nb/nbproject/project.xml:20
> >> ./java/j2ee.persistenceapi/nbproject/project.xml:19
> >> ./enterprise/javaee.specs.support/nbproject/project.xml:19
> >> ./webcommon/javascript2.lexer/nbproject/project.xml:17
> >> ./ide/xml.multiview/nbproject/project.xml:17
> >> ./ide/versioning.util/nbproject/project.xml:17
> >> ./ide/code.analysis/nbproject/project.xml:17
> >> ./php/php.api.framework/nbproject/project.xml:16
> >> ./ide/xml.text/nbproject/project.xml:16
> >> ./ide/versioning.core/nbproject/project.xml:16
> >> ./webcommon/javascript2.types/nbproject/project.xml:15
> >> ./platform/core.startup.base/nbproject/project.xml:15
> >> ./ide/editor.settings.storage/nbproject/project.xml:15
> >> ./enterprise/websvc.clientapi/nbproject/project.xml:15
> >> ./enterprise/web.project/nbproject/project.xml:15
> >> ./websvccommon/websvc.jaxwsmodelapi/nbproject/project.xml:14
> >> ./webcommon/javascript2.editor/nbproject/project.xml:14
> >> ./platform/core.startup/nbproject/project.xml:14
> >> ./java/j2ee.persistence/nbproject/project.xml:14
> >> ./ide/xml.axi/nbproject/project.xml:14
> >> ./enterprise/websvc.jaxwsapi/nbproject/project.xml:14
> >> ./websvccommon/websvc.saas.api/nbproject/project.xml:13
> >> ./java/whitelist/nbproject/project.xml:13
> >> ./enterprise/websvc.core/nbproject/project.xml:13
> >> ./platform/o.n.core/nbproject/project.xml:12
> >> ./ide/web.webkit.debugging/nbproject/project.xml:12
> >> ./ide/dlight.terminal/nbproject/project.xml:12
> >> ./webcommon/javascript2.model/nbproject/project.xml:11
> >> ./php/php.api.annotation/nbproject/project.xml:11
> >> ./java/maven.indexer/nbproject/project.xml:11
> >> ./java/javaee.injection/nbproject/project.xml:11
> >> ./java/j2ee.metadata.model.support/nbproject/project.xml:11
> >> ./ide/hudson/nbproject/project.xml:11
> >> ./extide/options.java/nbproject/project.xml:11
> >> ./enterprise/j2ee.sun.dd/nbproject/project.xml:11
> >> ./enterprise/glassfish.common/nbproject/project.xml:11
> >> ./platform/o.n.bootstrap/nbproject/project.xml:10
> >> ./java/java.testrunner/nbproject/project.xml:10
> >> ./java/java.j2seproject/nbproject/project.xml:10
> >>
> >>
> ./ide/xml.schema.completion/test/unit/src/org/netbeans/modules/xml/schema/completion/resources/project.xml:10
> >> ./ide/jumpto/nbproject/project.xml:10
> >> ./enterprise/web.jsf/nbproject/project.xml:10
> >> ./enterprise/web.jsfapi/nbproject/project.xml:10
> >>
> >> On 09/21/2018 05:26 PM, Tim Boudreau wrote:
> >> You may want to survey modules on Github that use implementation
> >> dependencies or use Uenta to bypass them. For example, I've been
> tweaking
> >> the rust module from github, which does tag with a couple of csl
> modules.
> >> Those should count toward "friends".
> >>
> >> -Tim
> >>
> >> On Fri, Sep 21, 2018 at 8:01 PM Laszlo Kishalmi <
> laszlo.kishalmi@gmail.com
> >> wrote:
> >>
> >> Dear all,
> >>
> >> I'd like to summarize whet happened on the "API Friendliness" issue:
> >>
> >> We collected a number of possible options on our previous discussions
> at:
> >>
> >>
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
> >>
> >> Commenting these options remained really silent though. This means our
> >> Friend APIs most likely stay as they are now.
> >>
> >> I must acknowledge that adding new friends to an existing API is easier
> >> than ever having NetBeans under Apache umbrella.
> >>
> >> I plan not to give up on making some APIs public though. Regarding the
> >> low interest of making something big around this area, I think the most
> >> viable solution is:
> >>
> >> Option 4: Make Module Public when There is more than a Certain Number of
> >> Friend Dependencies.
> >>
> >> So sometime in the future I'm going to create a list of how many friends
> >> a module does have and share the list with you.
> >>
> >>
> >> Thank you all who participated in this effort!
> >>
> >> Laszlo Kishalmi
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> >> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> >>
> >> For further information about the NetBeans mailing lists, visit:
> >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>
> >>
> >>
> >> --
> >> http://timboudreau.com
> >>
> >>
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Public vs. Friend API Reloaded (Summary)
Posted by Peter Nabbefeld <pe...@gmx.de>.
The problem here is:
1. If every API is friend-only, nobody will be able to depend on those
without first becoming a friend. Or You have to depend on implementation
version. So, these APIs will never be reviewed by the broader community
and will never be ready for usage.
2. If the API is public, You may break other implementors plugins.
You'll usually never do that to just annoy them, but because You've got
some serious problem without changing it. As a result, the API should
become more stable, more usable, and of better quality in general.
Probably, for the time the major version of NB doesn't change, there
should be a compatibility layer, if possible.
3. If the API changes, there needs of course to be a migration tutorial,
which must be upgraded if there are still any questions around about how
to upgrade the plugin.
4. Plugin developers are: plugin developers, so it should not be a big
issue for them to update their dependent module, if there's a tutorial.
5. As sometimes developers loose interest in further maintaining their
plugin, there should be the source available somewhere, so other
developers could take care of those. Ideally, the plugins should also be
licensed under AL2.0, so they could be supplied in some Apache contrib
repository.
So, IMHO modules should be friend-only for a maximum of 2 or 3 releases.
After this, I'd expect them to be reasonable stable to make them public,
so the community could experiment with those and probably make proposals
for a better API. If the API changes then, most developers depending on
the module will even be happy about the new possibilities. But they
should also tell, if some change may make their usage of the module
impossible, of course, so the problems could be considered early.
Kind regards
Peter
Am 23.09.18 um 12:04 schrieb Jan Lahoda:
> On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz <ch...@gmx.net>
> wrote:
>
>> Hey guys,
>>
>> please see my last 3 comments of this ticket. It explains, why it is
>> important to have public APIs instead of Friends:
>> https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
>>
>>
> My personal opinion only.
>
> I think noone doubts the a public API is better for plugins. However, I
> think that it is necessary that at least one of the following is true:
> a) someone signs up to make a proper public API, that we will be able to
> enhance compatibly
> b) we accept that there are smaller or bigger incompatible API changes
> (size of the incompatible change depends on the nature of the change and of
> the existing API)
> c) we accept that some changes to the API will be very difficult to do
> (compatibly), maybe even so difficult that they won't be made (so difficult
> that noone will sign up to do the change)
>
> So, I wonder what are the views of others on these.
>
> Thanks,
> Jan
>
>
>> The Thing is, no one know, what other nice Plugins will come in the
>> future, but everytime, someone creates a Plugin which Needs to be friend,
>> depends on only the next release that someone adds it. That means, that
>> this Plugin will first work only for the next release, if someone decided
>> to add this Plugin as a friend. Same happens for every other Plugins that
>> Comes later.
>>
>> It is not that everytime a user want to use the newest IDE, often someone
>> stays at the IDE if there is Nothing really new for him/her to Change
>> update. That means, that he/she could miss the Plugin, if it is relevant
>> for him. In this release.
>>
>> And what happens, if someone removes the Plugin as a friend? That happens
>> for Geertjans KendoUI Plugin. The Plugin worked some versions before, not
>> now anymore, because it was removed from being a friend.
>>
>> Making APIs public makes much more sense for 3rd-party Plugin developers.
>> I think HTML, JS, CSS, C/C++ PHP and whatever is there is stable enough for
>> years to say: yes, make them public. And will there some exceptions, that
>> the devs figure out, someone can fix it Maybe as a patch or for the next
>> release, which is acceptable.
>>
>>
>> Cheers
>>
>> Chris
>>
>>
>>
>> Von: Laszlo Kishalmi
>> Gesendet: Sonntag, 23. September 2018 04:45
>> An: dev@netbeans.incubator.apache.org
>> Betreff: Re: Public vs. Friend API Reloaded (Summary)
>>
>> Hi all,
>> This list is what we have inside the current codebase (Without Yenta on
>> other locations.)
>> I put those here which have 10+ friend marked. (The complete list is
>> attached)
>> Upon this list it could be a good choice to try make the following public
>> (maybe for NetBeans 10):
>> • gsf.testrunner
>> • gsf.testrunner.ui
>> I know that a few external language plugins are using those as well, and
>> the API is quite a good shape anyway.
>> What do you think?
>> Generated using: find . -name project.xml -exec grep -H -c friend\> {}
>> \;|sort -r -gt : -k 2 |grep -v :0
>> ./ide/dlight.nativeexecution/nbproject/project.xml:147
>> ./ide/dlight.nativeexecution.nb/nbproject/project.xml:145
>> ./ide/web.common/nbproject/project.xml:68
>> ./ide/gsf.testrunner/nbproject/project.xml:40
>> ./php/php.api.phpmodule/nbproject/project.xml:39
>> ./java/java.api.common/nbproject/project.xml:39
>> ./ide/options.editor/nbproject/project.xml:39
>> ./java/maven/nbproject/project.xml:37
>> ./enterprise/j2ee.common/nbproject/project.xml:34
>> ./profiler/profiler.api/nbproject/project.xml:32
>> ./profiler/lib.profiler/nbproject/project.xml:32
>> ./java/maven.embedder/nbproject/project.xml:31
>> ./webcommon/web.clientproject.api/nbproject/project.xml:29
>> ./profiler/lib.profiler.common/nbproject/project.xml:29
>> ./ide/gsf.testrunner.ui/nbproject/project.xml:28
>> ./php/php.api.executable/nbproject/project.xml:27
>> ./ide/html.editor.lib/nbproject/project.xml:26
>> ./enterprise/j2ee.api.ejbmodule/nbproject/project.xml:25
>> ./ide/web.browser.api/nbproject/project.xml:24
>> ./ide/lib.terminalemulator/nbproject/project.xml:24
>> ./profiler/lib.profiler.ui/nbproject/project.xml:23
>> ./java/maven.model/nbproject/project.xml:23
>> ./java/j2ee.core.utilities/nbproject/project.xml:23
>> ./enterprise/websvc.jaxwsmodel/nbproject/project.xml:23
>> ./ide/team.commons/nbproject/project.xml:22
>> ./ide/html.editor/nbproject/project.xml:22
>> ./profiler/profiler/nbproject/project.xml:21
>> ./platform/libs.jna/nbproject/project.xml:21
>> ./php/php.api.editor/nbproject/project.xml:21
>> ./java/java.preprocessorbridge/nbproject/project.xml:20
>> ./ide/web.common.ui/nbproject/project.xml:20
>> ./ide/terminal/nbproject/project.xml:20
>> ./ide/terminal.nb/nbproject/project.xml:20
>> ./java/j2ee.persistenceapi/nbproject/project.xml:19
>> ./enterprise/javaee.specs.support/nbproject/project.xml:19
>> ./webcommon/javascript2.lexer/nbproject/project.xml:17
>> ./ide/xml.multiview/nbproject/project.xml:17
>> ./ide/versioning.util/nbproject/project.xml:17
>> ./ide/code.analysis/nbproject/project.xml:17
>> ./php/php.api.framework/nbproject/project.xml:16
>> ./ide/xml.text/nbproject/project.xml:16
>> ./ide/versioning.core/nbproject/project.xml:16
>> ./webcommon/javascript2.types/nbproject/project.xml:15
>> ./platform/core.startup.base/nbproject/project.xml:15
>> ./ide/editor.settings.storage/nbproject/project.xml:15
>> ./enterprise/websvc.clientapi/nbproject/project.xml:15
>> ./enterprise/web.project/nbproject/project.xml:15
>> ./websvccommon/websvc.jaxwsmodelapi/nbproject/project.xml:14
>> ./webcommon/javascript2.editor/nbproject/project.xml:14
>> ./platform/core.startup/nbproject/project.xml:14
>> ./java/j2ee.persistence/nbproject/project.xml:14
>> ./ide/xml.axi/nbproject/project.xml:14
>> ./enterprise/websvc.jaxwsapi/nbproject/project.xml:14
>> ./websvccommon/websvc.saas.api/nbproject/project.xml:13
>> ./java/whitelist/nbproject/project.xml:13
>> ./enterprise/websvc.core/nbproject/project.xml:13
>> ./platform/o.n.core/nbproject/project.xml:12
>> ./ide/web.webkit.debugging/nbproject/project.xml:12
>> ./ide/dlight.terminal/nbproject/project.xml:12
>> ./webcommon/javascript2.model/nbproject/project.xml:11
>> ./php/php.api.annotation/nbproject/project.xml:11
>> ./java/maven.indexer/nbproject/project.xml:11
>> ./java/javaee.injection/nbproject/project.xml:11
>> ./java/j2ee.metadata.model.support/nbproject/project.xml:11
>> ./ide/hudson/nbproject/project.xml:11
>> ./extide/options.java/nbproject/project.xml:11
>> ./enterprise/j2ee.sun.dd/nbproject/project.xml:11
>> ./enterprise/glassfish.common/nbproject/project.xml:11
>> ./platform/o.n.bootstrap/nbproject/project.xml:10
>> ./java/java.testrunner/nbproject/project.xml:10
>> ./java/java.j2seproject/nbproject/project.xml:10
>>
>> ./ide/xml.schema.completion/test/unit/src/org/netbeans/modules/xml/schema/completion/resources/project.xml:10
>> ./ide/jumpto/nbproject/project.xml:10
>> ./enterprise/web.jsf/nbproject/project.xml:10
>> ./enterprise/web.jsfapi/nbproject/project.xml:10
>>
>> On 09/21/2018 05:26 PM, Tim Boudreau wrote:
>> You may want to survey modules on Github that use implementation
>> dependencies or use Uenta to bypass them. For example, I've been tweaking
>> the rust module from github, which does tag with a couple of csl modules.
>> Those should count toward "friends".
>>
>> -Tim
>>
>> On Fri, Sep 21, 2018 at 8:01 PM Laszlo Kishalmi <laszlo.kishalmi@gmail.com
>> wrote:
>>
>> Dear all,
>>
>> I'd like to summarize whet happened on the "API Friendliness" issue:
>>
>> We collected a number of possible options on our previous discussions at:
>>
>> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
>>
>> Commenting these options remained really silent though. This means our
>> Friend APIs most likely stay as they are now.
>>
>> I must acknowledge that adding new friends to an existing API is easier
>> than ever having NetBeans under Apache umbrella.
>>
>> I plan not to give up on making some APIs public though. Regarding the
>> low interest of making something big around this area, I think the most
>> viable solution is:
>>
>> Option 4: Make Module Public when There is more than a Certain Number of
>> Friend Dependencies.
>>
>> So sometime in the future I'm going to create a list of how many friends
>> a module does have and share the list with you.
>>
>>
>> Thank you all who participated in this effort!
>>
>> Laszlo Kishalmi
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>> --
>> http://timboudreau.com
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API Reloaded (Summary)
Posted by Jan Lahoda <la...@gmail.com>.
On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz <ch...@gmx.net>
wrote:
> Hey guys,
>
> please see my last 3 comments of this ticket. It explains, why it is
> important to have public APIs instead of Friends:
> https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
>
>
My personal opinion only.
I think noone doubts the a public API is better for plugins. However, I
think that it is necessary that at least one of the following is true:
a) someone signs up to make a proper public API, that we will be able to
enhance compatibly
b) we accept that there are smaller or bigger incompatible API changes
(size of the incompatible change depends on the nature of the change and of
the existing API)
c) we accept that some changes to the API will be very difficult to do
(compatibly), maybe even so difficult that they won't be made (so difficult
that noone will sign up to do the change)
So, I wonder what are the views of others on these.
Thanks,
Jan
> The Thing is, no one know, what other nice Plugins will come in the
> future, but everytime, someone creates a Plugin which Needs to be friend,
> depends on only the next release that someone adds it. That means, that
> this Plugin will first work only for the next release, if someone decided
> to add this Plugin as a friend. Same happens for every other Plugins that
> Comes later.
>
> It is not that everytime a user want to use the newest IDE, often someone
> stays at the IDE if there is Nothing really new for him/her to Change
> update. That means, that he/she could miss the Plugin, if it is relevant
> for him. In this release.
>
> And what happens, if someone removes the Plugin as a friend? That happens
> for Geertjans KendoUI Plugin. The Plugin worked some versions before, not
> now anymore, because it was removed from being a friend.
>
> Making APIs public makes much more sense for 3rd-party Plugin developers.
> I think HTML, JS, CSS, C/C++ PHP and whatever is there is stable enough for
> years to say: yes, make them public. And will there some exceptions, that
> the devs figure out, someone can fix it Maybe as a patch or for the next
> release, which is acceptable.
>
>
> Cheers
>
> Chris
>
>
>
> Von: Laszlo Kishalmi
> Gesendet: Sonntag, 23. September 2018 04:45
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Public vs. Friend API Reloaded (Summary)
>
> Hi all,
> This list is what we have inside the current codebase (Without Yenta on
> other locations.)
> I put those here which have 10+ friend marked. (The complete list is
> attached)
> Upon this list it could be a good choice to try make the following public
> (maybe for NetBeans 10):
> • gsf.testrunner
> • gsf.testrunner.ui
> I know that a few external language plugins are using those as well, and
> the API is quite a good shape anyway.
> What do you think?
> Generated using: find . -name project.xml -exec grep -H -c friend\> {}
> \;|sort -r -gt : -k 2 |grep -v :0
> ./ide/dlight.nativeexecution/nbproject/project.xml:147
> ./ide/dlight.nativeexecution.nb/nbproject/project.xml:145
> ./ide/web.common/nbproject/project.xml:68
> ./ide/gsf.testrunner/nbproject/project.xml:40
> ./php/php.api.phpmodule/nbproject/project.xml:39
> ./java/java.api.common/nbproject/project.xml:39
> ./ide/options.editor/nbproject/project.xml:39
> ./java/maven/nbproject/project.xml:37
> ./enterprise/j2ee.common/nbproject/project.xml:34
> ./profiler/profiler.api/nbproject/project.xml:32
> ./profiler/lib.profiler/nbproject/project.xml:32
> ./java/maven.embedder/nbproject/project.xml:31
> ./webcommon/web.clientproject.api/nbproject/project.xml:29
> ./profiler/lib.profiler.common/nbproject/project.xml:29
> ./ide/gsf.testrunner.ui/nbproject/project.xml:28
> ./php/php.api.executable/nbproject/project.xml:27
> ./ide/html.editor.lib/nbproject/project.xml:26
> ./enterprise/j2ee.api.ejbmodule/nbproject/project.xml:25
> ./ide/web.browser.api/nbproject/project.xml:24
> ./ide/lib.terminalemulator/nbproject/project.xml:24
> ./profiler/lib.profiler.ui/nbproject/project.xml:23
> ./java/maven.model/nbproject/project.xml:23
> ./java/j2ee.core.utilities/nbproject/project.xml:23
> ./enterprise/websvc.jaxwsmodel/nbproject/project.xml:23
> ./ide/team.commons/nbproject/project.xml:22
> ./ide/html.editor/nbproject/project.xml:22
> ./profiler/profiler/nbproject/project.xml:21
> ./platform/libs.jna/nbproject/project.xml:21
> ./php/php.api.editor/nbproject/project.xml:21
> ./java/java.preprocessorbridge/nbproject/project.xml:20
> ./ide/web.common.ui/nbproject/project.xml:20
> ./ide/terminal/nbproject/project.xml:20
> ./ide/terminal.nb/nbproject/project.xml:20
> ./java/j2ee.persistenceapi/nbproject/project.xml:19
> ./enterprise/javaee.specs.support/nbproject/project.xml:19
> ./webcommon/javascript2.lexer/nbproject/project.xml:17
> ./ide/xml.multiview/nbproject/project.xml:17
> ./ide/versioning.util/nbproject/project.xml:17
> ./ide/code.analysis/nbproject/project.xml:17
> ./php/php.api.framework/nbproject/project.xml:16
> ./ide/xml.text/nbproject/project.xml:16
> ./ide/versioning.core/nbproject/project.xml:16
> ./webcommon/javascript2.types/nbproject/project.xml:15
> ./platform/core.startup.base/nbproject/project.xml:15
> ./ide/editor.settings.storage/nbproject/project.xml:15
> ./enterprise/websvc.clientapi/nbproject/project.xml:15
> ./enterprise/web.project/nbproject/project.xml:15
> ./websvccommon/websvc.jaxwsmodelapi/nbproject/project.xml:14
> ./webcommon/javascript2.editor/nbproject/project.xml:14
> ./platform/core.startup/nbproject/project.xml:14
> ./java/j2ee.persistence/nbproject/project.xml:14
> ./ide/xml.axi/nbproject/project.xml:14
> ./enterprise/websvc.jaxwsapi/nbproject/project.xml:14
> ./websvccommon/websvc.saas.api/nbproject/project.xml:13
> ./java/whitelist/nbproject/project.xml:13
> ./enterprise/websvc.core/nbproject/project.xml:13
> ./platform/o.n.core/nbproject/project.xml:12
> ./ide/web.webkit.debugging/nbproject/project.xml:12
> ./ide/dlight.terminal/nbproject/project.xml:12
> ./webcommon/javascript2.model/nbproject/project.xml:11
> ./php/php.api.annotation/nbproject/project.xml:11
> ./java/maven.indexer/nbproject/project.xml:11
> ./java/javaee.injection/nbproject/project.xml:11
> ./java/j2ee.metadata.model.support/nbproject/project.xml:11
> ./ide/hudson/nbproject/project.xml:11
> ./extide/options.java/nbproject/project.xml:11
> ./enterprise/j2ee.sun.dd/nbproject/project.xml:11
> ./enterprise/glassfish.common/nbproject/project.xml:11
> ./platform/o.n.bootstrap/nbproject/project.xml:10
> ./java/java.testrunner/nbproject/project.xml:10
> ./java/java.j2seproject/nbproject/project.xml:10
>
> ./ide/xml.schema.completion/test/unit/src/org/netbeans/modules/xml/schema/completion/resources/project.xml:10
> ./ide/jumpto/nbproject/project.xml:10
> ./enterprise/web.jsf/nbproject/project.xml:10
> ./enterprise/web.jsfapi/nbproject/project.xml:10
>
> On 09/21/2018 05:26 PM, Tim Boudreau wrote:
> You may want to survey modules on Github that use implementation
> dependencies or use Uenta to bypass them. For example, I've been tweaking
> the rust module from github, which does tag with a couple of csl modules.
> Those should count toward "friends".
>
> -Tim
>
> On Fri, Sep 21, 2018 at 8:01 PM Laszlo Kishalmi <laszlo.kishalmi@gmail.com
> >
> wrote:
>
> Dear all,
>
> I'd like to summarize whet happened on the "API Friendliness" issue:
>
> We collected a number of possible options on our previous discussions at:
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
>
> Commenting these options remained really silent though. This means our
> Friend APIs most likely stay as they are now.
>
> I must acknowledge that adding new friends to an existing API is easier
> than ever having NetBeans under Apache umbrella.
>
> I plan not to give up on making some APIs public though. Regarding the
> low interest of making something big around this area, I think the most
> viable solution is:
>
> Option 4: Make Module Public when There is more than a Certain Number of
> Friend Dependencies.
>
> So sometime in the future I'm going to create a list of how many friends
> a module does have and share the list with you.
>
>
> Thank you all who participated in this effort!
>
> Laszlo Kishalmi
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
> http://timboudreau.com
>
>
>
>
AW: Public vs. Friend API Reloaded (Summary)
Posted by Christian Lenz <ch...@gmx.net>.
Hey guys,
please see my last 3 comments of this ticket. It explains, why it is important to have public APIs instead of Friends: https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
The Thing is, no one know, what other nice Plugins will come in the future, but everytime, someone creates a Plugin which Needs to be friend, depends on only the next release that someone adds it. That means, that this Plugin will first work only for the next release, if someone decided to add this Plugin as a friend. Same happens for every other Plugins that Comes later.
It is not that everytime a user want to use the newest IDE, often someone stays at the IDE if there is Nothing really new for him/her to Change update. That means, that he/she could miss the Plugin, if it is relevant for him. In this release.
And what happens, if someone removes the Plugin as a friend? That happens for Geertjans KendoUI Plugin. The Plugin worked some versions before, not now anymore, because it was removed from being a friend.
Making APIs public makes much more sense for 3rd-party Plugin developers. I think HTML, JS, CSS, C/C++ PHP and whatever is there is stable enough for years to say: yes, make them public. And will there some exceptions, that the devs figure out, someone can fix it Maybe as a patch or for the next release, which is acceptable.
Cheers
Chris
Von: Laszlo Kishalmi
Gesendet: Sonntag, 23. September 2018 04:45
An: dev@netbeans.incubator.apache.org
Betreff: Re: Public vs. Friend API Reloaded (Summary)
Hi all,
This list is what we have inside the current codebase (Without Yenta on other locations.)
I put those here which have 10+ friend marked. (The complete list is attached)
Upon this list it could be a good choice to try make the following public (maybe for NetBeans 10):
• gsf.testrunner
• gsf.testrunner.ui
I know that a few external language plugins are using those as well, and the API is quite a good shape anyway.
What do you think?
Generated using: find . -name project.xml -exec grep -H -c friend\> {} \;|sort -r -gt : -k 2 |grep -v :0
./ide/dlight.nativeexecution/nbproject/project.xml:147
./ide/dlight.nativeexecution.nb/nbproject/project.xml:145
./ide/web.common/nbproject/project.xml:68
./ide/gsf.testrunner/nbproject/project.xml:40
./php/php.api.phpmodule/nbproject/project.xml:39
./java/java.api.common/nbproject/project.xml:39
./ide/options.editor/nbproject/project.xml:39
./java/maven/nbproject/project.xml:37
./enterprise/j2ee.common/nbproject/project.xml:34
./profiler/profiler.api/nbproject/project.xml:32
./profiler/lib.profiler/nbproject/project.xml:32
./java/maven.embedder/nbproject/project.xml:31
./webcommon/web.clientproject.api/nbproject/project.xml:29
./profiler/lib.profiler.common/nbproject/project.xml:29
./ide/gsf.testrunner.ui/nbproject/project.xml:28
./php/php.api.executable/nbproject/project.xml:27
./ide/html.editor.lib/nbproject/project.xml:26
./enterprise/j2ee.api.ejbmodule/nbproject/project.xml:25
./ide/web.browser.api/nbproject/project.xml:24
./ide/lib.terminalemulator/nbproject/project.xml:24
./profiler/lib.profiler.ui/nbproject/project.xml:23
./java/maven.model/nbproject/project.xml:23
./java/j2ee.core.utilities/nbproject/project.xml:23
./enterprise/websvc.jaxwsmodel/nbproject/project.xml:23
./ide/team.commons/nbproject/project.xml:22
./ide/html.editor/nbproject/project.xml:22
./profiler/profiler/nbproject/project.xml:21
./platform/libs.jna/nbproject/project.xml:21
./php/php.api.editor/nbproject/project.xml:21
./java/java.preprocessorbridge/nbproject/project.xml:20
./ide/web.common.ui/nbproject/project.xml:20
./ide/terminal/nbproject/project.xml:20
./ide/terminal.nb/nbproject/project.xml:20
./java/j2ee.persistenceapi/nbproject/project.xml:19
./enterprise/javaee.specs.support/nbproject/project.xml:19
./webcommon/javascript2.lexer/nbproject/project.xml:17
./ide/xml.multiview/nbproject/project.xml:17
./ide/versioning.util/nbproject/project.xml:17
./ide/code.analysis/nbproject/project.xml:17
./php/php.api.framework/nbproject/project.xml:16
./ide/xml.text/nbproject/project.xml:16
./ide/versioning.core/nbproject/project.xml:16
./webcommon/javascript2.types/nbproject/project.xml:15
./platform/core.startup.base/nbproject/project.xml:15
./ide/editor.settings.storage/nbproject/project.xml:15
./enterprise/websvc.clientapi/nbproject/project.xml:15
./enterprise/web.project/nbproject/project.xml:15
./websvccommon/websvc.jaxwsmodelapi/nbproject/project.xml:14
./webcommon/javascript2.editor/nbproject/project.xml:14
./platform/core.startup/nbproject/project.xml:14
./java/j2ee.persistence/nbproject/project.xml:14
./ide/xml.axi/nbproject/project.xml:14
./enterprise/websvc.jaxwsapi/nbproject/project.xml:14
./websvccommon/websvc.saas.api/nbproject/project.xml:13
./java/whitelist/nbproject/project.xml:13
./enterprise/websvc.core/nbproject/project.xml:13
./platform/o.n.core/nbproject/project.xml:12
./ide/web.webkit.debugging/nbproject/project.xml:12
./ide/dlight.terminal/nbproject/project.xml:12
./webcommon/javascript2.model/nbproject/project.xml:11
./php/php.api.annotation/nbproject/project.xml:11
./java/maven.indexer/nbproject/project.xml:11
./java/javaee.injection/nbproject/project.xml:11
./java/j2ee.metadata.model.support/nbproject/project.xml:11
./ide/hudson/nbproject/project.xml:11
./extide/options.java/nbproject/project.xml:11
./enterprise/j2ee.sun.dd/nbproject/project.xml:11
./enterprise/glassfish.common/nbproject/project.xml:11
./platform/o.n.bootstrap/nbproject/project.xml:10
./java/java.testrunner/nbproject/project.xml:10
./java/java.j2seproject/nbproject/project.xml:10
./ide/xml.schema.completion/test/unit/src/org/netbeans/modules/xml/schema/completion/resources/project.xml:10
./ide/jumpto/nbproject/project.xml:10
./enterprise/web.jsf/nbproject/project.xml:10
./enterprise/web.jsfapi/nbproject/project.xml:10
On 09/21/2018 05:26 PM, Tim Boudreau wrote:
You may want to survey modules on Github that use implementation
dependencies or use Uenta to bypass them. For example, I've been tweaking
the rust module from github, which does tag with a couple of csl modules.
Those should count toward "friends".
-Tim
On Fri, Sep 21, 2018 at 8:01 PM Laszlo Kishalmi <la...@gmail.com>
wrote:
Dear all,
I'd like to summarize whet happened on the "API Friendliness" issue:
We collected a number of possible options on our previous discussions at:
https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
Commenting these options remained really silent though. This means our
Friend APIs most likely stay as they are now.
I must acknowledge that adding new friends to an existing API is easier
than ever having NetBeans under Apache umbrella.
I plan not to give up on making some APIs public though. Regarding the
low interest of making something big around this area, I think the most
viable solution is:
Option 4: Make Module Public when There is more than a Certain Number of
Friend Dependencies.
So sometime in the future I'm going to create a list of how many friends
a module does have and share the list with you.
Thank you all who participated in this effort!
Laszlo Kishalmi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
--
http://timboudreau.com
Re: Public vs. Friend API Reloaded (Summary)
Posted by Laszlo Kishalmi <la...@gmail.com>.
Hi all,
This list is what we have inside the current codebase (Without Yenta on
other locations.)
I put those here which have 10+ friend marked. (The complete list is
attached)
Upon this list it could be a good choice to try make the following
public (maybe for NetBeans 10):
* gsf.testrunner
* gsf.testrunner.ui
I know that a few external language plugins are using those as well, and
the API is quite a good shape anyway.
What do you think?
Generated using: find . -name project.xml -exec grep -H -c friend\> {}
\;|sort -r -gt : -k 2 |grep -v :0
./ide/dlight.nativeexecution/nbproject/project.xml:147
./ide/dlight.nativeexecution.nb/nbproject/project.xml:145
./ide/web.common/nbproject/project.xml:68
./ide/gsf.testrunner/nbproject/project.xml:40
./php/php.api.phpmodule/nbproject/project.xml:39
./java/java.api.common/nbproject/project.xml:39
./ide/options.editor/nbproject/project.xml:39
./java/maven/nbproject/project.xml:37
./enterprise/j2ee.common/nbproject/project.xml:34
./profiler/profiler.api/nbproject/project.xml:32
./profiler/lib.profiler/nbproject/project.xml:32
./java/maven.embedder/nbproject/project.xml:31
./webcommon/web.clientproject.api/nbproject/project.xml:29
./profiler/lib.profiler.common/nbproject/project.xml:29
./ide/gsf.testrunner.ui/nbproject/project.xml:28
./php/php.api.executable/nbproject/project.xml:27
./ide/html.editor.lib/nbproject/project.xml:26
./enterprise/j2ee.api.ejbmodule/nbproject/project.xml:25
./ide/web.browser.api/nbproject/project.xml:24
./ide/lib.terminalemulator/nbproject/project.xml:24
./profiler/lib.profiler.ui/nbproject/project.xml:23
./java/maven.model/nbproject/project.xml:23
./java/j2ee.core.utilities/nbproject/project.xml:23
./enterprise/websvc.jaxwsmodel/nbproject/project.xml:23
./ide/team.commons/nbproject/project.xml:22
./ide/html.editor/nbproject/project.xml:22
./profiler/profiler/nbproject/project.xml:21
./platform/libs.jna/nbproject/project.xml:21
./php/php.api.editor/nbproject/project.xml:21
./java/java.preprocessorbridge/nbproject/project.xml:20
./ide/web.common.ui/nbproject/project.xml:20
./ide/terminal/nbproject/project.xml:20
./ide/terminal.nb/nbproject/project.xml:20
./java/j2ee.persistenceapi/nbproject/project.xml:19
./enterprise/javaee.specs.support/nbproject/project.xml:19
./webcommon/javascript2.lexer/nbproject/project.xml:17
./ide/xml.multiview/nbproject/project.xml:17
./ide/versioning.util/nbproject/project.xml:17
./ide/code.analysis/nbproject/project.xml:17
./php/php.api.framework/nbproject/project.xml:16
./ide/xml.text/nbproject/project.xml:16
./ide/versioning.core/nbproject/project.xml:16
./webcommon/javascript2.types/nbproject/project.xml:15
./platform/core.startup.base/nbproject/project.xml:15
./ide/editor.settings.storage/nbproject/project.xml:15
./enterprise/websvc.clientapi/nbproject/project.xml:15
./enterprise/web.project/nbproject/project.xml:15
./websvccommon/websvc.jaxwsmodelapi/nbproject/project.xml:14
./webcommon/javascript2.editor/nbproject/project.xml:14
./platform/core.startup/nbproject/project.xml:14
./java/j2ee.persistence/nbproject/project.xml:14
./ide/xml.axi/nbproject/project.xml:14
./enterprise/websvc.jaxwsapi/nbproject/project.xml:14
./websvccommon/websvc.saas.api/nbproject/project.xml:13
./java/whitelist/nbproject/project.xml:13
./enterprise/websvc.core/nbproject/project.xml:13
./platform/o.n.core/nbproject/project.xml:12
./ide/web.webkit.debugging/nbproject/project.xml:12
./ide/dlight.terminal/nbproject/project.xml:12
./webcommon/javascript2.model/nbproject/project.xml:11
./php/php.api.annotation/nbproject/project.xml:11
./java/maven.indexer/nbproject/project.xml:11
./java/javaee.injection/nbproject/project.xml:11
./java/j2ee.metadata.model.support/nbproject/project.xml:11
./ide/hudson/nbproject/project.xml:11
./extide/options.java/nbproject/project.xml:11
./enterprise/j2ee.sun.dd/nbproject/project.xml:11
./enterprise/glassfish.common/nbproject/project.xml:11
./platform/o.n.bootstrap/nbproject/project.xml:10
./java/java.testrunner/nbproject/project.xml:10
./java/java.j2seproject/nbproject/project.xml:10
./ide/xml.schema.completion/test/unit/src/org/netbeans/modules/xml/schema/completion/resources/project.xml:10
./ide/jumpto/nbproject/project.xml:10
./enterprise/web.jsf/nbproject/project.xml:10
./enterprise/web.jsfapi/nbproject/project.xml:10
On 09/21/2018 05:26 PM, Tim Boudreau wrote:
> You may want to survey modules on Github that use implementation
> dependencies or use Uenta to bypass them. For example, I've been tweaking
> the rust module from github, which does tag with a couple of csl modules.
> Those should count toward "friends".
>
> -Tim
>
> On Fri, Sep 21, 2018 at 8:01 PM Laszlo Kishalmi <la...@gmail.com>
> wrote:
>
>> Dear all,
>>
>> I'd like to summarize whet happened on the "API Friendliness" issue:
>>
>> We collected a number of possible options on our previous discussions at:
>>
>> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
>>
>> Commenting these options remained really silent though. This means our
>> Friend APIs most likely stay as they are now.
>>
>> I must acknowledge that adding new friends to an existing API is easier
>> than ever having NetBeans under Apache umbrella.
>>
>> I plan not to give up on making some APIs public though. Regarding the
>> low interest of making something big around this area, I think the most
>> viable solution is:
>>
>> Option 4: Make Module Public when There is more than a Certain Number of
>> Friend Dependencies.
>>
>> So sometime in the future I'm going to create a list of how many friends
>> a module does have and share the list with you.
>>
>>
>> Thank you all who participated in this effort!
>>
>> Laszlo Kishalmi
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>> --
> http://timboudreau.com
>
Re: Public vs. Friend API Reloaded (Summary)
Posted by Tim Boudreau <ni...@gmail.com>.
You may want to survey modules on Github that use implementation
dependencies or use Uenta to bypass them. For example, I've been tweaking
the rust module from github, which does tag with a couple of csl modules.
Those should count toward "friends".
-Tim
On Fri, Sep 21, 2018 at 8:01 PM Laszlo Kishalmi <la...@gmail.com>
wrote:
> Dear all,
>
> I'd like to summarize whet happened on the "API Friendliness" issue:
>
> We collected a number of possible options on our previous discussions at:
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
>
> Commenting these options remained really silent though. This means our
> Friend APIs most likely stay as they are now.
>
> I must acknowledge that adding new friends to an existing API is easier
> than ever having NetBeans under Apache umbrella.
>
> I plan not to give up on making some APIs public though. Regarding the
> low interest of making something big around this area, I think the most
> viable solution is:
>
> Option 4: Make Module Public when There is more than a Certain Number of
> Friend Dependencies.
>
> So sometime in the future I'm going to create a list of how many friends
> a module does have and share the list with you.
>
>
> Thank you all who participated in this effort!
>
> Laszlo Kishalmi
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com