ApacheCon Montreal

[Kenneth Fogel]

I just received a notice of an Apache Con that will occur in Montreal at the 
end of September. I thought I might submit a talk on NetBeans. I could use 
suggestions about what I should put in my presentation such as what’s amazing 
about NetBeans 9.  The CFP closes March 30.

Ken Fogel

Re: Support of Java 10

[Kai Uwe Pel]

AWESOME !

Cheers,
Kai


On 3/14/2018 1:00 AM, Geertjan Wielenga wrote:

Excellent!

JDK 10, welcome to NetBeans IDE. :-)

Gj

On Tue, Mar 13, 2018 at 8:31 PM, Jan Lahoda  wrote:


FYI, the JDK 10 support (branch jdk18_3) has been merged to master.

Many thanks to all that contributed to the effort in some form: Dusan
Balek, Reema Taneja, Vikas Prabhakar, Geertjan, etc.

Jan


On Tue, Mar 13, 2018 at 10:48 AM, Neil C Smith 
wrote:


On Tue, 13 Mar 2018 at 02:09 Wade Chandler 
wrote:


-1 as well. The LTS versions live longer, and the processes between the
orgs will be different. They are also just different orgs. I don't

think

it

makes sense to try to align versioning. It was essentially marketing
between Oracle's Java and it's IDE, which made sense considering that,

but

isn't the case any longer. It also means we will jump major versions

just

for the Java support when NB is so much more than that.


Good points!  Yes, agree it was mainly marketing, although also about

what

level of Java was officially supported?

My original question elsewhere was whether we were consciously deciding

to

decouple versions or just letting it happen.  Quite happy with either,
actually, and I'd probably prefer a better semantic versioning strategy
anyway.

Of course, we need to be sure we don't disregard all marketing now in
Apache.  Something for discussion elsewhere might be how / whether this

is

communicated - you know someone will ask why we're releasing NetBeans 9
just as Java 10 is out?! ;-)

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: Think Java, not Electron! was: Apache HTML/Java UI instead of

[Zoran Sevarac]

Hi Jaroslav,

Can I do the following using HTML4J:
1. Build a frontend that will work in NetBeans Platform App and web app
without modifications?
2. Reuse stuff (wizards) based on Wizard API in web app?

If I can do that techicaly my next question is how. Thats when I'll need
some sample/tutorial.
I'm building a NB Platform based app at the moment, and it would be great
for me to have web version of it too, without much work.

Comunicate specific use cases and high level problems that you're solving,
that will get you the followers.

Cheers


On Tue, Mar 13, 2018 at 1:39 PM, Christian Lenz 
wrote:

> Hey Jaroslav and all others,
>
> thx for your explanation. I think you didn’t get everything wrong, maybe
> more promotion but this is PR part 😉. There are big players out there. And
> why I love electron? Because it is fucking HTML, CSS and JS AND for the
> Backend too. This eco system was build for fullstack developers, who wants
> to create desktop applications with HTML/CSS/JS still in the background.
>
> You know my example NbScratchFile, this is I think one of the best
> solution to promote a plugin for NetBeans, which was written in HTML,
> SCSS/CSS, TS/JS with a Framework called Knockout, a buildsystem with
> webpack and a communication with Java in the backend. Why I’ve chosen it?
> Because I wanted to write a plugin for NetBeans but w/o swing. The Mantisse
> editor is cool but far away from perfect, I created a ticket for a big
> problem to align checkboxes with labels pixel perfect, inside the Editor:
> https://netbeans.org/bugzilla/show_bug.cgi?id=257519
>
> Why I’m not writing the controls in Java? Sry but no, we have Qt, we have
> WPF (C# with XAML) and we have WYSIWYG editors to create UIs quick and fast
> and sometimes dirty. In HTML I don’t need such editor. It is my daily
> business, I have chrome with the powerful and best DevTools ever to see my
> progress immediately and I’m fast w/o having an editor.
>
> So I decided to give DukeScript and the archetype a try, but there are
> some problems with the project type:
>
> 1. It is still not fast while bootstrapping the UI when you call your UI
> inside a component, we talked about that, that there Needs an improvement
> that this bootstrapping has to be done while IDE start or wherever. As soon
> as possible. Of course my plugin has the same problem and I have to change
> it and it is not the problem of DukeScript but there needs to be done
> sooner. Sometimes it seems that the DukeScript stuff was a prototype to
> say: hey look this can be done with HTML AND Java, but it feels unfinished.
> 2. The Project is so coupled with each other, I can’t use the HTML5
> project features of NetBeans for that. It is still maven or Java with a
> piece of HTML inside. I can’t use the tasks for a HTML5 project, because it
> is not a HTML5 project. I can’t install npm, I can’t use scss etc from the
> IDE. This is why I created it by my own. You can see everything here:
> https://github.com/Chris2011/NbScratchFile/tree/master/src/main. I
> created a HTML5 project and copied the dist folder (Built with webpack, the
> outcome) over to the maven project to open the project again separately to
> build my UI, indepedent from the maven stuff. This should be a possible
> template to creating a HTML UI with the backend Java to creating a NetBeans
> plugin. Because everything is decoupled. It has the build process within
> the plugin for the UI and build process for the Java backend.
> 3. The WebView, which renders the UI, is, AFAIK not WebKit. Why WebKit?
> Because of the DevTools of Chrome. That tools are the best I’ve ever seen
> and yes, I can say I have seen a lot in my career. I started with IE, they
> were good, in the first 2000s. I worked with FF with the beloved Firebug, I
> switched to Chrome, because the DevTools are awesome. Sure the FF tools are
> also great, I tested them too, but I missed a lot of features there.
> Anyway, for that WebView, that HTML4J uses, I  can only add firebug lite,
> which is pretty old, obsoleted, dead, etc. So for this, we need a better
> solution.
> 4. I had some trouble with the magic generated code, that HTML4J creates
> in the background for i.e. knockout (I don’t have any control about that).
> I split some classes to decouple my logic and the build breaks because of
> the magic that happens in the background. Sure I had to create tickets for
> that, but I was frustrated, that I tried to create my own UI with WebView
> from the JavaFX to call it and bind the ViewModel from JS to Java and vice
> versa, as you already know, maybe Jaroslav.
> 5. Again, I’m still a frontend developer, fullstack now, because I have to
> use Spring and Java, but anyway. I love JS and TS, I don’t know which
> limitations other means, but don’t compare GWT or Vaading with JS or TS.
> Yes, you have limitations with GWT (I also worked with that), but those
> limitations are coming from GWT and you can extend that, but that has
> nothing todo with JS. 

Re: Problem with Java Help

[Zoran Sevarac]

Thanks Jarda. Good to hear that there is solution on horizon, hopefully
some time soon.
Does this also means that Apache NetBeans IDE will come without help system
by default for now?

On Tue, Mar 13, 2018 at 3:57 PM, Jaroslav Tulach 
wrote:

> Hello Zoran,
> JavaHelp is currently missing from standard NetBeans distribution as it is
> GPLv2withCPex licensed and Apache and GPL doesn't go well along. You need
> to put it into (boot)classpath somehow for now.
> -jt
>
> PS: There is a guy in Oracle working on relicensing JavaHelp to something
> easier to use from Apache code. Hard to estimate the delivery time,
> however...
>
> 2018-03-13 12:35 GMT+01:00 Zoran Sevarac :
>
> > Hi,
> >
> > Did anybody experienced/solved problem with module with Java help?
> > I'm getting the following Class not found exception for Java help when
> > building my NB platform app:
> >
> > An annotation processor threw an uncaught exception.
> > Consult the following stack trace for details.
> > java.lang.NoClassDefFoundError: com/sun/java/help/search/Indexer
> > at
> > org.netbeans.modules.javahelp.HelpSetRegistrationProcessor.
> handleProcess(
> > HelpSetRegistrationProcessor.java:145)
> > at
> > org.openide.filesystems.annotations.LayerGeneratingProcessor.process(
> > LayerGeneratingProcessor.java:99)
> > at com.sun.tools.javac
> >
> > Cheers
> > Zoran
> >
>



-- 
Zoran Sevarac, PhD, Assistant Professor
Department of Software Engineering
University of Belgrade, Faculty of Organisational Sciences

Neuroph  founder | Java Champion
 | NetBeans
Dream Team 
Homepage: http://www.zoransevarac.com

Re: Support of Java 10

[Geertjan Wielenga]

Excellent!

JDK 10, welcome to NetBeans IDE. :-)

Gj

On Tue, Mar 13, 2018 at 8:31 PM, Jan Lahoda  wrote:

> FYI, the JDK 10 support (branch jdk18_3) has been merged to master.
>
> Many thanks to all that contributed to the effort in some form: Dusan
> Balek, Reema Taneja, Vikas Prabhakar, Geertjan, etc.
>
> Jan
>
>
> On Tue, Mar 13, 2018 at 10:48 AM, Neil C Smith 
> wrote:
>
> > On Tue, 13 Mar 2018 at 02:09 Wade Chandler 
> > wrote:
> >
> > > -1 as well. The LTS versions live longer, and the processes between the
> > > orgs will be different. They are also just different orgs. I don't
> think
> > it
> > > makes sense to try to align versioning. It was essentially marketing
> > > between Oracle's Java and it's IDE, which made sense considering that,
> > but
> > > isn't the case any longer. It also means we will jump major versions
> just
> > > for the Java support when NB is so much more than that.
> > >
> >
> > Good points!  Yes, agree it was mainly marketing, although also about
> what
> > level of Java was officially supported?
> >
> > My original question elsewhere was whether we were consciously deciding
> to
> > decouple versions or just letting it happen.  Quite happy with either,
> > actually, and I'd probably prefer a better semantic versioning strategy
> > anyway.
> >
> > Of course, we need to be sure we don't disregard all marketing now in
> > Apache.  Something for discussion elsewhere might be how / whether this
> is
> > communicated - you know someone will ask why we're releasing NetBeans 9
> > just as Java 10 is out?! ;-)
> >
> > Best wishes,
> >
> > Neil
> > --
> > Neil C Smith
> > Artist & Technologist
> > www.neilcsmith.net
> >
> > Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
> >
>

Re: NetBeans external binaries and sha1 hash values from Maven Central

[Christian Bourque]

Hi Jan,

You're right! I started over on a fresh VM (without a local Maven
installation) and it worked this time!

I guess I have a conflict on my current installation where I use Maven for
a lot of other projects!

I'll investigate more to find the culprit...

Thanks a lot for your help!

Christian


On Tue, Mar 13, 2018 at 12:50 PM, Jan Lahoda  wrote:

> Well, doing:
>
> $ wget
> http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0.
> 201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar
> $ sha1sum org.eclipse.jgit-4.11.0.201803080745-r.jar
> 4ae44a6157e1bc4c5b373be0c274a8f1d9badd76
> org.eclipse.jgit-4.11.0.201803080745-r.jar
> $ wget -O - --quiet
> http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0.
> 201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1;
> echo
> 4ae44a6157e1bc4c5b373be0c274a8f1d9badd76
>
> Adding this to a binaries-list:
> 4AE44A6157E1BC4C5B373BE0C274A8F1D9BADD76
> org.eclipse.jgit:org.eclipse.jgit:4.11.0.201803080745-r
>
> Seems to download the file fine, and it checks against the hash.
>
> Jan
>
>
> On Tue, Mar 13, 2018 at 5:14 PM, Christian Bourque <
> christian.bour...@gmail.com> wrote:
>
> > Yes I noticed that but that's not the problem here!
> >
> > On Mar 13, 2018 11:50, "Jan Lahoda"  wrote:
> >
> > > One thing to note is that binaries-list expects the hashes to be
> > > upper-case, while the sum on the maven central is lower case. I.e.:
> > > 4AE44A6157E1BC4C5B373BE0C274A8F1D9BADD76
> > > is expected instead of:
> > > 4ae44a6157e1bc4c5b373be0c274a8f1d9badd76
> > >
> > > Jan
> > >
> > >
> > > On Tue, Mar 13, 2018 at 4:35 PM, Christian Bourque <
> > > christian.bour...@gmail.com> wrote:
> > >
> > > > Thanks Jaroslav, I'll have a look at this class and maybe I'll
> > understand
> > > > what is going on!
> > > >
> > > > On Tue, Mar 13, 2018 at 10:45 AM, Jaroslav Tulach <
> > > > jaroslav.tul...@gmail.com
> > > > > wrote:
> > > >
> > > > > Hard to say without debugging. You can find the code here:
> > > > > https://github.com/apache/incubator-netbeans/blob/
> > > > > master/nbbuild/antsrc/org/netbeans/nbbuild/extlibs/
> > > > > DownloadBinaries.java#L368
> > > > > -jt
> > > > >
> > > > >
> > > > > 2018-03-13 14:44 GMT+01:00 Christian Bourque <
> > > > christian.bour...@gmail.com
> > > > > >:
> > > > >
> > > > > > Hey guys,
> > > > > >
> > > > > > Thanks for your replies!
> > > > > >
> > > > > > But I think I wasn't clear enough in my original post: basically
> my
> > > > > > question is why is NetBeans expecting a different hash value than
> > the
> > > > one
> > > > > > found on Maven Central?
> > > > > >
> > > > > > C.
> > > > > >
> > > > > >
> > > > > > On Tue, Mar 13, 2018 at 4:29 AM, Jaroslav Tulach <
> > > > > > jaroslav.tul...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Did you built JGit from source and installed it into local
> Maven
> > > > > > > repository? Then the locally built version takes precedence
> over
> > > the
> > > > > one
> > > > > > in
> > > > > > > the Maven central and has, of course, different SHA. Adjust the
> > SHA
> > > > or
> > > > > > > delete the local copy from .m2/repository and let the build
> > > download
> > > > > the
> > > > > > > real version from Maven central.
> > > > > > >
> > > > > > > -jt
> > > > > > >
> > > > > > > PS: My experience tells me this is painful, sorry for the
> hassle.
> > > > > > >
> > > > > > >
> > > > > > > 2018-03-13 1:48 GMT+01:00 Christian Bourque <
> > > > > christian.bour...@gmail.com
> > > > > > >:
> > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > I'm currently trying to compile NetBeans 9.0 with a more
> recent
> > > > > Eclipse
> > > > > > > > JGit library (the one currently bundled with
> > > > > > > > NetBeans is 3 years old!) but I'm having a hard time with the
> > > hash
> > > > > > (sha1)
> > > > > > > > value that is used by the build system that's
> > > > > > > > downloading the artefact from the Maven Central repository!
> > When
> > > I
> > > > > > build
> > > > > > > > NetBeans it says that the hash value
> > > > > > > > that I put in the binaries-list file doesn't match the hash
> of
> > > the
> > > > > > > artefact
> > > > > > > > found on Maven Central, but I took the hash
> > > > > > > > value directly from the Maven Central repository so I
> expected
> > it
> > > > to
> > > > > be
> > > > > > > > correct:
> > > > > > > > http://central.maven.org/maven2/org/eclipse/jgit/org.
> > > > > > eclipse.jgit/4.11.0
> > > > > > > .
> > > > > > > > 201803080745-r/
> > > > > > > >
> > > > > > > > So then I decided to download the Eclipse JGit source code
> from
> > > > > GitHub:
> > > > > > > > https://github.com/eclipse/jgit/releases/tag/v4.11.0.
> > > > 201803080745-r
> > > > > > > > compile it and generate the sha1sum myself. To my surprise
> the
> > > > > computed
> > > > > > > > checksum was equal to the one expected by NetBeans during the
> > > build
> > > > > > > > process.
> > > > > > > >
> > > > > > > > So I'm a b

Re: Support of Java 10

[Jan Lahoda]

FYI, the JDK 10 support (branch jdk18_3) has been merged to master.

Many thanks to all that contributed to the effort in some form: Dusan
Balek, Reema Taneja, Vikas Prabhakar, Geertjan, etc.

