Re: Time to branch for the release candidate?

[Emilian Bold]

>  I think we should be able to release from master without branching.

Having release branches is quite useful if only because we can do per-release 
fixes while master/ has diverged / refactored that whole area.

--emi

‐‐‐ Original Message ‐‐‐

On 26 April 2018 5:08 PM, Wade Chandler  wrote:

> +1 and even if we don’t have a “dev” branch, I think we should be able to 
> release from master without branching. We should be working to stabilize 
> things near a release, and perhaps we ask folks not to merge new features to 
> master, but only fixes for a period of time. If we could support feature 
> flags, then even better, and for new modules and such I think we can through 
> configuration and clusters, to not have them enabled and included by default, 
> but not with big new features to existing modules. We would need new switches 
> in the config file for those. Then new work can be enabled or disabled for a 
> release depending on how far along it is.
> 
> Either way, I feel master should always build, run, and be as stable as 
> possible. Now, in this interim phase where we are still trying to get over to 
> Apache all that is NB, it may be harder or nearly impossible since it is so 
> much to bring over, but I think that should be our goal going forward once 
> the “drop” has happened.
> 
> My $0.02,
> 
> Wade
> 
> 
> 
> 
> Wade Chandler
> 
> e: cons...@wadechandler.com
> 
> t: @wadechandler
> 
> https://www.linkedin.com/in/wade-chandler
> 
> > On Apr 17, 2018, at 10:09 AM, Christian Lenz christian.l...@gmx.net wrote:
> > 
> > Master shouldn’t be that one, where the wild development is going on. 
> > Master should be that one which is already live.
> > 
> > In General, what gitflow does. Wild development is going on on the dev 
> > branch, for the next release. If whatever is finished, there is a release 
> > branch. After that, it will merged into master and created a tag.
> > 
> > If this is not possible, then an other solution is that develop stays clean 
> > and always releasable. You only work on Feature branches. After the Feature 
> > is finished and ready to go, it will merged into develop. Someday you can 
> > create a release branch of develop.
> 
> --
> 
> 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: NetBeans cash bounties

[Emilian Bold]

Not sure what JIRA APIs there are.

I'll try something simpler (static) first... when I find some time.

--emi

‐‐‐ Original Message ‐‐‐

On 24 April 2018 3:02 AM, John Muczynski  wrote:

