Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

[Gili T.]

I humbly disagree. Last time I played with Swing layouts I remember them
being able to do responsive UIs even better than HTML.

The only thing that web does better is more existing layouts out of the
box.  That's just a matter of people not technology.

Gili

On Sat, Mar 17, 2018, 07:39  wrote:

> Fully agree, and Swing and JavaFX stopped development before the concept
> of "responsive UIs" became popular. So they have nothing for that.
>
> I agree that layout via css used to be painful and hard to understand
> sometimes, but Flow and especially Grid Layout has completely solved this
> for me.
>
> --Toni
>
>
> -Ursprüngliche Nachricht-
> Von: Neil C Smith 
> Gesendet: Samstag, 17. März 2018 11:06
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Usability study was: Think Java, not Electron! was: Apache
> HTML/Java UI
>
> On Sat, 17 Mar 2018, 07:34 Dmitry Avtonomov, 
> wrote:
>
> > ​All I'm saying is that with the last N years of unprecedented
> > attention the web technologies have leaped light years ahead of
> > everything else in terms of basic UI.
> > ...
> > All I need is a good framework on top of swing that would help me out
> > with those things. In JS there's probably 100s.
> >
>
> You could probably manage all the validation and error display
> requirements you mention with HTML5's built in form validation without
> adding any JS at all.
>
> As someone working heavily with both Swing and HTML/CSS I find the idea
> that Swing's layouts are better quite amusing, or I would if I didn't have
> to fight with them so often! ;-) Mig is about the only one I use from code,
> Matisse is good but I find its output counterintuitive sometimes.
>
> Best wishes,
>
> Neil
>
> > --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>
>
> -
> 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 9.0 is very unstable with lombok in JDK 9

[Gili T.]

Josh,

Try JDK 9 specifically.

The fact that they use bytecode injection makes their library very
unstable.

Gili

On Sat, Mar 10, 2018, 11:59 Josh Juneau  wrote:

> I will chime in to mention that I utilize Lombok with NetBeans 8.2 and it
> works most of the time.  There are some annoyances that I've noticed, but
> it is most certainly due to the fact that Lombok is a compile-time
> process...not a library, as mentioned in a previous thread.  Typically if I
> change my Maven POM file at all, I need to clean my project, deleting
> "target", and recompile twice...a priming compile to download the Lombok
> dependency and then another to compile.  Sometimes I need to change my
> Lombok dependency between 1.16.16 and 1.16.18 to force a re-download of the
> Lombok dependency.  Annoying...but not really NetBeans' fault and I still
> prefer the cleaner code that does not become cluttered with getters and
> setters.
>
> I'll test with JDK 8 and Apache NetBeans 9 to see how it works, although I
> know it is not part of the NetCAT official testing.
>
> Josh Juneau
> juneau...@gmail.com
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
>
> On Fri, Mar 9, 2018 at 5:57 PM, Christian Lenz 
> wrote:
>
> > I have to use lombok in our Company, so it works ok but is not that
> > Feature rich unfortunately. I can’t refactor the getter and setter, when
> I
> > added @Getter and @Setter and Change the private variable. There is an
> > Option while refactoring: „Refactor getter and setter too“. But it seems
> > not working.
> >
> > Find usages of the private fields (where the getter and setter created)
> is
> > not working, it will not search for the getter and setter, it searches
> for
> > the private fields. But IntelliJ can resolve this part, which is very
> > Handy. Go to declaration on a getter or setter getId() which was
> generated
> > from private long id, is also not working.
> >
> > I use lombok with NetBeans 8.2. I know that this is not the right thread,
> > I only wanted to mention it. Will create tickets for this „Problem“.
> >
> > Didn’t test it with NB 9
> >
> >
> > Cheers
> >
> > Chris
> >
> > Von: William L. Thomson Jr.
> > Gesendet: Samstag, 10. März 2018 00:22
> > Cc: dev@netbeans.incubator.apache.org
> > Betreff: Re: Netbeans 9.0 is very unstable with lombok in JDK 9
> >
> > On Fri, 9 Mar 2018 19:44:08 -0300
> > Victor Williams Stafusa da Silva  wrote:
> > >
> > > So, what you are telling me seems to be more-or-less a great
> > > misunderstanding.
> >
> > Mostly for others, that miss I am building everything from source. I
> > care more about compile time than runtime dependencies. I am making
> > jars, not using others. Quite many things have different runtime
> > dependencies than compile time. Which is why I run into many issues
> > others do not.
> >
> > Like this one for Netbeans
> > https://github.com/apache/incubator-netbeans/pull/392
> >
> > > We could use the case of byte-buddy to persuade
> > > lombok guys to better modularize it by actually seeing some valor in
> > > doing so, since now, lombok (or at least part of it) would be a
> > > library afterall and not just some weird part of the compiler
> > > toolchain.
> >
> > They have their own dependency issues to address. Almost a year old I
> > have zero hope for movement there.
> > https://github.com/rzwitserloot/lombok.patcher/issues/2
> >
> > Not to mention new compile time ones that show up in patch versions...
> > https://github.com/rzwitserloot/lombok/issues/1437
> >
> > If you read that, they make illogical excuses on why they cannot
> > properly version releases of Lombok. They get upset when you give them
> > some details on what your doing so they can understand.
> >
> > Really broken down best by the points in this comment.
> >
> https://github.com/rzwitserloot/lombok/issues/1437#issuecomment-339757312
> >
> > > However, by opening up a ticket at their github to say
> > > that you have some trouble compiling it and that "*I have filed a bug
> > > with byte-buddy-dep, requesting they stop using lombok. It is really
> > > the worst Java package I have ever come across.*" you immediatelly
> > > thrown away any hope to get some collaboration out of those guys and
> > > also failed to explain them what was the real issue you were trying
> > > to solve.
> >
> > I do not make such statements lightly and it was not my first
> > interaction with them. The amount of open issues, etc Make the entire
> > project clearly a mess.
> >
> > 21 issues related to Netbeans
> >
> https://github.com/rzwitserloot/lombok/issues?utf8=%E2%9C%93=is%3Aissue+
> > is%3Aopen+netbeans
> >
> > My first experience with it was saying it was a terrible package and
> > one of the maintainers commented a fix.
> > https://github.com/Obsidian-StudiosInc/os-xtoo/commit/
> > dc0aa4cfc834ac598810a7db59ddcac5a8a0dbfc#commitcomment-22235501
> >
> > Before I went to 

