Re: Public vs. Friend API Reloaded (Summary)

[Neil C Smith]

On Sat, 22 Sep 2018 at 01:01, Laszlo Kishalmi  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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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)

[Peter Nabbefeld]

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 
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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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)

[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 
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-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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)

[Peter Nabbefeld]

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 
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 

Re: Public vs. Friend API Reloaded (Summary)

[Jan Lahoda]

On Sun, Sep 23, 2018 at 7:23 PM Peter Nabbefeld 
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 

Re: Public vs. Friend API Reloaded (Summary)

[Peter Nabbefeld]

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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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)

[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 

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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)

[Jan Lahoda]

ange
> >> 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/pro

Re: Public vs. Friend API Reloaded (Summary)

[Peter Nabbefeld]

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.l...@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=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
./

Re: Public vs. Friend API Reloaded (Summary)

[Jan Lahoda]

> >>
> >> Am 23.09.18 um 12:04 schrieb Jan Lahoda:
> >>> On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz <
> christian.l...@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=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
> >>>> 

Re: Public vs. Friend API Reloaded (Summary)

[Peter Nabbefeld]

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.xm

Re: Public vs. Friend API Reloaded (Summary)

[Jan Lahoda]

eans, 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.

Re: Public vs. Friend API Reloaded (Summary)

[Peter Nabbefeld]

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 
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=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
./

Re: Public vs. Friend API Reloaded (Summary)

[Jan Lahoda]

On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz 
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=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/pr

AW: Public vs. Friend API Reloaded (Summary)

[Christian Lenz]

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=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/nbproj

Re: Public vs. Friend API Reloaded (Summary)

[Laszlo Kishalmi]

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 
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. Thi

Re: Public vs. Friend API Reloaded (Summary)

[Tim Boudreau]

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 
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  schrieb am
> > Sa., 22. Sep. 2018, 09:54:
> >
> >> On Sat, Sep 22, 2018 at 2:01 AM, Laszlo Kishalmi <
> >> laszlo.kisha...@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-unsubscr...@netbeans.incubator.apache.org
> >>> For additional commands, e-mail:
> dev-h...@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-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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)

[Sven Reimers]

I completely agree... (with my Groovy support hat on)
-Sven

Svata Dedic  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  schrieb am
> > Sa., 22. Sep. 2018, 09:54:
> >
> >> On Sat, Sep 22, 2018 at 2:01 AM, Laszlo Kishalmi <
> >> laszlo.kisha...@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-unsubscr...@netbeans.incubator.apache.org
> >>> For additional commands, e-mail:
> dev-h...@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-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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)

[Sven Reimers]

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  schrieb am
Sa., 22. Sep. 2018, 09:54:

> On Sat, Sep 22, 2018 at 2:01 AM, Laszlo Kishalmi <
> laszlo.kisha...@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-unsubscr...@netbeans.incubator.apache.org
> > For additional commands, e-mail: dev-h...@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)

[Geertjan Wielenga]

On Sat, Sep 22, 2018 at 2:01 AM, Laszlo Kishalmi 
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-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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)

[Tim Boudreau]

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 
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-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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

Public vs. Friend API Reloaded (Summary)

[Laszlo Kishalmi]

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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Public vs. Friend API Reloaded (Round 2)

[Laszlo Kishalmi]

Dear all,

We had a quite active discussion on API Friendliness about 2 months ago.
I've tried to formalize the options we have and collect opinions.

https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API

It seems this debate is drying out. If anyone has additional think to 
add, share please do it till Monday night PST.


Then I'm going to summarize what has happened regarding this topic.


Thanks,

Laszlo Kishalmi

Re: Public vs. Friend API Reloaded (Round 2)

[Tim Boudreau]

I'll pitch a couple of things in here:

1. Part of the problem with friend apis is your that the term gets
overloaded for two different concerns: A. APIs undergoing stabilization,
where the expectation is that a stable api will emerge, and B. Dependencies
which are never intended to produce an API. Because at the technical level
the module system doesn't need to distinguish those two things, we have a
single term representing both, resulting in confused expectations.

2. That being said, something Jarda and I used to stress in our api design
talks was "you are always writing an api" - if you followed good api design
patterns, opening a friend api should not be sentencing yourself to
code-jail. So I'd suggest splitting out the question of "should existing
apis become public" from "how do we encourage more public apis in the
future".

3. If you don't like the current situation with friend apis, you probably
want to support some proposal other than maintaining the status quo, or you
can expect more of the same.

-Tim

On Thu, Aug 9, 2018 at 2:38 PM Laszlo Kishalmi 
wrote:

> Go on People, share your thoughts!
>
> Thanks for Neil who already did that!
> Thanks for Jarda to adding one more option to select from!
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
>
> On 08/08/2018 01:26 AM, Laszlo Kishalmi wrote:
> >
> > Dear all,
> >
> > I'd like to start the second round of discussion on this topic.
> >
> > Oliver Retting was so kind to summarize the opinions presented on our
> > mailing lists.
> >
> > I myself stared a mini analysis on each option, mentioning my attitude
> > to them as well.
> >
> > Please take your time, extend, modify and share your opinions and
> > attitude!
> >
> > Remember I'm just trying to drive this discussion not dictate it. So
> > any idea, opposition, pro and con are welcome!
> >
> >
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
> >
> > Let's give this round another 2 weeks, what can be extended with
> > another two if we feel the need.
> >
>
> --
http://timboudreau.com

Re: Public vs. Friend API Reloaded (Round 2)

[Laszlo Kishalmi]

Go on People, share your thoughts!

Thanks for Neil who already did that!
Thanks for Jarda to adding one more option to select from!

https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API

On 08/08/2018 01:26 AM, Laszlo Kishalmi wrote:


Dear all,

I'd like to start the second round of discussion on this topic.

Oliver Retting was so kind to summarize the opinions presented on our 
mailing lists.


I myself stared a mini analysis on each option, mentioning my attitude 
to them as well.


Please take your time, extend, modify and share your opinions and 
attitude!


Remember I'm just trying to drive this discussion not dictate it. So 
any idea, opposition, pro and con are welcome!


https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API

Let's give this round another 2 weeks, what can be extended with 
another two if we feel the need.

Public vs. Friend API Reloaded (Round 2)

[Laszlo Kishalmi]

Dear all,

I'd like to start the second round of discussion on this topic.

Oliver Retting was so kind to summarize the opinions presented on our 
mailing lists.


I myself stared a mini analysis on each option, mentioning my attitude 
to them as well.


Please take your time, extend, modify and share your opinions and attitude!

Remember I'm just trying to drive this discussion not dictate it. So any 
idea, opposition, pro and con are welcome!


https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API

Let's give this round another 2 weeks, what can be extended with another 
two if we feel the need.

Re: Public vs. Friend API Reloaded (Round 1)

[Laszlo Kishalmi]

Thanks Oliver!


On 08/07/2018 10:10 AM, Oliver Rettig wrote:

Hi,

I have read the complete mail discussion again and I tried to put all arguments 
into the wiki
page. It is not perfectly finished, mabe I can spend some more time in it at 
the end of the
week.

https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API

Hope this helps.

best regards
Oliver


On 07/25/2018 12:30 AM, Laszlo Kishalmi wrote:

Dear all,

It seems there is an active discussion on how to handle the API
Friend-lyness issues.

We have a few options to choose from and it seems to be we need to
vote sometime on this.

Geertjan somewhere suggested a wiki page to collect the ideas, as
discussing this on mailchain, could be interesting, but not productive
at all.

Here is the page:
https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API

I'd plan a 3 round process:

   1. Gather the possible solutions.

   2. Pro/Con analysis of the solutions (extendig the wiki)

   3. Vote (Might be different than just a +1 vote)

We are in round 1, let's give that two weeks. Please make sure you
idea is present in the list. It it is not there, just add it,

Or reply to me on this e-mail, I'd add your solution as well..

Laszlo Kishalmi

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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 (Round 1)

[Geertjan Wielenga]

Excellent, very clear and detailed.

Gj

On Tue, Aug 7, 2018 at 7:10 PM, Oliver Rettig  wrote:

> Hi,
>
> I have read the complete mail discussion again and I tried to put all
> arguments into the wiki
> page. It is not perfectly finished, mabe I can spend some more time in it
> at the end of the
> week.
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
>
> Hope this helps.
>
> best regards
> Oliver
>
> >
> > On 07/25/2018 12:30 AM, Laszlo Kishalmi wrote:
> > > Dear all,
> > >
> > > It seems there is an active discussion on how to handle the API
> > > Friend-lyness issues.
> > >
> > > We have a few options to choose from and it seems to be we need to
> > > vote sometime on this.
> > >
> > > Geertjan somewhere suggested a wiki page to collect the ideas, as
> > > discussing this on mailchain, could be interesting, but not productive
> > > at all.
> > >
> > > Here is the page:
> > > https://cwiki.apache.org/confluence/display/NETBEANS/
> Public+vs+Friend+API
> > >
> > > I'd plan a 3 round process:
> > >
> > >   1. Gather the possible solutions.
> > >
> > >   2. Pro/Con analysis of the solutions (extendig the wiki)
> > >
> > >   3. Vote (Might be different than just a +1 vote)
> > >
> > > We are in round 1, let's give that two weeks. Please make sure you
> > > idea is present in the list. It it is not there, just add it,
> > >
> > > Or reply to me on this e-mail, I'd add your solution as well..
> > >
> > > Laszlo Kishalmi
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> > For additional commands, e-mail: dev-h...@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 (Round 1)

[Oliver Rettig]

Hi,

I have read the complete mail discussion again and I tried to put all arguments 
into the wiki 
page. It is not perfectly finished, mabe I can spend some more time in it at 
the end of the 
week.

https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API

Hope this helps.

best regards
Oliver

> 
> On 07/25/2018 12:30 AM, Laszlo Kishalmi wrote:
> > Dear all,
> > 
> > It seems there is an active discussion on how to handle the API
> > Friend-lyness issues.
> > 
> > We have a few options to choose from and it seems to be we need to
> > vote sometime on this.
> > 
> > Geertjan somewhere suggested a wiki page to collect the ideas, as
> > discussing this on mailchain, could be interesting, but not productive
> > at all.
> > 
> > Here is the page:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
> > 
> > I'd plan a 3 round process:
> > 
> >   1. Gather the possible solutions.
> > 
> >   2. Pro/Con analysis of the solutions (extendig the wiki)
> > 
> >   3. Vote (Might be different than just a +1 vote)
> > 
> > We are in round 1, let's give that two weeks. Please make sure you
> > idea is present in the list. It it is not there, just add it,
> > 
> > Or reply to me on this e-mail, I'd add your solution as well..
> > 
> > Laszlo Kishalmi
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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 (Round 1)

[Emilian Bold]

I would like that wiki to better explain what is "the situation around Friend 
API-s"?

I vote for "Leave Friend API-s as it is" and will try not to comment anymore 
about this.

I don't believe a process or vote can replace somebody actually doing the work 
while preserving some quality.

--emi

‐‐‐ Original Message ‐‐‐
On 6 August 2018 4:43 AM, Laszlo Kishalmi  wrote:

> Dear all,
>
> The two week period is almost over. If anyone has any new idea to add
> please do it now.
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
>
> On 07/25/2018 12:30 AM, Laszlo Kishalmi wrote:
>
> > Dear all,
> > It seems there is an active discussion on how to handle the API
> > Friend-lyness issues.
> > We have a few options to choose from and it seems to be we need to
> > vote sometime on this.
> > Geertjan somewhere suggested a wiki page to collect the ideas, as
> > discussing this on mailchain, could be interesting, but not productive
> > at all.
> > Here is the page:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
> > I'd plan a 3 round process:
> > 1. Gather the possible solutions.
> > 2. Pro/Con analysis of the solutions (extendig the wiki)
> > 3. Vote (Might be different than just a +1 vote)
> > We are in round 1, let's give that two weeks. Please make sure you
> > idea is present in the list. It it is not there, just add it,
> > Or reply to me on this e-mail, I'd add your solution as well..
> > Laszlo Kishalmi
>
> --
>
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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 (Round 1)

[Laszlo Kishalmi]

Dear all,

The two week period is almost over. If anyone has any new idea to add 
please do it now.


https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API


On 07/25/2018 12:30 AM, Laszlo Kishalmi wrote:

Dear all,

It seems there is an active discussion on how to handle the API 
Friend-lyness issues.


We have a few options to choose from and it seems to be we need to 
vote sometime on this.


Geertjan somewhere suggested a wiki page to collect the ideas, as 
discussing this on mailchain, could be interesting, but not productive 
at all.


Here is the page: 
https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API


I'd plan a 3 round process:

  1. Gather the possible solutions.

  2. Pro/Con analysis of the solutions (extendig the wiki)

  3. Vote (Might be different than just a +1 vote)

We are in round 1, let's give that two weeks. Please make sure you 
idea is present in the list. It it is not there, just add it,


Or reply to me on this e-mail, I'd add your solution as well..

Laszlo Kishalmi




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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 (Round 1)

