travis weather report: stuck

[Michael Bien]

hi devs,

travis appears to be stuck again, 10 PRs in the build queue and nothing 
is building.


https://app.travis-ci.com/github/apache/netbeans/pull_requests

I canceled the build of my PR yesterday in hope this would get it 
unstuck but it is still not building. So i suppose canceling everything 
wouldn't work either, it would just annoy the affected PR owners.


I guess i wait a day and then file an issue@infra... again

-mbien


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

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

Code coverage

[Łukasz Bownik]

Hello.

Does NetBeans CI  provide code coverage reports?

Re: API change

[Łukasz Bownik]

Vicrims of popularity? ;)

On Tue, May 10, 2022, 1:56 PM Laszlo Kishalmi 
wrote:

> Also some of the platform modules are in other exotic IDE-s like
> JDeveloper.
>
> On 5/10/22 13:38, antonio wrote:
> > Hi,
> >
> > You're welcome! That's a way of building trust :-).
> >
> > Some of the committers around (not me, though) use NetBeans as a
> > platform for building applications, or to build plugins, so it's
> > always a good idea to ask in the mailing list when suggesting an API
> > change.
> >
> > Kind regards,
> > Antonio
> >
> > El 10/5/22 a las 22:17, Łukasz Bownik escribió:
> >> Thank You for explaining the process and reasoning behind it.
> >> It is also good to know the community's attitude towards backward
> >> compatibility.
> >>
> >> I'll close the current PRs and try to spoon feed changes while
> >> optimising
> >> for "diff-readability" until we build some trust.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.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.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: API change

[Laszlo Kishalmi]

Also some of the platform modules are in other exotic IDE-s like JDeveloper.

On 5/10/22 13:38, antonio wrote:

Hi,

You're welcome! That's a way of building trust :-).

Some of the committers around (not me, though) use NetBeans as a 
platform for building applications, or to build plugins, so it's 
always a good idea to ask in the mailing list when suggesting an API 
change.


Kind regards,
Antonio

El 10/5/22 a las 22:17, Łukasz Bownik escribió:

Thank You for explaining the process and reasoning behind it.
It is also good to know the community's attitude towards backward
compatibility.

I'll close the current PRs and try to spoon feed changes while 
optimising

for "diff-readability" until we build some trust.


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

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

Re: API change

[antonio]

Hi,

You're welcome! That's a way of building trust :-).

Some of the committers around (not me, though) use NetBeans as a 
platform for building applications, or to build plugins, so it's always 
a good idea to ask in the mailing list when suggesting an API change.


Kind regards,
Antonio

El 10/5/22 a las 22:17, Łukasz Bownik escribió:

Thank You for explaining the process and reasoning behind it.
It is also good to know the community's attitude towards backward
compatibility.

I'll close the current PRs and try to spoon feed changes while optimising
for "diff-readability" until we build some trust.


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

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

Re: API change

[Łukasz Bownik]

Thank You for explaining the process and reasoning behind it.
It is also good to know the community's attitude towards backward
compatibility.

I'll close the current PRs and try to spoon feed changes while optimising
for "diff-readability" until we build some trust.

On Mon, May 9, 2022 at 11:09 PM antonio  wrote:

> Hi,
>
> Some comments below.
>
> El 9/5/22 a las 22:17, Łukasz Bownik escribió:
> > So I suspect that the probability of any *external client *calling this
> > method is 0.
>
> As we have explained in some other threads, NetBeans is both an IDE and
> a platform. We want to be as much backwards compatible as possible.
>
> Even though you suspect "the probability of any external client calling
> this method is zero" (which IMHO is a bold statement coming from a
> newbie) and want to remove a method from an API, we still want to be
> backwards compatible.
>
> For making API changes I think the method is as follows [1]:
>
> 1. Newbies should discuss in the mailing list why they want to change an
> API, telling us if it is because "they suspect" the code is used "with
> zero probability", or because they've investigated the usage of the API
> in other ten NetBeans applications, or any other reasoning. If the
> change to the API affects a module that is heavily used (such as this
> one) then be ready to reason your change proposal with sound arguments.
>
> 2. Methods that are to be removed must add the @Deprecated annotation
> and won't be removed immediately, there's a grace period for API clients
> to have time to prepare for the change. Of course, deprecated methods
> should work _exactly_ the same as before the change.
>
> 3. API changes have to be documented in the `apichanges.xml` file [2].
>
> 4. API changes must bump the "specification version" in the module's
> manifest.mf file [3].
>
> 5. API changes have to update the ".sig" signature file [4] with the new
> signature.
>
> Hope this helps,
> Antonio
>
>
> [1]
> Read this full thread in the mailing list archive for some other tips on
> changing a NetBeans API.
>
> [2]
>
> https://github.com/apache/netbeans/blob/master/platform/openide.util/apichanges.xml
>
> [3]
>
> https://github.com/apache/netbeans/blob/ddcd57d016b1e801b6a7fba973ae9889d108b1f3/platform/openide.util/manifest.mf#L4
>
> [4]
>
> https://github.com/apache/netbeans/blob/ddcd57d016b1e801b6a7fba973ae9889d108b1f3/platform/openide.util/nbproject/org-openide-util.sig
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