> Hmm... can you connect it into JIRA?
> 
> 
> Johnny Muczynski
> 
> 734-262-2045
> 
> On Mon, Apr 23, 2018 at 2:44 PM Emilian Bold emilian.b...@protonmail.ch
> 
> wrote:
> 
> > Bought nbbounty.org today.
> > 
> > Let's see if I find a way to put it to good use.
> > 
> > --emi
> > 
> > ‐‐‐ Original Message ‐‐‐
> > 
> > On 16 April 2018 10:18 AM, Jaroslav Tulach jaroslav.tul...@gmail.com
> > 
> > wrote:
> > 
> > > Hi.
> > > 
> > > We always wanted to do bounties and we even had a domain for that -
> > > 
> > > nbbounty.org - however corporations like Sun or Oracle were never
> > > 
> > > supportive of such practices. Looks like Apache isn't in favor of that
> > > 
> > > either, but at least it is not going to stop such effort. As such I am
> > > 
> > > still hoping...
> > > 
> > > Bounties can help the quality of the product. There were thousands of
> > > 
> > > bugs
> > > 
> > > in the NetBeans Bugzilla, but only few of them really annoying. Giving
> > > 
> > > users a chance to select the important ones by spending few pennies or
> > > 
> > > cents would really help the development team to focus on the stuff that
> > > 
> > > matters.
> > > 
> > > Please, help the NetBeans Bounty program happen!
> > > 
> > > -jt
> > > 
> > > 2018-04-14 19:30 GMT+02:00 William L. Thomson Jr. wlt...@o-sinc.com:
> > > 
> > > > On Sat, 14 Apr 2018 03:23:42 -0400
> > > > 
> > > > Emilian Bold emilian.b...@protonmail.ch wrote:
> > > > 
> > > > > That's a very 'global' view, William.
> > > > > 
> > > > > The whole idea though is to improve the project in some areas I find
> > > > > 
> > > > > of need. Because I don't have the time or desire to do that myself.
> > > > 
> > > > Sure I understand, and agree with your idea.
> > > > 
> > > > > I don't believe my tiny bounty will change the course of the whole
> > > > > 
> > > > > project.
> > > > 
> > > > It likely would not. But it could encourage others to offer bounties
> > > > 
> > > > and it could snowball from there. It is a good idea after all. Thus it
> > > > 
> > > > likely would grow and spread.
> > > > 
> > > > > Also, it's not about security, it's normal user stuff, mostly UI
> > > > > 
> > > > > related.
> > > > 
> > > > My concerns were never security related. Just conflicting directions
> > > > 
> > > > that lead to debates, forks, loss of contributors and general issues
> > > > 
> > > > for
> > > 
> > > > the project resulting from different directions.
> > > > 
> > > > > Ubuntu had a cool project: 100 paper cuts. "Papercuts are trivial to
> > > > > 
> > > > > fix, but annoying bugs." So, I'm thinking along the same lines: stuff
> > > > > 
> > > > > that doesn't take lot of time to fix, but that would really help the
> > > > > 
> > > > > workflow.
> > > > 
> > > > Sure I agree, and like you see with Ubuntu and others, the idea being a
> > > > 
> > > > good one is spreading :)
> > > > 
> > > > > I see there's really no way to handle this. I'll just try something
> > > > > 
> > > > > at some point and see how it goes.
> > > > 
> > > > I surely was not trying to shoot down your idea, discourage, make
> > > > 
> > > > difficult, or pee in your cornflakes
> > > > 
> > > > I just had the idea before for like monthly news articles, and such.
> > > > 
> > > > I feel it is an idea that can benefit many projects in many small ways.
> > > > 
> > > > Leading to big things. Thousands of paper cuts :)
> > > > 
> > > > I think the future will see FOSS moving to funded models for
> > > > 
> > > > development via small bounties and the like. You see that now in a
> > > > 
> > > > manner with GSoC, and other stuff like FreeBSD Foundation activities.
> > > > 
> > > > --
> > > > 
> > > > William L. Thomson Jr.
> > 
> > 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: The IDE for DevOps was: IntelliJ IDEA vs Netbeans

[Jesse Glick]

On Mon, Apr 23, 2018 at 2:14 AM, Jaroslav Tulach
 wrote:
> there should be no Maven index processing on the
> client (by default). There should be a webservice the IDE would query
> instead.

This just begs the question of which web service that would be. If you
only use Maven Central, fine, but if you are using custom or even
private/firewalled repositories, this will not fly.

Not to say that the current Nexus index system is ideal—in fact Nexus
3 seems to have dropped this feature, at least so far, so you have to
stay on Nexus 2. (Or, ironically, Artifactory.)

*Probably* the current indexer functionality could be replaced by REST
calls to your artifact manager. But there is no standard API for that,
as far as I know, so there would need to be separately maintained
Nexus and Artifactory modules.

One relatively easy target for optimization, however: stop relying on
the indexer to service queries about available versions of a given
artifact (i.e., find GAVs when GA is known). That is a common
operation: for example, completion on `` in a POM, or the
hint about an old ``. This can be done quite simply and
portably by downloading `maven-metadata.xml` from the repository. In
fact Maven itself downloads this automatically at various times, and
caches it in the local repository; and the accuracy of even the cached
version is generally better than that of a Nexus index: Maven
refreshes the cache once per day or when passed `-U` or when running
`mvn install`.

-
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: AW: The IDE for DevOps was: IntelliJ IDEA vs Netbeans

[Tim Boudreau]

On Fri, Apr 27, 2018 at 1:56 AM Jaroslav Tulach 
wrote:

> Tim,
> its 21th century and we are using GitHub. If you want to contribute, please
> do it via PR.
> Thanks.