[Oliver Rettig]

Am Mittwoch, 25. Juli 2018, 12:05:27 CEST schrieb Geertjan Wielenga:
> I'm not sure whether voting is necessarily called for -- if we can resolve
> something via consensus, that would be much better for everyone.
+1
> Having a Wiki outlining the various positions would definitely be useful
> for clarity.
+1
> 
> Gj
> 
> 
> 
> On Wed, Jul 25, 2018 at 11:02 AM, Neil C Smith 
> 
> wrote:
> > On Wed, 25 Jul 2018 at 09:11, Laszlo Kishalmi 
> > 
> > wrote:
> > > Geertjan somewhere suggested a wiki page to collect the ideas, as
> > > discussing this on mailchain, could be interesting, but not productive
> > > at all.
> > 
> > Agreed! :-)
> > 
> > > Here is the page:
> > > https://cwiki.apache.org/confluence/display/NETBEANS/
> > 
> > Public+vs+Friend+API
> > 
> > In terms of old wiki pages, can we also link to
> > http://wiki.netbeans.org/NbmPackageStability ?  It seems to cover a
> > lot of the issues and alternatives that are currently being rehashed,
> > and some wider things around OSGi, Maven, implementation dependencies,
> > etc.  Looks like it was written by Jesse (mainly) and Jaroslav.
> > 
> > I'd encourage everyone who's proposing or voting to at least give it a
> > read first! ;-)
> > 
> > Best wishes,
> > 
> > Neil
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> > For additional commands, e-mail: dev-h...@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?

[Tim Boudreau]

Under Apache though... I would not want to spend time stabilising somebody
> else's friend API unless I really need to use it myself.


You're misunderstanding my proposal. It is not that anybody spends time
stabilizing someone else's API. It is that if a friend  API stays de-facto
stable for some period of time or releases, either the build system or the
module system simply stops enforcing it being friends-only, at which point
it is subject to the same compatibility requirements as declared to be
stable modules.

So it's not "imaginary person does the work", it's "if you don't do the
work you'll have to live with the consequences".

-Tim




>
> --emi
>
> ‐‐‐ Original Message ‐‐‐
> On 24 July 2018 11:54 PM, Geertjan Wielenga
>  wrote:
>
> > FYI, it's never been a question of money. Developers working on NetBeans
> > felt very comfortable keeping APIs under development via the friends API
> > mechanism. Keeping the API in friend mode is much easier for a developer
> to
> > make changes to it. No money at all involved in that thinking.
> >
> > Gj
> >
> > On Tue, Jul 24, 2018 at 10:15 PM, Emilian Bold <
> > emilian.b...@protonmail.ch.invalid> wrote:
> >
> > > This idea might work if developers are employees and they will be paid
> to
> > > stabilise friend APIs. But... this is the reason we got where we are:
> > > Sun/Oracle didn't put enough money on the table for this kind of work.
> > > But under Apache... who's going to do the work? All I understand is
> that
> > > when somebody introduces a new friend API they might break NetBeans
> builds
> > > in about 2 releases. So, will I +1 that friend API? I might be more
> > > inclined not to.
> > > Which means in practice we just stop using friends APIs. But... the
> need
> > > friend APIs cover is still there. What will we use then? It might be
> > > something even worse (like reflection, etc).
> > > --emi
> > > ‐‐‐ Original Message ‐‐‐
> > > On 24 July 2018 10:49 PM, Tim Boudreau niftin...@gmail.com wrote:
> > >
> > > > > I agree with Emilians comments (have a look at the end of this
> mail)
> > > > > and
> > > >
> > > > > I want to add that I
> > > > > like it to start with Friend-only API because then a potential user
> > > > > must
> > > >
> > > > > become active to use
> > > > > it. The user asks me to be added on the friend-list and I get his
> > > > > e-mail
> > > >
> > > > > and I can ask him for
> > > > > feedback in my answer. That is great. The main problem in the
> context
> > > > > of
> > > >
> > > > > netbeans maybe is
> > > > > that it needs additional time that the netbeans repository is
> updated
> > > > > with
> > > >
> > > > > the information of
> > > > > the list-change. Maybe other people are involved etc. But I am not
> > > > > sure if
> > > >
> > > > > this is really a
> > > > > problem.
> > > >
> > > > Historically, the problem has been:
> > > >
> > > > -   Developer develops some modules with a friend API between them
> > > >
> > > > -   Developer goes away / moves on to another project / loses access
> to
> > > > the
> > > > repo
> > > >
> > > > -   The modules stay in the distro, but other than someone updating
> them
> > > > in
> > > > the case of API changes, nobody is touching the code
> > > >
> > > > -   Somebody wants friend access to it
> > > >
> > > > -   There is nobody to ask
> > > >
> > > >
> > > > > I am afraid, that an automatism which makes friend APIs public
> after
> > > > > some
> > > >
> > > > > versions will
> > > > > produce more public APIs but with less quality.
> > > >
> > > > Oh, it's definitely a kind of social engineering. But so is making it
> > > > okay
> > > > to have "unstable" APIs that remain that way for years with no code
> > > > changes.
> > > > We know what kind of results the current situation gets. If we want
> > > > something different, we should do something different.
> > > >
> > > > > I like the situation that all public netbeans APIs are very stable
> and
> > > > > have good quality.
> > > >
> > > > I like it too. I appreciate it every time I maintain a NodeJS
> project,
> > > > where any library update almost invariably means rewriting a ton of
> code.
> > > >
> > > > > And
> > > > > thats more important for me than having more APIs. But of course to
> > > > > have
> > > >
> > > > > more APIs I will
> > > > > like too.
> > > >
> > > > The point is to create a forcing function to stabilize friend APIs.
> As
> > > > in,
> > > > either it needs to become a stable API by release X, or you have to
> use
> > > > implementation dependencies and your module won't be usable across
> > > > NetBeans
> > > > releases. That provides some motivation to stabilize an API.
> > > > The Idee Peter presents:
> > > >
> > > > > https://stackoverflow.com/q/3297/2999563
> > > > > I like too. It can be a nice additional feature to be used in the
> > > > > friend
> > > >
> > > > > APIs. The more and
> > > > > more stable the friend API will be, as less usage of @unstable
> > > > 

Re: Public vs. Friend API Reloaded (Round 1)

[Oliver Rettig]

Dear Laszlo,
great initiative, thanks for starting the Wiki-Page.
Oliver
> Dear all,
> 
> It seems there is an active discussion on how to handle the API
> Friend-lyness issues.
> 
> We have a few options to choose from and it seems to be we need to vote
> sometime on this.
> 
> Geertjan somewhere suggested a wiki page to collect the ideas, as
> discussing this on mailchain, could be interesting, but not productive
> at all.
> 
> Here is the page:
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
> 
> I'd plan a 3 round process:
> 
>1. Gather the possible solutions.
> 
>2. Pro/Con analysis of the solutions (extendig the wiki)
> 
>3. Vote (Might be different than just a +1 vote)
> 
> We are in round 1, let's give that two weeks. Please make sure you idea
> is present in the list. It it is not there, just add it,
> 
> Or reply to me on this e-mail, I'd add your solution as well..
> 
> Laszlo Kishalmi
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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?

[Emilian Bold]

A public API is a commitment from the whole project. So, everybody lives with 
the consequences. Which means I would treat a friend API more or less public 
from the start and weigh my +1 accordingly.

--emi

‐‐‐ Original Message ‐‐‐
On 25 July 2018 7:20 PM, Tim Boudreau  wrote:

> > Under Apache though... I would not want to spend time stabilising somebody 
> > else's friend API unless I really need to use it myself.
>
> You're misunderstanding my proposal. It is not that anybody spends time 
> stabilizing someone else's API. It is that if a friend  API stays de-facto 
> stable for some period of time or releases, either the build system or the 
> module system simply stops enforcing it being friends-only, at which point it 
> is subject to the same compatibility requirements as declared to be stable 
> modules.
>
> So it's not "imaginary person does the work", it's "if you don't do the work 
> you'll have to live with the consequences".
>
> -Tim
>
> > --emi
> >
> > ‐‐‐ Original Message ‐‐‐
> > On 24 July 2018 11:54 PM, Geertjan Wielenga 
> >  wrote:
> >
> > > FYI, it's never been a question of money. Developers working on NetBeans
> > > felt very comfortable keeping APIs under development via the friends API
> > > mechanism. Keeping the API in friend mode is much easier for a developer 
> > > to
> > > make changes to it. No money at all involved in that thinking.
> > >
> > > Gj
> > >
> > > On Tue, Jul 24, 2018 at 10:15 PM, Emilian Bold <
> > > emilian.b...@protonmail.ch.invalid> wrote:
> > >
> > > > This idea might work if developers are employees and they will be paid 
> > > > to
> > > > stabilise friend APIs. But... this is the reason we got where we are:
> > > > Sun/Oracle didn't put enough money on the table for this kind of work.
> > > > But under Apache... who's going to do the work? All I understand is that
> > > > when somebody introduces a new friend API they might break NetBeans 
> > > > builds
> > > > in about 2 releases. So, will I +1 that friend API? I might be more
> > > > inclined not to.
> > > > Which means in practice we just stop using friends APIs. But... the need
> > > > friend APIs cover is still there. What will we use then? It might be
> > > > something even worse (like reflection, etc).
> > > > --emi
> > > > ‐‐‐ Original Message ‐‐‐
> > > > On 24 July 2018 10:49 PM, Tim Boudreau niftin...@gmail.com wrote:
> > > >
> > > > > > I agree with Emilians comments (have a look at the end of this mail)
> > > > > > and
> > > > >
> > > > > > I want to add that I
> > > > > > like it to start with Friend-only API because then a potential user
> > > > > > must
> > > > >
> > > > > > become active to use
> > > > > > it. The user asks me to be added on the friend-list and I get his
> > > > > > e-mail
> > > > >
> > > > > > and I can ask him for
> > > > > > feedback in my answer. That is great. The main problem in the 
> > > > > > context
> > > > > > of
> > > > >
> > > > > > netbeans maybe is
> > > > > > that it needs additional time that the netbeans repository is 
> > > > > > updated
> > > > > > with
> > > > >
> > > > > > the information of
> > > > > > the list-change. Maybe other people are involved etc. But I am not
> > > > > > sure if
> > > > >
> > > > > > this is really a
> > > > > > problem.
> > > > >
> > > > > Historically, the problem has been:
> > > > >
> > > > > -   Developer develops some modules with a friend API between them
> > > > >
> > > > > -   Developer goes away / moves on to another project / loses access 
> > > > > to
> > > > >     the
> > > > >     repo
> > > > >
> > > > > -   The modules stay in the distro, but other than someone updating 
> > > > > them
> > > > >     in
> > > > >     the case of API changes, nobody is touching the code
> > > > >
> > > > > -   Somebody wants friend access to it
> > > > >
> > > > > -   There is nobody to ask
> > > > >
> > > > >
> > > > > > I am afraid, that an automatism which makes friend APIs public after
> > > > > > some
> > > > >
> > > > > > versions will
> > > > > > produce more public APIs but with less quality.
> > > > >
> > > > > Oh, it's definitely a kind of social engineering. But so is making it
> > > > > okay
> > > > > to have "unstable" APIs that remain that way for years with no code
> > > > > changes.
> > > > > We know what kind of results the current situation gets. If we want
> > > > > something different, we should do something different.
> > > > >
> > > > > > I like the situation that all public netbeans APIs are very stable 
> > > > > > and
> > > > > > have good quality.
> > > > >
> > > > > I like it too. I appreciate it every time I maintain a NodeJS project,
> > > > > where any library update almost invariably means rewriting a ton of 
> > > > > code.
> > > > >
> > > > > > And
> > > > > > thats more important for me than having more APIs. But of course to
> > > > > > have
> > > > >
> > > > > > more APIs I will
> > > > > > like too.
> > > > >
> > > > > The point is to create a forcing function to 

Re: Public vs. Friend API Reloaded (Round 1)

[Geertjan Wielenga]

I'm not sure whether voting is necessarily called for -- if we can resolve
something via consensus, that would be much better for everyone.

Having a Wiki outlining the various positions would definitely be useful
for clarity.

Gj



On Wed, Jul 25, 2018 at 11:02 AM, Neil C Smith 
wrote:

> On Wed, 25 Jul 2018 at 09:11, Laszlo Kishalmi 
> wrote:
> > Geertjan somewhere suggested a wiki page to collect the ideas, as
> > discussing this on mailchain, could be interesting, but not productive
> > at all.
>
> Agreed! :-)
>
> > Here is the page:
> > https://cwiki.apache.org/confluence/display/NETBEANS/
> Public+vs+Friend+API
>
> In terms of old wiki pages, can we also link to
> http://wiki.netbeans.org/NbmPackageStability ?  It seems to cover a
> lot of the issues and alternatives that are currently being rehashed,
> and some wider things around OSGi, Maven, implementation dependencies,
> etc.  Looks like it was written by Jesse (mainly) and Jaroslav.
>
> I'd encourage everyone who's proposing or voting to at least give it a
> read first! ;-)
>
> Best wishes,
>
> Neil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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 (Round 1)