Jan


On Tue, Mar 13, 2018 at 10:48 AM, Neil C Smith 
wrote:

> On Tue, 13 Mar 2018 at 02:09 Wade Chandler 
> wrote:
>
> > -1 as well. The LTS versions live longer, and the processes between the
> > orgs will be different. They are also just different orgs. I don't think
> it
> > makes sense to try to align versioning. It was essentially marketing
> > between Oracle's Java and it's IDE, which made sense considering that,
> but
> > isn't the case any longer. It also means we will jump major versions just
> > for the Java support when NB is so much more than that.
> >
>
> Good points!  Yes, agree it was mainly marketing, although also about what
> level of Java was officially supported?
>
> My original question elsewhere was whether we were consciously deciding to
> decouple versions or just letting it happen.  Quite happy with either,
> actually, and I'd probably prefer a better semantic versioning strategy
> anyway.
>
> Of course, we need to be sure we don't disregard all marketing now in
> Apache.  Something for discussion elsewhere might be how / whether this is
> communicated - you know someone will ask why we're releasing NetBeans 9
> just as Java 10 is out?! ;-)
>
> Best wishes,
>
> Neil
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>

Status of the documentation?

[Antonio]

Hi all,

AFAIK we now have:

- The old wiki DevFaq at http://netbeans.apache.org/wiki/
- The features section of the old website at 
https://github.com/apache/incubator-netbeans-website-cleanup/pull/2 
(pending Oracle IP clearance)
- The tutorials section of the old website at 
https://github.com/apache/incubator-netbeans-website-cleanup/pull/3 
(pending Oracle IP clearance)


So, are there any missing pieces of documentation we want to keep? Was 
there a user manual in DocBook format somewhere? How is the "JavaHelp" 
source stored? Also in docbook format?


Please speak up regarding documentation!!

Thanks,
Antonio

-
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

website:tutorials section

[Antonio]

Hi all,

I've submitted PR#3 against incubator-netbeans-website-cleanup [1].

This one contains an automatic conversion from the "kb/docs" section of 
the previous website, transformed to asciidoc format.


Again this requires IP clearance approval from Oracle before entering an 
Apache repository. Of course this will require later manual 
review/fine-tuning, as this is an automated conversion.


Results can be seen in github at [2] (see *.asciidoc files).

Kind regards,
Antonio

[1]
https://github.com/apache/incubator-netbeans-website-cleanup/pull/3

[2]
https://github.com/vieiro/incubator-netbeans-website-cleanup/tree/asciidoc-tutorials/website-html-to-asciidoc/build/tutorials-asciidoc

Some examples:
https://github.com/vieiro/incubator-netbeans-website-cleanup/blob/asciidoc-tutorials/website-html-to-asciidoc/build/tutorials-asciidoc/cnd/beginning-jni-linux.asciidoc

https://github.com/vieiro/incubator-netbeans-website-cleanup/blob/asciidoc-tutorials/website-html-to-asciidoc/build/tutorials-asciidoc/java/annotations-custom.asciidoc


-
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: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Glenn Holmer]

On 03/13/2018 12:13 AM, cowwoc wrote:
> Web-based development is cool because everyone is jumping on board. It
> isn't cool because it's better. Every week there is a new framework. The
> level of cross-platform compatibility doesn't begin to compare to Java.
> You have portability problems across different browsers on the same
> operating system, not to mention different operating systems.

Very well said, totally agree.

-- 
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: NetBeans external binaries and sha1 hash values from Maven Central

[Jan Lahoda]

Well, doing:

$ wget
http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0.201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar
$ sha1sum org.eclipse.jgit-4.11.0.201803080745-r.jar
4ae44a6157e1bc4c5b373be0c274a8f1d9badd76
org.eclipse.jgit-4.11.0.201803080745-r.jar
$ wget -O - --quiet
http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0.201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1;
echo
4ae44a6157e1bc4c5b373be0c274a8f1d9badd76

Adding this to a binaries-list:
4AE44A6157E1BC4C5B373BE0C274A8F1D9BADD76
org.eclipse.jgit:org.eclipse.jgit:4.11.0.201803080745-r

Seems to download the file fine, and it checks against the hash.

Jan


On Tue, Mar 13, 2018 at 5:14 PM, Christian Bourque <
christian.bour...@gmail.com> wrote:

> Yes I noticed that but that's not the problem here!
>
> On Mar 13, 2018 11:50, "Jan Lahoda"  wrote:
>
> > One thing to note is that binaries-list expects the hashes to be
> > upper-case, while the sum on the maven central is lower case. I.e.:
> > 4AE44A6157E1BC4C5B373BE0C274A8F1D9BADD76
> > is expected instead of:
> > 4ae44a6157e1bc4c5b373be0c274a8f1d9badd76
> >
> > Jan
> >
> >
> > On Tue, Mar 13, 2018 at 4:35 PM, Christian Bourque <
> > christian.bour...@gmail.com> wrote:
> >
> > > Thanks Jaroslav, I'll have a look at this class and maybe I'll
> understand
> > > what is going on!
> > >
> > > On Tue, Mar 13, 2018 at 10:45 AM, Jaroslav Tulach <
> > > jaroslav.tul...@gmail.com
> > > > wrote:
> > >
> > > > Hard to say without debugging. You can find the code here:
> > > > https://github.com/apache/incubator-netbeans/blob/
> > > > master/nbbuild/antsrc/org/netbeans/nbbuild/extlibs/
> > > > DownloadBinaries.java#L368
> > > > -jt
> > > >
> > > >
> > > > 2018-03-13 14:44 GMT+01:00 Christian Bourque <
> > > christian.bour...@gmail.com
> > > > >:
> > > >
> > > > > Hey guys,
> > > > >
> > > > > Thanks for your replies!
> > > > >
> > > > > But I think I wasn't clear enough in my original post: basically my
> > > > > question is why is NetBeans expecting a different hash value than
> the
> > > one
> > > > > found on Maven Central?
> > > > >
> > > > > C.
> > > > >
> > > > >
> > > > > On Tue, Mar 13, 2018 at 4:29 AM, Jaroslav Tulach <
> > > > > jaroslav.tul...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Did you built JGit from source and installed it into local Maven
> > > > > > repository? Then the locally built version takes precedence over
> > the
> > > > one
> > > > > in
> > > > > > the Maven central and has, of course, different SHA. Adjust the
> SHA
> > > or
> > > > > > delete the local copy from .m2/repository and let the build
> > download
> > > > the
> > > > > > real version from Maven central.
> > > > > >
> > > > > > -jt
> > > > > >
> > > > > > PS: My experience tells me this is painful, sorry for the hassle.
> > > > > >
> > > > > >
> > > > > > 2018-03-13 1:48 GMT+01:00 Christian Bourque <
> > > > christian.bour...@gmail.com
> > > > > >:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I'm currently trying to compile NetBeans 9.0 with a more recent
> > > > Eclipse
> > > > > > > JGit library (the one currently bundled with
> > > > > > > NetBeans is 3 years old!) but I'm having a hard time with the
> > hash
> > > > > (sha1)
> > > > > > > value that is used by the build system that's
> > > > > > > downloading the artefact from the Maven Central repository!
> When
> > I
> > > > > build
> > > > > > > NetBeans it says that the hash value
> > > > > > > that I put in the binaries-list file doesn't match the hash of
> > the
> > > > > > artefact
> > > > > > > found on Maven Central, but I took the hash
> > > > > > > value directly from the Maven Central repository so I expected
> it
> > > to
> > > > be
> > > > > > > correct:
> > > > > > > http://central.maven.org/maven2/org/eclipse/jgit/org.
> > > > > eclipse.jgit/4.11.0
> > > > > > .
> > > > > > > 201803080745-r/
> > > > > > >
> > > > > > > So then I decided to download the Eclipse JGit source code from
> > > > GitHub:
> > > > > > > https://github.com/eclipse/jgit/releases/tag/v4.11.0.
> > > 201803080745-r
> > > > > > > compile it and generate the sha1sum myself. To my surprise the
> > > > computed
> > > > > > > checksum was equal to the one expected by NetBeans during the
> > build
> > > > > > > process.
> > > > > > >
> > > > > > > So I'm a bit puzzled! If the build script is downloading an
> > > external
> > > > > > > dependency from Maven Central then the hash should
> > > > > > > match the one found in this file:
> > > > > > > http://central.maven.org/maven2/org/eclipse/jgit/org.
> > > > > eclipse.jgit/4.11.0
> > > > > > .
> > > > > > > 201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1
> > > > > > >
> > > > > > > Anyway, if anyone could shed some light on this situation I
> would
> > > > > really
> > > > > > > appreciate it!
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Christian
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: My Personal UI Rant, Was: Think Java, not Electron! was: Apache HTML/Java UI instead of

[Chuck Davis]

Scott, thanks for saying it so well.  I absolutely loathe and despise
trying to get any real work done with a browser interface.

On Tue, Mar 13, 2018 at 8:06 AM, Scott Palmer  wrote:

> Sometimes I think the world has gone crazy.
>
> Here are a few simple observations:
>  - JavaFX is the best UI tech that Java has going for it these days.
>  - Swing/AWT has been heading towards obsolescence for several years now.
> It works, but the future of desktop UI with Java is JavaFX.
>  - HTML is a HORRIBLE way to render an application.  It works very poorly,
> if at all, and not consistently across browsers. (Look what people have to
> go through to try to get something as simple as a table with scrolling data
> and static column headers, for example.)
>  - Javascript is junk.  The interesting thing about stuff like Electron is
> that they managed to get it to work at all.  We give it extra credit simply
> because it was done with technologies that make it so much harder to do.
> (It also tends to be slow IMO.) That’s cute and all, but ultimately wasted
> time.  It would be that much better and cheaper to develop if done with
> better tech like Java/JavaFX.
> - The popularity of Web UIs has done a disservice to the development
> community.  They have lowered the bar so far that we accept the utter
> rubbish and awful user experience of most web apps as ‘normal’.  We have a
> generation of developers that don’t even understand why Javascript is
> garbage or how crippled applications are that run in a browser. Have you
> noticed when you see an interesting web app that you are more impressed
> because it is a web app?  If it were a desktop app you wouldn’t give it a
> second thought.
> - I don’t know why anyone would want to bring HTML UI into a Java
> application (when they don’t have to) as it is such a massive step
> backwards.
>
>
> So stopping running around like the sky is falling.  Swing/AWT, JavaFX
> aren’t going to disappear.  Oracle wasn’t doing anything significant with
> Swing.  If they stop, we aren’t likely to notice.  JavaFX is the greater
> concern, because it is the better tech and still needs feature
> development.  The community around it can keep it going as long as there is
> a consistent vision for it  Ideas of using HTML for UI on a desktop app
> programmed in Java are ridiculously insane. We already have a much better
> cross-platform UI technology, no need to put work in to move backwards to
> an inferior UI tech.
>
> Scott
>
>
> -
> 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 external binaries and sha1 hash values from Maven Central

[Christian Bourque]

Hi Antonio,

Well you asked me for 2 things:

1) The artifact that I'm trying to download from the Maven repository (and
this information was indeed in my original post)!