As I said, when I have the tests passing I'll do that.

-Tim



> -jt
>
>
> 2018-04-25 13:31 GMT+02:00 Tim Boudreau :
>
> > To follow up on this a bit, since I spent a bit of time attempting to
> > optimize this - the two big performance wins are:
> >
> >  1. Cache a byte[] and reuse it for every JAR entry (pass in a lambda to
> > read() rather than get out a Map)
> >  2. Maven's DefaultScanner will pass the indexer *every single file* in
> the
> > repository it's indexing, while NetBeans is likely uninterested in .sha1
> > files and similar;  filtering the list of files to things NetBeans is
> > likely to be interested offers large benefits
> >
> > These two optimizations cut scanning time of my ~/.m2/repository dir
> (~2700
> > JAR files) from 42304ms to 30100ms, which is a 29% performance
> improvement
> > with
> >
> > That said, I have some tests to get passing before this is patch-worthy,
> so
> > we'll see if those results hold up.
> >
> > Of course, this only helps local indexing - whatever "Unpacking indexes"
> is
> > doing with remote repositories won't be helped by this.
> >
> > Still, it seems like something that could be optimized quite a bit before
> > giving up on it.  If anyone's interested in poking at this:
> > https://timboudreau.com/files/maven-indexer.diff
> >
> > -Tim
> >
>
-- 
http://timboudreau.com

NetBeans Day UK and podcast idea

[Geertjan Wielenga]

Hi all,

I had a great time at Apache NetBeans Day in London today.

Again enthusiasm from people who somehow ‘get’ what NetBeans is about.

Take a look on Twitter, search for NetBeans.

It occurred to me how cool it would be to have short user driven podcasts
around NetBeans to try to provide a space to let people share their
enthusiasm

Maybe James Gosling as the first guest, for example.

Thanks all, especially Ovi and Mark for today. And John for coming from
Dublin and Enrico from near Venice.

Gj

Re: JUnit 5 Support

[John McDonnell]

After a conversation with Geertjan at NetBeans Day UK earlier today, I have
migrated these requirements into a more formal document:
https://cwiki.apache.org/confluence/display/NETBEANS/Feature+Request+-+JUnit+5+Outline

Please feel free to add requirements to this and we can start working on
introducing this to NetBeans 9, maybe with some features even making a
NetBeans 9.0 release :)

Regards

John

On 25 April 2018 at 08:35, John McDonnell  wrote:

>
>
> On 2017/05/17 17:50:30, Marc Philipp  wrote:
> > Hi Emi,
> >
> > JUnit 5 introduces a new architecture: It supports running multiple
> engines (i.e. testing frameworks) on a common platform. JUnit Vintage is an
> engine implementation that makes it possible to run JUnit 3 and 4 tests on
> the new platform. JUnit Jupiter is comprised of an API to write tests and
> an engine implementation to execute them on the platform.
> >
> > The platform provides an API (the Launcher API) for IDEs and build tools
> to execute tests using any engine that’s available at runtime. For example,
> an IDE would tell the the Launcher to execute a Java class. It does not
> necessarily have to know anything about the testing framework this test
> class was written for. The platform is open for any testing framework that
> runs on the JVM, not just for JUnit projects. Thus, we’d like to see
> Netbeans support the new platform instead of providing custom support for
> JUnit 4. Please refer to the documentation for an example of how to use the
> Launcher API: http://junit.org/junit5/docs/current/user-guide/#
> launcher-api
> >
> > We can’t spare any resources at the moment but would be happy to provide
> guidance, feedback on the implementation etc.
> >
> > Thanks,
> > Marc
> >
> >
> > On 17. May 2017, 16:43 +0200, Emilian Bold ,
> wrote:
> > > Hello Marc,
> > >
> > > I've read that with "JUnit Vintage" one can still run Junit 3 and 4
> tests.
> > > Presumably IDE support will work for those out of the box?
> > >
> > > So the problem is only for tests specifically written for JUnit 5? Do
> you
> > > have any statistics of the JUnit 5 adoption within the dev community?
> > >
> > > I remember there was a license conflict with NetBeans under the
> previous
> > > license and we couldn't ship JUnit.
> > >
> > > Now I see that the Junit Eclipse Public License (EPL 1.0) is compatible
> > > with Apache ( https://www.apache.org/legal/resolved.html#category-b )
> so
> > > it's nice that we will ship it again after switching to the ASF.
> > >
> > > Just having you here on the mailing list and available is a good step.
> > > Various other ways JUnit could help, but it depends on the kind of
> > > resources you can spare and who will take up the Junit5 task.
> > >
> > >
> > >
> > > --emi
> > >
> > > On Wed, May 17, 2017 at 5:19 PM, Marc Philipp 
> wrote:
> > >
> > > > Hi all,
> > > >
> > > > I’m a member of the JUnit team. We’re currently working on a major
> new
> > > > version: JUnit 5. It will require work by IDEs to support test
> execution
> > > > and reporting within the IDE. IntelliJ IDEA and Eclipse (on a branch)
> > > > already support the new JUnit Platform and the new Jupiter API to
> write
> > > > tests.
> > > >
> > > > Are there any plans to add JUnit 5 support to Netbeans? If so, how
> can we
> > > > help?
> > > >
> > > > Thanks,
> > > > Marc
> > > >
> > > >
> > > >
> >
> Hi,
>
> Resurrecting an ancient thread here, but I recently went to a DubJug event
> and we walked through migrating code from JUnit 4 to 5, and last week when
> I had some downtime I migrated some work related stuff as well.  So I find
> myself starting to use JUnit 5 more and more and want to see what support
> we need to get into Netbeans.
>
> I've started to compile a sort of requirements list and would like some
> input into area's I'm missing.  Note I only work with Maven based projects,
> so knowledge of ant based projects I would need help with (will need to
> also read up on how JUnit 5 handles ant as well)
>
> Maven Based Projects:
> Create/Update Tests dialog to automatically pick JUint 5.x when Java
> version is 8+
>  + Auto generate correct code for JUnit 5
>  Test File & Debug Test File Actions work
> Run/Debug Focused actions to handle new annotations/custom (tagged)
> annotations
>
> Test Results window to support JUnit 5 features like:
>  + Parameterized Tests
>  + Display Names
>
> Unit Test Template for JUnit 5.x
> Don't change JUint 4 Support, i.e. Don't use Vintage Engine
> Include Library for JUnit 5  (Tools -> Library -> JUnit 5.x) to include
> the following dependencies :
>  + org.junit.platform:junit-platform-launcher:1.1.1:jar
>  + org.junit.jupiter:junit-jupiter-engine:5.1.1:jar
>  + org.junit.jupiter:junit-jupiter-api:5.1.1:jar
>  + org.junit.jupiter:junit-jupiter-params:5.1.1:jar
>
> Any areas of the IDE that I'm missing?
>
>
> John
>
> 

Re: AW: The IDE for DevOps was: IntelliJ IDEA vs Netbeans

[Jaroslav Tulach]

Tim,
its 21th century and we are using GitHub. If you want to contribute, please
do it via PR.
Thanks.
-jt


2018-04-25 13:31 GMT+02:00 Tim Boudreau :

> To follow up on this a bit, since I spent a bit of time attempting to
> optimize this - the two big performance wins are:
>
>  1. Cache a byte[] and reuse it for every JAR entry (pass in a lambda to
> read() rather than get out a Map)
>  2. Maven's DefaultScanner will pass the indexer *every single file* in the
> repository it's indexing, while NetBeans is likely uninterested in .sha1
> files and similar;  filtering the list of files to things NetBeans is
> likely to be interested offers large benefits
>
> These two optimizations cut scanning time of my ~/.m2/repository dir (~2700
> JAR files) from 42304ms to 30100ms, which is a 29% performance improvement
> with
>
> That said, I have some tests to get passing before this is patch-worthy, so
> we'll see if those results hold up.
>
> Of course, this only helps local indexing - whatever "Unpacking indexes" is
> doing with remote repositories won't be helped by this.
>
> Still, it seems like something that could be optimized quite a bit before
> giving up on it.  If anyone's interested in poking at this:
> https://timboudreau.com/files/maven-indexer.diff
>
> -Tim
>

Re: which build?

[Jaroslav Tulach]

I've updated description of the -linux and -windows ones. Their primary
usage is for testing. Up to Jan Lahoda to update the description of the
release job.
-jt


2018-04-26 15:18 GMT+02:00 Glenn Holmer :

> What's the difference between the builds from incubator-netbeans-linux
> and those from incubator-netbeans-release?
>
> --
> Glenn Holmer (Linux registered user #16682)
> "After the vintage season came the aftermath -- and Cenbe."
>
> -
> 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: Time to branch for the release candidate?

[John McDonnell]

@Laszlo, Have you made it public?

It's not loading for me, even when I'm logged in.


Regards


John

On 27 April 2018 at 04:20, Laszlo Kishalmi 
wrote:

> Well, I've got the rights to share my dashboard.
>
> It's called: NetBeans Overview
>
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12332552
>
>
> On 04/26/2018 03:53 PM, Laszlo Kishalmi wrote:
>
>> I went though the open issues with PR-s list.
>>
>> I've marked 17 issues resolved due to it's PR merged, and added some
>> flags for 9.0 as well.
>>
>> Right now in JIRA we have 27 open issues with PR and 9 of them are marked
>> for 9.0 release.
>>
>> We still have 31 open PRs.
>>
>> As of 9.0: We have 40 issues open (I've marked the 3 blocker ones, that
>> pointed out by Geertjan)
>>
>> 3 blocker
>>
>> 6 critical
>>
>> 25 major
>>
>> 5 minor
>>
>> 1 trivial
>>
>> 9 of these has PR-s
>>
>>
>> Just one note: Our most voted/watched issue is supporting JUnit 5
>>
>>
>> On 04/26/2018 10:56 AM, Laszlo Kishalmi wrote:
>>
>>> Well,
>>>
>>> I'm trying to collect the remaining things to do for 9.0 release for a
>>> week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0 in
>>> numbers are the following (none may be accurate, though):
>>>
>>> We have 31 open PR-s in GitHub (not necessary 9.0 related)
>>>
>>> We have 44 open issues with PR-s.
>>>
>>> We have 32 open issues marked for 9.0
>>>
>>> We also have 5 open issues with PR-s for 9.0
>>>
>>> The issues and PRs are not really aligned.
>>>
>>> Well this does not necessarily means that we should not branch for
>>> release. I just would like to say, we probably need to be more focused on
>>> what we are doing.
>>>
>>> I could promise to go over the open issues and the PR-s and close those
>>> which have merged PRs-.
>>>
>>> Also I feel the number of open PRs is quite high, though it might really
>>> mean that changes that we do not want to include into 9.0 are piling up
>>> (indicates the need of the release branch).
>>>
>>> Also those 5 issues with PR-s might just go into master in the following
>>> days and we could make the release branch after that.
>>>
>>> So If I would vote for release branch now it would be 0/-1 right now as
>>> we (or maybe just me) can't really see clearly on 9.0.
>>>
>>>
>>>
>>> On 04/17/2018 05:52 AM, Neil C Smith wrote:
>>>
 On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
 wrote:

 Yeah, there are changes in the queue for the master branch that could be
> too destabilizing. To avoid something like that to negatively
> influence the
> 9.0 release, I'd suggest to create a branch release/9.0 and put only
> the
> safe fixes ready for 9.0 there. The wild development would continue in
> the
> master branch.
>
> +1 to branching and that.  Longer term perhaps a more gitflow-like
 system
 where PR's come into a develop branch too?

   A question, though - I assume this will branch off master now, not
 from
 the beta tag?  Given that in NetCAT we were testing the beta, I assume
 there is nothing you'd consider "too destabilizing"  between then and
 now?

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