[Emilian Bold]

Not sure what there's to vote about.

--emi

‐‐‐ Original Message ‐‐‐
On 25 July 2018 10:30 AM, Laszlo Kishalmi  wrote:

> Dear all,
>
> It seems there is an active discussion on how to handle the API
> Friend-lyness issues.
>
> We have a few options to choose from and it seems to be we need to vote
> sometime on this.
>
> Geertjan somewhere suggested a wiki page to collect the ideas, as
> discussing this on mailchain, could be interesting, but not productive
> at all.
>
> Here is the page:
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
>
> I'd plan a 3 round process:
>
>   1. Gather the possible solutions.
>
>   2. Pro/Con analysis of the solutions (extendig the wiki)
>
>   3. Vote (Might be different than just a +1 vote)
>
> We are in round 1, let's give that two weeks. Please make sure you idea
> is present in the list. It it is not there, just add it,
>
> Or reply to me on this e-mail, I'd add your solution as well..
>
> Laszlo Kishalmi
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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 (Round 1)

[Neil C Smith]

On Wed, 25 Jul 2018 at 09:11, Laszlo Kishalmi  wrote:
> Geertjan somewhere suggested a wiki page to collect the ideas, as
> discussing this on mailchain, could be interesting, but not productive
> at all.

Agreed! :-)

> Here is the page:
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API

In terms of old wiki pages, can we also link to
http://wiki.netbeans.org/NbmPackageStability ?  It seems to cover a
lot of the issues and alternatives that are currently being rehashed,
and some wider things around OSGi, Maven, implementation dependencies,
etc.  Looks like it was written by Jesse (mainly) and Jaroslav.

I'd encourage everyone who's proposing or voting to at least give it a
read first! ;-)

Best wishes,

Neil

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Public vs. Friend API Reloaded (Round 1)

[Laszlo Kishalmi]

Dear all,

It seems there is an active discussion on how to handle the API 
Friend-lyness issues.


We have a few options to choose from and it seems to be we need to vote 
sometime on this.


Geertjan somewhere suggested a wiki page to collect the ideas, as 
discussing this on mailchain, could be interesting, but not productive 
at all.


Here is the page: 
https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API


I'd plan a 3 round process:

  1. Gather the possible solutions.

  2. Pro/Con analysis of the solutions (extendig the wiki)

  3. Vote (Might be different than just a +1 vote)

We are in round 1, let's give that two weeks. Please make sure you idea 
is present in the list. It it is not there, just add it,


Or reply to me on this e-mail, I'd add your solution as well..

Laszlo Kishalmi


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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?

[Geertjan Wielenga]

On Tue, Jul 24, 2018 at 11:02 PM, Emilian Bold <
emilian.b...@protonmail.ch.invalid> wrote:

> In understand wanting to change the API without so many restrictions, but
> when the API hasn't changed for years, it seems like a fun activity
> spending a week making a proper API out of it. My original assumption was
> that the employer never gave developers that week because the time could be
> better used for something else.
>
> Anyhow, just speculating.
>
> Under Apache though... I would not want to spend time stabilising somebody
> else's friend API unless I really need to use it myself.
>


That's perfectly reasonable and exactly the same motivation as for working
on anything else, e.g., bugs, adding features, etc -- i.e., scratch your
itch, that's all.

Gj




>
> --emi
>
> ‐‐‐ Original Message ‐‐‐
> On 24 July 2018 11:54 PM, Geertjan Wielenga 
> 
> wrote:
>
> > FYI, it's never been a question of money. Developers working on NetBeans
> > felt very comfortable keeping APIs under development via the friends API
> > mechanism. Keeping the API in friend mode is much easier for a developer
> to
> > make changes to it. No money at all involved in that thinking.
> >
> > Gj
> >
> > On Tue, Jul 24, 2018 at 10:15 PM, Emilian Bold <
> > emilian.b...@protonmail.ch.invalid> wrote:
> >
> > > This idea might work if developers are employees and they will be paid
> to
> > > stabilise friend APIs. But... this is the reason we got where we are:
> > > Sun/Oracle didn't put enough money on the table for this kind of work.
> > > But under Apache... who's going to do the work? All I understand is
> that
> > > when somebody introduces a new friend API they might break NetBeans
> builds
> > > in about 2 releases. So, will I +1 that friend API? I might be more
> > > inclined not to.
> > > Which means in practice we just stop using friends APIs. But... the
> need
> > > friend APIs cover is still there. What will we use then? It might be
> > > something even worse (like reflection, etc).
> > > --emi
> > > ‐‐‐ Original Message ‐‐‐
> > > On 24 July 2018 10:49 PM, Tim Boudreau niftin...@gmail.com wrote:
> > >
> > > > > I agree with Emilians comments (have a look at the end of this
> mail)
> > > > > and
> > > >
> > > > > I want to add that I
> > > > > like it to start with Friend-only API because then a potential user
> > > > > must
> > > >
> > > > > become active to use
> > > > > it. The user asks me to be added on the friend-list and I get his
> > > > > e-mail
> > > >
> > > > > and I can ask him for
> > > > > feedback in my answer. That is great. The main problem in the
> context
> > > > > of
> > > >
> > > > > netbeans maybe is
> > > > > that it needs additional time that the netbeans repository is
> updated
> > > > > with
> > > >
> > > > > the information of
> > > > > the list-change. Maybe other people are involved etc. But I am not
> > > > > sure if
> > > >
> > > > > this is really a
> > > > > problem.
> > > >
> > > > Historically, the problem has been:
> > > >
> > > > -   Developer develops some modules with a friend API between them
> > > >
> > > > -   Developer goes away / moves on to another project / loses access
> to
> > > > the
> > > > repo
> > > >
> > > > -   The modules stay in the distro, but other than someone updating
> them
> > > > in
> > > > the case of API changes, nobody is touching the code
> > > >
> > > > -   Somebody wants friend access to it
> > > >
> > > > -   There is nobody to ask
> > > >
> > > >
> > > > > I am afraid, that an automatism which makes friend APIs public
> after
> > > > > some
> > > >
> > > > > versions will
> > > > > produce more public APIs but with less quality.
> > > >
> > > > Oh, it's definitely a kind of social engineering. But so is making it
> > > > okay
> > > > to have "unstable" APIs that remain that way for years with no code
> > > > changes.
> > > > We know what kind of results the current situation gets. If we want
> > > > something different, we should do something different.
> > > >
> > > > > I like the situation that all public netbeans APIs are very stable
> and
> > > > > have good quality.
> > > >
> > > > I like it too. I appreciate it every time I maintain a NodeJS
> project,
> > > > where any library update almost invariably means rewriting a ton of
> code.
> > > >
> > > > > And
> > > > > thats more important for me than having more APIs. But of course to
> > > > > have
> > > >
> > > > > more APIs I will
> > > > > like too.
> > > >
> > > > The point is to create a forcing function to stabilize friend APIs.
> As
> > > > in,
> > > > either it needs to become a stable API by release X, or you have to
> use
> > > > implementation dependencies and your module won't be usable across
> > > > NetBeans
> > > > releases. That provides some motivation to stabilize an API.
> > > > The Idee Peter presents:
> > > >
> > > > > https://stackoverflow.com/q/3297/2999563
> > > > > I like too. It can be a nice additional feature to be used in the
> > > > > 

Re: Public vs. Friend API?

[Neil C Smith]

On Tue, 24 Jul 2018, 21:15 Emilian Bold, 
wrote:

> Which means in practice we just stop using friends APIs. But... the need
> friend APIs cover is still there. What will we use then?
>

Semantic versioning?! I still fail to see what the friend API gives us in
this case (as opposed to the meta-module case) that a better approach to
versioning wouldn't work better for?

I almost wholeheartedly agree with Tim except for thinking the friend API
mechanism has any role or benefit in  achieving this. And as much as npm
naturally precedes hell in my mind, I've had far less issues upgrading node
projects than I've had upgrading PraxisLIVE from one IDE release to the
next!

Best wishes,

Neil

>

Re: Public vs. Friend API?

[Emilian Bold]

In understand wanting to change the API without so many restrictions, but when 
the API hasn't changed for years, it seems like a fun activity spending a week 
making a proper API out of it. My original assumption was that the employer 
never gave developers that week because the time could be better used for 
something else.

Anyhow, just speculating.

Under Apache though... I would not want to spend time stabilising somebody 
else's friend API unless I really need to use it myself.

--emi

‐‐‐ Original Message ‐‐‐
On 24 July 2018 11:54 PM, Geertjan Wielenga 
 wrote:

> FYI, it's never been a question of money. Developers working on NetBeans
> felt very comfortable keeping APIs under development via the friends API
> mechanism. Keeping the API in friend mode is much easier for a developer to
> make changes to it. No money at all involved in that thinking.
>
> Gj
>
> On Tue, Jul 24, 2018 at 10:15 PM, Emilian Bold <
> emilian.b...@protonmail.ch.invalid> wrote:
>
> > This idea might work if developers are employees and they will be paid to
> > stabilise friend APIs. But... this is the reason we got where we are:
> > Sun/Oracle didn't put enough money on the table for this kind of work.
> > But under Apache... who's going to do the work? All I understand is that
> > when somebody introduces a new friend API they might break NetBeans builds
> > in about 2 releases. So, will I +1 that friend API? I might be more
> > inclined not to.
> > Which means in practice we just stop using friends APIs. But... the need
> > friend APIs cover is still there. What will we use then? It might be
> > something even worse (like reflection, etc).
> > --emi
> > ‐‐‐ Original Message ‐‐‐
> > On 24 July 2018 10:49 PM, Tim Boudreau niftin...@gmail.com wrote:
> >
> > > > I agree with Emilians comments (have a look at the end of this mail)
> > > > and
> > >
> > > > I want to add that I
> > > > like it to start with Friend-only API because then a potential user
> > > > must
> > >
> > > > become active to use
> > > > it. The user asks me to be added on the friend-list and I get his
> > > > e-mail
> > >
> > > > and I can ask him for
> > > > feedback in my answer. That is great. The main problem in the context
> > > > of
> > >
> > > > netbeans maybe is
> > > > that it needs additional time that the netbeans repository is updated
> > > > with
> > >
> > > > the information of
> > > > the list-change. Maybe other people are involved etc. But I am not
> > > > sure if
> > >
> > > > this is really a
> > > > problem.
> > >
> > > Historically, the problem has been:
> > >
> > > -   Developer develops some modules with a friend API between them
> > >
> > > -   Developer goes away / moves on to another project / loses access to
> > > the
> > > repo
> > >
> > > -   The modules stay in the distro, but other than someone updating them
> > > in
> > > the case of API changes, nobody is touching the code
> > >
> > > -   Somebody wants friend access to it
> > >
> > > -   There is nobody to ask
> > >
> > >
> > > > I am afraid, that an automatism which makes friend APIs public after
> > > > some
> > >
> > > > versions will
> > > > produce more public APIs but with less quality.
> > >
> > > Oh, it's definitely a kind of social engineering. But so is making it
> > > okay
> > > to have "unstable" APIs that remain that way for years with no code
> > > changes.
> > > We know what kind of results the current situation gets. If we want
> > > something different, we should do something different.
> > >
> > > > I like the situation that all public netbeans APIs are very stable and
> > > > have good quality.
> > >
> > > I like it too. I appreciate it every time I maintain a NodeJS project,
> > > where any library update almost invariably means rewriting a ton of code.
> > >
> > > > And
> > > > thats more important for me than having more APIs. But of course to
> > > > have
> > >
> > > > more APIs I will
> > > > like too.
> > >
> > > The point is to create a forcing function to stabilize friend APIs. As
> > > in,
> > > either it needs to become a stable API by release X, or you have to use
> > > implementation dependencies and your module won't be usable across
> > > NetBeans
> > > releases. That provides some motivation to stabilize an API.
> > > The Idee Peter presents:
> > >
> > > > https://stackoverflow.com/q/3297/2999563
> > > > I like too. It can be a nice additional feature to be used in the
> > > > friend
> > >
> > > > APIs. The more and
> > > > more stable the friend API will be, as less usage of @unstable
> > > > annotation
> > >
> > > > is used and if the
> > > > last position of the @unstable annotation is deleted than it is time to
> > > > make the API public.
> > >
> > > The endgame of that approach is the same mess NodeJS has - there won't be
> > > stable APIs. If you can just mark something unstable permanently (which
> > > is
> > > the situation we already have), there's no reason to choose to commit to
> > > backward 

Re: Public vs. Friend API?

[Geertjan Wielenga]

FYI, it's never been a question of money. Developers working on NetBeans
felt very comfortable keeping APIs under development via the friends API
mechanism. Keeping the API in friend mode is much easier for a developer to
make changes to it. No money at all involved in that thinking.

Gj

On Tue, Jul 24, 2018 at 10:15 PM, Emilian Bold <
emilian.b...@protonmail.ch.invalid> wrote:

> This idea might work if developers are employees and they will be paid to
> stabilise friend APIs. But... this is the reason we got where we are:
> Sun/Oracle didn't put enough money on the table for this kind of work.
>
> But under Apache... who's going to do the work? All I understand is that
> when somebody introduces a new friend API they might break NetBeans builds
> in about 2 releases. So, will I +1 that friend API? I might be more
> inclined not to.
>
> Which means in practice we just stop using friends APIs. But... the need
> friend APIs cover is still there. What will we use then? It might be
> something even worse (like reflection, etc).
>
> --emi
>
> ‐‐‐ Original Message ‐‐‐
> On 24 July 2018 10:49 PM, Tim Boudreau  wrote:
>
> > > I agree with Emilians comments (have a look at the end of this mail)
> and
> > > I want to add that I
> > > like it to start with Friend-only API because then a potential user
> must
> > > become active to use
> > > it. The user asks me to be added on the friend-list and I get his
> e-mail
> > > and I can ask him for
> > > feedback in my answer. That is great. The main problem in the context
> of
> > > netbeans maybe is
> > > that it needs additional time that the netbeans repository is updated
> with
> > > the information of
> > > the list-change. Maybe other people are involved etc. But I am not
> sure if
> > > this is really a
> > > problem.
> >
> > Historically, the problem has been:
> >
> > -   Developer develops some modules with a friend API between them
> > -   Developer goes away / moves on to another project / loses access to
> the
> > repo
> >
> > -   The modules stay in the distro, but other than someone updating them
> in
> > the case of API changes, nobody is touching the code
> >
> > -   Somebody wants friend access to it
> > -   There is nobody to ask
> >
> >
> > > I am afraid, that an automatism which makes friend APIs public after
> some
> > > versions will
> > > produce more public APIs but with less quality.
> >
> > Oh, it's definitely a kind of social engineering. But so is making it
> okay
> > to have "unstable" APIs that remain that way for years with no code
> > changes.
> >
> > We know what kind of results the current situation gets. If we want
> > something different, we should do something different.
> >
> > > I like the situation that all public netbeans APIs are very stable and
> > > have good quality.
> >
> > I like it too. I appreciate it every time I maintain a NodeJS project,
> > where any library update almost invariably means rewriting a ton of code.
> >
> > > And
> > > thats more important for me than having more APIs. But of course to
> have
> > > more APIs I will
> > > like too.
> >
> > The point is to create a forcing function to stabilize friend APIs. As
> in,
> > either it needs to become a stable API by release X, or you have to use
> > implementation dependencies and your module won't be usable across
> NetBeans
> > releases. That provides some motivation to stabilize an API.
> >
> > The Idee Peter presents:
> >
> > > https://stackoverflow.com/q/3297/2999563
> > > I like too. It can be a nice additional feature to be used in the
> friend
> > > APIs. The more and
> > > more stable the friend API will be, as less usage of @unstable
> annotation
> > > is used and if the
> > > last position of the @unstable annotation is deleted than it is time to
> > > make the API public.
> >
> > The endgame of that approach is the same mess NodeJS has - there won't be
> > stable APIs. If you can just mark something unstable permanently (which
> is
> > the situation we already have), there's no reason to choose to commit to
> > backward compatibility. The only thing that changes is it becomes
> > module-developer-beware.
> >
> > Whereas actually making friend APIs into stable APIs if some set of
> > conditions is met (say, has stayed compatible for two releases) like it
> or
> > not actually pushes the developer to stabilize the API.
> >
> > One gets you friend modules that are just called "unstable" which you can
> > use, and when they break it sucks to be you. The other approach actually
> > creates a process that forces APIs to be stabilized.
> >
> > Which is better for everyone in the long term?
> >
> > -Tim
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> 

Re: Public vs. Friend API?

[Emilian Bold]

This idea might work if developers are employees and they will be paid to 
stabilise friend APIs. But... this is the reason we got where we are: 
Sun/Oracle didn't put enough money on the table for this kind of work.

But under Apache... who's going to do the work? All I understand is that when 
somebody introduces a new friend API they might break NetBeans builds in about 
2 releases. So, will I +1 that friend API? I might be more inclined not to.

Which means in practice we just stop using friends APIs. But... the need friend 
APIs cover is still there. What will we use then? It might be something even 
worse (like reflection, etc).

--emi

‐‐‐ Original Message ‐‐‐
On 24 July 2018 10:49 PM, Tim Boudreau  wrote:

> > I agree with Emilians comments (have a look at the end of this mail) and
> > I want to add that I
> > like it to start with Friend-only API because then a potential user must
> > become active to use
> > it. The user asks me to be added on the friend-list and I get his e-mail
> > and I can ask him for
> > feedback in my answer. That is great. The main problem in the context of
> > netbeans maybe is
> > that it needs additional time that the netbeans repository is updated with
> > the information of
> > the list-change. Maybe other people are involved etc. But I am not sure if
> > this is really a
> > problem.
>
> Historically, the problem has been:
>
> -   Developer develops some modules with a friend API between them
> -   Developer goes away / moves on to another project / loses access to the
> repo
>
> -   The modules stay in the distro, but other than someone updating them in
> the case of API changes, nobody is touching the code
>
> -   Somebody wants friend access to it
> -   There is nobody to ask
>
>
> > I am afraid, that an automatism which makes friend APIs public after some
> > versions will
> > produce more public APIs but with less quality.
>
> Oh, it's definitely a kind of social engineering. But so is making it okay
> to have "unstable" APIs that remain that way for years with no code
> changes.
>
> We know what kind of results the current situation gets. If we want
> something different, we should do something different.
>
> > I like the situation that all public netbeans APIs are very stable and
> > have good quality.
>
> I like it too. I appreciate it every time I maintain a NodeJS project,
> where any library update almost invariably means rewriting a ton of code.
>
> > And
> > thats more important for me than having more APIs. But of course to have
> > more APIs I will
> > like too.
>
> The point is to create a forcing function to stabilize friend APIs. As in,
> either it needs to become a stable API by release X, or you have to use
> implementation dependencies and your module won't be usable across NetBeans
> releases. That provides some motivation to stabilize an API.
>
> The Idee Peter presents:
>
> > https://stackoverflow.com/q/3297/2999563
> > I like too. It can be a nice additional feature to be used in the friend
> > APIs. The more and
> > more stable the friend API will be, as less usage of @unstable annotation
> > is used and if the
> > last position of the @unstable annotation is deleted than it is time to
> > make the API public.
>
> The endgame of that approach is the same mess NodeJS has - there won't be
> stable APIs. If you can just mark something unstable permanently (which is
> the situation we already have), there's no reason to choose to commit to
> backward compatibility. The only thing that changes is it becomes
> module-developer-beware.
>
> Whereas actually making friend APIs into stable APIs if some set of
> conditions is met (say, has stayed compatible for two releases) like it or
> not actually pushes the developer to stabilize the API.
>
> One gets you friend modules that are just called "unstable" which you can
> use, and when they break it sucks to be you. The other approach actually
> creates a process that forces APIs to be stabilized.
>
> Which is better for everyone in the long term?
>
> -Tim



-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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?

[Tim Boudreau]

>
> I agree with Emilians comments (have a look at the end of this mail)  and
> I want to add that I
> like it to start with Friend-only API because then a potential user must
> become active to use
> it. The user asks me to be added on the friend-list and I get his e-mail
> and I can ask him for
> feedback in my answer. That is great. The main problem in the context of
> netbeans  maybe is
> that it needs additional time that the netbeans repository is updated with
> the information of
> the list-change. Maybe other people are involved etc. But I am not sure if
> this is really a
> problem.
>

Historically, the problem has been:
 - Developer develops some modules with a friend API between them
 - Developer goes away / moves on to another project / loses access to the
repo
 - The modules stay in the distro, but other than someone updating them in
the case of API changes, nobody is touching the code
 - Somebody wants friend access to it
 - There is nobody to ask


> I am afraid, that an automatism which makes friend APIs public after some
> versions will
> produce more public APIs but with less quality.
>

Oh, it's definitely a kind of social engineering.  But so is making it okay
to have "unstable" APIs that remain that way for *years* with no code
changes.

We know what kind of results the current situation gets.  If we want
something different, we should do something different.


> I like the situation that all public netbeans APIs are very stable and
> have good quality.


I like it too.  I appreciate it every time I maintain a NodeJS project,
where any library update almost invariably means rewriting a ton of code.


> And
> thats more important for me than having more APIs. But of course to have
> more APIs I will
> like too.
>

The point is to create a forcing function to stabilize friend APIs.  As in,
either it needs to become a stable API by release X, or you have to use
implementation dependencies and your module won't be usable across NetBeans
releases.  That provides some motivation to stabilize an API.

The Idee Peter presents:
>
> https://stackoverflow.com/q/3297/2999563
>
> I like too. It can be a nice additional feature to be used in the friend
> APIs. The more and
> more stable the friend API will be, as less usage of @unstable annotation
> is used and if the
> last position of the @unstable annotation is deleted than it is time to
> make the API public.
>

The endgame of that approach is the same mess NodeJS has - there won't be
stable APIs.  If you can just mark something unstable permanently (which is
the situation we already have), there's no reason to choose to commit to
backward compatibility.  The only thing that changes is it becomes
module-developer-beware.

Whereas actually making friend APIs into stable APIs if some set of
conditions is met (say, has stayed compatible for two releases) like it or
not actually pushes the developer to stabilize the API.

One gets you friend modules that are just called "unstable" which you can
use, and when they break it sucks to be you.  The other approach actually
creates a process that *forces* APIs to be stabilized.

Which is better for everyone in the long term?

-Tim

Re: Public vs. Friend API?

[Oliver Rettig]

Hi,

I agree with Emilians comments (have a look at the end of this mail)  and I 
want to add that I 
like it to start with Friend-only API because then a potential user must  
become active to use 
it. The user asks me to be added on the friend-list and I get his e-mail and I 
can ask him for 
feedback in my answer. That is great. The main problem in the context of 
netbeans  maybe is 
that it needs additional time that the netbeans repository is updated with the 
information of 
the list-change. Maybe other people are involved etc. But I am not sure if this 
is really a 
problem.

I am afraid, that an automatism which makes friend APIs public after some 
versions will 
produce more public APIs but with less quality. 

I like the situation that all public netbeans APIs are very stable and have 
good quality. And 
thats more important for me than having more APIs. But of course to have more 
APIs I will 
like too.

The Idee Peter presents:

https://stackoverflow.com/q/3297/2999563

I like too. It can be a nice additional feature to be used in the friend APIs. 
The more and 
more stable the friend API will be, as less usage of @unstable annotation is 
used and if the 
last position of the @unstable annotation is deleted than it is time to make 
the API public.

best regards
Oliver

> I think you are annoyed by friend APIs just because nobody cared through
> time about those APIs to bring them to a public API. But that's just a sign
> of no money / human resources poured into it, not a lack of automation or
> other processes.
> 
> If you somehow force people to reconsider friend APIs as they become public
> in 2 releases then they will just stop using friend APIs and find other
> creative ways via reflection, the global lookup, etc. So... you only
> obfuscate the matter.
> 
> Note that the Friend API is not only for NetBeans! You could also have your
> own bunch of modules and defined friends among some of them, etc. I know
> that some NetBeans friend APIs are quite juicy so I understand the
> frustration but it's a frustration with the NetBeans codebase, not the
> concept itself.
> 
> --emi
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On 13 July 2018 2:11 AM, Peter Nabbefeld  wrote:
> > Hello all,
> > 
> > I personally don't like "Friend" APIs, as really I like the idea of an
> > 
> > open, extensible IDE.
> > 
> > From my point of view, Friend APIs make it difficult or impossible to
> > 
> > extend NetBeans for personal use:
> > 
> > -   You have to ask for being added to the friends list. This is
> > 
> > especially a problem, if You want to implement some private-use
> > feature,
> > 
> > e.g. for Your employer.
> > 
> > -   Alternatively You could depend on the implementation version; but I
> > 
> > don't see how to do that, if You're using Maven.
> > 
> > -   Third possibility is just patching the modules to remove the friends
> > 
> > and make the API public - very ugly, and You have to do it after every
> > 
> > update.

Re: Public vs. Friend API?

[Peter Steele]

Could Netbeans implement something similar in his stack overflow?

https://stackoverflow.com/q/3297/2999563

Let it be flagged as unstable or experimental in the javadoc but let the
user decide (how ever stupid it maybe)

On Mon, 23 Jul 2018 10:12 Neil C Smith,  wrote:

> On Mon, 23 Jul 2018, 00:12 Emilian Bold,  .invalid>
> wrote:
>
> > How do you get more input about the API if the consumer can unilaterally
> > ask for access?
> >
>
> Because people have a tendency to input when things are broken or don't
> work as expected / required! ;-)
>
> Best wishes,
>
> Neil
>
> >
>

Re: Public vs. Friend API?

[Neil C Smith]

On Mon, 23 Jul 2018, 00:12 Emilian Bold, 
wrote:

> How do you get more input about the API if the consumer can unilaterally
> ask for access?
>