Re: Users first (was Re: Pull requests need to be reviewed)

[Gili T.]

It seems to me that maybe you need to document your desired coding style
and perhaps ask people to break PRs into smaller pieces but beyond that I
see nothing wrong with someone reducing the number of compiler warnings in
a PR and nothing else.

Code hygine is a necessary part of software development. To pretend you can
wish it away rarely leads to positive outcomes for end-users.

Gili

On Sat, Jan 13, 2018, 05:51 Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> OK, here it is: https://github.com/apache/incubator-netbeans/pull/361
>
> Looking forward to your review,
>
> Gj
>
> On Sat, Jan 13, 2018 at 11:47 AM, Gili T. <cow...@bbs.darktech.org> wrote:
> > I guess I'll be the odd man out: the bigger the project the more relevant
> > cosmetic fixes are in my opinion. Why? Because in the 10+ years I've used
> > NetBean, bug fixes were more important to me than new features. Cosmetic
> > fixes tend to reduce the bug count at the cost of new features and I'm
> > certainly in favor of that at the moment.
> >
> > Gili
> >
> > On Sat, Jan 13, 2018, 02:35 Antonio <anto...@vieiro.net> wrote:
> >
> >> Hi,
> >>
> >> My 2 cents: I agree with Geertjan: I think we should concentrate our
> >> efforts in the best NetBeans 9 we can build for users. There're many
> >> important things to do, ranging from the website to the jdk-javac
> >> branch. And many new tools to control, ranging from the wiki to the very
> >> slow JIRA issue tracker.
> >>
> >> I think we should stay focused in those things that worry users, for the
> >> benefit of the users, and leave those code-cosmetic, internal changes
> >> for later on. After all NetBeans users deserve the best IDE we can
> >> build, and it does not really matter to them if we're improving the
> >> readability of ternary operators or if we're replacing for loops with
> >> the Streaming API.
> >>
> >> NetBeans is the second Apache project by size (as per [1]), with more
> >> than 5.5M lines of code. Making those millions of lines of code more
> >> readable & pretty may be a perfect academic case study, but spending our
> >> efforts on those areas won't make our users more happy.
> >>
> >> Cheers,
> >> Antonio
> >>
> >> [1]
> >> Apache in 2017 - By The Digits
> >> https://blogs.apache.org/foundation/entry/apache-in-2017-by-the
> >>
> >> On 12/01/18 11:54, Geertjan Wielenga wrote:
> >> > On Friday, January 12, 2018, Christian Lenz <christian.l...@gmx.net>
> >> wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> first, in my opinion each PR is welcome, why not cosmetic stuff too?
> >> There
> >> >> is always a need to refactor code to make it more readable,
> maintainable
> >> >> and sometimes or more often it makes stuff faster. So why not
> accepting
> >> >> everything?
> >> >
> >> >
> >> >
> >> > The concern is that we could end up with hundreds of PRs that are
> nothing
> >> > more than small tweaks for no clear reason, drowning out PRs such as
> >> yours
> >> > that provide new meaningful features.
> >> >
> >> > We do need to discuss this, probably in a new thread, but I’d suggest
> >> each
> >> > PR needs to start off with a new issue describing exactly what the
> >> problem
> >> > is, with the proposed solution, followed by some discussion, after
> which
> >> a
> >> > PR is made. Refactoring for the sake of refactoring, without any
> planning
> >> > or motivation, could lead to chaos.
> >> >
> >> > Gj
> >> >
> >> >
> >> >
> >> >>
> >> >> Yes I think we need guidelines too. Like „when do we need Tests“,
> „how a
> >> >> commit should look like“, etc. and we need more branches. I mean atm
> we
> >> >> have develop, master and some feature branches?
> >> >>
> >> >> So develop should be the next release. Until a specific point, we
> need a
> >> >> relase branch like release/nb9 maybe for Alpha/beta and or rc state.
> So
> >> we
> >> >> have a fixed state where we can fix bugs and stuff but no new
> features.
> >> New
> >> >> features until beta or rc, should be done in feature branches and
> merged
> >> >> into develop, where this is NB9.1 or whatever.
&g