-- 
Łukasz Bownik

Re: API change

[Svata Dedic]

Dne 09. 05. 22 v 22:17 Łukasz Bownik napsal(a):


The problem is that another method of this class
*public String processPattern(String newPattern) throws
IllegalArgumentException*
becomes useless now.

I think it should be removed.



In general no API can be *ever* removed once published in a NetBeans 
release. While there's no client of this in the Apache codebase, the 
openide-util is also published as a maven artifact and can be consumed 
by anyone anywhere.



My reasoning is the following (based on original implementation)

(not disputing the reasons at all)


But.. If we want to keep this API structure unchanged then I could provide
a stubbed implementation like

@deprecated 
public String processPattern(String newPattern) throws
IllegalArgumentException {
return newPattern;
}

would it be acceptable?
I don't think so - if the client is expecting some semantics of the 


A (potential) client might expect existing semantic of the return value, 
even de-facto one (since @return is not javadoc-ed); we should not break 
that "contract". The method can be removed in the next release version 
(/x after the codename) of the openide.util - if it ever reaches a next 
release version at all.


Actually removing a method from the API can be done in a binary 
backwards-compatible way; but it would be an overkill in this case, IMHO.


Make the method deprecated, javadoc-explain why, and cut out everything 
except construction of the return value. Let's add it to all our old 
past sins.


-S.

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

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

RE: [RELEASES] 14 remaining issues

[Eric Barboni]

Hi,

Thanks to tester we found a regression and a fix is inbound.

There is a remaing issue 😝 (mine 😃) that seems not happening on linux. If 
someone can test on windows it would be nice otherwise this could be postponed 
to version 15
https://github.com/apache/netbeans/issues/4084

Best Regards
Eric
-Message d'origine-
De : Eric Barboni <> 
Envoyé : jeudi 5 mai 2022 11:11
À : dev@netbeans.apache.org
Objet : RE: [RELEASES] 14- RC3 preparation

Hi,
 I will generate the RC3 after the #4047 get green (more or less). 

RC3 contains the 2 unmerged PR of RC2. I reapply Martin Entlicher work using a 
PR I created with diff file from PR 4004. Hope is good enough.

As netbeans parent was release I will regenerate the RELEASE140 staging to be 
able to test artefacts.

Best Regards

Eric

-Message d'origine-
De : Michael Bien <>
Envoyé : mardi 3 mai 2022 18:50
À : dev@netbeans.apache.org; Eric Barboni  Objet : Re: 
[RELEASES] Issue on delivery merge

On 03.05.22 18:28, Michael Bien wrote:
>
> or:
>
> I (or anybody else) could also simply create another PR, from the 
> original PR branch and we could just review + press merge again?

here a draft:

https://github.com/apache/netbeans/pull/4070

-michael

>
>
> whatever you prefer - don't know what the others think.
>
> best regards,
>
> michael
>
>
>>
>> Eric
>>
>> -Message d'origine-
>> De : Neil C Smith <>
>> Envoyé : lundi 2 mai 2022 18:45
>> À : dev@netbeans.apache.org
>> Objet : Re: [RELEASES] Issue on delivery merge
>>
>> On Mon, 2 May 2022 at 17:11, Matthias Bläsing 
>>  wrote:
>>> ebarboni force-pushed the delivery branch from 74e1e5f to 217f7df 4 
>>> days ago (2022-04-28 13:58 CEST)
>> ..
>>> - get a list of all closed PRs on github with a change date in the 
>>> last 4-5 days
>> Also, a reversed way which correlates is to use 
>> https://github.com/apache/netbeans/commit/74e1e5f91c48df7a06154781bcf
>> 17da397a589a8
>>
>> and follow the parent links - only those two PRs have a warning that 
>> the commit isn't in delivery.
>>
>> Neil
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
>> For additional commands, e-mail: dev-h...@netbeans.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.apache.org
>> For additional commands, e-mail: dev-h...@netbeans.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.apache.org
For additional commands, e-mail: dev-h...@netbeans.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.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

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