Because people have a tendency to input when things are broken or don't
work as expected / required! ;-)

Best wishes,

Neil

>

Re: Public vs. Friend API?

[Emilian Bold]

How do you get more input about the API if the consumer can unilaterally ask 
for access?

--emi

‐‐‐ Original Message ‐‐‐

On 21 July 2018 12:43 PM, Neil C Smith  wrote:

> On Sat, 21 Jul 2018, 08:59 Geertjan Wielenga,
> 
> geertjan.wiele...@googlemail.com.invalid wrote:
> 
> > +1
> > 
> > On Sat, Jul 21, 2018 at 9:01 AM, Emilian Bold <
> > 
> > emilian.b...@protonmail.ch.invalid> wrote:
> > 
> > > I think you are annoyed by friend APIs just because nobody cared through
> > > 
> > > time about those APIs to bring them to a public API.
> 
> ...
> 
> > > Note that the Friend API is not only for NetBeans! ... I understand the
> > > 
> > > frustration but it's a frustration with the NetBeans codebase, not the
> > > 
> > > concept itself.
> 
> Well, to balance things out, -1. :-)
> 
> I personally am frustrated precisely with the concept itself, at least for
> 
> non-stable APIs. IMO it's the wrong way around. It should be for the
> 
> consumer of an API to request unstable access, not the provider to grant
> 
> it. Which incidentally is probably a good way of getting more input into
> 
> the evolution of the API?
> 
> A non-stable API in NetBeans is also stable for the release it's in AFAIK.
> 
> Best wishes,
> 
> Neil
> 
> >



-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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?

[Neil C Smith]

On Sat, 21 Jul 2018, 08:59 Geertjan Wielenga,
 wrote:

> +1
>
> On Sat, Jul 21, 2018 at 9:01 AM, Emilian Bold <
> emilian.b...@protonmail.ch.invalid> wrote:
>
> > I think you are annoyed by friend APIs just because nobody cared through
> > time about those APIs to bring them to a public API.
>
...

> > Note that the Friend API is not only for NetBeans! ... I understand the
> > frustration but it's a frustration with the NetBeans codebase, not the
> > concept itself.
>

Well, to balance things out, -1. :-)

I personally am frustrated precisely with the concept itself, at least for
non-stable APIs. IMO it's the wrong way around. It should be for the
consumer of an API to request unstable access, not the provider to grant
it. Which incidentally is probably a good way of getting more input into
the evolution of the API?

A non-stable API in NetBeans is also stable for the release it's in AFAIK.

Best wishes,

Neil

>

Re: Public vs. Friend API?

[Geertjan Wielenga]

+1

Gj

On Sat, Jul 21, 2018 at 9:01 AM, Emilian Bold <
emilian.b...@protonmail.ch.invalid> wrote:

> I think you are annoyed by friend APIs just because nobody cared through
> time about those APIs to bring them to a public API. But that's just a sign
> of no money / human resources poured into it, not a lack of automation or
> other processes.
>
> If you somehow force people to reconsider friend APIs as they become
> public in 2 releases then they will just stop using friend APIs and find
> other creative ways via reflection, the global lookup, etc. So... you only
> obfuscate the matter.
>
> Note that the Friend API is not only for NetBeans! You could also have
> your own bunch of modules and defined friends among some of them, etc. I
> know that some NetBeans friend APIs are quite juicy so I understand the
> frustration but it's a frustration with the NetBeans codebase, not the
> concept itself.
>
> --emi
>
> ‐‐‐ Original Message ‐‐‐
>
> On 13 July 2018 2:11 AM, Peter Nabbefeld  wrote:
>
> > Hello all,
> >
> > I personally don't like "Friend" APIs, as really I like the idea of an
> >
> > open, extensible IDE.
> >
> > From my point of view, Friend APIs make it difficult or impossible to
> >
> > extend NetBeans for personal use:
> >
> > -   You have to ask for being added to the friends list. This is
> >
> > especially a problem, if You want to implement some private-use
> feature,
> >
> > e.g. for Your employer.
> >
> > -   Alternatively You could depend on the implementation version; but I
> >
> > don't see how to do that, if You're using Maven.
> >
> > -   Third possibility is just patching the modules to remove the friends
> >
> > and make the API public - very ugly, and You have to do it after
> every
> >
> > update.
> >
> > OTOH, having a friends-only API leads to fewer dependencies on the
> API,
> >
> > thus less impact from changes to the API, which makes work easier for
> >
> > the developers, of course.
> >
> > However, if an API isn't stable, yet, it could also just be flagged
> as
> >
> > "Under Development", thus telling users of those, that it is subject
> to
> >
> > change. Also, as it is possible to use default methods in interfaces
> >
> > from Java 8, it should be less of a problem to extend an existing
> API.
> >
> > But You can use the API on Your own risk without any conflicts.
> >
> > An exception of course is having APIs only for modularity, if classes
> >
> > are spread over different modules and need an API to interact with
> each
> >
> > other. In this case the API's purpose is not to integrate extensions,
> >
> > but to split responsibilities - in this case I fully agree these are
> not
> >
> > for public use.
> >
> > I'd be interested in comments on this - so, what do You think?
> >
> > Kind regards
> >
> > Peter
> >
> >
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> >
> > For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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?

[Emilian Bold]

I think you are annoyed by friend APIs just because nobody cared through time 
about those APIs to bring them to a public API. But that's just a sign of no 
money / human resources poured into it, not a lack of automation or other 
processes.

If you somehow force people to reconsider friend APIs as they become public in 
2 releases then they will just stop using friend APIs and find other creative 
ways via reflection, the global lookup, etc. So... you only obfuscate the 
matter.

Note that the Friend API is not only for NetBeans! You could also have your own 
bunch of modules and defined friends among some of them, etc. I know that some 
NetBeans friend APIs are quite juicy so I understand the frustration but it's a 
frustration with the NetBeans codebase, not the concept itself.

--emi

‐‐‐ Original Message ‐‐‐

On 13 July 2018 2:11 AM, Peter Nabbefeld  wrote:

> Hello all,
> 
> I personally don't like "Friend" APIs, as really I like the idea of an
> 
> open, extensible IDE.
> 
> From my point of view, Friend APIs make it difficult or impossible to
> 
> extend NetBeans for personal use:
> 
> -   You have to ask for being added to the friends list. This is
> 
> especially a problem, if You want to implement some private-use feature,
> 
> e.g. for Your employer.
> 
> -   Alternatively You could depend on the implementation version; but I
> 
> don't see how to do that, if You're using Maven.
> 
> -   Third possibility is just patching the modules to remove the friends
> 
> and make the API public - very ugly, and You have to do it after every
> 
> update.
> 
> OTOH, having a friends-only API leads to fewer dependencies on the API,
> 
> thus less impact from changes to the API, which makes work easier for
> 
> the developers, of course.
> 
> However, if an API isn't stable, yet, it could also just be flagged as
> 
> "Under Development", thus telling users of those, that it is subject to
> 
> change. Also, as it is possible to use default methods in interfaces
> 
> from Java 8, it should be less of a problem to extend an existing API.
> 
> But You can use the API on Your own risk without any conflicts.
> 
> An exception of course is having APIs only for modularity, if classes
> 
> are spread over different modules and need an API to interact with each
> 
> other. In this case the API's purpose is not to integrate extensions,
> 
> but to split responsibilities - in this case I fully agree these are not
> 
> for public use.
> 
> I'd be interested in comments on this - so, what do You think?
> 
> Kind regards
> 
> Peter
> 
> 
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> 
> For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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?

[Tim Boudreau]

>
> While I appriciate the idea of automatically propagating API state from
> instable/friend to stable after some time, there may also be less APIs
> as a result.


We have fewer APIs already - lots of friend APIs, almost no new public
APIs.  It has been that way for years.  Continuing to do what we've been
doing will the same result.  If you want more, something must change.


> So probably there should be some group of people, e.g. QA
> team, deciding on where APIs should be defined. Then an API should be
> defined and reviewed, say version 0.1 (to express it's still early alpha
> stage).
>
> This API should then be implemented and further discussed (You'll
> probably see during implementation what can be handled better some other
> way, or simply where the specification is incomplete, erroneous or just
> unspecified).
>
> Another issue is still module splitting - bigger feature implementations
> are often splitted into several modules, which need the ability to
> privately access each other. This also results in some mismatch:
> Sometimes it would be nice to be able to expose some APIs as
> friend-only, while others are interesting for public usage.


If it is interesting to another module, it is interesting for public
usage.  Whether the author wants responsibility for making it stable is a
separate question :-)

But, is the splitting for aesthetic or more meaningful reasons?


> Therefore I'd prefer to:
> - set up a community page for API request. This page may just explain,
> what to do, e.g. create a Jira issue, which parameters tu use (should be
> task or wish or ..., keywords, etc.);
> - set up a responsible QA team;
> - discuss the API on the dev list with interested members.
>

Review is necessary, for sure.

If you want to force that to actually happen, a timeout is a good way.

-Tim

Re: Public vs. Friend API?

[Peter Nabbefeld]

Am 14.07.2018 um 23:14 schrieb Tim Boudreau:

On Sat, Jul 14, 2018 at 6:23 AM Neil C Smith  wrote:


On Sat, 14 Jul 2018 at 05:41, Tim Boudreau  wrote:

I was there when friend APIs were being invented.  The *entire* purpose

was

for a developer to evolve an API,

Well, fair enough, can't argue with that (although I'd argue there are
uses now that aren't for that purpose).  Still seems the wrong way
around to me in comparison to other things I've worked with.


IMO, there *is no such thing as a "true friend" API.*  If you don't want

to

publish an API, put all of your code in one module - the compatibility
contract is between that module and itself.  If module X depends on

module

Y, and nothing else may depend on Y, and X cannot function without Y,

then

you have *a single logical module.*  You might think it looks nicer

carved

up into two pieces, but at that point you're doing code feng shui, not
engineering.

There are other reasons for using more than one module where you
*never* intend to create a public API, but need other aspects of the
module system - optionally loaded parts, OS-specific parts, etc.  So I
*am* thinking of a small number of things that are logically a unit.


True that things like OS-specific pieces are a special case.  Optional
seems iffy (unless it's huge, just bundle it but don't load it if you don't
need it).

But I think there's also a bit of social nudging any infrastructure around
this inevitably does - and a solution where creating a public, maintained
API with a commitment to backward compatibility is the path of least
resistance is going to have far more benefits for the project as a whole
than one where creating permanent friend APIs is the path of least
resistance, and that's what the existing way of doing things has gotten us.



If you have "non-stable dependencies", eventually that is all that will
exist.  Nobody would prefer to keep compatibility if they don't have to.

Well, that's a pessimistic viewpoint! ;-)


19 years working on or involved in a project will do that :-)

But seriously, if you have a shifting team of developers over a period of
years, the best guarantee that the things you want to happen on an ongoing
basis are remembered is if there is automation and infrastructure that
makes them a natural part of doing work.  Otherwise you're relying on
institutional knowledge and someone having the time and concern to do it.
I've seen "please make my module a friend of X" bugs languish for 6-9
months simply because it wasn't someone's priority, and they were working
for someone who didn't see it as a priority either.  If it's "hey we better
stabilize this or we've got to live with it as-is", that makes it a
priority, like it or not.



   But I agree with you that
time-limiting instability is probably a good idea.  And if optionally
installed modules can only be installed against a single release
(major/minor not point) of the IDE (and perhaps show a big warning
dialog to that fact) I think you'd see things pushed to become stable.


You can.  If you're writing an IDE module, your users can't.  They just
upgrade the IDE and find something doesn't work anymore, say "this sucks"
and go download Eclipse.

I'd argue that the friend system has made that problem worse not
better.  Assuming in-development API's don't change via automatic
updates as opposed to manual upgrade, then I don't see the issue here.
With the friend API you either don't have the module in the first
place, or a module that's had to hack its way into working in such a
way that it's more prone to breakage?!


Agree that it doesn't help much - heck, just recently I was playing with
Rust and found someone's Rust plugin on Github, which uses a ton of friend
and implementation dependencies that are broken, and rather than dig into
it I gave up.

A process that time-limits "unstable" APIs would fix that.

-Tim

While I appriciate the idea of automatically propagating API state from 
instable/friend to stable after some time, there may also be less APIs 
as a result. So probably there should be some group of people, e.g. QA 
team, deciding on where APIs should be defined. Then an API should be 
defined and reviewed, say version 0.1 (to express it's still early alpha 
stage).


This API should then be implemented and further discussed (You'll 
probably see during implementation what can be handled better some other 
way, or simply where the specification is incomplete, erroneous or just 
unspecified).


Another issue is still module splitting - bigger feature implementations 
are often splitted into several modules, which need the ability to 
privately access each other. This also results in some mismatch: 
Sometimes it would be nice to be able to expose some APIs as 
friend-only, while others are interesting for public usage. Currently, 
only either export is possible. While one can split the exporting module 
once more, this is probably not always convenient - probably this should 
be fixed. 

Re: Public vs. Friend API?