Re: Users first (was Re: Pull requests need to be reviewed)

[Gili T.]

I guess I'll be the odd man out: the bigger the project the more relevant
cosmetic fixes are in my opinion. Why? Because in the 10+ years I've used
NetBean, bug fixes were more important to me than new features. Cosmetic
fixes tend to reduce the bug count at the cost of new features and I'm
certainly in favor of that at the moment.

Gili

On Sat, Jan 13, 2018, 02:35 Antonio  wrote:

> Hi,
>
> My 2 cents: I agree with Geertjan: I think we should concentrate our
> efforts in the best NetBeans 9 we can build for users. There're many
> important things to do, ranging from the website to the jdk-javac
> branch. And many new tools to control, ranging from the wiki to the very
> slow JIRA issue tracker.
>
> I think we should stay focused in those things that worry users, for the
> benefit of the users, and leave those code-cosmetic, internal changes
> for later on. After all NetBeans users deserve the best IDE we can
> build, and it does not really matter to them if we're improving the
> readability of ternary operators or if we're replacing for loops with
> the Streaming API.
>
> NetBeans is the second Apache project by size (as per [1]), with more
> than 5.5M lines of code. Making those millions of lines of code more
> readable & pretty may be a perfect academic case study, but spending our
> efforts on those areas won't make our users more happy.
>
> Cheers,
> Antonio
>
> [1]
> Apache in 2017 - By The Digits
> https://blogs.apache.org/foundation/entry/apache-in-2017-by-the
>
> On 12/01/18 11:54, Geertjan Wielenga wrote:
> > On Friday, January 12, 2018, Christian Lenz 
> wrote:
> >
> >> Hi,
> >>
> >> first, in my opinion each PR is welcome, why not cosmetic stuff too?
> There
> >> is always a need to refactor code to make it more readable, maintainable
> >> and sometimes or more often it makes stuff faster. So why not accepting
> >> everything?
> >
> >
> >
> > The concern is that we could end up with hundreds of PRs that are nothing
> > more than small tweaks for no clear reason, drowning out PRs such as
> yours
> > that provide new meaningful features.
> >
> > We do need to discuss this, probably in a new thread, but I’d suggest
> each
> > PR needs to start off with a new issue describing exactly what the
> problem
> > is, with the proposed solution, followed by some discussion, after which
> a
> > PR is made. Refactoring for the sake of refactoring, without any planning
> > or motivation, could lead to chaos.
> >
> > Gj
> >
> >
> >
> >>
> >> Yes I think we need guidelines too. Like „when do we need Tests“, „how a
> >> commit should look like“, etc. and we need more branches. I mean atm we
> >> have develop, master and some feature branches?
> >>
> >> So develop should be the next release. Until a specific point, we need a
> >> relase branch like release/nb9 maybe for Alpha/beta and or rc state. So
> we
> >> have a fixed state where we can fix bugs and stuff but no new features.
> New
> >> features until beta or rc, should be done in feature branches and merged
> >> into develop, where this is NB9.1 or whatever.
> >>
> >> Than there will be no discussion about whether we can handle or we have
> >> time for „luxury“ stuff or not. Each PR, which is not a bug fix and
> >> important for the next release, is done inside the dev state when we
> have a
> >> release branch.
> >>
> >>
> >> Cheers
> >>
> >> Chris
> >>
> >>
> >> Von: Neil C Smith
> >> Gesendet: Freitag, 12. Januar 2018 10:02
> >> An: dev@netbeans.incubator.apache.org
> >> Betreff: Re: Pull requests need to be reviewed
> >>
> >> On Fri, 12 Jan 2018 at 08:04 Geertjan Wielenga <
> >> geertjan.wiele...@googlemail.com> wrote:
> >>
> >>> I think we need to set up guidelines — e.g., a PR must be connected to
> an
> >>> issue; a PR must solve a problem and not be cosmetic only; etc.
> >>>
> >>> I’d advise looking at pull/3 by Chris instead.
> >>>
> >>
> >> I like Chris' PR, and see the benefit of it ... but, within those
> >> guidelines are we going to have the concept of feature freeze?  In my
> >> opinion, if we're in beta vote phase, we should also only be accepting
> bug
> >> fixes.  In which case, I'd be tempted to push that back to the next
> point
> >> release?
> >>
> >> Out of interest, what were the old NetBeans policies around feature
> >> freezing / release planning?
> >>
> >> Best wishes,
> >>
> >> Neil
> >>
> >>
> >>
> >> --
> >> Neil C Smith
> >> Artist & Technologist
> >> www.neilcsmith.net
> >>
> >> Praxis LIVE - hybrid visual IDE for creative coding -
> www.praxislive.org
> >>
> >>
> >
>
> -
> 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: [VOTE] Release Apache NetBeans 9.0 Beta (incubating) rc1

[Gili T.]

Who gets to vote?
What determines when the final release is made?

My concern is that I've seen many regressions relative to 8.2 and very few
new features (jdk9 support being the major feature that I am aware of). I
want to ensure that the vast majority of regressions are fixed prior to a
release.

Gili

On Wed, Jan 10, 2018, 18:14 Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> Hi all,
>
> Please vote on releasing Apache NetBeans 9.0 Beta (incubating) rc1! If
> this voting passes, another similar voting will be started on
> gene...@incubator.apache.org, and if that passes too, then we can
> release this version.
>
> Apache NetBeans 9.0 Beta (incubating) constitutes all the modules in
> the Apache NetBeans Git repo, which together provide the NetBeans
> Platform (i.e., the underlying application framework), which was
> released as Apache NetBeans 9.0 Alpha (incubating), as well as all the
> modules that provide the Java SE-related features of Apache NetBeans.
> In short, Apache NetBeans 9.0 Beta (incubating) is a full IDE for Java
> SE development.
>
> Build artifacts available here:
>
>
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-beta/
>
> The artifact to be voted on:
>
>
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-beta/incubating-netbeans-java-9.0-beta-source.zip
>
> Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and NOTICE
> files, as well as a README file with build instructions, which are the
> same as these:
>
> https://github.com/apache/incubator-netbeans/blob/master/README.md
>
> MD5: 4b7df9b329bf17e3b05419eebfa066aa
> SHA1: cdf486afbfdad7719c2c0308d78e10562a55422e
>
> Apache NetBeans Git Repo tag: 9.0-beta-rc1
>
> Rat report shows no unknown licenses:
>
>
> https://builds.apache.org/job/incubator-netbeans-release/lastSuccessfulBuild/artifact/rat-java-temp/nbbuild/build/rat-report.txt
>
> Included as a convenience is a binary, unzip it and run it and you'll
> see Apache NetBeans:
>
>
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-beta/incubating-netbeans-java-9.0-beta-bin.zip
>
> MD5: 8e450ab47bc204fdf17463621f3448bc
> SHA1: d64038153c52264ac12f8206aa58e2c76dc3446c
>
> Notable changes:
>
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+9.0+Beta
>
> Please try out the package and vote!
>
> The vote is open for a minimum of 72 hours or until the necessary
> number of votes (3 binding +1s) is reached.
>
> [ ] +1 Release this package as Apache NetBeans 9.0 Beta (incubating)
> [ ] 0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
>
> Please add "(binding)" if your vote is binding, i.e., you are an
> Apache NetBeans committer, i.e., your name is on this page:
> https://wiki.apache.org/incubator/NetBeansProposal, although note the
> only real binding votes in the incubator are those of the IPMC, i.e.,
> in the next vote thread, after this one passes.
>
> Geertjan
> on behalf of the Apache NetBeans team
>
> -
> 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
>
>
>
>