2) The hash value (and I told you that I didn't have the information with
me because I wasn't at home but that I was going to send it tonight)!

I'm sorry if I misunderstood you...

Christian

On Mar 13, 2018 11:57, "Antonio"  wrote:

> Hi Christian,
>
> [1] has SHA-1 [2]:
> 4ae44a6157e1bc4c5b373be0c274a8f1d9badd76
> (I've confirmed this downloading from Maven central myself).
>
> Note that there exists a SHA-1 sum for the ".asc.jar" file [3], which is:
> 828a2a1d1ef47aa69beb86104d8cc68300db0da8. Of course you want the _jar_
> file, not the _.asc.jar_ file
>
> In your original post:
>
> 1. You do not state the SHA-1 sum you're using that should be
> 4ae44a6157e1bc4c5b373be0c274a8f1d9badd76
>
> 2. You do not include your binaries-list file, that should contain a
> single like like this:
>
> 4AE44A6157E1BC4C5B373BE0C274A8F1D9BADD76 org.eclipse.jgit:org.eclipse.j
> git:4.11.0.201803080745-r
>
> Again make sure that the jar files in your $HOME/.m2/repository/org/eclip
> se/jgit/org.eclipse.jgit/4.11.0.201803080745-r/  have not been generated
> by any source builds of yours, as stated in other emails.
>
> If after all those steps the thing keeps failing then please file a bug
> report, including the binaries-list you're using.
>
> Kind regards,
> Antonio
>
>
> [1]
> http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse
> .jgit/4.11.0.201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar
>
> [2]
> http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse
> .jgit/4.11.0.201803080745-r/org.eclipse.jgit-4.11.0.
> 201803080745-r.jar.sha1
>
> [3]
> http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse
> .jgit/4.11.0.201803080745-r/org.eclipse.jgit-4.11.0.
> 201803080745-r.jar.asc.sha1
>
>
> On 13/03/18 16:33, Christian Bourque wrote:
>
>> Hi Antonio,
>>
>> All the information about the artifact is already in my original post...
>>
>> I'm not at home at the moment so I don't have the hash with me but I'll
>> send it tonight!
>>
>> Thanks
>>
>> Christian
>>
>>
>> On Tue, Mar 13, 2018 at 10:39 AM, Antonio  wrote:
>>
>> Hi Christian,
>>>
>>> Please state:
>>>
>>> - The artifact you are trying to download from Maven Central.
>>> - The "hash value" that NetBeans is expecting (if you've modified the
>>> binaries-list let us know the contents).
>>>
>>> Thanks,
>>> Antonio
>>>
>>>
>>> On 13/03/18 14:44, Christian Bourque wrote:
>>>
>>> Hey guys,

 Thanks for your replies!

 But I think I wasn't clear enough in my original post: basically my
 question is why is NetBeans expecting a different hash value than the
 one
 found on Maven Central?

 C.


 On Tue, Mar 13, 2018 at 4:29 AM, Jaroslav Tulach <
 jaroslav.tul...@gmail.com>
 wrote:

 Did you built JGit from source and installed it into local Maven

> repository? Then the locally built version takes precedence over the
> one
> in
> the Maven central and has, of course, different SHA. Adjust the SHA or
> delete the local copy from .m2/repository and let the build download
> the
> real version from Maven central.
>
> -jt
>
> PS: My experience tells me this is painful, sorry for the hassle.
>
>
> 2018-03-13 1:48 GMT+01:00 Christian Bourque <
> christian.bour...@gmail.com
>
>> :
>>
>
> Hi all,
>
>>
>> I'm currently trying to compile NetBeans 9.0 with a more recent
>> Eclipse
>> JGit library (the one currently bundled with
>> NetBeans is 3 years old!) but I'm having a hard time with the hash
>> (sha1)
>> value that is used by the build system that's
>> downloading the artefact from the Maven Central repository! When I
>> build
>> NetBeans it says that the hash value
>> that I put in the binaries-list file doesn't match the hash of the
>>
>> artefact
>
> found on Maven Central, but I took the hash
>> value directly from the Maven Central repository so I expected it to
>> be
>> correct:
>> http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse
>> .jgit/4.11.0
>>
>> .
>
> 201803080745-r/
>>
>> So then I decided to download the Eclipse JGit source code from
>> GitHub:
>> https://github.com/eclipse/jgit/releases/tag/v4.11.0.201803080745-r
>> compile it and generate the sha1sum myself. To my surprise the
>> computed
>> checksum was equal to the one expected by NetBeans during the build
>> process.
>>
>> So I'm a bit puzzled! If the build script is downloading an external
>> dependency from Maven Central then the hash should
>> match the one found in this file:
>> http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse
>> .jgit/4.11.0
>>
>> .
>
> 201803080745-r/org.eclipse.

Re: NetBeans external binaries and sha1 hash values from Maven Central

[Christian Bourque]

Yes I noticed that but that's not the problem here!

On Mar 13, 2018 11:50, "Jan Lahoda"  wrote:

> One thing to note is that binaries-list expects the hashes to be
> upper-case, while the sum on the maven central is lower case. I.e.:
> 4AE44A6157E1BC4C5B373BE0C274A8F1D9BADD76
> is expected instead of:
> 4ae44a6157e1bc4c5b373be0c274a8f1d9badd76
>
> Jan
>
>
> On Tue, Mar 13, 2018 at 4:35 PM, Christian Bourque <
> christian.bour...@gmail.com> wrote:
>
> > Thanks Jaroslav, I'll have a look at this class and maybe I'll understand
> > what is going on!
> >
> > On Tue, Mar 13, 2018 at 10:45 AM, Jaroslav Tulach <
> > jaroslav.tul...@gmail.com
> > > wrote:
> >
> > > Hard to say without debugging. You can find the code here:
> > > https://github.com/apache/incubator-netbeans/blob/
> > > master/nbbuild/antsrc/org/netbeans/nbbuild/extlibs/
> > > DownloadBinaries.java#L368
> > > -jt
> > >
> > >
> > > 2018-03-13 14:44 GMT+01:00 Christian Bourque <
> > christian.bour...@gmail.com
> > > >:
> > >
> > > > Hey guys,
> > > >
> > > > Thanks for your replies!
> > > >
> > > > But I think I wasn't clear enough in my original post: basically my
> > > > question is why is NetBeans expecting a different hash value than the
> > one
> > > > found on Maven Central?
> > > >
> > > > C.
> > > >
> > > >
> > > > On Tue, Mar 13, 2018 at 4:29 AM, Jaroslav Tulach <
> > > > jaroslav.tul...@gmail.com>
> > > > wrote:
> > > >
> > > > > Did you built JGit from source and installed it into local Maven
> > > > > repository? Then the locally built version takes precedence over
> the
> > > one
> > > > in
> > > > > the Maven central and has, of course, different SHA. Adjust the SHA
> > or
> > > > > delete the local copy from .m2/repository and let the build
> download
> > > the
> > > > > real version from Maven central.
> > > > >
> > > > > -jt
> > > > >
> > > > > PS: My experience tells me this is painful, sorry for the hassle.
> > > > >
> > > > >
> > > > > 2018-03-13 1:48 GMT+01:00 Christian Bourque <
> > > christian.bour...@gmail.com
> > > > >:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I'm currently trying to compile NetBeans 9.0 with a more recent
> > > Eclipse
> > > > > > JGit library (the one currently bundled with
> > > > > > NetBeans is 3 years old!) but I'm having a hard time with the
> hash
> > > > (sha1)
> > > > > > value that is used by the build system that's
> > > > > > downloading the artefact from the Maven Central repository! When
> I
> > > > build
> > > > > > NetBeans it says that the hash value
> > > > > > that I put in the binaries-list file doesn't match the hash of
> the
> > > > > artefact
> > > > > > found on Maven Central, but I took the hash
> > > > > > value directly from the Maven Central repository so I expected it
> > to
> > > be
> > > > > > correct:
> > > > > > http://central.maven.org/maven2/org/eclipse/jgit/org.
> > > > eclipse.jgit/4.11.0
> > > > > .
> > > > > > 201803080745-r/
> > > > > >
> > > > > > So then I decided to download the Eclipse JGit source code from
> > > GitHub:
> > > > > > https://github.com/eclipse/jgit/releases/tag/v4.11.0.
> > 201803080745-r
> > > > > > compile it and generate the sha1sum myself. To my surprise the
> > > computed
> > > > > > checksum was equal to the one expected by NetBeans during the
> build
> > > > > > process.
> > > > > >
> > > > > > So I'm a bit puzzled! If the build script is downloading an
> > external
> > > > > > dependency from Maven Central then the hash should
> > > > > > match the one found in this file:
> > > > > > http://central.maven.org/maven2/org/eclipse/jgit/org.
> > > > eclipse.jgit/4.11.0
> > > > > .
> > > > > > 201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1
> > > > > >
> > > > > > Anyway, if anyone could shed some light on this situation I would
> > > > really
> > > > > > appreciate it!
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Christian
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Wade Chandler]

> On Mar 13, 2018, at 3:04 AM,  
>  wrote:
> 
> Hi Wade,
> 
> I agree, desktop isn't going away. At DukeScript we're using HTML4J Apis 
> mainly for desktop applications. The Java Desktop Application is just using a 
> HTML5-Component ("browser") to render the view instead of a native or Java 
> rendering pipeline. 

How are events handled then? If you want to open a file as an example? Are you 
running the JVM as a separate service backend and using web services?

> 
> Since the separation of view and view logic is very clean the view technology 
> can be completely replaced. In some of our commercial projects we used 
> Controls4J to render the view, in others plain HTML and CSS. I've got working 
> prototypes that use native controls instead on iOS and Android. Even one that 
> renders to JavaFX that I sometimes use for debugging. 

That sounds pretty cool.

> 
> And unlike Swing or JavaFX browsers are evolving at great speed and getter 
> better day by day without any investment on our side. That's a great benefit 
> if you compare that to the sluggish development of Swing and JavaFX that 
> we've seen in the past years.  
> 

Perhaps, but I think one has to bind a product to a specific and embeddable 
browser for something like NB and NB RCP, or perhaps some custom Webkit. 
Relying on just anything seems like a lot to support at that level.

I figure if views themselves can be replaced, then technically we could have 
our own native views instead. We could do some things based on OpenGL or Vulkan 
https://www.khronos.org/vulkan/  or stay 
low-level yet remain in Java with LWJGL https://www.lwjgl.org 
, and not have any browser limitations. Here’s an 
example of an OpenGL based UI library https://github.com/wjakob/nanogui 

> I think that the stuff that Sean does with the crippled JavaFX 3D API is 
> amazing, but think about what he could do with a really good 3D API, like the 
> many that exist for WebGL. 
> 

I’ll let him speak more to this, but per his talks he tried different browser 
based 3D APIs, and the performance wasn’t there yet. Personally, I have seen a 
lot of WebGL components get the sad face uh oh in Chrome, and not be that 
stable; this on good hardware.

Wade

Re: NetBeans external binaries and sha1 hash values from Maven Central

[Antonio]

Hi Christian,

[1] has SHA-1 [2]:
4ae44a6157e1bc4c5b373be0c274a8f1d9badd76
(I've confirmed this downloading from Maven central myself).

Note that there exists a SHA-1 sum for the ".asc.jar" file [3], which 
is: 828a2a1d1ef47aa69beb86104d8cc68300db0da8. Of course you want the 
_jar_ file, not the _.asc.jar_ file


In your original post:

1. You do not state the SHA-1 sum you're using that should be 
4ae44a6157e1bc4c5b373be0c274a8f1d9badd76


2. You do not include your binaries-list file, that should contain a 
single like like this:


4AE44A6157E1BC4C5B373BE0C274A8F1D9BADD76 
org.eclipse.jgit:org.eclipse.jgit:4.11.0.201803080745-r


Again make sure that the jar files in your 
$HOME/.m2/repository/org/eclipse/jgit/org.eclipse.jgit/4.11.0.201803080745-r/ 
 have not been generated by any source builds of yours, as stated in 
other emails.


If after all those steps the thing keeps failing then please file a bug 
report, including the binaries-list you're using.


Kind regards,
Antonio


[1]
http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0.201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar

[2]
http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0.201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1

[3]
http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0.201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.asc.sha1


On 13/03/18 16:33, Christian Bourque wrote:

Hi Antonio,

All the information about the artifact is already in my original post...

I'm not at home at the moment so I don't have the hash with me but I'll
send it tonight!

Thanks

Christian


On Tue, Mar 13, 2018 at 10:39 AM, Antonio  wrote:


Hi Christian,

Please state:

- The artifact you are trying to download from Maven Central.
- The "hash value" that NetBeans is expecting (if you've modified the
binaries-list let us know the contents).

Thanks,
Antonio


On 13/03/18 14:44, Christian Bourque wrote:


Hey guys,

Thanks for your replies!

But I think I wasn't clear enough in my original post: basically my
question is why is NetBeans expecting a different hash value than the one
found on Maven Central?

C.


On Tue, Mar 13, 2018 at 4:29 AM, Jaroslav Tulach <
jaroslav.tul...@gmail.com>
wrote:

Did you built JGit from source and installed it into local Maven

repository? Then the locally built version takes precedence over the one
in
the Maven central and has, of course, different SHA. Adjust the SHA or
delete the local copy from .m2/repository and let the build download the
real version from Maven central.

-jt

PS: My experience tells me this is painful, sorry for the hassle.


2018-03-13 1:48 GMT+01:00 Christian Bourque 
:


Hi all,


I'm currently trying to compile NetBeans 9.0 with a more recent Eclipse
JGit library (the one currently bundled with
NetBeans is 3 years old!) but I'm having a hard time with the hash
(sha1)
value that is used by the build system that's
downloading the artefact from the Maven Central repository! When I build
NetBeans it says that the hash value
that I put in the binaries-list file doesn't match the hash of the


artefact


found on Maven Central, but I took the hash
value directly from the Maven Central repository so I expected it to be
correct:
http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse
.jgit/4.11.0


.


201803080745-r/

So then I decided to download the Eclipse JGit source code from GitHub:
https://github.com/eclipse/jgit/releases/tag/v4.11.0.201803080745-r
compile it and generate the sha1sum myself. To my surprise the computed
checksum was equal to the one expected by NetBeans during the build
process.

So I'm a bit puzzled! If the build script is downloading an external
dependency from Maven Central then the hash should
match the one found in this file:
http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse
.jgit/4.11.0


.


201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1

Anyway, if anyone could shed some light on this situation I would really
appreciate it!

Thanks,

Christian







-
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 external binaries and sha1 hash values from Maven Central

[Jan Lahoda]

One thing to note is that binaries-list expects the hashes to be
upper-case, while the sum on the maven central is lower case. I.e.:
4AE44A6157E1BC4C5B373BE0C274A8F1D9BADD76
is expected instead of:
4ae44a6157e1bc4c5b373be0c274a8f1d9badd76

Jan


On Tue, Mar 13, 2018 at 4:35 PM, Christian Bourque <
christian.bour...@gmail.com> wrote:

> Thanks Jaroslav, I'll have a look at this class and maybe I'll understand
> what is going on!
>
> On Tue, Mar 13, 2018 at 10:45 AM, Jaroslav Tulach <
> jaroslav.tul...@gmail.com
> > wrote:
>
> > Hard to say without debugging. You can find the code here:
> > https://github.com/apache/incubator-netbeans/blob/
> > master/nbbuild/antsrc/org/netbeans/nbbuild/extlibs/
> > DownloadBinaries.java#L368
> > -jt
> >
> >
> > 2018-03-13 14:44 GMT+01:00 Christian Bourque <
> christian.bour...@gmail.com
> > >:
> >
> > > Hey guys,
> > >
> > > Thanks for your replies!
> > >
> > > But I think I wasn't clear enough in my original post: basically my
> > > question is why is NetBeans expecting a different hash value than the
> one
> > > found on Maven Central?
> > >
> > > C.
> > >
> > >
> > > On Tue, Mar 13, 2018 at 4:29 AM, Jaroslav Tulach <
> > > jaroslav.tul...@gmail.com>
> > > wrote:
> > >
> > > > Did you built JGit from source and installed it into local Maven
> > > > repository? Then the locally built version takes precedence over the
> > one
> > > in
> > > > the Maven central and has, of course, different SHA. Adjust the SHA
> or
> > > > delete the local copy from .m2/repository and let the build download
> > the
> > > > real version from Maven central.
> > > >
> > > > -jt
> > > >
> > > > PS: My experience tells me this is painful, sorry for the hassle.
> > > >
> > > >
> > > > 2018-03-13 1:48 GMT+01:00 Christian Bourque <
> > christian.bour...@gmail.com
> > > >:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I'm currently trying to compile NetBeans 9.0 with a more recent
> > Eclipse
> > > > > JGit library (the one currently bundled with
> > > > > NetBeans is 3 years old!) but I'm having a hard time with the hash
> > > (sha1)
> > > > > value that is used by the build system that's
> > > > > downloading the artefact from the Maven Central repository! When I
> > > build
> > > > > NetBeans it says that the hash value
> > > > > that I put in the binaries-list file doesn't match the hash of the
> > > > artefact
> > > > > found on Maven Central, but I took the hash
> > > > > value directly from the Maven Central repository so I expected it
> to
> > be
> > > > > correct:
> > > > > http://central.maven.org/maven2/org/eclipse/jgit/org.
> > > eclipse.jgit/4.11.0
> > > > .
> > > > > 201803080745-r/
> > > > >
> > > > > So then I decided to download the Eclipse JGit source code from
> > GitHub:
> > > > > https://github.com/eclipse/jgit/releases/tag/v4.11.0.
> 201803080745-r
> > > > > compile it and generate the sha1sum myself. To my surprise the
> > computed
> > > > > checksum was equal to the one expected by NetBeans during the build
> > > > > process.
> > > > >
> > > > > So I'm a bit puzzled! If the build script is downloading an
> external
> > > > > dependency from Maven Central then the hash should
> > > > > match the one found in this file:
> > > > > http://central.maven.org/maven2/org/eclipse/jgit/org.
> > > eclipse.jgit/4.11.0
> > > > .
> > > > > 201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1
> > > > >
> > > > > Anyway, if anyone could shed some light on this situation I would
> > > really
> > > > > appreciate it!
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Christian
> > > > >
> > > >
> > >
> >
>

Re: My Personal UI Rant, Was: Think Java, not Electron! was: Apache HTML/Java UI instead of

[Bernd Ruehlicke]

Scott, you are writing what my heart also was telling me. Still, it 
never occurred to me to look at anything which had he letters "HTML" in 
their api's as I always link this to "web" and my app is super heavy 
non-web-desktop-app-monster-size-local-file-reading-not-usually-associated-to-browser 
thingy. Though the "What is the HTML/Java project goal? To be a portable 
abstraction over such pipeline!" is exciting and I now know that this 
is/could be the way forward. Thank for the good discussion - lots of the 
comments were an eye-opener to me as I live in my little desktop 
Swing/AWT/JavaFX world.


Bernd

On 3/13/2018 10:06 AM, Scott Palmer wrote:

Sometimes I think the world has gone crazy.

Here are a few simple observations:
  - JavaFX is the best UI tech that Java has going for it these days.
  - Swing/AWT has been heading towards obsolescence for several years now. It 
works, but the future of desktop UI with Java is JavaFX.
  - HTML is a HORRIBLE way to render an application.  It works very poorly, if 
at all, and not consistently across browsers. (Look what people have to go 
through to try to get something as simple as a table with scrolling data and 
static column headers, for example.)
  - Javascript is junk.  The interesting thing about stuff like Electron is 
that they managed to get it to work at all.  We give it extra credit simply 
because it was done with technologies that make it so much harder to do. (It 
also tends to be slow IMO.) That’s cute and all, but ultimately wasted time.  
It would be that much better and cheaper to develop if done with better tech 
like Java/JavaFX.
- The popularity of Web UIs has done a disservice to the development community. 
 They have lowered the bar so far that we accept the utter rubbish and awful 
user experience of most web apps as ‘normal’.  We have a generation of 
developers that don’t even understand why Javascript is garbage or how crippled 
applications are that run in a browser. Have you noticed when you see an 
interesting web app that you are more impressed because it is a web app?  If it 
were a desktop app you wouldn’t give it a second thought.
- I don’t know why anyone would want to bring HTML UI into a Java application 
(when they don’t have to) as it is such a massive step backwards.


So stopping running around like the sky is falling.  Swing/AWT, JavaFX aren’t 
going to disappear.  Oracle wasn’t doing anything significant with Swing.  If 
they stop, we aren’t likely to notice.  JavaFX is the greater concern, because 
it is the better tech and still needs feature development.  The community 
around it can keep it going as long as there is a consistent vision for it  
Ideas of using HTML for UI on a desktop app programmed in Java are ridiculously 
insane. We already have a much better cross-platform UI technology, no need to 
put work in to move backwards to an inferior UI tech.

Scott


-
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



.

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Christian Lenz]

Sure it is my opinion but never ever, will a FrontEnd developer using swing to 
bring it into the browser. For me, it doesn’t make sense, if you have a 
powerful language like HTML and CSS and JS to make better UIs than you can 
expect, to communicate with a REST Backend.


Cheers

Chris


Von: toni.ep...@eppleton.de
Gesendet: Dienstag, 13. März 2018 10:09
An: dev@netbeans.incubator.apache.org; 'Emilian Bold'
Betreff: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from 
Oracle JDK

> We need a way to render Swing on a web browser canvas!

 We were actually thinking about doing this using DukeScript a while ago to 
allow people to run their legacy applications. It would be doable. The JavaFX 
Team at Oracle had a working JavaFX version for the browser (without Java 
Plugin). It was using bck2brwsr and my DukeScript canvas API as the rendering 
pipeline (the demo is still in the internet somewhere). The same would be 
possible for Swing.

But then we decided that it's much better if developers use a modern concept 
for UI Development like MVVM, otherwise we'll end up in a horrible niche as the 
only ones doing archaic Swing development in a world that has much better 
concepts for UI development.

--Toni
 
-Ursprüngliche Nachricht-
Von: Emilian Bold  
Gesendet: Dienstag, 13. März 2018 08:59
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from 
Oracle JDK

HTML4J goes the wrong way in providing a migration path.

We don't need new ways to embed components into Swing. We could already embed 
JavaFX stuff and now we can also embed HTML stuff (rendered by JavaFX).

We need a way to render Swing on a web browser canvas!

Then, after Swing is fully in the browser we can decide that instead of having 
a canvas there just replace that topcomponent rectangle area with a div.

So, for new apps HTML4J makes more sense.

For NetBeans HTML4J only makes sense if we start a multi-year process of slowly 
migrating to HTML4J and then, in the far future, realise we migrated so much we 
might as well switch the whole main window from a JFrame to a browser tab.
  This plan would probably make sense in a corporation like Oracle, but will no 
do well under Apache, also because we would have our own technology stack that 
no contributor would use elsewhere. Mozilla also had XULRunner and people 
didn't really flock to it. 

--emi

‐‐‐ Original Message ‐‐‐

On 12 March 2018 5:59 PM, Jaroslav Tulach  wrote:

> > "Oracle has begun conversations with interested parties in the Java
> 
> > ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
> > 
> > > > > referenced timeframes."
> 
> The official announcement is here and people are finally starting to
> 
> realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
> 
> will sponsor development of anything new for these technologies. Even if
> 
> they get transfered to their new owners, they will be in maintenance mode:
> 
> Bugfixes and little features. No bigger changes - no new rendering
> 
> pipelines using new nifty features of graphics cards. Just sustaining. I've
> 
> been explaining this would happen since 2012.
> 
> To help us out of this situation and save Java as a programming language I
> 
> dedicated my days to smoothing out interoperability between Java and
> 
> JavaScript with the goal to reuse the most flexible and portable rendering
> 
> system of these days: the browser. My work has already been donated to
> 
> Apache, see: https://github.com/apache/incubator-netbeans-html4j \- let's
> 
> use it to build new features of NetBeans and other future Java desktop
> 
> applications. Get started by reading Javadoc at
> 
> http://bits.netbeans.org/html+java/
> 
> Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> 
> care about Java, then your future should be Apache HTML/Java API!
> 
> -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

AW: My Personal UI Rant, Was: Think Java, not Electron! was: ApacheHTML/Java UI instead of

[Christian Lenz]

Swing is what winforms is for Windows, it is old, it is not looking good. We 
live in a world and in a century, where the Styling changed over the years. 
Sure, you can create good looking UIs with Swing, if you are a Java developer, 
I don’t want it. For NetBeans I have to OR I can use HTML, which is my eco 
System.  

Von: Scott Palmer
Gesendet: Dienstag, 13. März 2018 16:07
An: dev@netbeans.incubator.apache.org
Betreff: My Personal UI Rant, Was: Think Java, not Electron! was: 
ApacheHTML/Java UI instead of

Sometimes I think the world has gone crazy.

Here are a few simple observations:
 - JavaFX is the best UI tech that Java has going for it these days.
 - Swing/AWT has been heading towards obsolescence for several years now. It 
works, but the future of desktop UI with Java is JavaFX.
 - HTML is a HORRIBLE way to render an application.  It works very poorly, if 
at all, and not consistently across browsers. (Look what people have to go 
through to try to get something as simple as a table with scrolling data and 
static column headers, for example.)
 - Javascript is junk.  The interesting thing about stuff like Electron is that 
they managed to get it to work at all.  We give it extra credit simply because 
it was done with technologies that make it so much harder to do. (It also tends 
to be slow IMO.) That’s cute and all, but ultimately wasted time.  It would be 
that much better and cheaper to develop if done with better tech like 
Java/JavaFX.  
- The popularity of Web UIs has done a disservice to the development community. 
 They have lowered the bar so far that we accept the utter rubbish and awful 
user experience of most web apps as ‘normal’.  We have a generation of 
developers that don’t even understand why Javascript is garbage or how crippled 
applications are that run in a browser. Have you noticed when you see an 
interesting web app that you are more impressed because it is a web app?  If it 
were a desktop app you wouldn’t give it a second thought.
- I don’t know why anyone would want to bring HTML UI into a Java application 
(when they don’t have to) as it is such a massive step backwards.


So stopping running around like the sky is falling.  Swing/AWT, JavaFX aren’t 
going to disappear.  Oracle wasn’t doing anything significant with Swing.  If 
they stop, we aren’t likely to notice.  JavaFX is the greater concern, because 
it is the better tech and still needs feature development.  The community 
around it can keep it going as long as there is a consistent vision for it  
Ideas of using HTML for UI on a desktop app programmed in Java are ridiculously 
insane. We already have a much better cross-platform UI technology, no need to 
put work in to move backwards to an inferior UI tech.

Scott


-
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 external binaries and sha1 hash values from Maven Central

[Christian Bourque]

Thanks Jaroslav, I'll have a look at this class and maybe I'll understand
what is going on!

On Tue, Mar 13, 2018 at 10:45 AM, Jaroslav Tulach  wrote:

> Hard to say without debugging. You can find the code here:
> https://github.com/apache/incubator-netbeans/blob/
> master/nbbuild/antsrc/org/netbeans/nbbuild/extlibs/
> DownloadBinaries.java#L368
> -jt
>
>
> 2018-03-13 14:44 GMT+01:00 Christian Bourque  >:
>
> > Hey guys,
> >
> > Thanks for your replies!
> >
> > But I think I wasn't clear enough in my original post: basically my
> > question is why is NetBeans expecting a different hash value than the one
> > found on Maven Central?
> >
> > C.
> >
> >
> > On Tue, Mar 13, 2018 at 4:29 AM, Jaroslav Tulach <
> > jaroslav.tul...@gmail.com>
> > wrote:
> >
> > > Did you built JGit from source and installed it into local Maven
> > > repository? Then the locally built version takes precedence over the
> one
> > in
> > > the Maven central and has, of course, different SHA. Adjust the SHA or
> > > delete the local copy from .m2/repository and let the build download
> the
> > > real version from Maven central.
> > >
> > > -jt
> > >
> > > PS: My experience tells me this is painful, sorry for the hassle.
> > >
> > >
> > > 2018-03-13 1:48 GMT+01:00 Christian Bourque <
> christian.bour...@gmail.com
> > >:
> > >
> > > > Hi all,
> > > >
> > > > I'm currently trying to compile NetBeans 9.0 with a more recent
> Eclipse
> > > > JGit library (the one currently bundled with
> > > > NetBeans is 3 years old!) but I'm having a hard time with the hash
> > (sha1)
> > > > value that is used by the build system that's
> > > > downloading the artefact from the Maven Central repository! When I
> > build
> > > > NetBeans it says that the hash value
> > > > that I put in the binaries-list file doesn't match the hash of the
> > > artefact
> > > > found on Maven Central, but I took the hash
> > > > value directly from the Maven Central repository so I expected it to
> be
> > > > correct:
> > > > http://central.maven.org/maven2/org/eclipse/jgit/org.
> > eclipse.jgit/4.11.0
> > > .
> > > > 201803080745-r/
> > > >
> > > > So then I decided to download the Eclipse JGit source code from
> GitHub:
> > > > https://github.com/eclipse/jgit/releases/tag/v4.11.0.201803080745-r
> > > > compile it and generate the sha1sum myself. To my surprise the
> computed
> > > > checksum was equal to the one expected by NetBeans during the build
> > > > process.
> > > >
> > > > So I'm a bit puzzled! If the build script is downloading an external
> > > > dependency from Maven Central then the hash should
> > > > match the one found in this file:
> > > > http://central.maven.org/maven2/org/eclipse/jgit/org.
> > eclipse.jgit/4.11.0
> > > .
> > > > 201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1
> > > >
> > > > Anyway, if anyone could shed some light on this situation I would
> > really
> > > > appreciate it!
> > > >
> > > > Thanks,
> > > >
> > > > Christian
> > > >
> > >
> >
>

Re: NetBeans external binaries and sha1 hash values from Maven Central

[Christian Bourque]

Hi Antonio,

All the information about the artifact is already in my original post...

I'm not at home at the moment so I don't have the hash with me but I'll
send it tonight!

Thanks

Christian


On Tue, Mar 13, 2018 at 10:39 AM, Antonio  wrote:

> Hi Christian,
>
> Please state:
>
> - The artifact you are trying to download from Maven Central.
> - The "hash value" that NetBeans is expecting (if you've modified the
> binaries-list let us know the contents).
>
> Thanks,
> Antonio
>
>
> On 13/03/18 14:44, Christian Bourque wrote:
>
>> Hey guys,
>>
>> Thanks for your replies!
>>
>> But I think I wasn't clear enough in my original post: basically my
>> question is why is NetBeans expecting a different hash value than the one
>> found on Maven Central?
>>
>> C.
>>
>>
>> On Tue, Mar 13, 2018 at 4:29 AM, Jaroslav Tulach <
>> jaroslav.tul...@gmail.com>
>> wrote:
>>
>> Did you built JGit from source and installed it into local Maven
>>> repository? Then the locally built version takes precedence over the one
>>> in
>>> the Maven central and has, of course, different SHA. Adjust the SHA or
>>> delete the local copy from .m2/repository and let the build download the
>>> real version from Maven central.
>>>
>>> -jt
>>>
>>> PS: My experience tells me this is painful, sorry for the hassle.
>>>
>>>
>>> 2018-03-13 1:48 GMT+01:00 Christian Bourque >> >:
>>>
>>> Hi all,

 I'm currently trying to compile NetBeans 9.0 with a more recent Eclipse
 JGit library (the one currently bundled with
 NetBeans is 3 years old!) but I'm having a hard time with the hash
 (sha1)
 value that is used by the build system that's
 downloading the artefact from the Maven Central repository! When I build
 NetBeans it says that the hash value
 that I put in the binaries-list file doesn't match the hash of the

>>> artefact
>>>
 found on Maven Central, but I took the hash
 value directly from the Maven Central repository so I expected it to be
 correct:
 http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse
 .jgit/4.11.0

>>> .
>>>
 201803080745-r/

 So then I decided to download the Eclipse JGit source code from GitHub:
 https://github.com/eclipse/jgit/releases/tag/v4.11.0.201803080745-r
 compile it and generate the sha1sum myself. To my surprise the computed
 checksum was equal to the one expected by NetBeans during the build
 process.

 So I'm a bit puzzled! If the build script is downloading an external
 dependency from Maven Central then the hash should
 match the one found in this file:
 http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse
 .jgit/4.11.0

>>> .
>>>
 201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1

 Anyway, if anyone could shed some light on this situation I would really
 appreciate it!

 Thanks,

 Christian


>>>
>>
> -
> 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 external binaries and sha1 hash values from Maven Central

[Emilian Bold]

Please paste actual changes you made and actual error NetBeans build gave you.

--emi

‐‐‐ Original Message ‐‐‐

On 13 March 2018 3:44 PM, Christian Bourque  wrote:

> Hey guys,
> 
> Thanks for your replies!
> 
> But I think I wasn't clear enough in my original post: basically my
> 
> question is why is NetBeans expecting a different hash value than the one
> 
> found on Maven Central?
> 
> C.
> 
> On Tue, Mar 13, 2018 at 4:29 AM, Jaroslav Tulach jaroslav.tul...@gmail.com
> 
> wrote:
> 
> > Did you built JGit from source and installed it into local Maven
> > 
> > repository? Then the locally built version takes precedence over the one in
> > 
> > the Maven central and has, of course, different SHA. Adjust the SHA or
> > 
> > delete the local copy from .m2/repository and let the build download the
> > 
> > real version from Maven central.
> > 
> > -jt
> > 
> > PS: My experience tells me this is painful, sorry for the hassle.
> > 
> > 2018-03-13 1:48 GMT+01:00 Christian Bourque christian.bour...@gmail.com:
> > 
> > > Hi all,
> > > 
> > > I'm currently trying to compile NetBeans 9.0 with a more recent Eclipse
> > > 
> > > JGit library (the one currently bundled with
> > > 
> > > NetBeans is 3 years old!) but I'm having a hard time with the hash (sha1)
> > > 
> > > value that is used by the build system that's
> > > 
> > > downloading the artefact from the Maven Central repository! When I build
> > > 
> > > NetBeans it says that the hash value
> > > 
> > > that I put in the binaries-list file doesn't match the hash of the
> > > 
> > > artefact
> > > 
> > > found on Maven Central, but I took the hash
> > > 
> > > value directly from the Maven Central repository so I expected it to be
> > > 
> > > correct:
> > > 
> > > http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0
> > > 
> > > .
> > > 
> > > 201803080745-r/
> > > 
> > > So then I decided to download the Eclipse JGit source code from GitHub:
> > > 
> > > https://github.com/eclipse/jgit/releases/tag/v4.11.0.201803080745-r
> > > 
> > > compile it and generate the sha1sum myself. To my surprise the computed
> > > 
> > > checksum was equal to the one expected by NetBeans during the build
> > > 
> > > process.
> > > 
> > > So I'm a bit puzzled! If the build script is downloading an external
> > > 
> > > dependency from Maven Central then the hash should
> > > 
> > > match the one found in this file:
> > > 
> > > http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0
> > > 
> > > .
> > > 
> > > 201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1
> > > 
> > > Anyway, if anyone could shed some light on this situation I would really
> > > 
> > > appreciate it!
> > > 
> > > Thanks,
> > > 
> > > Christian



-
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: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Emilian Bold]

> We were actually thinking about doing this using DukeScript a while ago to 
> allow people to run their legacy applications. It would be doable.

I believe it would rather useful for NetBeans (and others).

> But then we decided that it's much better if developers use a modern concept 
> for UI Development like MVVM, otherwise we'll end up in a horrible niche as 
> the only ones doing archaic Swing development in a world that has much better 
> concepts for UI development.

This makes sense if you want to start something new, but what about the 1000 
man-years-projects like NetBeans. Just rewrite it all, with open-source 
contributors?

Isn't MVVM accomplished with Swing an a BeansBinding library?

--emi

‐‐‐ Original Message ‐‐‐

On 13 March 2018 10:56 AM,  wrote:

> > We need a way to render Swing on a web browser canvas!
> 
> We were actually thinking about doing this using DukeScript a while ago to 
> allow people to run their legacy applications. It would be doable. The JavaFX 
> Team at Oracle had a working JavaFX version for the browser (without Java 
> Plugin). It was using bck2brwsr and my DukeScript canvas API as the rendering 
> pipeline (the demo is still in the internet somewhere). The same would be 
> possible for Swing.
> 
> But then we decided that it's much better if developers use a modern concept 
> for UI Development like MVVM, otherwise we'll end up in a horrible niche as 
> the only ones doing archaic Swing development in a world that has much better 
> concepts for UI development.
> 
> --Toni
> 
> -Ursprüngliche Nachricht-
> 
> Von: Emilian Bold emilian.b...@protonmail.ch
> 
> Gesendet: Dienstag, 13. März 2018 08:59
> 
> An: dev@netbeans.incubator.apache.org
> 
> Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX 
> from Oracle JDK
> 
> HTML4J goes the wrong way in providing a migration path.
> 
> We don't need new ways to embed components into Swing. We could already embed 
> JavaFX stuff and now we can also embed HTML stuff (rendered by JavaFX).
> 
> We need a way to render Swing on a web browser canvas!
> 
> Then, after Swing is fully in the browser we can decide that instead of 
> having a canvas there just replace that topcomponent rectangle area with a 
> div.
> 
> So, for new apps HTML4J makes more sense.
> 
> For NetBeans HTML4J only makes sense if we start a multi-year process of 
> slowly migrating to HTML4J and then, in the far future, realise we migrated 
> so much we might as well switch the whole main window from a JFrame to a 
> browser tab.
> 
> This plan would probably make sense in a corporation like Oracle, but will no 
> do well under Apache, also because we would have our own technology stack 
> that no contributor would use elsewhere. Mozilla also had XULRunner and 
> people didn't really flock to it.
> 
> --emi
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On 12 March 2018 5:59 PM, Jaroslav Tulach jaroslav.tul...@gmail.com wrote:
> 
> > > "Oracle has begun conversations with interested parties in the Java
> > 
> > > ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
> > > 
> > > > > > referenced timeframes."
> > 
> > The official announcement is here and people are finally starting to
> > 
> > realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
> > 
> > will sponsor development of anything new for these technologies. Even if
> > 
> > they get transfered to their new owners, they will be in maintenance mode:
> > 
> > Bugfixes and little features. No bigger changes - no new rendering
> > 
> > pipelines using new nifty features of graphics cards. Just sustaining. I've
> > 
> > been explaining this would happen since 2012.
> > 
> > To help us out of this situation and save Java as a programming language I
> > 
> > dedicated my days to smoothing out interoperability between Java and
> > 
> > JavaScript with the goal to reuse the most flexible and portable rendering
> > 
> > system of these days: the browser. My work has already been donated to
> > 
> > Apache, see: https://github.com/apache/incubator-netbeans-html4j \- let's
> > 
> > use it to build new features of NetBeans and other future Java desktop
> > 
> > applications. Get started by reading Javadoc at
> > 
> > http://bits.netbeans.org/html+java/
> > 
> > Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> > 
> > care about Java, then your future should be Apache HTML/Java API!
> > 
> > -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
> 
> HTML4J goes the wrong way in providing a migration path.
> 
> We don't need new ways to embed components into Swing. We could already embed 
> JavaFX stuff and now we can also embed HTML stuff (rendered by JavaFX).
> 
> 

Re: [LAZY CONSENSUS] Definining Apache NetBeans Days

[Geertjan Wielenga]

Yes, I was waiting for you to point that out. :-)

Gj

On Tue, Mar 13, 2018 at 4:24 PM, Bertrand Delacretaz  wrote:

> Hi,
>
> On Thu, Mar 8, 2018 at 1:26 PM, Geertjan Wielenga
>  wrote:
> > ...Here's the central location where Apache NetBeans Events are defined:
> > https://netbeans.apache.org/community/events.html
> ...
>
> Thanks, having this is great!
>
> With my incubation mentor hat on I suggest adding a requirement for
> the event to be *approved* by the NetBeans (P)PMC on this list. Unless
> I missed something that page only says "discussed/notified" which is a
> bit vague.
>
> -Bertrand
>
> -
> 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: [LAZY CONSENSUS] Definining Apache NetBeans Days

[Bertrand Delacretaz]

Hi,

On Thu, Mar 8, 2018 at 1:26 PM, Geertjan Wielenga
 wrote:
> ...Here's the central location where Apache NetBeans Events are defined:
> https://netbeans.apache.org/community/events.html
...

Thanks, having this is great!

With my incubation mentor hat on I suggest adding a requirement for
the event to be *approved* by the NetBeans (P)PMC on this list. Unless
I missed something that page only says "discussed/notified" which is a
bit vague.

-Bertrand

-
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

Fwd: Pull request review.

[Hector Espert]

Hi, I don't have permissions to request a review in github.

Could anyone review this pull request? https://github.com/
apache/incubator-netbeans/pull/419

Thanks, Hector.

My Personal UI Rant, Was: Think Java, not Electron! was: Apache HTML/Java UI instead of

[Scott Palmer]

Sometimes I think the world has gone crazy.

Here are a few simple observations:
 - JavaFX is the best UI tech that Java has going for it these days.
 - Swing/AWT has been heading towards obsolescence for several years now. It 
works, but the future of desktop UI with Java is JavaFX.
 - HTML is a HORRIBLE way to render an application.  It works very poorly, if 
at all, and not consistently across browsers. (Look what people have to go 
through to try to get something as simple as a table with scrolling data and 
static column headers, for example.)
 - Javascript is junk.  The interesting thing about stuff like Electron is that 
they managed to get it to work at all.  We give it extra credit simply because 
it was done with technologies that make it so much harder to do. (It also tends 
to be slow IMO.) That’s cute and all, but ultimately wasted time.  It would be 
that much better and cheaper to develop if done with better tech like 
Java/JavaFX.  
- The popularity of Web UIs has done a disservice to the development community. 
 They have lowered the bar so far that we accept the utter rubbish and awful 
user experience of most web apps as ‘normal’.  We have a generation of 
developers that don’t even understand why Javascript is garbage or how crippled 
applications are that run in a browser. Have you noticed when you see an 
interesting web app that you are more impressed because it is a web app?  If it 
were a desktop app you wouldn’t give it a second thought.
- I don’t know why anyone would want to bring HTML UI into a Java application 
(when they don’t have to) as it is such a massive step backwards.


So stopping running around like the sky is falling.  Swing/AWT, JavaFX aren’t 
going to disappear.  Oracle wasn’t doing anything significant with Swing.  If 
they stop, we aren’t likely to notice.  JavaFX is the greater concern, because 
it is the better tech and still needs feature development.  The community 
around it can keep it going as long as there is a consistent vision for it  
Ideas of using HTML for UI on a desktop app programmed in Java are ridiculously 
insane. We already have a much better cross-platform UI technology, no need to 
put work in to move backwards to an inferior UI tech.

Scott


-
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: Problem with Java Help

[Jaroslav Tulach]

Hello Zoran,
JavaHelp is currently missing from standard NetBeans distribution as it is
GPLv2withCPex licensed and Apache and GPL doesn't go well along. You need
to put it into (boot)classpath somehow for now.
-jt

PS: There is a guy in Oracle working on relicensing JavaHelp to something
easier to use from Apache code. Hard to estimate the delivery time,
however...

2018-03-13 12:35 GMT+01:00 Zoran Sevarac :

> Hi,
>
> Did anybody experienced/solved problem with module with Java help?
> I'm getting the following Class not found exception for Java help when
> building my NB platform app:
>
> An annotation processor threw an uncaught exception.
> Consult the following stack trace for details.
> java.lang.NoClassDefFoundError: com/sun/java/help/search/Indexer
> at
> org.netbeans.modules.javahelp.HelpSetRegistrationProcessor.handleProcess(
> HelpSetRegistrationProcessor.java:145)
> at
> org.openide.filesystems.annotations.LayerGeneratingProcessor.process(
> LayerGeneratingProcessor.java:99)
> at com.sun.tools.javac
>
> Cheers
> Zoran
>

Re: [LAZY CONSENSUS] Apache NetBeans Day UK -- April 27, 2018

[Geertjan Wielenga]

More than 24 hours having passed without objections, Apache NetBeans Day UK
to be held on 27 April 2018 is hereby approved by the Apache NetBeans
community.

Thanks,

Gj

On Mon, Mar 12, 2018 at 11:10 AM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> Hi all,
>
> Now that trademarks@ has approved the class of events to be known as
> 'Apache NetBeans Day' and now that via lazy consensus we have defined the
> requirements for an event to be a member of that class... let's have the
> first implementation of Apache NetBeans Day!
>
> All that info is documented here:
>
> https://netbeans.apache.org/community/events.html
>
> We have agreed via lazy consensus that a requirements for an event to be a
> member of the Apache NetBeans Day class, it 'Must be discussed/notified
> via the Apache NetBeans dev mailing list'.
>
> So, here we go -- I propose an Apache NetBeans Day to be held at
> the University of Greenwich in London on April 27, 2018, to be named
> 'Apache NetBeans Day UK'. Every year over the past years, a NetBeans Day
> has been held there, in co-operation between staff and students at the
> university and members of the NetBeans community, so all the infrastructure
> and logistics are well established.
>
> Proposed agenda:
>
> 09:00 – 9:30: Registration
> 09:30 – 10:00: Opening Keynote - Geertjan Wielenga
> 10:00 – 10:45: Using VisualVM to fix your code and find your bugs  - Kirk
> Pepperdine
> 10:45 – 11:30: Understanding the compilation process with Graal and IGV -
> Duncan Macgregor
> 11:30 – 12:15: Writing code with NetBeans  - Ovidijus Okinskas and Mark
> Stephens
> 12.15 – 13:00: Update on Jakarta EE - Andrew Pielage and Steve Millidge
> 13:00 – 14:00: Lunch & Networking
> 14:00 – 15:30: Choice of:-
> -- Build plugins and applications on the NetBeans platform - Ovidijus
> Okinskas and Mark Stephens
> -- Writing web application in JavaScript the easy way with OracleJET -
> Geertjan Wielenga
> 15:00 – 15:30: Tea & Networking
> 15:30 – 16:30: Choice of:-
> -- NetBeans VisualVM Workshop - Kirk Pepperdine
> -- MicroProfile on PayaraMicro - Andrew Pielage and Steve Millidge
> 16:30: Wrap Up and prize draw.
>
> As agreed via lazy consensus, all demos will be done in NetBeans and the
> opening keynote is, as can be seen above, focused on the current state and
> roadmap of NetBeans.
>
> Following Apache lazy consensus (https://www.apache.org/founda
> tion/voting.html#LazyConsensu
> ), i.e., no
> voting or responses of any kind are needed, except if you object. If no one
> objects within 24 hours, we'll assume lazy consensus and implement the
> above proposal.
>
> Thanks,
>
> Gj
>
>

Re: NetBeans external binaries and sha1 hash values from Maven Central

[Jaroslav Tulach]

Hard to say without debugging. You can find the code here:
https://github.com/apache/incubator-netbeans/blob/master/nbbuild/antsrc/org/netbeans/nbbuild/extlibs/DownloadBinaries.java#L368
-jt


2018-03-13 14:44 GMT+01:00 Christian Bourque :

> Hey guys,
>
> Thanks for your replies!
>
> But I think I wasn't clear enough in my original post: basically my
> question is why is NetBeans expecting a different hash value than the one
> found on Maven Central?
>
> C.
>
>
> On Tue, Mar 13, 2018 at 4:29 AM, Jaroslav Tulach <
> jaroslav.tul...@gmail.com>
> wrote:
>
> > Did you built JGit from source and installed it into local Maven
> > repository? Then the locally built version takes precedence over the one
> in
> > the Maven central and has, of course, different SHA. Adjust the SHA or
> > delete the local copy from .m2/repository and let the build download the
> > real version from Maven central.
> >
> > -jt
> >
> > PS: My experience tells me this is painful, sorry for the hassle.
> >
> >
> > 2018-03-13 1:48 GMT+01:00 Christian Bourque  >:
> >
> > > Hi all,
> > >
> > > I'm currently trying to compile NetBeans 9.0 with a more recent Eclipse
> > > JGit library (the one currently bundled with
> > > NetBeans is 3 years old!) but I'm having a hard time with the hash
> (sha1)
> > > value that is used by the build system that's
> > > downloading the artefact from the Maven Central repository! When I
> build
> > > NetBeans it says that the hash value
> > > that I put in the binaries-list file doesn't match the hash of the
> > artefact
> > > found on Maven Central, but I took the hash
> > > value directly from the Maven Central repository so I expected it to be
> > > correct:
> > > http://central.maven.org/maven2/org/eclipse/jgit/org.
> eclipse.jgit/4.11.0
> > .
> > > 201803080745-r/
> > >
> > > So then I decided to download the Eclipse JGit source code from GitHub:
> > > https://github.com/eclipse/jgit/releases/tag/v4.11.0.201803080745-r
> > > compile it and generate the sha1sum myself. To my surprise the computed
> > > checksum was equal to the one expected by NetBeans during the build
> > > process.
> > >
> > > So I'm a bit puzzled! If the build script is downloading an external
> > > dependency from Maven Central then the hash should
> > > match the one found in this file:
> > > http://central.maven.org/maven2/org/eclipse/jgit/org.
> eclipse.jgit/4.11.0
> > .
> > > 201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1
> > >
> > > Anyway, if anyone could shed some light on this situation I would
> really
> > > appreciate it!
> > >
> > > Thanks,
> > >
> > > Christian
> > >
> >
>

Re: NetBeans external binaries and sha1 hash values from Maven Central

[Antonio]

Hi Christian,

Please state:

- The artifact you are trying to download from Maven Central.
- The "hash value" that NetBeans is expecting (if you've modified the 
binaries-list let us know the contents).


Thanks,
Antonio

On 13/03/18 14:44, Christian Bourque wrote:

Hey guys,

Thanks for your replies!

But I think I wasn't clear enough in my original post: basically my
question is why is NetBeans expecting a different hash value than the one
found on Maven Central?

C.


On Tue, Mar 13, 2018 at 4:29 AM, Jaroslav Tulach 
wrote:


Did you built JGit from source and installed it into local Maven
repository? Then the locally built version takes precedence over the one in
the Maven central and has, of course, different SHA. Adjust the SHA or
delete the local copy from .m2/repository and let the build download the
real version from Maven central.

-jt

PS: My experience tells me this is painful, sorry for the hassle.


2018-03-13 1:48 GMT+01:00 Christian Bourque :


Hi all,

I'm currently trying to compile NetBeans 9.0 with a more recent Eclipse
JGit library (the one currently bundled with
NetBeans is 3 years old!) but I'm having a hard time with the hash (sha1)
value that is used by the build system that's
downloading the artefact from the Maven Central repository! When I build
NetBeans it says that the hash value
that I put in the binaries-list file doesn't match the hash of the

artefact

found on Maven Central, but I took the hash
value directly from the Maven Central repository so I expected it to be
correct:
http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0

.

201803080745-r/

So then I decided to download the Eclipse JGit source code from GitHub:
https://github.com/eclipse/jgit/releases/tag/v4.11.0.201803080745-r
compile it and generate the sha1sum myself. To my surprise the computed
checksum was equal to the one expected by NetBeans during the build
process.

So I'm a bit puzzled! If the build script is downloading an external
dependency from Maven Central then the hash should
match the one found in this file:
http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0

.

201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1

Anyway, if anyone could shed some light on this situation I would really
appreciate it!

Thanks,

Christian







-
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 external binaries and sha1 hash values from Maven Central

[Christian Bourque]

Hey guys,

Thanks for your replies!

But I think I wasn't clear enough in my original post: basically my
question is why is NetBeans expecting a different hash value than the one
found on Maven Central?

C.


On Tue, Mar 13, 2018 at 4:29 AM, Jaroslav Tulach 
wrote:

> Did you built JGit from source and installed it into local Maven
> repository? Then the locally built version takes precedence over the one in
> the Maven central and has, of course, different SHA. Adjust the SHA or
> delete the local copy from .m2/repository and let the build download the
> real version from Maven central.
>
> -jt
>
> PS: My experience tells me this is painful, sorry for the hassle.
>
>
> 2018-03-13 1:48 GMT+01:00 Christian Bourque :
>
> > Hi all,
> >
> > I'm currently trying to compile NetBeans 9.0 with a more recent Eclipse
> > JGit library (the one currently bundled with
> > NetBeans is 3 years old!) but I'm having a hard time with the hash (sha1)
> > value that is used by the build system that's
> > downloading the artefact from the Maven Central repository! When I build
> > NetBeans it says that the hash value
> > that I put in the binaries-list file doesn't match the hash of the
> artefact
> > found on Maven Central, but I took the hash
> > value directly from the Maven Central repository so I expected it to be
> > correct:
> > http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0
> .
> > 201803080745-r/
> >
> > So then I decided to download the Eclipse JGit source code from GitHub:
> > https://github.com/eclipse/jgit/releases/tag/v4.11.0.201803080745-r
> > compile it and generate the sha1sum myself. To my surprise the computed
> > checksum was equal to the one expected by NetBeans during the build
> > process.
> >
> > So I'm a bit puzzled! If the build script is downloading an external
> > dependency from Maven Central then the hash should
> > match the one found in this file:
> > http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0
> .
> > 201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1
> >
> > Anyway, if anyone could shed some light on this situation I would really
> > appreciate it!
> >
> > Thanks,
> >
> > Christian
> >
>

AW: Think Java, not Electron! was: Apache HTML/Java UI instead of

[Christian Lenz]

Hey Jaroslav and all others,

thx for your explanation. I think you didn’t get everything wrong, maybe more 
promotion but this is PR part 😉. There are big players out there. And why I 
love electron? Because it is fucking HTML, CSS and JS AND for the Backend too. 
This eco system was build for fullstack developers, who wants to create desktop 
applications with HTML/CSS/JS still in the background.

You know my example NbScratchFile, this is I think one of the best solution to 
promote a plugin for NetBeans, which was written in HTML, SCSS/CSS, TS/JS with 
a Framework called Knockout, a buildsystem with webpack and a communication 
with Java in the backend. Why I’ve chosen it? Because I wanted to write a 
plugin for NetBeans but w/o swing. The Mantisse editor is cool but far away 
from perfect, I created a ticket for a big problem to align checkboxes with 
labels pixel perfect, inside the Editor: 
https://netbeans.org/bugzilla/show_bug.cgi?id=257519

Why I’m not writing the controls in Java? Sry but no, we have Qt, we have WPF 
(C# with XAML) and we have WYSIWYG editors to create UIs quick and fast and 
sometimes dirty. In HTML I don’t need such editor. It is my daily business, I 
have chrome with the powerful and best DevTools ever to see my progress 
immediately and I’m fast w/o having an editor.

So I decided to give DukeScript and the archetype a try, but there are some 
problems with the project type:

1. It is still not fast while bootstrapping the UI when you call your UI inside 
a component, we talked about that, that there Needs an improvement that this 
bootstrapping has to be done while IDE start or wherever. As soon as possible. 
Of course my plugin has the same problem and I have to change it and it is not 
the problem of DukeScript but there needs to be done sooner. Sometimes it seems 
that the DukeScript stuff was a prototype to say: hey look this can be done 
with HTML AND Java, but it feels unfinished.
2. The Project is so coupled with each other, I can’t use the HTML5 project 
features of NetBeans for that. It is still maven or Java with a piece of HTML 
inside. I can’t use the tasks for a HTML5 project, because it is not a HTML5 
project. I can’t install npm, I can’t use scss etc from the IDE. This is why I 
created it by my own. You can see everything here: 
https://github.com/Chris2011/NbScratchFile/tree/master/src/main. I created a 
HTML5 project and copied the dist folder (Built with webpack, the outcome) over 
to the maven project to open the project again separately to build my UI, 
indepedent from the maven stuff. This should be a possible template to creating 
a HTML UI with the backend Java to creating a NetBeans plugin. Because 
everything is decoupled. It has the build process within the plugin for the UI 
and build process for the Java backend.
3. The WebView, which renders the UI, is, AFAIK not WebKit. Why WebKit? Because 
of the DevTools of Chrome. That tools are the best I’ve ever seen and yes, I 
can say I have seen a lot in my career. I started with IE, they were good, in 
the first 2000s. I worked with FF with the beloved Firebug, I switched to 
Chrome, because the DevTools are awesome. Sure the FF tools are also great, I 
tested them too, but I missed a lot of features there. Anyway, for that 
WebView, that HTML4J uses, I  can only add firebug lite, which is pretty old, 
obsoleted, dead, etc. So for this, we need a better solution.
4. I had some trouble with the magic generated code, that HTML4J creates in the 
background for i.e. knockout (I don’t have any control about that). I split 
some classes to decouple my logic and the build breaks because of the magic 
that happens in the background. Sure I had to create tickets for that, but I 
was frustrated, that I tried to create my own UI with WebView from the JavaFX 
to call it and bind the ViewModel from JS to Java and vice versa, as you 
already know, maybe Jaroslav.
5. Again, I’m still a frontend developer, fullstack now, because I have to use 
Spring and Java, but anyway. I love JS and TS, I don’t know which limitations 
other means, but don’t compare GWT or Vaading with JS or TS. Yes, you have 
limitations with GWT (I also worked with that), but those limitations are 
coming from GWT and you can extend that, but that has nothing todo with JS. So 
my eco system is JS/TS, HTML/SCSS/CSS for the FrontEnd and JS/TS + Node in the 
BackEnd. And again I want to write as less as possible Java code for the 
plugin. Only that pieces what is needed. Your PR, which I merged into my 
plugin, has coupled JS within Java, which I don’t want but yes I know this is 
needed. Before I used your PR, you saw how I realized that, because I don’t 
wanted to coupled it.
6. I couldn’t resized the window when I was working with DukeScript, I didn’t 
have a lot of control to change the stuff to my needs. (setSize, noResizable, 
etc.) I simple couldn’t find that.

So again, I hope it is a bit clearer how an eco system for a pure frontend guy 
l

Problem with Java Help

[Zoran Sevarac]

Hi,

Did anybody experienced/solved problem with module with Java help?
I'm getting the following Class not found exception for Java help when
building my NB platform app:

An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.NoClassDefFoundError: com/sun/java/help/search/Indexer
at
org.netbeans.modules.javahelp.HelpSetRegistrationProcessor.handleProcess(HelpSetRegistrationProcessor.java:145)
at
org.openide.filesystems.annotations.LayerGeneratingProcessor.process(LayerGeneratingProcessor.java:99)
at com.sun.tools.javac

Cheers
Zoran

Re: Think Java, not Electron! was: Apache HTML/Java UI instead of

[Chuck Davis]

[2] does not build on release 219 with jdk9


> [1] Plus few minutes of Maven plugins initial download time...
> [2] Have you noticed that the wizard ("New Project", "JavaFX", "Java HTML5
> Application") is written in HTML UI? I hope the transition from the Swing
> to the HTML UI was smooth enough to not be really noticeable.
>

Re: Think Java, not Electron! was: Apache HTML/Java UI instead of

[Antonio]

Hi all,

Some comments inlined below:

On 13/03/18 09:26, Jaroslav Tulach wrote:

Thanks a lot for your opinions! I am going to react to one recurring theme
in this email...

2018-03-12 16:59 GMT+01:00 Jaroslav Tulach :



Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
care about Java, then your future should be Apache HTML/Java API!



I'd love to see an example of this Apache HTML/Java API while forgetting 
about AWT, Swing and JavaFX ...



OK, I can see people are looking (or at least googling) for alternatives to
current UIs. Yes, I agree HTML is one of (the best) options there -
especially if you want real WORA - e.g. also target plain browser. However


... and I agree that HTML is one of the best option here for WORA...


...and trying Electron samples! C'mon do you have recent version of
NetBeans 9.0? Then just select "New Project", "JavaFX", "Java HTML5
Application" click through the wizard and choose Run/Debug on the generated
project! How much did it take? 30s of activity[1]?



... but I cannot see any "New Project/JavaFX/Java HTML5 Application" in 
my Apache NetBeans IDE.


In fact all "New Project/JavaFX" and "New Project/Examples/JavaFX" 
wizards fail on my IDE because _I don't have JavaFX installed_.


In fact JavaFX and WORA are incompatible: JavaFX has not been ported to 
BSDs (but Swing is). Also JavaFX is GPLed.


But, wait, you said about forgetting about AWT, Swing _and_ JavaFX, 
right? How is so that JavaFX has entered the equation again? This is 
confusing!



I consider it patriotic to try NetBeans own solution first. Am I completely
off?


No, you aren't. In fact you're completely right. We should try our own 
first.


So, to summarize: I'd love to experiment with a HTML UI, without _any_ 
JavaFX dependencies (a plain browser is a good dependency, though, as 
that is WORA), and with the following requirements:


- It allows me to type (very) quickly.
- It is able to launch heavy tasks on a background processes/threads 
(i.e., does not block the UI).

- It keeps the UI in sync with my local filesystem.
- It has CSS animation support.
- It provides 2D and 2.5D transforms and other graphic stuff (SVG, for 
instance).

- Takes profit of graphic acceleration in my graphics card.

Can we do an experiment with these requirements?

Kind regards,
Antonio




-
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: Support of Java 10

[Neil C Smith]

On Tue, 13 Mar 2018 at 02:09 Wade Chandler  wrote:

> -1 as well. The LTS versions live longer, and the processes between the
> orgs will be different. They are also just different orgs. I don't think it
> makes sense to try to align versioning. It was essentially marketing
> between Oracle's Java and it's IDE, which made sense considering that, but
> isn't the case any longer. It also means we will jump major versions just
> for the Java support when NB is so much more than that.
>

Good points!  Yes, agree it was mainly marketing, although also about what
level of Java was officially supported?

My original question elsewhere was whether we were consciously deciding to
decouple versions or just letting it happen.  Quite happy with either,
actually, and I'd probably prefer a better semantic versioning strategy
anyway.

Of course, we need to be sure we don't disregard all marketing now in
Apache.  Something for discussion elsewhere might be how / whether this is
communicated - you know someone will ask why we're releasing NetBeans 9
just as Java 10 is out?! ;-)

Best wishes,

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: Think Java, not Electron! was: Apache HTML/Java UI instead of

[Hermien Pellissier]

Hi Jaroslav,

Waiting for the maven downloads as I write. :)

Are there any tutorials or other cool documents out there about Apache
HTML/Java UI?

~ Hermien


On Tue, Mar 13, 2018 at 10:26 AM, Jaroslav Tulach  wrote:

> Thanks a lot for your opinions! I am going to react to one recurring theme
> in this email...
>
> 2018-03-12 16:59 GMT+01:00 Jaroslav Tulach :
>
> >
> > Forget about AWT, Swing and JavaFX - the future is HTML. In case you
> still
> > care about Java, then your future should be Apache HTML/Java API!
> >
> >
> First of all I have to admit it drives me mad, how incapable I am in
> communicating these ideas. How could I be the initial architect of
> NetBeans, when I am not able to explain what HTML/Java API is beneficial
> for? Or was I just the architect and there had to be others to handle the
> public relations? Or was the success of NetBeans (Platform) just an
> unrepeatable luck?
>
> Anyway, there have been few references to Electron framework in your
> reactions to my email:
>
> > There is nothing better than creating UIs with HTML and use them
> everywhere, like in the Electron Framework.
> > ... look into electron apps ... like VS Code and I think this is a big
> Player and you can see, that it performs very well and it is performant as
> hell.
>
> OK, I can see people are looking (or at least googling) for alternatives to
> current UIs. Yes, I agree HTML is one of (the best) options there -
> especially if you want real WORA - e.g. also target plain browser. However
> I have to say the following sentence is just increasing my internal
> suffering...
>
> > heavyweight, ...(but)... the open source nature ... of Electron make it
> potentially an attractive option for mixed Java/HTML applications
>
> We - the NetBeans (incubating) project - have such technology, it is
> HTML/Java API. It has been intentionally designed to support mixed
> Java/HTML applications. We are the community of the project! But instead of
> improving what we have and making it work for our NetBeans IDE purposes
> (which is certainly simpler than trying to use Electron designed for
> something different; more on that later), we are looking at other project
> and admiring their "open source nature"!
>
> Am I really doing so poor job that people aren't willing to dedicate 10
> minutes of their personal time to try HTML/Java API in action? Rather they
> are looking...
>
> > I was looking at an example project using Vaadin running inside Electron
> recently.  Have you tried this approach with HTML/Java?
>
> ...and trying Electron samples! C'mon do you have recent version of
> NetBeans 9.0? Then just select "New Project", "JavaFX", "Java HTML5
> Application" click through the wizard and choose Run/Debug on the generated
> project! How much did it take? 30s of activity[1]?
>
> > I keep trying to find some time to experiment with Apache HTML/Java and
> wondered at the feasibility of reworking that Electron example with it?
>
> If you give the NetBeans 9.0 support for HTML/Java UI a try, you see (when
> using for example the Visual archetype) that rewriting visually rich
> Electron application like
> https://github.com/electron/simple-samples/tree/master/activity-monitor
> should be a piece of cake.
>
> I consider it patriotic to try NetBeans own solution first. Am I completely
> off?
>
> > Demo app showing all kind of features a given system allows me to use.
> Like a toolbox, which I run and say - hey that's the component I need. Is
> there something like this for the HTML+JAVA api?
>
> The visual archetype offers canvas sample, line charts and pie charts
> sample and interactive GeoBase application. Isn't that enough? Then there
> is another CRUD like archetype, as well as simple MVVM sample. All of them
> are just few clicks from your reach ("New Project", "JavaFX", "Java HTML5
> Application"), is that enough to get started?
>
> I hope it is. Guys, please, instead of drinking your morning coffee, click
> though the wizard and see Apache HTML/Java API in action yourself. I'll be
> thankful for comments. As confessed, I am depressed by my inability to
> communicate what our HTML/Java project can do for you. It may not be 100%
> perfect fit, but it is so close to what you guys need Shame on me for
> not being able to explain that!
>
> Thanks.
> -js
>
> PS: Now let's look at what Electron isn't and why HTML/Java shall be a
> better choice:
>
> > I am sure electron is good, but my personal preference is to not use a
> web ide.
>
> I share your feelings. However we are not talking about Web IDE. We are
> talking about reusing rendering pipeline that is behind HTML. Sure, this
> pipeline is used in browsers, but that doesn't mean browser == the
> rendering pipeline. Browser is much more and we don't need all of that.
>
> > Think about ... what Electron actually *is* ...
>
> Electron is the rendering pipeline, plus a bunch of libraries for dealing
> with the surrounding operating system, plus JavaScript specific build
> sys

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Neil C Smith]

On Tue, 13 Mar 2018 at 08:56  wrote:

> > We need a way to render Swing on a web browser canvas!
>
>  We were actually thinking about doing this using DukeScript a while ago
> to allow people to run their legacy applications. It would be doable.


Reminds me of this - http://demo.creamtec.com/ajaxswing/apps/SwingSet2


> But then we decided that it's much better if developers use a modern
> concept for UI Development like MVVM, otherwise we'll end up in a horrible
> niche as the only ones doing archaic Swing development in a world that has
> much better concepts for UI development.
>

Yep, still reminds me of this -
http://demo.creamtec.com/ajaxswing/apps/SwingSet2 ;-)

Best wishes,

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: Think Java, not Electron! was: Apache HTML/Java UI instead of

[Neil C Smith]

Hi,

On Tue, 13 Mar 2018 at 08:26 Jaroslav Tulach 
wrote:

> > heavyweight, ...(but)... the open source nature ... of Electron make it
> potentially an attractive option for mixed Java/HTML applications
>
> I was looking at an example project using Vaadin running inside Electron
recently.  Have you tried this approach with HTML/Java?

>
> We - the NetBeans (incubating) project - have such technology, it is
> HTML/Java API. It has been intentionally designed to support mixed
> Java/HTML applications. We are the community of the project! But instead of
> improving what we have and making it work for our NetBeans IDE purposes
> (which is certainly simpler than trying to use Electron designed for
> something different; more on that later), we are looking at other project
> and admiring their "open source nature"!
>
> Am I really doing so poor job that people aren't willing to dedicate 10
> minutes of their personal time to try HTML/Java API in action?


No, you aren't!  I'm potentially doing a poor job of explaining why that
example might be interesting though.  As far as I'm concerned, web view in
JavaFX is not a viable option.  Toni mentioned JxBrowser, which is
unfortunately proprietary, and when this last came up we talked a bit about
JavaCEF, but I seem to remember some issues with that?

All the node side of that Vaadin Electron example is doing is handling
distribution, launching of the Chromium renderer, and launching the JVM as
a child process.  Now, don't get me started at how overkill it is to do
that! ;-)

I am really interested in our HTML/Java API, but we seem to be lacking a
viable, stable and open option for people to distribute fully HTML UI Java
applications?  We're missing an Electron-like framework based around the
HTML/Java API and the JVM.

I'm more talking about people building stuff with NetBeans there, rather
than necessarily the IDE itself.

Best wishes,

Neil



-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[toni.epple]

> We need a way to render Swing on a web browser canvas!

 We were actually thinking about doing this using DukeScript a while ago to 
allow people to run their legacy applications. It would be doable. The JavaFX 
Team at Oracle had a working JavaFX version for the browser (without Java 
Plugin). It was using bck2brwsr and my DukeScript canvas API as the rendering 
pipeline (the demo is still in the internet somewhere). The same would be 
possible for Swing.

But then we decided that it's much better if developers use a modern concept 
for UI Development like MVVM, otherwise we'll end up in a horrible niche as the 
only ones doing archaic Swing development in a world that has much better 
concepts for UI development.

--Toni
 
-Ursprüngliche Nachricht-
Von: Emilian Bold  
Gesendet: Dienstag, 13. März 2018 08:59
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from 
Oracle JDK

HTML4J goes the wrong way in providing a migration path.

We don't need new ways to embed components into Swing. We could already embed 
JavaFX stuff and now we can also embed HTML stuff (rendered by JavaFX).

We need a way to render Swing on a web browser canvas!

Then, after Swing is fully in the browser we can decide that instead of having 
a canvas there just replace that topcomponent rectangle area with a div.

So, for new apps HTML4J makes more sense.

For NetBeans HTML4J only makes sense if we start a multi-year process of slowly 
migrating to HTML4J and then, in the far future, realise we migrated so much we 
might as well switch the whole main window from a JFrame to a browser tab.
  This plan would probably make sense in a corporation like Oracle, but will no 
do well under Apache, also because we would have our own technology stack that 
no contributor would use elsewhere. Mozilla also had XULRunner and people 
didn't really flock to it. 

--emi

‐‐‐ Original Message ‐‐‐

On 12 March 2018 5:59 PM, Jaroslav Tulach  wrote:

> > "Oracle has begun conversations with interested parties in the Java
> 
> > ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
> > 
> > > > > referenced timeframes."
> 
> The official announcement is here and people are finally starting to
> 
> realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
> 
> will sponsor development of anything new for these technologies. Even if
> 
> they get transfered to their new owners, they will be in maintenance mode:
> 
> Bugfixes and little features. No bigger changes - no new rendering
> 
> pipelines using new nifty features of graphics cards. Just sustaining. I've
> 
> been explaining this would happen since 2012.
> 
> To help us out of this situation and save Java as a programming language I
> 
> dedicated my days to smoothing out interoperability between Java and
> 
> JavaScript with the goal to reuse the most flexible and portable rendering
> 
> system of these days: the browser. My work has already been donated to
> 
> Apache, see: https://github.com/apache/incubator-netbeans-html4j \- let's
> 
> use it to build new features of NetBeans and other future Java desktop
> 
> applications. Get started by reading Javadoc at
> 
> http://bits.netbeans.org/html+java/
> 
> Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> 
> care about Java, then your future should be Apache HTML/Java API!
> 
> -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



--- Begin Message ---
HTML4J goes the wrong way in providing a migration path.

We don't need new ways to embed components into Swing. We could already embed 
JavaFX stuff and now we can also embed HTML stuff (rendered by JavaFX).

We need a way to render Swing on a web browser canvas!

Then, after Swing is fully in the browser we can decide that instead of having 
a canvas there just replace that topcomponent rectangle area with a div.

So, for new apps HTML4J makes more sense.

For NetBeans HTML4J only makes sense if we start a multi-year process of slowly 
migrating to HTML4J and then, in the far future, realise we migrated so much we 
might as well switch the whole main window from a JFrame to a browser tab.
  This plan would probably make sense in a corporation like Oracle, but will no 
do well under Apache, also because we would have our own technology stack that 
no contributor would use elsewhere. Mozilla also had XULRunner and people 
didn't really flock to it. 

--emi

‐‐‐ Original Message ‐‐‐

On 12 March 2018 5:59 PM, Jaroslav Tulach  wrote:

> > "Oracle has begun conversations with interested parties in the Java
> 
> > ecosystem on the stewardship of JavaFX, Swing and A

Re: Think Java, not Electron! was: Apache HTML/Java UI instead of

[Geertjan Wielenga]

On Tue, Mar 13, 2018 at 9:26 AM, Jaroslav Tulach 
wrote:

>
>
> > I was looking at an example project using Vaadin running inside Electron
> recently.  Have you tried this approach with HTML/Java?
>
> ...and trying Electron samples! C'mon do you have recent version of
> NetBeans 9.0? Then just select "New Project", "JavaFX", "Java HTML5
> Application" click through the wizard and choose Run/Debug on the generated
> project! How much did it take? 30s of activity[1]?
>


Well, you must admit that that is pretty well hidden.

You're saying the HTML/Java (or is it not HTML4J) sample is hidden inside
the JavaFX category and is named "Java HTML5 Application".

I think this is the key problem -- how well hidden this technology is.

To be honest, it took me many years to understand what the NetBeans Lookup
API was for. Eventually I understood it as a generic mechanism for
decoupling, which can be used in several different ways -- e.g., to provide
a global context and for pub/sub communication.

The problem/challenge with HTML4J is very similar -- it is a generic
mechanism and its usages take a while to understand. To help with this, you
can make really crystal clear what it is -- and the info in the README here
https://github.com/apache/incubator-netbeans-html4j is good, but probably
best would be a library of very basic samples, i.e., the repo needs a
samples folder.

Also, what would a transition from NetBeans IDE to HTML/Java API look like
-- OK, sure, we can make TopComponents that contains HTML files, via the
HTML/Java API. But how far can we go with that, can you do a POC of the
complete NetBeans IDE redone via HTML/Java API? You or Toni are the only
ones who are able to do that and you should do that or stop talking about
it as a way forward.

Thanks,

Gj




>
> > I keep trying to find some time to experiment with Apache HTML/Java and
> wondered at the feasibility of reworking that Electron example with it?
>
> If you give the NetBeans 9.0 support for HTML/Java UI a try, you see (when
> using for example the Visual archetype) that rewriting visually rich
> Electron application like
> https://github.com/electron/simple-samples/tree/master/activity-monitor
> should be a piece of cake.
>
> I consider it patriotic to try NetBeans own solution first. Am I completely
> off?
>
> > Demo app showing all kind of features a given system allows me to use.
> Like a toolbox, which I run and say - hey that's the component I need. Is
> there something like this for the HTML+JAVA api?
>
> The visual archetype offers canvas sample, line charts and pie charts
> sample and interactive GeoBase application. Isn't that enough? Then there
> is another CRUD like archetype, as well as simple MVVM sample. All of them
> are just few clicks from your reach ("New Project", "JavaFX", "Java HTML5
> Application"), is that enough to get started?
>
> I hope it is. Guys, please, instead of drinking your morning coffee, click
> though the wizard and see Apache HTML/Java API in action yourself. I'll be
> thankful for comments. As confessed, I am depressed by my inability to
> communicate what our HTML/Java project can do for you. It may not be 100%
> perfect fit, but it is so close to what you guys need Shame on me for
> not being able to explain that!
>
> Thanks.
> -js
>
> PS: Now let's look at what Electron isn't and why HTML/Java shall be a
> better choice:
>
> > I am sure electron is good, but my personal preference is to not use a
> web ide.
>
> I share your feelings. However we are not talking about Web IDE. We are
> talking about reusing rendering pipeline that is behind HTML. Sure, this
> pipeline is used in browsers, but that doesn't mean browser == the
> rendering pipeline. Browser is much more and we don't need all of that.
>
> > Think about ... what Electron actually *is* ...
>
> Electron is the rendering pipeline, plus a bunch of libraries for dealing
> with the surrounding operating system, plus JavaScript specific build
> system. But, when writing Java application, why would you need those
> libraries? Java has pretty rich operating system API (think of java.nio,
> missing in JavaScript) and there are plenty of libraries to deal with other
> aspects of OS integration. Why would you need npm build system? Java has
> other, well established build systems as well. Conclusion? The only thing
> you'd want from Electron is the rendering pipeline.
>
> But then: What is the HTML/Java project goal? To be a portable abstraction
> over such pipeline! I would conclude that you don't want to look at
> Electron to begin with! Again, I am ashamed of not being able to get my
> message thru...
>
>
> > Funfact: Without JavaFX you don't have a HTML5 renderer
>
> The truth is that we already have our existing Swing/JavaFX applications
> and if we want to move towards HTML, we need an incremental way to migrate,
> rather than big bang rewrite of everything. That is not at all what
> Electron can give you! On the other hand that is something HTML

Re: NetBeans external binaries and sha1 hash values from Maven Central

[Jaroslav Tulach]

Did you built JGit from source and installed it into local Maven
repository? Then the locally built version takes precedence over the one in
the Maven central and has, of course, different SHA. Adjust the SHA or
delete the local copy from .m2/repository and let the build download the
real version from Maven central.

-jt

PS: My experience tells me this is painful, sorry for the hassle.


2018-03-13 1:48 GMT+01:00 Christian Bourque :

> Hi all,
>
> I'm currently trying to compile NetBeans 9.0 with a more recent Eclipse
> JGit library (the one currently bundled with
> NetBeans is 3 years old!) but I'm having a hard time with the hash (sha1)
> value that is used by the build system that's
> downloading the artefact from the Maven Central repository! When I build
> NetBeans it says that the hash value
> that I put in the binaries-list file doesn't match the hash of the artefact
> found on Maven Central, but I took the hash
> value directly from the Maven Central repository so I expected it to be
> correct:
> http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0.
> 201803080745-r/
>
> So then I decided to download the Eclipse JGit source code from GitHub:
> https://github.com/eclipse/jgit/releases/tag/v4.11.0.201803080745-r
> compile it and generate the sha1sum myself. To my surprise the computed
> checksum was equal to the one expected by NetBeans during the build
> process.
>
> So I'm a bit puzzled! If the build script is downloading an external
> dependency from Maven Central then the hash should
> match the one found in this file:
> http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0.
> 201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1
>
> Anyway, if anyone could shed some light on this situation I would really
> appreciate it!
>
> Thanks,
>
> Christian
>

Think Java, not Electron! was: Apache HTML/Java UI instead of

[Jaroslav Tulach]

Thanks a lot for your opinions! I am going to react to one recurring theme
in this email...

2018-03-12 16:59 GMT+01:00 Jaroslav Tulach :

>
> Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> care about Java, then your future should be Apache HTML/Java API!
>
>
First of all I have to admit it drives me mad, how incapable I am in
communicating these ideas. How could I be the initial architect of
NetBeans, when I am not able to explain what HTML/Java API is beneficial
for? Or was I just the architect and there had to be others to handle the
public relations? Or was the success of NetBeans (Platform) just an
unrepeatable luck?

Anyway, there have been few references to Electron framework in your
reactions to my email:

> There is nothing better than creating UIs with HTML and use them
everywhere, like in the Electron Framework.
> ... look into electron apps ... like VS Code and I think this is a big
Player and you can see, that it performs very well and it is performant as
hell.

OK, I can see people are looking (or at least googling) for alternatives to
current UIs. Yes, I agree HTML is one of (the best) options there -
especially if you want real WORA - e.g. also target plain browser. However
I have to say the following sentence is just increasing my internal
suffering...

> heavyweight, ...(but)... the open source nature ... of Electron make it
potentially an attractive option for mixed Java/HTML applications

We - the NetBeans (incubating) project - have such technology, it is
HTML/Java API. It has been intentionally designed to support mixed
Java/HTML applications. We are the community of the project! But instead of
improving what we have and making it work for our NetBeans IDE purposes
(which is certainly simpler than trying to use Electron designed for
something different; more on that later), we are looking at other project
and admiring their "open source nature"!

Am I really doing so poor job that people aren't willing to dedicate 10
minutes of their personal time to try HTML/Java API in action? Rather they
are looking...

> I was looking at an example project using Vaadin running inside Electron
recently.  Have you tried this approach with HTML/Java?

...and trying Electron samples! C'mon do you have recent version of
NetBeans 9.0? Then just select "New Project", "JavaFX", "Java HTML5
Application" click through the wizard and choose Run/Debug on the generated
project! How much did it take? 30s of activity[1]?

> I keep trying to find some time to experiment with Apache HTML/Java and
wondered at the feasibility of reworking that Electron example with it?

If you give the NetBeans 9.0 support for HTML/Java UI a try, you see (when
using for example the Visual archetype) that rewriting visually rich
Electron application like
https://github.com/electron/simple-samples/tree/master/activity-monitor
should be a piece of cake.

I consider it patriotic to try NetBeans own solution first. Am I completely
off?

> Demo app showing all kind of features a given system allows me to use.
Like a toolbox, which I run and say - hey that's the component I need. Is
there something like this for the HTML+JAVA api?

The visual archetype offers canvas sample, line charts and pie charts
sample and interactive GeoBase application. Isn't that enough? Then there
is another CRUD like archetype, as well as simple MVVM sample. All of them
are just few clicks from your reach ("New Project", "JavaFX", "Java HTML5
Application"), is that enough to get started?

I hope it is. Guys, please, instead of drinking your morning coffee, click
though the wizard and see Apache HTML/Java API in action yourself. I'll be
thankful for comments. As confessed, I am depressed by my inability to
communicate what our HTML/Java project can do for you. It may not be 100%
perfect fit, but it is so close to what you guys need Shame on me for
not being able to explain that!

Thanks.
-js

PS: Now let's look at what Electron isn't and why HTML/Java shall be a
better choice:

> I am sure electron is good, but my personal preference is to not use a
web ide.

I share your feelings. However we are not talking about Web IDE. We are
talking about reusing rendering pipeline that is behind HTML. Sure, this
pipeline is used in browsers, but that doesn't mean browser == the
rendering pipeline. Browser is much more and we don't need all of that.

> Think about ... what Electron actually *is* ...

Electron is the rendering pipeline, plus a bunch of libraries for dealing
with the surrounding operating system, plus JavaScript specific build
system. But, when writing Java application, why would you need those
libraries? Java has pretty rich operating system API (think of java.nio,
missing in JavaScript) and there are plenty of libraries to deal with other
aspects of OS integration. Why would you need npm build system? Java has
other, well established build systems as well. Conclusion? The only thing
you'd want from Electron is the rendering p

Re: Pull request review.

[Emilian Bold]

I'm not on GitHub here, but any reason that test exists?

>From the looks of it we might as well delete it entirely.

--emi

‐‐‐ Original Message ‐‐‐

On 12 March 2018 9:46 PM, Hector Espert  wrote:

> Hi, I don't have permissions to request a review in github.
> 
> Could anyone review this pull request?
> 
> https://github.com/apache/incubator-netbeans/pull/419
> 
> Thanks, Hector.



-
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 external binaries and sha1 hash values from Maven Central

[Emilian Bold]

Maybe you should explain what exactly did you do and paste the exact error you 
get during the build.

It should be visible which file is getting downloaded and you could compare the 
hash yourself and see who's right or wrong.

--emi

‐‐‐ Original Message ‐‐‐

On 13 March 2018 2:48 AM, Christian Bourque  wrote:

> Hi all,
> 
> I'm currently trying to compile NetBeans 9.0 with a more recent Eclipse
> 
> JGit library (the one currently bundled with
> 
> NetBeans is 3 years old!) but I'm having a hard time with the hash (sha1)
> 
> value that is used by the build system that's
> 
> downloading the artefact from the Maven Central repository! When I build
> 
> NetBeans it says that the hash value
> 
> that I put in the binaries-list file doesn't match the hash of the artefact
> 
> found on Maven Central, but I took the hash
> 
> value directly from the Maven Central repository so I expected it to be
> 
> correct:
> 
> http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0.201803080745-r/
> 
> So then I decided to download the Eclipse JGit source code from GitHub:
> 
> https://github.com/eclipse/jgit/releases/tag/v4.11.0.201803080745-r
> 
> compile it and generate the sha1sum myself. To my surprise the computed
> 
> checksum was equal to the one expected by NetBeans during the build process.
> 
> So I'm a bit puzzled! If the build script is downloading an external
> 
> dependency from Maven Central then the hash should
> 
> match the one found in this file:
> 
> http://central.maven.org/maven2/org/eclipse/jgit/org.eclipse.jgit/4.11.0.201803080745-r/org.eclipse.jgit-4.11.0.201803080745-r.jar.sha1
> 
> Anyway, if anyone could shed some light on this situation I would really
> 
> appreciate it!
> 
> Thanks,
> 
> Christian



-
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

[Jan Lahoda]

Hi Victor,

Thanks for looking at this. Some comments inline.

On Tue, Mar 13, 2018 at 12:02 AM, Victor Williams Stafusa da Silva <
victorwssi...@gmail.com> wrote:

> Anyway, independent of how much lombok finger-pointing, blaming or flaming
> we have, there seems to be something indeed problematic in Netbeans side.
> If I use Maven or Gradle to build a non-modular lombok project in Java 9,
> it builds correctly afterall, but Netbeans chokes with that.
>
> Looking at the source, the problems comes from line 113 of
> PatchModuleFileManager, which is this:
>
> final URL url = fo.toUri().toURL();
>
> This is the link:
>
> https://github.com/apache/incubator-netbeans/blob/
> master/java.source.base/src/org/netbeans/modules/java/source/parsing/
> PatchModuleFileManager.java#L113
>
> That "fo" is a javax.tools.JavaFileObject instance probably provided by
> lombok or by something else related. The toUri() method provides a
> java.net.URI object which is then converted to a java.net.URL. However, the
> toURL() method throws an exception for URIs that aren't absolute.
>
> Although I can go on to the lombok source trying to understand how and why
> the heck the non-absolute URI is generated and also talk with them about
> the issue, I first want to know if JavaFileObject instances should be
> allowed to have non-absolute URIs, since the toUri() method javadocs are
> silent about that.
>
> The Netbeans code clearly and strongly assumes that whichever instance of
> JavaFileObject received will always provide an URI which can be derived to
> a URL (and so, the URI has to be absolute). The URL is compared with many
>

I believe the code in NetBeans expects that it will get JFOs which NetBeans
has constructed. Which apparently is not the case here. This is not a
completely wrong assumption: I am not aware about any API that would allow
to inject external JFOs into javac. I guess a solution here might be to
ignore unknown JFOs, which is what the standard file manager in javac is
doing, for better or worse.

URL keys of a Map to see if it is a child of some of those accordingly to
> the toExternalForm() method (which produces a String). The keys to the Map
> are produced by the parseModulePatches(Iterator) method
> of the org.netbeans.modules.java.source.parsing.FileObjects class.
>
> My first tought is that the URI indeed must be absolute in order to clearly
> be able to refer to a unambiguously identifiable resource.
>
> But on a second thought, it might (or might not) make sense that
> code-generating tools provides URIs that aren't absolute.
>
> On a third tought, even if non-absolute URIs make no sense, Netbeans could
> try to provide some defense against that (i.e: if the URI is a "file://" or
> "jar://", but is not absolute, normalize it before proceeding). This would
> not only serve the purpose of defending from questionable practices on
> lombok side, but on any other weird code-generation-on-the-fly tool that
> will come around in the next corner tomorrow. Since there is no clear and
> explicit requirement that the toURI() method shoudl provide an absolute
> URI, trying something to remedy the situation if that occurs might be a
> good idea.
>
> On a forth thought, as I said in this list in a moment last year (looking
> for that very same issue, but had not enough time to chase it deeper),
> using URLs instead of URIs seems to be dangerous because the equals method
> of the URL class sucks, making it a poor choice as a key to a map. However
> (as someone also said at that time), we are still in the safe side because
> the URL's equals method delegates the work to the StreamHandler which have
> no problems when the protocol is "file://" and "jar://", which are the ones
> produced from java.util.File by the inner guts of the parseModulePatches
> method
> (if we ever change that by producing an "http://"; URL somewhere, we would
> be screwed, so I consider this approach fragile and questionable at least).
> But, thinking about the code, I see a loop bruteforcing a bunch of URLs
> trying to match the JavaFileObject with any of them, for every
> JavaFileObject that eventually comes along. This doesn't seems to be an
> efficient approach for this problem on the Netbeans side.
>

I guess a good proposal to make this more efficient would be welcome.

The goal here is to find out if a given file belongs to any of the given
source roots. So the file's path is inside a given root, so it is not easy
to just look into some map and get the output. As far as I know, there are
two solutions for this method:
-the one used here in NetBeans: iterate over the roots, and ask if the
given file is inside the root
-the one used in javac: look at parents of the given file, to find out if
some of them is the root.

It is difficult to say which of these is better, but the NB implementation
does not seem necessarily bad: I'd expect the number of entries in the map
to be very small (and typically zero), so iterating through the map should
b

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Emilian Bold]

HTML4J goes the wrong way in providing a migration path.

We don't need new ways to embed components into Swing. We could already embed 
JavaFX stuff and now we can also embed HTML stuff (rendered by JavaFX).

We need a way to render Swing on a web browser canvas!

Then, after Swing is fully in the browser we can decide that instead of having 
a canvas there just replace that topcomponent rectangle area with a div.

So, for new apps HTML4J makes more sense.

For NetBeans HTML4J only makes sense if we start a multi-year process of slowly 
migrating to HTML4J and then, in the far future, realise we migrated so much we 
might as well switch the whole main window from a JFrame to a browser tab.
  This plan would probably make sense in a corporation like Oracle, but will no 
do well under Apache, also because we would have our own technology stack that 
no contributor would use elsewhere. Mozilla also had XULRunner and people 
didn't really flock to it. 

--emi

‐‐‐ Original Message ‐‐‐

On 12 March 2018 5:59 PM, Jaroslav Tulach  wrote:

> > "Oracle has begun conversations with interested parties in the Java
> 
> > ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
> > 
> > > > > referenced timeframes."
> 
> The official announcement is here and people are finally starting to
> 
> realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
> 
> will sponsor development of anything new for these technologies. Even if
> 
> they get transfered to their new owners, they will be in maintenance mode:
> 
> Bugfixes and little features. No bigger changes - no new rendering
> 
> pipelines using new nifty features of graphics cards. Just sustaining. I've
> 
> been explaining this would happen since 2012.
> 
> To help us out of this situation and save Java as a programming language I
> 
> dedicated my days to smoothing out interoperability between Java and
> 
> JavaScript with the goal to reuse the most flexible and portable rendering
> 
> system of these days: the browser. My work has already been donated to
> 
> Apache, see: https://github.com/apache/incubator-netbeans-html4j \- let's
> 
> use it to build new features of NetBeans and other future Java desktop
> 
> applications. Get started by reading Javadoc at
> 
> http://bits.netbeans.org/html+java/
> 
> Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
> 
> care about Java, then your future should be Apache HTML/Java API!
> 
> -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: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Tim Boudreau]

First - we're talking 8 years from now.  Eight years is a long time.  That
doesn't mean don't be ready for it, but it does mean don't panic.
Secondly, what it means is that Oracle doesn't plan to develop AWT and
Swing after that point.  That doesn't mean nobody will or could.

That said, the way AWT does graphics is optimized for the XWindows of the
90s, and does not play nicely with what modern graphics cards actually do
today.  That was really the promise of JavaFX in its final, neutered,
too-late form - a modern graphics pipeline.

Re Electron:  Think of what Electron actually *is* - it bundles *all* of
Chromium.  I feel this pain particularly since I run Gentoo and build my
entire system and all its software from source - Chromium builds lately
take about 5-7 hours (on a 3Ghz i7 with 8Gb and SSD!) - while nothing else
on my system takes more than a few minutes.  For a while I had Atom
installed, which uses Electron.  Building that from source added another 8
hours to every time I updated my system - turning what used to be an hour
or so to update everything into something akin to compiling the Linux
kernel on a 486 - check back tomorrow to see if it's done.

I also, using Gentoo and frequently MongoDB, lived through MongoDB's brief
dalliance with depending on and linking, then bundling, then getting rid of
v8 - and the big problem there was that v8's ABI was broken incompatibly
very regularly.  I expect Electron will suffer that pain as well, and
eventually go through some growing pains that likely result in forking what
they depend on, or writing their own replacement + vanilla WebKit or
something like that.  Not to mention that, both in terms of build times and
size, there will be pressure from people developing on it to please, please
make the gargantuan runtime smaller.  In other words, to do exactly the
same kind of splitting the JDK finally began to undergo with JDK 9.  Any
solves-all-your-desktop-application-problems platform is going to wind up
recapitulating a lot of the history of the Java platform.


I thought Oracle's effort to make NetBeans into a web-based IDE was likely
misguided - I don't want to program in a web browser and don't know anyone
who does, and doing that rules out using well, pick-any-unix-text-utility -
it's a huge step backwards in development tooling.  But I liked the idea
that it forced decoupling the functionality of the IDE from AWT and Swing,
so from that perspective it's goodness.

The only good I see out of doing the UI in HTML and Javascript is, finally,
a solution to blocking the UI on I/O, which is a bug baked so deeply into
NetBeans APIs it can't be eliminated without a separate UI layer on top of
the existing one.  I don't actually think it's a great way to go - for
anyone who wrote dynamic HTML with Javascript in the 90s or early 2000s,
how much of your code still works?  Browsers are a moving target in a way
Swing never was.

To my instincts, preferable would probably be some OpenGL-based toolkit for
the basic drawing and interaction support, and take it from there with a
small suite of custom components on top of that, in terms of
cost-of-maintenance and stability.  The brave new world of modern web
development - and I just spent a bunch of time working on a React project
(and spent a bunch of time patching a drag and drop library because Chrome
stopped allowing you to call consume() on touch events unless you do
something special when you register your listener - code which worked fine
a few months before) - doesn't really do backward compatibility - which
means keeping an HTML-based NetBeans actually working for users requires a
large, permanent ongoing investment of work that's more costly than
maintaining a handful of UI components where, once you have a button
component that works, it works forever.  I see the appeal of HTML in that
it's omnipresent, and at present looks like it's sucked all the air out of
the user interface room - but I also remember when Javascript was dead, and
when Windows had killed Unix.

-Tim

List of options of "cluster.config"

[Peter Cheung]

Hi All
   How to know/get the list of options of parameter “cluster.config”?

$ ant -Dcluster.config=platform

Thanks
From Peter

AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[toni.epple]

Hi Wade,

I agree, desktop isn't going away. At DukeScript we're using HTML4J Apis mainly 
for desktop applications. The Java Desktop Application is just using a 
HTML5-Component ("browser") to render the view instead of a native or Java 
rendering pipeline. 

Since the separation of view and view logic is very clean the view technology 
can be completely replaced. In some of our commercial projects we used 
Controls4J to render the view, in others plain HTML and CSS. I've got working 
prototypes that use native controls instead on iOS and Android. Even one that 
renders to JavaFX that I sometimes use for debugging. 

And unlike Swing or JavaFX browsers are evolving at great speed and getter 
better day by day without any investment on our side. That's a great benefit if 
you compare that to the sluggish development of Swing and JavaFX that we've 
seen in the past years.  

I think that the stuff that Sean does with the crippled JavaFX 3D API is 
amazing, but think about what he could do with a really good 3D API, like the 
many that exist for WebGL. 

--Toni





 





-Ursprüngliche Nachricht-
Von: Wade Chandler  
Gesendet: Dienstag, 13. März 2018 05:54
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from 
Oracle JDK

On Mar 12, 2018 11:59, "Jaroslav Tulach"  wrote:

> "Oracle has begun conversations with interested parties in the Java

> ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
 referenced timeframes."

>>>
>>
The official announcement is here and people are finally starting to realize 
the truth: There is no future for JavaFX, AWT and Swing. Nobody will sponsor 
development of anything new for these technologies. Even if they get transfered 
to their new owners, they will be in maintenance mode:
Bugfixes and little features. No bigger changes - no new rendering pipelines 
using new nifty features of graphics cards. Just sustaining. I've been 
explaining this would happen since 2012.

To help us out of this situation and save Java as a programming language I 
dedicated my days to smoothing out interoperability between Java and JavaScript 
with the goal to reuse the most flexible and portable rendering system of these 
days: the browser. My work has already been donated to Apache, see: 
https://github.com/apache/incubator-netbeans-html4j - let's use it to build new 
features of NetBeans and other future Java desktop applications. Get started by 
reading Javadoc at http://bits.netbeans.org/html+java/

Forget about AWT, Swing and JavaFX - the future is HTML. In case you still care 
about Java, then your future should be Apache HTML/Java API!


Personally, I feel if that is true, then why all the hodgepodge, and why not 
just Electron which is already driving window creation and interacting with the 
desktop? Then, why not wasm and a real type safe language, and not TypeScript 
nor JS? Or maybe just VS Code plugins?

Why use the browser for all that if there is a desktop need? I mean, is it just 
me, or does that all just feel wrong?

Look at how many resources the Slack and VS Code apps need just running a few 
simple things, and they exist how they are, and are successful because people 
want to use the desktop app, and not tabs in their browsers. Then there are all 
the tricks to access the file system indirectly.

I don't see the desktop app disappearing for specific types of applications, 
and IMO that includes IDEs. Who wants to do all that work in browser tabs? 
Nobody. Electron is a desktop app environment. It isn't a container or a 
browser bound environment even if a browser is a component.

So what is the benefit of doing away with better rendering pipelines and direct 
resource access just to wind up manipulating a slow and bloated DOM in its 
place? Folks should checkout things Sean Phillips is doing with Java FX inside 
NB RCP Swing.

I think IntelliJ shows that a successful Swing based product can be a winner 
just as NetBeans has, and doesn't seem to be slowing down nor changing 
directions. To me it seems more feasible to support Swing itself for our needs, 
and continue making NB and NB RCP unique if we can be involved. Otherwise, 
isn't it VS Code or Eclipse Che ideas, just far behind?

Wade


-
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