[Jaroslav Tulach]

Dne sobota 14. července 2018 6:46:06 CEST, Tim Boudreau napsal(a):
> There are friend APIs in NetBeans that have not seen a single change in
> going on a decade.  All of those IMO, should simply get the "friend" label
> removed from them - if it hasn't changed in that long, it's clearly stable
> in every practical meaning of the word.  I'm just suggesting a way to make
> that automatic, 

Turn all current [Friend APIs](http://wiki.netbeans.org/API_Stability#Friend) 
into [Under development ones](http://wiki.netbeans.org/API_Stability#Devel).

Before you do the above change:
- [snapshot current APIs](http://wiki.netbeans.org/SignatureTest) of 9.0 
release
- make sure the build fails on an accidental change in such APIs

That's my 2 Kč suggestion.
-jt





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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?

[Neil C Smith]

On Sat, 14 Jul 2018 at 05:41, Tim Boudreau  wrote:
> I was there when friend APIs were being invented.  The *entire* purpose was
> for a developer to evolve an API,

Well, fair enough, can't argue with that (although I'd argue there are
uses now that aren't for that purpose).  Still seems the wrong way
around to me in comparison to other things I've worked with.

> IMO, there *is no such thing as a "true friend" API.*  If you don't want to
> publish an API, put all of your code in one module - the compatibility
> contract is between that module and itself.  If module X depends on module
> Y, and nothing else may depend on Y, and X cannot function without Y, then
> you have *a single logical module.*  You might think it looks nicer carved
> up into two pieces, but at that point you're doing code feng shui, not
> engineering.

There are other reasons for using more than one module where you
*never* intend to create a public API, but need other aspects of the
module system - optionally loaded parts, OS-specific parts, etc.  So I
*am* thinking of a small number of things that are logically a unit.

> If you have "non-stable dependencies", eventually that is all that will
> exist.  Nobody would prefer to keep compatibility if they don't have to.

Well, that's a pessimistic viewpoint! ;-)  But I agree with you that
time-limiting instability is probably a good idea.  And if optionally
installed modules can only be installed against a single release
(major/minor not point) of the IDE (and perhaps show a big warning
dialog to that fact) I think you'd see things pushed to become stable.

> You can.  If you're writing an IDE module, your users can't.  They just
> upgrade the IDE and find something doesn't work anymore, say "this sucks"
> and go download Eclipse.

I'd argue that the friend system has made that problem worse not
better.  Assuming in-development API's don't change via automatic
updates as opposed to manual upgrade, then I don't see the issue here.
With the friend API you either don't have the module in the first
place, or a module that's had to hack its way into working in such a
way that it's more prone to breakage?!

Best wishes,

Neil

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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?

[Tim Boudreau]

>
> I can be prepared on my side when I use something unstable and can adopt
> the change.
>

You can.  If you're writing an IDE module, your users can't.  They just
upgrade the IDE and find something doesn't work anymore, say "this sucks"
and go download Eclipse.

There are friend APIs in NetBeans that have not seen a single change in
going on a decade.  All of those IMO, should simply get the "friend" label
removed from them - if it hasn't changed in that long, it's clearly stable
in every practical meaning of the word.  I'm just suggesting a way to make
that automatic, instead of someone having to go do that process manually,
because what's predictable is that maybe it gets done in one release, and
then it doesn't happen again for another decade until this exact
conversation is happening again.

-Tim

Re: Public vs. Friend API?

[Tim Boudreau]

>
> > So there's no reason the module system itself couldn't just discard
> > "friend" status for any friend API and allow any module to depend on it,
> > where the running release version is >= the first-appeared-in-release + 2
> > (or whatever number).  So, a friend API that appears in release 9 is
> > automatically a public API in release 11, no human intervention required
> > (the Ant build harness and Maven plugin would also have to do this
> > computation).
> >
>
> I still don't see why this isn't looking at the problem backwards. True
> friend APIs and not-yet-stable public APIs seem to be orthogonal problems.
>

I was there when friend APIs were being invented.  The *entire* purpose was
for a developer to evolve an API, in collaboration with others whose
requirements might lead to incompatible changes in it, prior to being
subject to the stringent backward compatibility requirements Sun required
of public APIs.

IMO, there *is no such thing as a "true friend" API.*  If you don't want to
publish an API, put all of your code in one module - the compatibility
contract is between that module and itself.  If module X depends on module
Y, and nothing else may depend on Y, and X cannot function without Y, then
you have *a single logical module.*  You might think it looks nicer carved
up into two pieces, but at that point you're doing code feng shui, not
engineering.

Assuming even non-stable APIs are stable for at least one release of the
> IDE / platform, what benefit does this actually provide? Surely it is for
> the user of the API to specify a non-stable dependency, not the provider to
> act as gatekeeper?
>

The logical outcome of friend APIs is nobody creates anything else, unless
there is a mechanism that says "stabilize your API or you're going to have
to keep binary compatibility with whatever you've got when the clock runs
out."  The ongoing growth of stable APIs is what moves the platform and IDE
forward, allowing new functionality to stand on the shoulders of what is
already there.  Friend APIs keep that from happening.

If you have "non-stable dependencies", eventually that is all that will
exist.  Nobody would prefer to keep compatibility if they don't have to.

-Tim

Re: Public vs. Friend API?

[Laszlo Kishalmi]

Well, I guess all this "friendly"-ness use case shall be re-evaluated.

For me an unstable or incubation flag would be more than sufficient, and 
the build might warn me or optionally fail if I'd use an 
unstable/incubation level of module.


I can be prepared on my side when I use something unstable and can adopt 
the change.


Though we have other type of users, who seriously invested in NetBeans 
Platform. Geertjan probably know the most of them, a survey on their 
site would be good to have.


Right now there is a possibility to tweak friendliness using Yenta 
(search it on Google).


Just a sample set of modules, from my own plugin code. These could be 
real public from 8.0 at least:


"org.netbeans.modules.gsf.testrunner",
"org.netbeans.modules.gsf.testrunner.ui",
"org.netbeans.modules.java.testrunner.ui",
"org.netbeans.modules.junit",
"org.netbeans.modules.junit.ui"



On 07/12/2018 04:11 PM, Peter Nabbefeld wrote:


Hello all,

I personally don't like "Friend" APIs, as really I like the idea of an 
open, extensible IDE.


From my point of view, Friend APIs make it difficult or impossible to 
extend NetBeans for personal use:
- You have to ask for being added to the friends list. This is 
especially a problem, if You want to implement some private-use 
feature, e.g. for Your employer.
- Alternatively You could depend on the implementation version; but I 
don't see how to do that, if You're using Maven.
- Third possibility is just patching the modules to remove the friends 
and make the API public - very ugly, and You have to do it after every 
update.


OTOH, having a friends-only API leads to fewer dependencies on the 
API, thus less impact from changes to the API, which makes work easier 
for the developers, of course.


However, if an API isn't stable, yet, it could also just be flagged as 
"Under Development", thus telling users of those, that it is subject 
to change. Also, as it is possible to use default methods in 
interfaces from Java 8, it should be less of a problem to extend an 
existing API. But You can use the API on Your own risk without any 
conflicts.


An exception of course is having APIs only for modularity, if classes 
are spread over different modules and need an API to interact with 
each other. In this case the API's purpose is not to integrate 
extensions, but to split responsibilities - in this case I fully agree 
these are not for public use.


I'd be interested in comments on this - so, what do You think?

Kind regards

Peter

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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?

[Neil C Smith]

On Fri, 13 Jul 2018, 20:15 Tim Boudreau,  wrote:

> So there's no reason the module system itself couldn't just discard
> "friend" status for any friend API and allow any module to depend on it,
> where the running release version is >= the first-appeared-in-release + 2
> (or whatever number).  So, a friend API that appears in release 9 is
> automatically a public API in release 11, no human intervention required
> (the Ant build harness and Maven plugin would also have to do this
> computation).
>

I still don't see why this isn't looking at the problem backwards. True
friend APIs and not-yet-stable public APIs seem to be orthogonal problems.
Assuming even non-stable APIs are stable for at least one release of the
IDE / platform, what benefit does this actually provide? Surely it is for
the user of the API to specify a non-stable dependency, not the provider to
act as gatekeeper?

I guess what I'd like to see is something that is neither friend nor
implementation here.

And never using friend API for third-party stuff either - JNA caused me no
end of issues over the years!

Best wishes,

Neil

>

Re: Public vs. Friend API?

[Tim Boudreau]

Pull requests are good; automation is better.  NetBeans knows its own
release version.  The only (potentially) missing information is what
release the friend API first appeared in.

So there's no reason the module system itself couldn't just discard
"friend" status for any friend API and allow any module to depend on it,
where the running release version is >= the first-appeared-in-release + 2
(or whatever number).  So, a friend API that appears in release 9 is
automatically a public API in release 11, no human intervention required
(the Ant build harness and Maven plugin would also have to do this
computation).

That would also light a fire under developers to actually stabilize APIs.

-Tim



On Fri, Jul 13, 2018 at 9:34 AM Neil C Smith  wrote:

> On Fri, 13 Jul 2018 at 14:26, Geertjan Wielenga
>  wrote:
> >
> > Put together a proposal on the Apache NetBeans Wiki and we can discuss
> it.
>
> The wiki page I linked to on the old site does have some proposals
> here that look interesting and detailed.  We should make sure we don't
> lose that page as well - we haven't migrated everything and this
> doesn't seem to be there.  At the moment it's mainly DevFAQ.  Do you
> know where that page is sitting in the old wiki?  Not always easy to
> tell when Google takes you there directly, unless I've missed
> something staring me in the face?! :-)
>
> Best wishes,
>
> Neil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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?

[Neil C Smith]

On Fri, 13 Jul 2018 at 14:26, Geertjan Wielenga
 wrote:
>
> Put together a proposal on the Apache NetBeans Wiki and we can discuss it.

The wiki page I linked to on the old site does have some proposals
here that look interesting and detailed.  We should make sure we don't
lose that page as well - we haven't migrated everything and this
doesn't seem to be there.  At the moment it's mainly DevFAQ.  Do you
know where that page is sitting in the old wiki?  Not always easy to
tell when Google takes you there directly, unless I've missed
something staring me in the face?! :-)

Best wishes,

Neil

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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?

[Geertjan Wielenga]

Put together a proposal on the Apache NetBeans Wiki and we can discuss it.

Discussion in this thread is indeed going to stop very soon unless an
actual concrete proposal is put together.

Gj

On Friday, July 13, 2018, Peter Nabbefeld  wrote:

>
> Yes, I know. I just wanted to make sure discussion doesn't stop at this
> point. In the past, I'd already some discussions of this type, mostly
> ending some time later anywhere else.
>
> So, while Johannes was *really* helpful, I just want to keep the direction
> of the topic, as I see the move to Apache as a chance, to finally implement
> a better API release process. This chance will probably never come back.
>
> Kind regards
>
> Peter
>
>
>
> Am 13.07.2018 um 12:03 schrieb Geertjan Wielenga:
>
>> Yes, of course. But Johannes was responding to this statement of yours and
>> trying to help you and show you how to do this:
>>
>> - Alternatively You could depend on the implementation version; but I
>> don't
>>
>>> see how to do that, if You're using Maven.
>>>
>>
>> Gj
>>
>> On Fri, Jul 13, 2018 at 12:01 PM, Peter Nabbefeld > >
>> wrote:
>>
>> Hi Johannes,
>>>
>>> thank You for the info! I'll have to find out what I was missing then.
>>> Nevertheless, IMHO a module depending on an implementation is not very
>>> convenient, as it will always fail to load when the dependency changed in
>>> any way, not necessarily the API (in that case the spec version should
>>> probably change, too).
>>>
>>> Kind regards
>>> Peter
>>>
>>>
>>>
>>> Am 13.07.2018 um 10:33 schrieb Johannes Boesl:
>>>
>>> Hi there,

 just for completeness. It's well possible to depend on implementation
 version using maven. Here is an abstract from one of my poms:

org.codehaus.mojo
 nbm-maven-plugin 
  de.adito.aditow
 eb.nbm.designerbase.* 
   org.netbeans.modules:org-n
 etbeans-modules-projectui
 impl org.netbeans.modules.projectui =
 201609300101  
 org.netbeans.modules:org-netbeans-modules-git
 impl
 org.netbeans.modules.git = 201609300101
   org.netbeans.modules:org-n
 etbeans-modules-versioning-util impl 
 org.netbeans.modules.versioning.util = 201609300101
   org.netbeans.api:org-netbe
 ans-modules-csl-api
 impl org.netbeans.modules.csl.api/2 =
 2  
 eager   
 

 With kind regards,
 Johannes Boesl


 Am 13.07.2018 um 01:11 schrieb Peter Nabbefeld:

 Hello all,
>
> I personally don't like "Friend" APIs, as really I like the idea of an
> open, extensible IDE.
>
>   From my point of view, Friend APIs make it difficult or impossible to
> extend NetBeans for personal use:
> - You have to ask for being added to the friends list. This is
> especially a problem, if You want to implement some private-use
> feature, e.g. for Your employer.
> - Alternatively You could depend on the implementation version; but I
> don't see how to do that, if You're using Maven.
> - Third possibility is just patching the modules to remove the friends
> and make the API public - very ugly, and You have to do it after every
> update.
>
> OTOH, having a friends-only API leads to fewer dependencies on the
> API, thus less impact from changes to the API, which makes work easier
> for the developers, of course.
>
> However, if an API isn't stable, yet, it could also just be flagged as
> "Under Development", thus telling users of those, that it is subject
> to change. Also, as it is possible to use default methods in
> interfaces from Java 8, it should be less of a problem to extend an
> existing API. But You can use the API on Your own risk without any
> conflicts.
>
> An exception of course is having APIs only for modularity, if classes
> are spread over different modules and need an API to interact with
> each other. In this case the API's purpose is not to integrate
> extensions, but to split responsibilities - in this case I fully agree
> these are not for public use.
>
> I'd be interested in comments on this - so, what do You think?
>
> Kind regards
>
> Peter
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@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-unsubscr...@netbeans.incubator.apache.org
>>> For additional commands, e-mail: dev-h...@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?

[Peter Nabbefeld]

Yes, I know. I just wanted to make sure discussion doesn't stop at this 
point. In the past, I'd already some discussions of this type, mostly 
ending some time later anywhere else.


So, while Johannes was *really* helpful, I just want to keep the 
direction of the topic, as I see the move to Apache as a chance, to 
finally implement a better API release process. This chance will 
probably never come back.


Kind regards

Peter



Am 13.07.2018 um 12:03 schrieb Geertjan Wielenga:

Yes, of course. But Johannes was responding to this statement of yours and
trying to help you and show you how to do this:

- Alternatively You could depend on the implementation version; but I don't

see how to do that, if You're using Maven.


Gj

On Fri, Jul 13, 2018 at 12:01 PM, Peter Nabbefeld 
wrote:


Hi Johannes,

thank You for the info! I'll have to find out what I was missing then.
Nevertheless, IMHO a module depending on an implementation is not very
convenient, as it will always fail to load when the dependency changed in
any way, not necessarily the API (in that case the spec version should
probably change, too).

Kind regards
Peter



Am 13.07.2018 um 10:33 schrieb Johannes Boesl:


Hi there,

just for completeness. It's well possible to depend on implementation
version using maven. Here is an abstract from one of my poms:

   org.codehaus.mojo
nbm-maven-plugin 
 de.adito.aditow
eb.nbm.designerbase.* 
  
org.netbeans.modules:org-netbeans-modules-projectui
impl org.netbeans.modules.projectui =
201609300101  
org.netbeans.modules:org-netbeans-modules-git impl
org.netbeans.modules.git = 201609300101
  org.netbeans.modules:org-n
etbeans-modules-versioning-util impl 
org.netbeans.modules.versioning.util = 201609300101
  
org.netbeans.api:org-netbeans-modules-csl-api
impl org.netbeans.modules.csl.api/2 =
2  
eager   


With kind regards,
Johannes Boesl


Am 13.07.2018 um 01:11 schrieb Peter Nabbefeld:


Hello all,

I personally don't like "Friend" APIs, as really I like the idea of an
open, extensible IDE.

  From my point of view, Friend APIs make it difficult or impossible to
extend NetBeans for personal use:
- You have to ask for being added to the friends list. This is
especially a problem, if You want to implement some private-use
feature, e.g. for Your employer.
- Alternatively You could depend on the implementation version; but I
don't see how to do that, if You're using Maven.
- Third possibility is just patching the modules to remove the friends
and make the API public - very ugly, and You have to do it after every
update.

OTOH, having a friends-only API leads to fewer dependencies on the
API, thus less impact from changes to the API, which makes work easier
for the developers, of course.

However, if an API isn't stable, yet, it could also just be flagged as
"Under Development", thus telling users of those, that it is subject
to change. Also, as it is possible to use default methods in
interfaces from Java 8, it should be less of a problem to extend an
existing API. But You can use the API on Your own risk without any
conflicts.

An exception of course is having APIs only for modularity, if classes
are spread over different modules and need an API to interact with
each other. In this case the API's purpose is not to integrate
extensions, but to split responsibilities - in this case I fully agree
these are not for public use.

I'd be interested in comments on this - so, what do You think?

Kind regards

Peter

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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?

[Geertjan Wielenga]

Yes, of course. But Johannes was responding to this statement of yours and
trying to help you and show you how to do this:

- Alternatively You could depend on the implementation version; but I don't
> see how to do that, if You're using Maven.


Gj

On Fri, Jul 13, 2018 at 12:01 PM, Peter Nabbefeld 
wrote:

>
> Hi Johannes,
>
> thank You for the info! I'll have to find out what I was missing then.
> Nevertheless, IMHO a module depending on an implementation is not very
> convenient, as it will always fail to load when the dependency changed in
> any way, not necessarily the API (in that case the spec version should
> probably change, too).
>
> Kind regards
> Peter
>
>
>
> Am 13.07.2018 um 10:33 schrieb Johannes Boesl:
>
>> Hi there,
>>
>> just for completeness. It's well possible to depend on implementation
>> version using maven. Here is an abstract from one of my poms:
>>
>>org.codehaus.mojo
>> nbm-maven-plugin 
>>  de.adito.aditow
>> eb.nbm.designerbase.* 
>>   
>> org.netbeans.modules:org-netbeans-modules-projectui
>> impl org.netbeans.modules.projectui =
>> 201609300101  
>> org.netbeans.modules:org-netbeans-modules-git impl
>> org.netbeans.modules.git = 201609300101
>>   org.netbeans.modules:org-n
>> etbeans-modules-versioning-util impl 
>> org.netbeans.modules.versioning.util = 201609300101
>>   
>> org.netbeans.api:org-netbeans-modules-csl-api
>> impl org.netbeans.modules.csl.api/2 =
>> 2  
>> eager   
>> 
>>
>> With kind regards,
>> Johannes Boesl
>>
>>
>> Am 13.07.2018 um 01:11 schrieb Peter Nabbefeld:
>>
>>> Hello all,
>>>
>>> I personally don't like "Friend" APIs, as really I like the idea of an
>>> open, extensible IDE.
>>>
>>>  From my point of view, Friend APIs make it difficult or impossible to
>>> extend NetBeans for personal use:
>>> - You have to ask for being added to the friends list. This is
>>> especially a problem, if You want to implement some private-use
>>> feature, e.g. for Your employer.
>>> - Alternatively You could depend on the implementation version; but I
>>> don't see how to do that, if You're using Maven.
>>> - Third possibility is just patching the modules to remove the friends
>>> and make the API public - very ugly, and You have to do it after every
>>> update.
>>>
>>> OTOH, having a friends-only API leads to fewer dependencies on the
>>> API, thus less impact from changes to the API, which makes work easier
>>> for the developers, of course.
>>>
>>> However, if an API isn't stable, yet, it could also just be flagged as
>>> "Under Development", thus telling users of those, that it is subject
>>> to change. Also, as it is possible to use default methods in
>>> interfaces from Java 8, it should be less of a problem to extend an
>>> existing API. But You can use the API on Your own risk without any
>>> conflicts.
>>>
>>> An exception of course is having APIs only for modularity, if classes
>>> are spread over different modules and need an API to interact with
>>> each other. In this case the API's purpose is not to integrate
>>> extensions, but to split responsibilities - in this case I fully agree
>>> these are not for public use.
>>>
>>> I'd be interested in comments on this - so, what do You think?
>>>
>>> Kind regards
>>>
>>> Peter
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
>>> For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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?

[Peter Nabbefeld]

Hi Johannes,

thank You for the info! I'll have to find out what I was missing then. 
Nevertheless, IMHO a module depending on an implementation is not very 
convenient, as it will always fail to load when the dependency changed 
in any way, not necessarily the API (in that case the spec version 
should probably change, too).


Kind regards
Peter


Am 13.07.2018 um 10:33 schrieb Johannes Boesl:

Hi there,

just for completeness. It's well possible to depend on implementation
version using maven. Here is an abstract from one of my poms:

   org.codehaus.mojo nbm-maven-plugin   de.adito.aditoweb.nbm.designerbase.*
org.netbeans.modules:org-netbeans-modules-projectui impl org.netbeans.modules.projectui = 201609300101   org.netbeans.modules:org-netbeans-modules-git impl org.netbeans.modules.git = 
201609300101   org.netbeans.modules:org-netbeans-modules-versioning-util impl org.netbeans.modules.versioning.util = 201609300101   org.netbeans.api:org-netbeans-modules-csl-api 
impl org.netbeans.modules.csl.api/2 = 2   eager

With kind regards,
Johannes Boesl


Am 13.07.2018 um 01:11 schrieb Peter Nabbefeld:

Hello all,

I personally don't like "Friend" APIs, as really I like the idea of an
open, extensible IDE.

 From my point of view, Friend APIs make it difficult or impossible to
extend NetBeans for personal use:
- You have to ask for being added to the friends list. This is
especially a problem, if You want to implement some private-use
feature, e.g. for Your employer.
- Alternatively You could depend on the implementation version; but I
don't see how to do that, if You're using Maven.
- Third possibility is just patching the modules to remove the friends
and make the API public - very ugly, and You have to do it after every
update.

OTOH, having a friends-only API leads to fewer dependencies on the
API, thus less impact from changes to the API, which makes work easier
for the developers, of course.

However, if an API isn't stable, yet, it could also just be flagged as
"Under Development", thus telling users of those, that it is subject
to change. Also, as it is possible to use default methods in
interfaces from Java 8, it should be less of a problem to extend an
existing API. But You can use the API on Your own risk without any
conflicts.

An exception of course is having APIs only for modularity, if classes
are spread over different modules and need an API to interact with
each other. In this case the API's purpose is not to integrate
extensions, but to split responsibilities - in this case I fully agree
these are not for public use.

I'd be interested in comments on this - so, what do You think?

Kind regards

Peter

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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?

[Johannes Boesl]

Hi there,

just for completeness. It's well possible to depend on implementation
version using maven. Here is an abstract from one of my poms:

   org.codehaus.mojo 
nbm-maven-plugin   
de.adito.aditoweb.nbm.designerbase.* 
   
org.netbeans.modules:org-netbeans-modules-projectui impl 
org.netbeans.modules.projectui = 201609300101 
  
org.netbeans.modules:org-netbeans-modules-git impl 
org.netbeans.modules.git = 201609300101 
  
org.netbeans.modules:org-netbeans-modules-versioning-util 
impl org.netbeans.modules.versioning.util = 
201609300101   
org.netbeans.api:org-netbeans-modules-csl-api impl 
org.netbeans.modules.csl.api/2 = 2  
 eager   
 

With kind regards,
Johannes Boesl


Am 13.07.2018 um 01:11 schrieb Peter Nabbefeld:
>
> Hello all,
>
> I personally don't like "Friend" APIs, as really I like the idea of an
> open, extensible IDE.
>
> From my point of view, Friend APIs make it difficult or impossible to
> extend NetBeans for personal use:
> - You have to ask for being added to the friends list. This is
> especially a problem, if You want to implement some private-use
> feature, e.g. for Your employer.
> - Alternatively You could depend on the implementation version; but I
> don't see how to do that, if You're using Maven.
> - Third possibility is just patching the modules to remove the friends
> and make the API public - very ugly, and You have to do it after every
> update.
>
> OTOH, having a friends-only API leads to fewer dependencies on the
> API, thus less impact from changes to the API, which makes work easier
> for the developers, of course.
>
> However, if an API isn't stable, yet, it could also just be flagged as
> "Under Development", thus telling users of those, that it is subject
> to change. Also, as it is possible to use default methods in
> interfaces from Java 8, it should be less of a problem to extend an
> existing API. But You can use the API on Your own risk without any
> conflicts.
>
> An exception of course is having APIs only for modularity, if classes
> are spread over different modules and need an API to interact with
> each other. In this case the API's purpose is not to integrate
> extensions, but to split responsibilities - in this case I fully agree
> these are not for public use.
>
> I'd be interested in comments on this - so, what do You think?
>
> Kind regards
>
> Peter
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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?

[Peter Nabbefeld]

HTML and Palette have been mentioned as examples here only. When I'm 
ready to change sth., I'll provide a pull request together with starting 
a separate discussion.


However, I remember being stopped from Friend APIs some long time ago, 
so IMHO this should be discussed.


I understand, there're two different points of view:
1. API user's view: Give me as many APIs as possible, so I can do almost 
everything with the IDE.
2. IDE developers view: Provide as few as possible, only absolutely 
necessary, so IDE changes can be freely developed without impact to API 
users.


These two views have to be considered for API state, and I'd be happy, 
if this discussion would lead to a better understanding of these and 
probably some rules, how to handle these. Hopefully this will lead to 
some rules for the Apache NetBeans project, how API state could be 
handled in a better and especially more transparent process.


Regards
Peter


Am 13.07.2018 um 08:33 schrieb Geertjan Wielenga:

Maybe a starting point could be for you to provide a pull request with the
changes you'd like and then we can discuss that and agree together whether
or not those changes make sense.

Gj


On Fri, Jul 13, 2018 at 8:27 AM, Peter Nabbefeld 
wrote:


If this process (hardening the API and releasing it as public) would have
been followed, it would be great. Unfortunately, it seems there're a bunch
of useful APIs now which are not even part of the javadoc at
bits.netbeans.org (and therefore mostly unknown) and seem to never be
released.

Some other APIs (like Palette API) seem to have extensions in many parts
(= collections of modules building a functional part, like HTML support) of
NetBeans, which could probably be made more general and then moved into the
"Main API" (Palette, in this case), so everybody could use those. E.g. html
module seems to have the ability to activate parts of different HTML APIs
via layer, and some interface is there defined (but not yet used) to do
this programmatically (probably using annotations). IMHO, this could be
useful for other parts, too.

So, while NetBeans moves to Apache, I'd like to further discuss the
process of extending and hardening APIs.

Regards
Peter



Am 13.07.2018 um 04:28 schrieb Tim Boudreau:


The original idea of friend apis was to allow development of an api with
the understanding that nobody gets things perfect the first time, so
clients v could be developed but at the risk of dealing with breakage.

The point was for the api to be in friend mode until it matures, at which
point it becomes official compatible api. That's the part that never
happened - no mechanism pushing moving apis out of friend mode.

I'd suggest a rule that that happens automatically if a friend api has
been
around for more than 2-3 releases. Enforcement of that could probably be
automated with a bit of auto bug filing cleverness.

-Tim

On Thu, Jul 12, 2018 at 7:11 PM Peter Nabbefeld 
wrote:

Hello all,

I personally don't like "Friend" APIs, as really I like the idea of an
open, extensible IDE.

   From my point of view, Friend APIs make it difficult or impossible to
extend NetBeans for personal use:
- You have to ask for being added to the friends list. This is
especially a problem, if You want to implement some private-use feature,
e.g. for Your employer.
- Alternatively You could depend on the implementation version; but I
don't see how to do that, if You're using Maven.
- Third possibility is just patching the modules to remove the friends
and make the API public - very ugly, and You have to do it after every
update.

OTOH, having a friends-only API leads to fewer dependencies on the API,
thus less impact from changes to the API, which makes work easier for
the developers, of course.

However, if an API isn't stable, yet, it could also just be flagged as
"Under Development", thus telling users of those, that it is subject to
change. Also, as it is possible to use default methods in interfaces
from Java 8, it should be less of a problem to extend an existing API.
But You can use the API on Your own risk without any conflicts.

An exception of course is having APIs only for modularity, if classes
are spread over different modules and need an API to interact with each
other. In this case the API's purpose is not to integrate extensions,
but to split responsibilities - in this case I fully agree these are not
for public use.

I'd be interested in comments on this - so, what do You think?

Kind regards

Peter

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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: 

Re: Public vs. Friend API?

[Neil C Smith]

On Fri, 13 Jul 2018, 00:11 Peter Nabbefeld,  wrote:

> I personally don't like "Friend" APIs, as really I like the idea of an
> open, extensible IDE. ... However, if an API isn't stable, yet, it could
> also just be flagged as
> "Under Development"
>

+110%

Linking something for completeness -
https://github.com/apache/incubator-netbeans/pull/415

IMO this concept needs rethinking, at least as something to mark unstable
APIs (might have a limited role in small module groupings). We should make
better use of semantic versioning, maybe extend module versioning to
support / warn on -beta suffixes, and not break APIs in point releases.

This old wiki page looks interesting, although only skimmed so far. Found
it while searching for something else related.
http://wiki.netbeans.org/NbmPackageStability

Best wishes,

Neil

Re: Public vs. Friend API?

[Geertjan Wielenga]

Maybe a starting point could be for you to provide a pull request with the
changes you'd like and then we can discuss that and agree together whether
or not those changes make sense.

Gj


On Fri, Jul 13, 2018 at 8:27 AM, Peter Nabbefeld 
wrote:

>
> If this process (hardening the API and releasing it as public) would have
> been followed, it would be great. Unfortunately, it seems there're a bunch
> of useful APIs now which are not even part of the javadoc at
> bits.netbeans.org (and therefore mostly unknown) and seem to never be
> released.
>
> Some other APIs (like Palette API) seem to have extensions in many parts
> (= collections of modules building a functional part, like HTML support) of
> NetBeans, which could probably be made more general and then moved into the
> "Main API" (Palette, in this case), so everybody could use those. E.g. html
> module seems to have the ability to activate parts of different HTML APIs
> via layer, and some interface is there defined (but not yet used) to do
> this programmatically (probably using annotations). IMHO, this could be
> useful for other parts, too.
>
> So, while NetBeans moves to Apache, I'd like to further discuss the
> process of extending and hardening APIs.
>
> Regards
> Peter
>
>
>
> Am 13.07.2018 um 04:28 schrieb Tim Boudreau:
>
>> The original idea of friend apis was to allow development of an api with
>> the understanding that nobody gets things perfect the first time, so
>> clients v could be developed but at the risk of dealing with breakage.
>>
>> The point was for the api to be in friend mode until it matures, at which
>> point it becomes official compatible api. That's the part that never
>> happened - no mechanism pushing moving apis out of friend mode.
>>
>> I'd suggest a rule that that happens automatically if a friend api has
>> been
>> around for more than 2-3 releases. Enforcement of that could probably be
>> automated with a bit of auto bug filing cleverness.
>>
>> -Tim
>>
>> On Thu, Jul 12, 2018 at 7:11 PM Peter Nabbefeld 
>> wrote:
>>
>> Hello all,
>>>
>>> I personally don't like "Friend" APIs, as really I like the idea of an
>>> open, extensible IDE.
>>>
>>>   From my point of view, Friend APIs make it difficult or impossible to
>>> extend NetBeans for personal use:
>>> - You have to ask for being added to the friends list. This is
>>> especially a problem, if You want to implement some private-use feature,
>>> e.g. for Your employer.
>>> - Alternatively You could depend on the implementation version; but I
>>> don't see how to do that, if You're using Maven.
>>> - Third possibility is just patching the modules to remove the friends
>>> and make the API public - very ugly, and You have to do it after every
>>> update.
>>>
>>> OTOH, having a friends-only API leads to fewer dependencies on the API,
>>> thus less impact from changes to the API, which makes work easier for
>>> the developers, of course.
>>>
>>> However, if an API isn't stable, yet, it could also just be flagged as
>>> "Under Development", thus telling users of those, that it is subject to
>>> change. Also, as it is possible to use default methods in interfaces
>>> from Java 8, it should be less of a problem to extend an existing API.
>>> But You can use the API on Your own risk without any conflicts.
>>>
>>> An exception of course is having APIs only for modularity, if classes
>>> are spread over different modules and need an API to interact with each
>>> other. In this case the API's purpose is not to integrate extensions,
>>> but to split responsibilities - in this case I fully agree these are not
>>> for public use.
>>>
>>> I'd be interested in comments on this - so, what do You think?
>>>
>>> Kind regards
>>>
>>> Peter
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
>>> For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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?

[Peter Nabbefeld]

If this process (hardening the API and releasing it as public) would 
have been followed, it would be great. Unfortunately, it seems there're 
a bunch of useful APIs now which are not even part of the javadoc at 
bits.netbeans.org (and therefore mostly unknown) and seem to never be 
released.


Some other APIs (like Palette API) seem to have extensions in many parts 
(= collections of modules building a functional part, like HTML support) 
of NetBeans, which could probably be made more general and then moved 
into the "Main API" (Palette, in this case), so everybody could use 
those. E.g. html module seems to have the ability to activate parts of 
different HTML APIs via layer, and some interface is there defined (but 
not yet used) to do this programmatically (probably using annotations). 
IMHO, this could be useful for other parts, too.


So, while NetBeans moves to Apache, I'd like to further discuss the 
process of extending and hardening APIs.


Regards
Peter


Am 13.07.2018 um 04:28 schrieb Tim Boudreau:

The original idea of friend apis was to allow development of an api with
the understanding that nobody gets things perfect the first time, so
clients v could be developed but at the risk of dealing with breakage.

The point was for the api to be in friend mode until it matures, at which
point it becomes official compatible api. That's the part that never
happened - no mechanism pushing moving apis out of friend mode.

I'd suggest a rule that that happens automatically if a friend api has been
around for more than 2-3 releases. Enforcement of that could probably be
automated with a bit of auto bug filing cleverness.

-Tim

On Thu, Jul 12, 2018 at 7:11 PM Peter Nabbefeld 
wrote:


Hello all,

I personally don't like "Friend" APIs, as really I like the idea of an
open, extensible IDE.

  From my point of view, Friend APIs make it difficult or impossible to
extend NetBeans for personal use:
- You have to ask for being added to the friends list. This is
especially a problem, if You want to implement some private-use feature,
e.g. for Your employer.
- Alternatively You could depend on the implementation version; but I
don't see how to do that, if You're using Maven.
- Third possibility is just patching the modules to remove the friends
and make the API public - very ugly, and You have to do it after every
update.

OTOH, having a friends-only API leads to fewer dependencies on the API,
thus less impact from changes to the API, which makes work easier for
the developers, of course.

However, if an API isn't stable, yet, it could also just be flagged as
"Under Development", thus telling users of those, that it is subject to
change. Also, as it is possible to use default methods in interfaces
from Java 8, it should be less of a problem to extend an existing API.
But You can use the API on Your own risk without any conflicts.

An exception of course is having APIs only for modularity, if classes
are spread over different modules and need an API to interact with each
other. In this case the API's purpose is not to integrate extensions,
but to split responsibilities - in this case I fully agree these are not
for public use.

I'd be interested in comments on this - so, what do You think?

Kind regards

Peter

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@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?

[Tim Boudreau]

The original idea of friend apis was to allow development of an api with
the understanding that nobody gets things perfect the first time, so
clients v could be developed but at the risk of dealing with breakage.

The point was for the api to be in friend mode until it matures, at which
point it becomes official compatible api. That's the part that never
happened - no mechanism pushing moving apis out of friend mode.

I'd suggest a rule that that happens automatically if a friend api has been
around for more than 2-3 releases. Enforcement of that could probably be
automated with a bit of auto bug filing cleverness.

-Tim

On Thu, Jul 12, 2018 at 7:11 PM Peter Nabbefeld 
wrote:

>
> Hello all,
>
> I personally don't like "Friend" APIs, as really I like the idea of an
> open, extensible IDE.
>
>  From my point of view, Friend APIs make it difficult or impossible to
> extend NetBeans for personal use:
> - You have to ask for being added to the friends list. This is
> especially a problem, if You want to implement some private-use feature,
> e.g. for Your employer.
> - Alternatively You could depend on the implementation version; but I
> don't see how to do that, if You're using Maven.
> - Third possibility is just patching the modules to remove the friends
> and make the API public - very ugly, and You have to do it after every
> update.
>
> OTOH, having a friends-only API leads to fewer dependencies on the API,
> thus less impact from changes to the API, which makes work easier for
> the developers, of course.
>
> However, if an API isn't stable, yet, it could also just be flagged as
> "Under Development", thus telling users of those, that it is subject to
> change. Also, as it is possible to use default methods in interfaces
> from Java 8, it should be less of a problem to extend an existing API.
> But You can use the API on Your own risk without any conflicts.
>
> An exception of course is having APIs only for modularity, if classes
> are spread over different modules and need an API to interact with each
> other. In this case the API's purpose is not to integrate extensions,
> but to split responsibilities - in this case I fully agree these are not
> for public use.
>
> I'd be interested in comments on this - so, what do You think?
>
> Kind regards
>
> Peter
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@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

Public vs. Friend API?

[Peter Nabbefeld]

Hello all,

I personally don't like "Friend" APIs, as really I like the idea of an 
open, extensible IDE.


From my point of view, Friend APIs make it difficult or impossible to 
extend NetBeans for personal use:
- You have to ask for being added to the friends list. This is 
especially a problem, if You want to implement some private-use feature, 
e.g. for Your employer.
- Alternatively You could depend on the implementation version; but I 
don't see how to do that, if You're using Maven.
- Third possibility is just patching the modules to remove the friends 
and make the API public - very ugly, and You have to do it after every 
update.


OTOH, having a friends-only API leads to fewer dependencies on the API, 
thus less impact from changes to the API, which makes work easier for 
the developers, of course.


However, if an API isn't stable, yet, it could also just be flagged as 
"Under Development", thus telling users of those, that it is subject to 
change. Also, as it is possible to use default methods in interfaces 
from Java 8, it should be less of a problem to extend an existing API. 
But You can use the API on Your own risk without any conflicts.


An exception of course is having APIs only for modularity, if classes 
are spread over different modules and need an API to interact with each 
other. In this case the API's purpose is not to integrate extensions, 
but to split responsibilities - in this case I fully agree these are not 
for public use.


I'd be interested in comments on this - so, what do You think?

Kind regards

Peter

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists