date:20171108

But Dave's idea of including Automatic-Module-Name would make HTML/Java API
an automatic JDK 9 module (
http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html).

Maybe a cool idea, what would the problem be, and maybe Dave should provide
a pull request for this?

Gj

On Thu, Nov 9, 2017 at 6:39 AM, Jaroslav Tulach 
wrote:

> Hello Dave,
> I know little about desirable changes to target JDK9. However if you want
> to start development that would bring HTML/Java API closer to JDK9, you are
> more than welcomed. Of course, that would be for some future release, not
> 1.5.x.
> -jt
>
>
> 2017-11-09 0:52 GMT+01:00 Dave Schoorl :
>
> > Should we not add Automatic-Module-Name attribute to the jar's manifests,
> > now that Java9 is out? Especially since these files end up in public
> maven
> > repo.
> >
> > Kind regards,
> >
> > Dave
> >
> >
> > Op 8 november 2017 om 20:40 schreef Jaroslav Tulach <
> > jaroslav.tul...@gmail.com>:
> >
> > OK, the bits are now in
> > https://dist.apache.org/repos/dist/release/incubator/
> > netbeans/incubating-netbeans-html4j/
> > directory since revision 23014.
> >
> > Since revision 23015 the files are removed from the
> > https://dist.apache.org/repos/dist/dev/incubator/netbeans/
> > directory.
> >
> > The release 1.5 is out! Time to prepare 1.5.1...
> > -jt
> >
> > 2017-11-07 17:20 GMT+01:00 Bertrand Delacretaz :
> >
> > On Mon, Nov 6, 2017 at 4:54 PM, Jaroslav Tulach
> >
> >  wrote:
> >
> > ...Does it still make sense to do official release of
> > version 1.5 or can we skip that?...
> >
> > IIUC the only thing left is to move that release under
> > /dist/release/incubator/netbeans - I think you should do it to
> > demonstrate the complete process.
> >
> > If you don't expect people to use that release it's fine to avoid
> > "advertising" it.
> >
> > -Bertrand
> >
>

Re: [RESULT]: [VOTE] Release 1.5 of NetBeans HTML/Java API

Hello Dave,
I know little about desirable changes to target JDK9. However if you want
to start development that would bring HTML/Java API closer to JDK9, you are
more than welcomed. Of course, that would be for some future release, not
1.5.x.
-jt


2017-11-09 0:52 GMT+01:00 Dave Schoorl :

> Should we not add Automatic-Module-Name attribute to the jar's manifests,
> now that Java9 is out? Especially since these files end up in public maven
> repo.
>
> Kind regards,
>
> Dave
>
>
> Op 8 november 2017 om 20:40 schreef Jaroslav Tulach <
> jaroslav.tul...@gmail.com>:
>
> OK, the bits are now in
> https://dist.apache.org/repos/dist/release/incubator/
> netbeans/incubating-netbeans-html4j/
> directory since revision 23014.
>
> Since revision 23015 the files are removed from the
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/
> directory.
>
> The release 1.5 is out! Time to prepare 1.5.1...
> -jt
>
> 2017-11-07 17:20 GMT+01:00 Bertrand Delacretaz :
>
> On Mon, Nov 6, 2017 at 4:54 PM, Jaroslav Tulach
>
>  wrote:
>
> ...Does it still make sense to do official release of
> version 1.5 or can we skip that?...
>
> IIUC the only thing left is to move that release under
> /dist/release/incubator/netbeans - I think you should do it to
> demonstrate the complete process.
>
> If you don't expect people to use that release it's fine to avoid
> "advertising" it.
>
> -Bertrand
>

Re: [RESULT]: [VOTE] Release 1.5 of NetBeans HTML/Java API

2017-11-08 Thread Dave Schoorl

Should we not add Automatic-Module-Name attribute to the jar's manifests, now 
that Java9 is out? Especially since these files end up in public maven repo.

Kind regards,

Dave


Op 8 november 2017 om 20:40 schreef Jaroslav Tulach :

OK, the bits are now in
https://dist.apache.org/repos/dist/release/incubator/netbeans/incubating-netbeans-html4j/
directory since revision 23014.

Since revision 23015 the files are removed from the
https://dist.apache.org/repos/dist/dev/incubator/netbeans/
directory.

The release 1.5 is out! Time to prepare 1.5.1...
-jt

2017-11-07 17:20 GMT+01:00 Bertrand Delacretaz :

On Mon, Nov 6, 2017 at 4:54 PM, Jaroslav Tulach

 wrote:

...Does it still make sense to do official release of
version 1.5 or can we skip that?...

IIUC the only thing left is to move that release under
/dist/release/incubator/netbeans - I think you should do it to
demonstrate the complete process.

If you don't expect people to use that release it's fine to avoid
"advertising" it.

-Bertrand

RE: Give JavaHelp a chance! was: Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread Jan Tosovsky

Btw, what is the source for NetBeans help?

Some content is now distributed as JavaHelp, some is hosted here: 
https://docs.oracle.com/netbeans/nb82/netbeans/NBDAG/gs_nbeans.htm#NBDAG111

>From my point of view:

JavaHelp 
+ context sensitive help
+ search capabilities
- HTML 3.2 with very limited CSS support
- ugly UI

HTML based help (e.g. DocBook WebHelp)
+ HTML5, responsivity
+ search capabilities using Lucene search index
- context sensitive help needs a special handling:
  (a) a special mapping 'context ID -> URL' is required 
  (b) as opening a browser and passing an URL with a fragment identifier is 
buggy in Java, a special strategy has to be employed

If the help source was DocBook, that WebHelp output could be generated quite 
'easily'. But in this case I'd rather recommend my fork (yet to be distributed 
on GitHub) without jQuery/jQueryUI dependencies and with some additional 
features (responsivity, breadcrumb).

See the real example at https://www.bilyujezd.cz/ (not at all related to 
programming :-)

Jan


> -Original Message-
> From: Antonio Vieiro [mailto:anto...@vieiro.net]
> Sent: Wednesday, November 8, 2017 12:38 PM
> To: dev@netbeans.incubator.apache.org
> Subject: Re: Give JavaHelp a chance! was: Release Apache NetBeans 9.0
> Alpha (incubating)
> 
> So, what about using DocBook Web Help [1]? After all nowadays all
> users have a web browser, don't they?
> 
> They even have a maven plugin[2]. This is BSD licensed. The results
> [3] look acceptable to me.
> 
> We could even try to fork the project (maybe it's unmaintained)?
> 
> Cheers,
> Antonio
> 
> [1] http://blog.kasunbg.org/2010/08/docbook-webhelp-project.html
> [2] http://docbkx-tools.sourceforge.net/docbkx-samples/manual.html
> [3]
> http://docbook.sourceforge.net/release/xsl/current/webhelp/docs/index.h
> tml
> 
> 2017-11-08 12:19 GMT+01:00 Geertjan Wielenga
> :
> > Here's the issue relating to JavaHelp, would be best to
> track/document
> > everything there:
> >
> > https://issues.apache.org/jira/browse/NETBEANS-3
> >
> > Gj
> >
> > On Wed, Nov 8, 2017 at 11:26 AM, Jan Lahoda  wrote:
> >
> >> On Wed, Nov 8, 2017 at 10:40 AM, Ate Douma  wrote:
> >>
> >> >
> >> >
> >> > On 2017-11-08 09:52, Jaroslav Tulach wrote:
> >> >
> >> >> Hello Ate,
> >> >> thanks for trying the NetBeans Platform 9.0 Alpha bits.
> >> >>
> >> >>
> >> >>  > And that still has status "To do". Furthermore, it depends on
> the
> >> *GPL*
> >> >>
> >> >> external jsearch-2.0_05.jar which is a no-go... for the ASF.
> >> >> See: https://www.apache.org/legal/resolved.html#category-x
> >> >> 
> >> >>
> >> >> ...
> >> >>  >
> >> >>
> >> >> Note that the binary also includes the jsearch jar.
> >> >> And while the binary isn't the release itself, if/when a
> convenience
> >> >> binary is provided *then* it needs to be in compliance with
> the
> >> >> distribution rules. So no GPL artifacts allowed.
> >> >>
> >> >>
> >> >> Yes, NetBeans depends on JavaHelp and JavaHelp has been developed
> under
> >> >> GPLv2 with CP exception. However the last commit has been made
> ten years
> >> >> ago by me or Jesse Glick - e.g. nobody cares about JavaHelp
> anymore.
> >> That
> >> >> means there are no business reasons to keep JavaHelp under GPLv2.
> As
> >> such
> >> >> we are trying to convince Oracle to relicense JavaHelp and
> release it
> >> under
> >> >> more Apache friendly license.  toThere are at least two good
> reasons to
> >> do
> >> >> it:
> >> >>
> >> >> #1 - simplify NetBeans Apache incubation
> >> >> #2 - simplify acceptance of JavaEE into Eclipse Foundation (yes,
> JavaEE
> >> >> also needs JavaHelp for some reason)
> >> >>
> >> >> While we saw a bit of resistance when we used #1 as argument for
> >> >> re-licensing JavaHelp, things started to change when #2 issue
> showed
> >> up. As
> >> >> such we believe that the JavaHelp licensing issue will be
> resolved soon
> >> >> (measuring that in the glacier speed changes are happening in
> Oracle).
> >> In
> >> >> any case I believe in a year or two we can expected JavaHelp with
> a
> >> >> friendly license.
> >> >>
> >> >> Btw. there already is https://github.com/javaee/javahelp with
> CDDL
> >> >> license. A proof the JavaEE guys are solving the same problem.
> Maybe we
> >> can
> >> >> just use JavaHelp from that source and our GPL problems are gone.
> >> >>
> >> > Seems like a, or even the, direction to solve this.
> >> > If those 'JavaEE guys' can be persuaded to tag/release soon, then
> yes,
> >> > Netbeans can use (externally depend on) that JavaHelp version
> under the
> >> > CDDL license.
> >> > So I suggest start persuading them :-)
> >> >
> >> > In any case I don't think we need urgent surgery/lobotomy for 1st
> >> NetBeans
> >> >> Alpha (incubating) release. It may be wiser to wait until the
> problem
> >> >> solves itself >
> >> >> All I am asking: Please give JavaHelp a chance!
> >> >>
> >> >
> >> > Well, as long

[GitHub] geertjanw commented on issue #251: [NETBEANS-126] Re-instate browser icons

geertjanw commented on issue #251: [NETBEANS-126] Re-instate browser icons
URL: 
https://github.com/apache/incubator-netbeans/pull/251#issuecomment-342977366
 
 
   I'd suggest you start a new thread in the Apache NetBeans dev mailing list 
with this question, starting with [mentors] in the subject line to ensure 
they're notified of this question.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] geertjanw closed pull request #260: [NETBEANS-129] For source zips, alter the nbbuild/cluster.properties ?

geertjanw closed pull request #260: [NETBEANS-129] For source zips, alter the 
nbbuild/cluster.properties ?
URL: https://github.com/apache/incubator-netbeans/pull/260
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/nbbuild/build.xml b/nbbuild/build.xml
index db1024677..121e12e04 100644
--- a/nbbuild/build.xml
+++ b/nbbuild/build.xml
@@ -1515,14 +1515,24 @@ It is possible to use -Ddebug.port=3234 -Ddebug.pause=y 
to start the system in d
 
 
 
+
+
+
+
+
+
+
+
 
   
   
   
+  
   
   
   
   
+  
   
   
   


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] geertjanw closed pull request #261: Removing notice fragments that are unnecessary per the release vote t?

geertjanw closed pull request #261: Removing notice fragments that are 
unnecessary per the release vote t?
URL: https://github.com/apache/incubator-netbeans/pull/261
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/junitlib/external/junit-4.12-notice.txt 
b/junitlib/external/junit-4.12-notice.txt
deleted file mode 100644
index 952103043..0
--- a/junitlib/external/junit-4.12-notice.txt
+++ /dev/null
@@ -1,2 +0,0 @@
-JUnit 4.12 is licensed under EPL-v10.
-See https://www.eclipse.org/legal/epl-v10.html.
diff --git a/libs.felix/external/org.apache.felix.main-4.2.1-notice.txt 
b/libs.felix/external/org.apache.felix.main-4.2.1-notice.txt
index 49171bdb6..8b4b009ac 100644
--- a/libs.felix/external/org.apache.felix.main-4.2.1-notice.txt
+++ b/libs.felix/external/org.apache.felix.main-4.2.1-notice.txt
@@ -1,7 +1,3 @@
-
-Apache Felix Main
-Copyright 2006-2013 The Apache Software Foundation
-
 This product includes software developed at
 The OSGi Alliance (http://www.osgi.org/).
 Copyright (c) OSGi Alliance (2000, 2012).
diff --git a/nbbuild/build.xml b/nbbuild/build.xml
index db1024677..ae53891ac 100644
--- a/nbbuild/build.xml
+++ b/nbbuild/build.xml
@@ -1475,6 +1475,14 @@ It is possible to use -Ddebug.port=3234 -Ddebug.pause=y 
to start the system in d
   
   
+  
+  
+  
+  
+ 
+  
 
 
   
   
+   includes="*/notice.txt" />
+  
+  
+  
+  
+  
+  
 
 
   
diff --git a/nbbuild/notice-stub.txt b/nbbuild/notice-stub.txt
index 16737de03..5bfd3e752 100644
--- a/nbbuild/notice-stub.txt
+++ b/nbbuild/notice-stub.txt
@@ -5,4 +5,5 @@ This product includes software developed at
 The Apache Software Foundation (http://www.apache.org/).
 
 The code is based on NetBeans Copyright (c) Oracle Corp
-that has been kindly donated to the Apache Software Foundation.
\ No newline at end of file
+that has been kindly donated to the Apache Software Foundation.
+
diff --git 
a/net.java.html.boot.fx/external/net.java.html.boot.fx-1.5-notice.txt 
b/net.java.html.boot.fx/external/net.java.html.boot.fx-1.5-notice.txt
deleted file mode 100644
index 7c16fe38c..0
--- a/net.java.html.boot.fx/external/net.java.html.boot.fx-1.5-notice.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-
-FX WebView Bootstrap
-Copyright 2017 NetBeans
-
-This product includes software developed at
-The Apache Software Foundation (http://www.apache.org/).
-
-
diff --git 
a/net.java.html.boot.script/external/net.java.html.boot.script-1.5-notice.txt 
b/net.java.html.boot.script/external/net.java.html.boot.script-1.5-notice.txt
deleted file mode 100644
index ee3ec2a82..0
--- 
a/net.java.html.boot.script/external/net.java.html.boot.script-1.5-notice.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-
-Presenter via javax.script
-Copyright 2017 NetBeans
-
-This product includes software developed at
-The Apache Software Foundation (http://www.apache.org/).
-
-
diff --git a/net.java.html.boot/external/net.java.html.boot-1.5-notice.txt 
b/net.java.html.boot/external/net.java.html.boot-1.5-notice.txt
deleted file mode 100644
index f24655d25..0
--- a/net.java.html.boot/external/net.java.html.boot-1.5-notice.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-
-Browser Bootstrap
-Copyright 2017 NetBeans
-
-This product includes software developed at
-The Apache Software Foundation (http://www.apache.org/).
-
-
diff --git a/net.java.html.geo/external/net.java.html.geo-1.5-notice.txt 
b/net.java.html.geo/external/net.java.html.geo-1.5-notice.txt
deleted file mode 100644
index 053a84375..0
--- a/net.java.html.geo/external/net.java.html.geo-1.5-notice.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-
-Geolocation API
-Copyright 2017 NetBeans
-
-This product includes software developed at
-The Apache Software Foundation (http://www.apache.org/).
-
-
diff --git a/net.java.html.json/external/net.java.html.json-1.5-notice.txt 
b/net.java.html.json/external/net.java.html.json-1.5-notice.txt
deleted file mode 100644
index d5325846b..0
--- a/net.java.html.json/external/net.java.html.json-1.5-notice.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-
-JSON Model in Java
-Copyright 2017 NetBeans
-
-This product includes software developed at
-The Apache Software Foundation (http://www.apache.org/).
-
-
diff --git a/net.java.html.sound/external/net.java.html.sound-1.5-notice.txt 
b/net.java.html.sound/external/net.java.html.sound-1.5-notice.txt
deleted file mode 100644
index 559b34db8..0
--- a/net.java.html.sound/external/net.java.html.sound-1.5-notice.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-
-Sound API via HTML
-Copyright 2017 NetBeans
-
-This product includes software developed at
-The Apache Softwa

Re: [VOTE] Release Apache NetBeans 9.0 Alpha (incubating)

Yup, agreed.

Great work, thanks.

Gj

On Wed, 8 Nov 2017 at 21:36, Jan Lahoda  wrote:

> Thanks Ate, I tried to clean up the notice fragments here:
> https://github.com/apache/incubator-netbeans/pull/261
>
> Overall, what we need to fix seems to be:
> -the notices:
> https://github.com/apache/incubator-netbeans/pull/261
> -change the cluster.config in the source zip so that it only refers to the
> cluster config packed in the zip:
> https://github.com/apache/incubator-netbeans/pull/260
> -not copy the ide launchers to the platform (working on that, but not done
> yet)
> -delete inclusion of jsearch.jar in apisupport.harness (should be trivial
> by itself)
> -add a README - this I guess may be the trickiest fix, as that needs to be
> different for the platform and for the IDE
>
> Geertjan, it might make sense to cancel the vote and restart it when this
> is done (as these changes are significant).
>
> Jan
>
>
> On Wed, Nov 8, 2017 at 4:16 PM, Ate Douma  wrote:
>
> >
> >
> > On 2017-11-08 11:18, Jan Lahoda wrote:
> >
> >> On Wed, Nov 8, 2017 at 10:44 AM, Ate Douma  wrote:
> >>
> >> On 2017-11-08 07:54, Jan Lahoda wrote:
> >>>
> >>> Hi Ate,
> 
>  Thanks a lot for your review and comments.
> 
>  On Wed, Nov 8, 2017 at 12:04 AM, Ate Douma  wrote:
> 
>  I get a different build error:
> 
> >
> > BUILD FAILED
> > /home/ate/tmp/netbeans/netbeans-platform-source-platform-9.
> > 0-alpha/nbbuild/build.xml:122:
> > Download of 276009D3F0A27079A80D241C3183EC
> > 712305A42A-net.java.html.boot.
> > script-1.5.jar
> > produced content with hash 5DE9DD70EDCD9B30E0671ACC813F6F0C80E951AA
> > when
> > 276009D3F0A27079A80D241C3183EC712305A42A was expected
> >
> >
> > Sorry, not sure what is happening, I tried to download:
>  https://search.maven.org/remotecontent?filepath=org/netbeans
>  /html/net.java.html.boot.script/1.5/net.java.html.boot.script-1.5.jar
> 
>  and it seems to have sha1sum:
>  276009d3f0a27079a80d241c3183ec712305a42a
> 
> 
> >>> Indeed, if I download the above manually I can confirm it to have the
> >>> expected sha1sum.
> >>>
> >>> The problem seems to be caused by my local maven repository already
> >>> having these artifacts, and *those* have different sha1sum...
> >>> Disabling my local maven repository 'fixed' this and the build
> succeeds.
> >>> And ant tryme does start the platform now.
> >>>
> >>>
> >>>
>  But disregarding the above, I think a more serious, blocking, issue is
> 
> > that AFAICT *not* all platform modules have been reviewed yet.
> > I notice this release candidate includes the apisupport.harness
> module.
> > And that still has status "To do". Furthermore, it depends on the
> *GPL*
> > external jsearch-2.0_05.jar which is a no-go... for the ASF.
> > See: https://www.apache.org/legal/resolved.html#category-x
> >
> >
> 
>  Oops, sorry I missed this one  I think there's no other solution than
> to
>  simply remove that. The build of a platform application modules that
>  have
>  help will then (I believe) fail, but users should  be able to supply
> the
>  jar manually.
> 
> 
> >>> Just provide a README (and not just for this reason, see my other
> >>> problem starting the binary) which explains users what they need to do
> >>> *if* they want/need to use help.
> >>>
> >>> With regards to the current release candidate I've to vote -1 based on
> >>> the current findings as IMO this one is blocking.
> >>>
> >>> (An alternative would be to make such a build pass with a
> >>>
>  warning, but since that would lead to a wrongly built module, it is
>  better
>  to continue failing IMO.)
> 
>  (We may need to enhance the license checking task to fail on GPL.)
> 
> 
> >>> It most definitely should fail on encountering GPL.
> >>>
> >>>
> >>>
> 
> > I haven't looked in more detail yet, but before spending more time on
> > it
> > I'd like to know if the inclusion of the harness module is an
> oversight
> > which can be quickly fixed. Regardless, I think this should be fixed
> > first.
> >
> >
> > I was thinking of removing the harness, but a) we would need to
> finish
>  work
>  on harness sometime soon anyway; b) I think the platform is more
> useful
>  with the harness than without it. So, I was fixing problems in the
>  harness
>  modules I've noticed.
> 
> 
>  Note that the binary also includes the jsearch jar.
> > And while the binary isn't the release itself, if/when a convenience
> > binary is provided *then* it needs to be in compliance with the
> > distribution rules. So no GPL artifacts allowed.
> >
> > I also see the bundled LICENSE and NOTICE files in the binary zip
> > are a bit weirdly formatted and the NOTICE file in particular.
> > Seems both are produced by concatenating several files togeth

Re: [JIRA-admin] Re: JIRA permission: Can't resolve issues

2017-11-08 Thread John McDonnell

Hi Matthias,

Sorry for the delay,  I did some digging this evening and it not just
the close permission needed in order to close a JIRA ticket...

Please, can you give this a shot again?


Regards

John

On 6 November 2017 at 19:05, Matthias Bläsing  wrote:
> Hi all,
>
> this is a request for persons that can change jira permissions. I sill
> can't resolve issues that I did not file. Please enable committers to
> resolve issues for the whole netbeans project.
>
> Thank you
>
> Matthias
>
>
> Am Dienstag, den 31.10.2017, 16:44 + schrieb John McDonnell:
>> I think the difference there, is that you opened the ticket, so you
>> can close it.
>>
>> I'll take another look when I get home from work, if I cant solve it
>> maybe we ask a mentor as I'm probably missing something...
>>
>> John
>>
>> On 31 October 2017 at 11:35, Matthias Bläsing > .eu> wrote:
>> > Hi John,
>> >
>> > Am Montag, den 30.10.2017, 20:34 + schrieb John McDonnell:
>> > > That's strange, since your in the jira-users group, and when we
>> > > looked at the permissions for assigning tickets, we made sure
>> > > that the
>> > > jira-users group was given the role of Contributor, and it seems
>> > > the
>> > > JIRA permission for resolving/closing tickets includes
>> > > contributors.
>> > >
>> > > That's about the extent of my knowledge.  If I have time tomorrow
>> > > I
>> > > might take another look unless someone gets there before me...
>> > >
>> > > On 30 October 2017 at 20:07, Matthias Bläsing > > > elix.eu> wrote:
>> > > >
>> > > > I successfully assigned an issue to me, but I'm missing the
>> > > > option
>> > > > to mark it resolved.
>> > > >
>> > > > For reference - this is the issue:
>> > > >
>> > > > https://issues.apache.org/jira/browse/NETBEANS-105
>> >
>> > thank you for looking into this. And maybe this can shed some light
>> > on
>> > this. I contrasted this with an issue I reported:
>> >
>> > https://issues.apache.org/jira/browse/NETBEANS-68
>> >
>> > There I can resolve the issue.
>> >
>> > HTH
>> >
>> > Matthias
>>
>>
>>



-- 
John

[GitHub] dtrebbien opened a new pull request #262: Fix NullPointerException at com.sun.source.util.TreePath.

dtrebbien opened a new pull request #262: Fix NullPointerException at 
com.sun.source.util.TreePath.
URL: https://github.com/apache/incubator-netbeans/pull/262
 
 
   Fixes https://netbeans.org/bugzilla/show_bug.cgi?id=271772


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: [VOTE] Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread Jan Lahoda

Thanks Ate, I tried to clean up the notice fragments here:
https://github.com/apache/incubator-netbeans/pull/261

Overall, what we need to fix seems to be:
-the notices:
https://github.com/apache/incubator-netbeans/pull/261
-change the cluster.config in the source zip so that it only refers to the
cluster config packed in the zip:
https://github.com/apache/incubator-netbeans/pull/260
-not copy the ide launchers to the platform (working on that, but not done
yet)
-delete inclusion of jsearch.jar in apisupport.harness (should be trivial
by itself)
-add a README - this I guess may be the trickiest fix, as that needs to be
different for the platform and for the IDE

Geertjan, it might make sense to cancel the vote and restart it when this
is done (as these changes are significant).

Jan


On Wed, Nov 8, 2017 at 4:16 PM, Ate Douma  wrote:

>
>
> On 2017-11-08 11:18, Jan Lahoda wrote:
>
>> On Wed, Nov 8, 2017 at 10:44 AM, Ate Douma  wrote:
>>
>> On 2017-11-08 07:54, Jan Lahoda wrote:
>>>
>>> Hi Ate,

 Thanks a lot for your review and comments.

 On Wed, Nov 8, 2017 at 12:04 AM, Ate Douma  wrote:

 I get a different build error:

>
> BUILD FAILED
> /home/ate/tmp/netbeans/netbeans-platform-source-platform-9.
> 0-alpha/nbbuild/build.xml:122:
> Download of 276009D3F0A27079A80D241C3183EC
> 712305A42A-net.java.html.boot.
> script-1.5.jar
> produced content with hash 5DE9DD70EDCD9B30E0671ACC813F6F0C80E951AA
> when
> 276009D3F0A27079A80D241C3183EC712305A42A was expected
>
>
> Sorry, not sure what is happening, I tried to download:
 https://search.maven.org/remotecontent?filepath=org/netbeans
 /html/net.java.html.boot.script/1.5/net.java.html.boot.script-1.5.jar

 and it seems to have sha1sum:
 276009d3f0a27079a80d241c3183ec712305a42a


>>> Indeed, if I download the above manually I can confirm it to have the
>>> expected sha1sum.
>>>
>>> The problem seems to be caused by my local maven repository already
>>> having these artifacts, and *those* have different sha1sum...
>>> Disabling my local maven repository 'fixed' this and the build succeeds.
>>> And ant tryme does start the platform now.
>>>
>>>
>>>
 But disregarding the above, I think a more serious, blocking, issue is

> that AFAICT *not* all platform modules have been reviewed yet.
> I notice this release candidate includes the apisupport.harness module.
> And that still has status "To do". Furthermore, it depends on the *GPL*
> external jsearch-2.0_05.jar which is a no-go... for the ASF.
> See: https://www.apache.org/legal/resolved.html#category-x
>
>

 Oops, sorry I missed this one  I think there's no other solution than to
 simply remove that. The build of a platform application modules that
 have
 help will then (I believe) fail, but users should  be able to supply the
 jar manually.


>>> Just provide a README (and not just for this reason, see my other
>>> problem starting the binary) which explains users what they need to do
>>> *if* they want/need to use help.
>>>
>>> With regards to the current release candidate I've to vote -1 based on
>>> the current findings as IMO this one is blocking.
>>>
>>> (An alternative would be to make such a build pass with a
>>>
 warning, but since that would lead to a wrongly built module, it is
 better
 to continue failing IMO.)

 (We may need to enhance the license checking task to fail on GPL.)


>>> It most definitely should fail on encountering GPL.
>>>
>>>
>>>

> I haven't looked in more detail yet, but before spending more time on
> it
> I'd like to know if the inclusion of the harness module is an oversight
> which can be quickly fixed. Regardless, I think this should be fixed
> first.
>
>
> I was thinking of removing the harness, but a) we would need to finish
 work
 on harness sometime soon anyway; b) I think the platform is more useful
 with the harness than without it. So, I was fixing problems in the
 harness
 modules I've noticed.


 Note that the binary also includes the jsearch jar.
> And while the binary isn't the release itself, if/when a convenience
> binary is provided *then* it needs to be in compliance with the
> distribution rules. So no GPL artifacts allowed.
>
> I also see the bundled LICENSE and NOTICE files in the binary zip
> are a bit weirdly formatted and the NOTICE file in particular.
> Seems both are produced by concatenating several files together, but
> the result is confusing, especially the NOTICE file.
>
>
> Yes, the NOTICE is a concatenation of several files, as i suspect it is
 not
 feasible to have a manually updated NOTICE file for each distribution we
 do. The form can surely be improved.


 The NOTICE file should only contain what is needed, nothing

[GitHub] jlahoda opened a new pull request #261: Removing notice fragments that are unnecessary per the release vote t?

jlahoda opened a new pull request #261: Removing notice fragments that are 
unnecessary per the release vote t?
URL: https://github.com/apache/incubator-netbeans/pull/261
 
 
   ?hread.
   
   Also tries to avoid unnecessary newlines in the NOTICE file, by coalescing 
multiple empty lines to a single line.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] jlahoda opened a new pull request #260: [NETBEANS-129] For source zips, alter the nbbuild/cluster.properties ?

jlahoda opened a new pull request #260: [NETBEANS-129] For source zips, alter 
the nbbuild/cluster.properties ?
URL: https://github.com/apache/incubator-netbeans/pull/260
 
 
   ?so that the cluster.config property defaults to the cluster config packed 
in the zip.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: [RESULT]: [VOTE] Release 1.5 of NetBeans HTML/Java API

OK, the bits are now in
https://dist.apache.org/repos/dist/release/incubator/netbeans/incubating-netbeans-html4j/
directory since revision 23014.

Since revision 23015 the files are removed from the
https://dist.apache.org/repos/dist/dev/incubator/netbeans/
directory.

The release 1.5 is out! Time to prepare 1.5.1...
-jt

2017-11-07 17:20 GMT+01:00 Bertrand Delacretaz :

> On Mon, Nov 6, 2017 at 4:54 PM, Jaroslav Tulach
>  wrote:
> > ...Does it still make sense to do official release of
> > version 1.5 or can we skip that?...
>
> IIUC the only thing left is to move that release under
> /dist/release/incubator/netbeans - I think you should do it to
> demonstrate the complete process.
>
> If you don't expect people to use that release it's fine to avoid
> "advertising" it.
>
> -Bertrand
>

Re: HTML/Java checksums was: Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 15:12 GMT+01:00 Bertrand Delacretaz :

> Hi,
>
> On Wed, Nov 8, 2017 at 2:02 PM, Jaroslav Tulach
>  wrote:
> > ...this is a result of your previous testing of HTML/Java 1.5. You have
> built
> > the artifacts and they got into your local Maven repository

It is a Maven flaw that  it produces different artifacts with every new
build. But almost any build system is flawed this way. Unless I am mistaken
only Debian invested enormous amount of effort to create reproducible
builds of its artifacts.

> Does this means the platform build only works using binaries
> downloaded from search.maven.org, as opposed to binaries built
> locally?
>

The platform indeed works with libraries built locally. Once you change the
platform code to properly reference the binaries built locally.

>  If yes that's a problem IMO, developers should be able (and encouraged

> to) build everything themselves from sources.
>

Fine. But we also want stable and predictable build which will not suffer
from shaky network connections and/or man in middle attack. Right now I
prefer correctness of the build over developer's comfort.

>
> Nothing urgent but something to fix at some point, unless there's a
> workaround already.
>

The workaround is to change the binaries-list file to point to the locally
build JAR and to provide its correct checksum. That has worked acceptably
for last 17 years, so I think it will be fine for a while.
-jt

[VOTE] Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread Delfi Ramirez


+1

guest it's three counting on.

cheers




smime.p7s
Description: S/MIME Cryptographic Signature

[GitHub] geertjanw commented on issue #259: Sdedic/netbeans bugfixes

geertjanw commented on issue #259: Sdedic/netbeans bugfixes
URL: 
https://github.com/apache/incubator-netbeans/pull/259#issuecomment-342903023
 
 
   Excellent. Lots of new code for us to review. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Give JavaHelp a chance! was: Release Apache NetBeans 9.0 Alpha (incubating)

On Wed, Nov 8, 2017 at 4:30 PM, Ate Douma  wrote:

>
> Or postpone adding/providing the javahelp feature until its (downstream) 
> licenses
 are resolved.
>>>
>>>

+1

Gj

[GitHub] lbruun commented on a change in pull request #161: [NETBEANS-96] New PAC Script evaluation environment

lbruun commented on a change in pull request #161: [NETBEANS-96] New PAC Script 
evaluation environment
URL: https://github.com/apache/incubator-netbeans/pull/161#discussion_r149708351
 
 

 ##
 File path: 
core.network/src/org/netbeans/core/network/utils/hname/win/HostnameUtilsWin.java
 ##
 @@ -0,0 +1,110 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.netbeans.core.network.utils.hname.win;
+
+import com.sun.jna.Native;
+import com.sun.jna.platform.win32.Kernel32Util;
+import com.sun.jna.platform.win32.Win32Exception;
+import java.util.logging.Level;
+import java.util.logging.Logger;
+import org.netbeans.core.network.utils.IpAddressUtils;
+import org.netbeans.core.network.utils.NativeException;
+
+/**
+ * Hostname utilities for Microsoft Windows OS.
+ */
+public class HostnameUtilsWin {
+
+private static final Logger LOGGER = 
Logger.getLogger(HostnameUtilsWin.class.getName());
+
+/**
+ * Gets the computer name.
+ * 
+ * This is the also known as the NetBIOS name, although NetBIOS is 
+ * hardly used anymore. It is the same value as can be seen from the
+ * {@code COMPUTERNAME} environment variable.
+ * 
+ * 
+ * Windows API equivalent: {@code GetComputerName()} function from 
+ * {@code Kernel32} library.
+ * 
+ * @return computer name
+ * @throws NativeException if there was an error executing the
+ *system call.
+ */
+public static String getComputerName() throws NativeException {
 
 Review comment:
   About size: If that is a concern, how about the JNA project would consider 
splitting Platform jar into one jar per OS ?   :-)  COM in its own jar, of 
course, in order to further reduce size.
   
   Anyways, I don't see a size of > 2MB. When I look in the `.nbm` file I see a 
pack200'ed jar of approx 178 KB. 
   
   But if you feel it is important to get rid of JNA Platform lib then I'll be 
happy to extract the bits I need into the source. And I'll have to do the same 
in the next iterations of `core.network`, of course.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] sdedic opened a new pull request #259: Sdedic/netbeans bugfixes

sdedic opened a new pull request #259: Sdedic/netbeans bugfixes
URL: https://github.com/apache/incubator-netbeans/pull/259
 
 
   Hello. I was, too, somewhat bugfixing during the time between the Oracle 
donation to ASF and now, so here are my commits, bugfixes and some enhancements 
to Java, Hints, Java Shell and Refactoring.
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

RE: [VOTE] Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread Vincent.Sheard

+1


"Use the force"  http://microchip.wikidot.com/mplabx:start
Set the standard with the MPLAB X IDE!
Vince Sheard
(480) 792 7342


-Original Message-
From: Vadiraj Deshpande [mailto:vadira...@icloud.com] 
Sent: Tuesday, November 07, 2017 6:18 PM
To: d...@netbeans.apache.org
Subject: Re: [VOTE] Release Apache NetBeans 9.0 Alpha (incubating)

+1

On 2017-11-07 05:17, Geertjan Wielenga wrote: 
> Hi all,>
> 
> Please vote on releasing Apache NetBeans 9.0 Alpha (incubating)! If 
> this> voting passes, another similar voting will be started on> 
> gene...@incubator.apache.org, and if that passes too, then we can 
> release> this version.>
> 
> Apache NetBeans 9.0 Alpha (incubating) are the modules of Apache 
> NetBeans> that provide the application framework of NetBeans, that is, 
> the NetBeans> Platform.>
> 
> Build artifacts:>
> 
> https://builds.apache.org/view/Incubator%20Projects/job/incubator-netb
> eans-release/>
> 
> Source md5sum is 548058644764a07ef54568aa79a10aa1.>
> 
> The artifact to be voted on:>
> 
> https://builds.apache.org/view/Incubator%20Projects/job/incubator-netb
> eans-release/lastSuccessfulBuild/artifact/dist/netbeans-platform-sourc
> e-.zip>
> 
> Rat report shows no unknown licenses:>
> 
> https://builds.apache.org/view/Incubator%20Projects/job/incubator-netb
> eans-release/lastSuccessfulBuild/artifact/rat-temp/nbbuild/build/rat-r
> eport.txt>
> 
> Included as a convenience is a binary, unzip it and run it and you'll 
> see> the NetBeans Platform:>
> 
> https://builds.apache.org/view/Incubator%20Projects/job/incubator-netb
> eans-release/lastSuccessfulBuild/artifact/dist/netbeans-platform-bin-.
> zip>
> 
> Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and 
> NOTICE> files.>
> 
> Please try out the package and vote!>
> 
> The vote is open for a minimum of 72 hours or until the necessary 
> number of> votes (3 binding +1s) is reached.>
> 
> [ ] +1 Release this package as Apache NetBeans 9.0 Alpha (incubating)> 
> [ ] 0 I don't feel strongly about it, but I'm okay with the release> [ 
> ] -1 Do not release this package because...>
> 
> Please add "(binding)" if your vote is binding, i.e., you are an 
> Apache> NetBeans committer.>
> 
> Geertjan> 
> on behalf of the Apache NetBeans tea,>
>


Sent from my iPhone

Re: Give JavaHelp a chance! was: Release Apache NetBeans 9.0 Alpha (incubating)

On 2017-11-08 11:26, Jan Lahoda wrote:

On Wed, Nov 8, 2017 at 10:40 AM, Ate Douma  wrote:

On 2017-11-08 09:52, Jaroslav Tulach wrote:

Hello Ate,
thanks for trying the NetBeans Platform 9.0 Alpha bits.

  > And that still has status "To do". Furthermore, it depends on the *GPL*

 external jsearch-2.0_05.jar which is a no-go... for the ASF.
 See: https://www.apache.org/legal/resolved.html#category-x

 ...
  >

 Note that the binary also includes the jsearch jar.
 And while the binary isn't the release itself, if/when a convenience
 binary is provided *then* it needs to be in compliance with the
 distribution rules. So no GPL artifacts allowed.

Yes, NetBeans depends on JavaHelp and JavaHelp has been developed under
GPLv2 with CP exception. However the last commit has been made ten years
ago by me or Jesse Glick - e.g. nobody cares about JavaHelp anymore. That
means there are no business reasons to keep JavaHelp under GPLv2. As such
we are trying to convince Oracle to relicense JavaHelp and release it under
more Apache friendly license.  toThere are at least two good reasons to do
it:

#1 - simplify NetBeans Apache incubation
#2 - simplify acceptance of JavaEE into Eclipse Foundation (yes, JavaEE
also needs JavaHelp for some reason)

While we saw a bit of resistance when we used #1 as argument for
re-licensing JavaHelp, things started to change when #2 issue showed up. As
such we believe that the JavaHelp licensing issue will be resolved soon
(measuring that in the glacier speed changes are happening in Oracle). In
any case I believe in a year or two we can expected JavaHelp with a
friendly license.

Btw. there already is https://github.com/javaee/javahelp with CDDL
license. A proof the JavaEE guys are solving the same problem. Maybe we can
just use JavaHelp from that source and our GPL problems are gone.

Seems like a, or even the, direction to solve this.
If those 'JavaEE guys' can be persuaded to tag/release soon, then yes,
Netbeans can use (externally depend on) that JavaHelp version under the
CDDL license.
So I suggest start persuading them :-)

In any case I don't think we need urgent surgery/lobotomy for 1st NetBeans

Alpha (incubating) release. It may be wiser to wait until the problem
solves itself >
All I am asking: Please give JavaHelp a chance!

Well, as long as there is no alternative under an acceptable license,
the GPL license remains a blocker IMO to include the current version.

Just to be sure: it is OK to build against a GPL library, right? (Having it
optional at runtime.) We can strip the jsearch.jar for now, that's not that
big deal IMO (I can do that tonight, but not right now). But we have a
different version of JavaHelp against which we compile the NetBeans help;
and we have some more GPL libraries against which it would be much easier
to compile.

This is very much alike the nb-javac discussion, for which we have
explicit clearance from Apache Legal [1]. But we cannot automatically
assume the same clearance holds for any other type of GPL+CPE.

IMO this and likewise cases require one by one separate clearance (need
a separate LEGAL ticket) first.

Furthermore, we need to provide users instructions (or in the future
some kind of interactive dialog) how to *separately* download/provide
the 3rd party dependency with GPL+CPE license needed for it.
So they know about and accept the consequence of using that license.
To be sure: we can *not* bundle any form or variant of GPL artifacts in
the distribution!

Or postpone adding/providing the javahelp feature until its (downstream)
licenses are resolved.

Also to be clear: the above only is or might be applicable for GPL+CPE
(or LGPL) dependencies, but *never* for full GPL, e.g. we cannot and may
not have any form of direct/indirect usage/linking to full GPL source or
 artifact within the ASF.

[1] https://issues.apache.org/jira/browse/LEGAL-279

Jan

Unless, we can get an explicit exception for the restriction from the
Apache Legal Committee.
Which is not impossible but needs to be asked first, e.g. needs creating
a https://issues.apache.org/jira/browse/LEGAL ticket with the clear
use-case and explanation of what we need here.

Ate

-jt

[GitHub] lbruun commented on a change in pull request #161: [NETBEANS-96] New PAC Script evaluation environment

lbruun commented on a change in pull request #161: [NETBEANS-96] New PAC Script 
evaluation environment
URL: https://github.com/apache/incubator-netbeans/pull/161#discussion_r149642386
 
 

 ##
 File path: core.network/src/org/netbeans/core/network/utils/HostnameUtils.java
 ##
 @@ -0,0 +1,72 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.netbeans.core.network.utils;
+
+import com.sun.jna.Platform;
+
+/**
+ * Utility functions for finding the local computer's name. 
+ * 
+ *
+ * @author lbruun
+ */
+public class HostnameUtils {
+
+private HostnameUtils() {}
+
+
+/**
+ * Gets the name which is likely to be the local host's primary
+ * name on the network.
+ * 
+ * 
+ * IMPLEMENTATION:
+ * 
+ * 
+ *   On Unix-like OSes (incl Mac OS X) this is the value as returned 
from
+ *   the {@code gethostname()} function from the standard C Library. 

+ *   On Windows it is the value as returned from the
+ *   {@code gethostname()} function from {@code Ws2_32} library.
+ *   (without domain name). Note that this Windows function will do a 
+ *   name service lookup and the method is therefore potentially 
blocking, 
+ *   although it is more than likely that Windows has cached this 
result 
+ *   on computer startup in its DNS Client Cache and therefore the 
+ *   result will be returned very fast.
+ * 
+ * 
+ * @return host name
+ * @throws NativeException if there was an error executing the
+ *system call.
+ */
+public static String getNetworkHostname() throws NativeException {
 
 Review comment:
   Well, this is partly due to history. If I remember correctly, I used to use 
different functions on MacOSX and Linux. But through trials and tests I finally 
settled on using the same C lib function on everything but Windows. This 
decision may be reverted in the future, as this isn't a well defined discipline.
   
   The `hname` packages exist currently mainly as a way to get the host's 
_kernel name_, so that we can use that in an insane ride to find the host's own 
IP address. This functionality is mandated for PAC evaluator. 
   
   But when I started on the hname package, I thought of it as a general 
purpose package for everything related to the host's naming. For example, I 
wanted to add methods for getting the host's _display name_, e.g. "Joey's 
Laptop" and this is done very differently between OSes. This is another reason 
for the sub-packages per OS. I don't know if I'll ever get around to adding 
that. Right now the focus was on getting a working PAC evaluator as the 
existing one is broken. And frankly the host's display name has little usage 
except for use in About box and things like that.  :-)
   
   I would like to keep the subpackages and the delegation for now even if it 
is a lot of ceremony for nothing.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: [VOTE] Release Apache NetBeans 9.0 Alpha (incubating)




On 2017-11-08 11:18, Jan Lahoda wrote:

On Wed, Nov 8, 2017 at 10:44 AM, Ate Douma  wrote:


On 2017-11-08 07:54, Jan Lahoda wrote:


Hi Ate,

Thanks a lot for your review and comments.

On Wed, Nov 8, 2017 at 12:04 AM, Ate Douma  wrote:

I get a different build error:


BUILD FAILED
/home/ate/tmp/netbeans/netbeans-platform-source-platform-9.
0-alpha/nbbuild/build.xml:122:
Download of 276009D3F0A27079A80D241C3183EC712305A42A-net.java.html.boot.
script-1.5.jar
produced content with hash 5DE9DD70EDCD9B30E0671ACC813F6F0C80E951AA when
276009D3F0A27079A80D241C3183EC712305A42A was expected



Sorry, not sure what is happening, I tried to download:
https://search.maven.org/remotecontent?filepath=org/netbeans
/html/net.java.html.boot.script/1.5/net.java.html.boot.script-1.5.jar

and it seems to have sha1sum:
276009d3f0a27079a80d241c3183ec712305a42a



Indeed, if I download the above manually I can confirm it to have the
expected sha1sum.

The problem seems to be caused by my local maven repository already
having these artifacts, and *those* have different sha1sum...
Disabling my local maven repository 'fixed' this and the build succeeds.
And ant tryme does start the platform now.




But disregarding the above, I think a more serious, blocking, issue is

that AFAICT *not* all platform modules have been reviewed yet.
I notice this release candidate includes the apisupport.harness module.
And that still has status "To do". Furthermore, it depends on the *GPL*
external jsearch-2.0_05.jar which is a no-go... for the ASF.
See: https://www.apache.org/legal/resolved.html#category-x




Oops, sorry I missed this one  I think there's no other solution than to
simply remove that. The build of a platform application modules that have
help will then (I believe) fail, but users should  be able to supply the
jar manually.



Just provide a README (and not just for this reason, see my other
problem starting the binary) which explains users what they need to do
*if* they want/need to use help.

With regards to the current release candidate I've to vote -1 based on
the current findings as IMO this one is blocking.

(An alternative would be to make such a build pass with a

warning, but since that would lead to a wrongly built module, it is better
to continue failing IMO.)

(We may need to enhance the license checking task to fail on GPL.)



It most definitely should fail on encountering GPL.






I haven't looked in more detail yet, but before spending more time on it
I'd like to know if the inclusion of the harness module is an oversight
which can be quickly fixed. Regardless, I think this should be fixed
first.



I was thinking of removing the harness, but a) we would need to finish
work
on harness sometime soon anyway; b) I think the platform is more useful
with the harness than without it. So, I was fixing problems in the harness
modules I've noticed.



Note that the binary also includes the jsearch jar.
And while the binary isn't the release itself, if/when a convenience
binary is provided *then* it needs to be in compliance with the
distribution rules. So no GPL artifacts allowed.

I also see the bundled LICENSE and NOTICE files in the binary zip
are a bit weirdly formatted and the NOTICE file in particular.
Seems both are produced by concatenating several files together, but
the result is confusing, especially the NOTICE file.



Yes, the NOTICE is a concatenation of several files, as i suspect it is
not
feasible to have a manually updated NOTICE file for each distribution we
do. The form can surely be improved.



The NOTICE file should only contain what is needed, nothing
more. Of the current content only the OSGi Alliance notice seems to be
needed, beside the base NOTICE header.



It unfortunately wasn't clear which notices are needed and which not, so I
was trying to err on the side of including them. Fortunately, it should be
very easy to reduce the notices.



A possible solution is to use/add an additional NOTICE-APPEND file, for
those modules that need it, which only contains the bits needing to be
appended, so without the standard Apache header.
Then the ant task just needs to aggregate/append those files (when
encountered) to the root NOTICE file.



This is almost exactly what is done: there may be -notice.txt files in
*/external, which are merged (if the binary is used) to the NOTICE. I guess
there is a problem with "the bits needing to be appended", which is still
unclear to me (i.e. which exact notices need to be appended and which not,
I've read the pages about that but still unclear to me).


The canonical rule is defined here:

  http://www.apache.org/dev/licensing-howto.html#mod-notice

Which bottom line means: only add (and aggregate) notices when
explicitly required.
Either because specific copyright notices were transferred from source
files OR when including (in source, or as bundled dependency) external
resources which carry or require a NOTICE (file) themselves.
The latter *may* include artif

Re: HTML/Java checksums was: Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread Michael Nascimento

On Wed, Nov 8, 2017 at 1:02 PM, Ate Douma  wrote:
> That is not the case. I *did* built the correct version locally.

Ooops, sorry for jumping to conclusions, Ate.

> No, And that is the cause of the issue here.
> Every built of a jar will produce a different sha, so you're assessment
> is correct.
> While not a blocking issue I agree the current check is not sustainable.

True then.

Regards,
Michael

[GitHub] junichi11 closed pull request #207: [NETBEANS-54] Module Review o.n.upgrader

junichi11 closed pull request #207: [NETBEANS-54] Module Review o.n.upgrader
URL: https://github.com/apache/incubator-netbeans/pull/207
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/o.n.upgrader/src/org/netbeans/upgrade/systemoptions/systemoptionsimport 
b/o.n.upgrader/src/org/netbeans/upgrade/systemoptions/systemoptionsimport
index 6caf84336..d30b68ebd 100644
--- a/o.n.upgrader/src/org/netbeans/upgrade/systemoptions/systemoptionsimport
+++ b/o.n.upgrader/src/org/netbeans/upgrade/systemoptions/systemoptionsimport
@@ -1,3 +1,19 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
 Services/org-netbeans-core-IDESettings.settings
 Services/org-netbeans-modules-derby-DerbyOptions.settings
 Services/org-apache-tools-ant-module-AntSettings.settings


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: HTML/Java checksums was: Release Apache NetBeans 9.0 Alpha (incubating)




On 2017-11-08 15:25, Bertrand Delacretaz wrote:

On Wed, Nov 8, 2017 at 3:16 PM, Michael Nascimento  wrote:

...Had he built the correct version,
everything would have worked out fine


That is not the case. I *did* built the correct version locally.



Can you build the same jar multiple times and get the same digest every time? >
Some jars include build timestamps which breaks this, but maybe the
NetBeans builds take care of that?


No, And that is the cause of the issue here.
Every built of a jar will produce a different sha, so you're assessment
is correct.
While not a blocking issue I agree the current check is not sustainable.

Ate



-Bertrand

[GitHub] JaroslavTulach closed pull request #256: NETBEANS-127 use path to relativize file to root folder instead of regexp

JaroslavTulach closed pull request #256: NETBEANS-127 use path to relativize 
file to root folder instead of regexp
URL: https://github.com/apache/incubator-netbeans/pull/256
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/nbbuild/antsrc/org/netbeans/nbbuild/RatReportTask.java 
b/nbbuild/antsrc/org/netbeans/nbbuild/RatReportTask.java
index 72b6b28a0..350757bfb 100644
--- a/nbbuild/antsrc/org/netbeans/nbbuild/RatReportTask.java
+++ b/nbbuild/antsrc/org/netbeans/nbbuild/RatReportTask.java
@@ -21,11 +21,11 @@
 import java.io.BufferedReader;
 import java.io.File;
 import java.io.FileInputStream;
-import java.io.FileNotFoundException;
-import java.io.FileReader;
 import java.io.IOException;
 import java.io.InputStream;
 import java.io.InputStreamReader;
+import java.nio.file.Path;
+import java.nio.file.Paths;
 import java.util.ArrayList;
 import java.util.HashSet;
 import java.util.LinkedHashMap;
@@ -34,8 +34,6 @@
 import java.util.Set;
 import java.util.TreeMap;
 import java.util.TreeSet;
-import java.util.logging.Level;
-import java.util.logging.Logger;
 import javax.xml.parsers.DocumentBuilder;
 import javax.xml.parsers.DocumentBuilderFactory;
 import javax.xml.parsers.ParserConfigurationException;
@@ -129,7 +127,7 @@ public void execute() throws BuildException {
 simplfiedKey = simplfiedKey.replaceAll(".dir", "");
 simplfiedKey = simplfiedKey.replaceAll(".depends", "");
 clusterList.add(simplfiedKey);
-modulebycluster.put(simplfiedKey, new HashSet());
+modulebycluster.put(simplfiedKey, new HashSet<>());
 }
 }
 for (String clusterName : clusterList) {
@@ -212,7 +210,7 @@ private static String writeFiles(Set listFile, 
String repo) {
 private void doPopulateUnapproved(Map moduleRATInfo, 
Element rootElement, XPath path) throws XPathExpressionException {
 NodeList evaluate = (NodeList) 
path.evaluate("descendant::resource[license-approval/@name=\"false\"]", 
rootElement, XPathConstants.NODESET);
 for (int i = 0; i < evaluate.getLength(); i++) {
-String resources = 
evaluate.item(i).getAttributes().getNamedItem("name").getTextContent().replaceFirst(root.getPath()
 + File.separator, "");
+String resources = 
relativize(evaluate.item(i).getAttributes().getNamedItem("name").getTextContent());
 String moduleName = getModuleName(resources);
 if (!moduleRATInfo.containsKey(moduleName)) {
 moduleRATInfo.get(NOT_CLUSTER).addUnapproved(resources);
@@ -225,7 +223,7 @@ private void doPopulateUnapproved(Map 
moduleRATInfo, Element
 private void doPopulateApproved(Map moduleRATInfo, 
Element rootElement, XPath path) throws XPathExpressionException {
 NodeList evaluate = (NodeList) 
path.evaluate("descendant::resource[license-approval/@name=\"true\"]", 
rootElement, XPathConstants.NODESET);
 for (int i = 0; i < evaluate.getLength(); i++) {
-String resources = 
evaluate.item(i).getAttributes().getNamedItem("name").getTextContent().replaceFirst(root.getPath()
 + File.separator, "");
+String resources = 
relativize(evaluate.item(i).getAttributes().getNamedItem("name").getTextContent());
 String moduleName = getModuleName(resources);
 if (!moduleRATInfo.containsKey(moduleName)) {
 moduleRATInfo.get(NOT_CLUSTER).addApproved(resources);
@@ -236,6 +234,12 @@ private void doPopulateApproved(Map 
moduleRATInfo, Element r
 }
 }
 
+private String relativize(String target) {
+Path full = Paths.get(target);
+Path rootPath = root.toPath();
+return rootPath.relativize(full).toString();
+}
+
 private String getModuleName(String resource) {
 String moduleName;
 if (!resource.contains(File.separator)) {


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] JaroslavTulach commented on issue #256: NETBEANS-127 use path to relativize file to root folder instead of regexp

JaroslavTulach commented on issue #256: NETBEANS-127 use path to relativize 
file to root folder instead of regexp
URL: 
https://github.com/apache/incubator-netbeans/pull/256#issuecomment-342836007
 
 
   OK, this could be the fix.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] dtrebbien opened a new pull request #258: Handle implicitly static interface field declarations

dtrebbien opened a new pull request #258: Handle implicitly static interface 
field declarations
URL: https://github.com/apache/incubator-netbeans/pull/258
 
 
   Fixes https://netbeans.org/bugzilla/show_bug.cgi?id=271736


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: HTML/Java checksums was: Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread Bertrand Delacretaz

On Wed, Nov 8, 2017 at 3:16 PM, Michael Nascimento  wrote:
> ...Had he built the correct version,
> everything would have worked out fine

Can you build the same jar multiple times and get the same digest every time?

Some jars include build timestamps which breaks this, but maybe the
NetBeans builds take care of that?

-Bertrand

[GitHub] junichi11 commented on issue #248: adding crlf characters for the failing tests in api.templates

junichi11 commented on issue #248: adding crlf characters for the failing tests 
in api.templates
URL: 
https://github.com/apache/incubator-netbeans/pull/248#issuecomment-342832689
 
 
   @sarveshkesharwani Great. Thanks a lot! It would be nice if you can rebase 
and squash your changes into one commit with a proper commit message.
   
   @JaroslavTulach That makes sense. Thank you for your help!


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: HTML/Java checksums was: Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread Michael Nascimento

On Wed, Nov 8, 2017 at 12:12 PM, Bertrand Delacretaz
 wrote:
> Does this means the platform build only works using binaries
> downloaded from search.maven.org, as opposed to binaries built
> locally?

No, he just had a messed up version deployed in his local Maven repo
and this was picked by the build. Had he built the correct version,
everything would have worked out fine.

Regards,
Michael

Re: HTML/Java checksums was: Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread Bertrand Delacretaz

Hi,

On Wed, Nov 8, 2017 at 2:02 PM, Jaroslav Tulach
 wrote:
> ...this is a result of your previous testing of HTML/Java 1.5. You have built
> the artifacts and they got into your local Maven repository

Does this means the platform build only works using binaries
downloaded from search.maven.org, as opposed to binaries built
locally?

If yes that's a problem IMO, developers should be able (and encouraged
to) build everything themselves from sources.

Nothing urgent but something to fix at some point, unless there's a
workaround already.

-Bertrand

HTML/Java checksums was: Release Apache NetBeans 9.0 Alpha (incubating)

>
> Sorry, not sure what is happening, I tried to download:
>> https://search.maven.org/remotecontent?filepath=org/netbeans
>> /html/net.java.html.boot.script/1.5/net.java.html.boot.script-1.5.jar
>>
>> and it seems to have sha1sum:
>> 276009d3f0a27079a80d241c3183ec712305a42a
>>
>
> Indeed, if I download the above manually I can confirm it to have the
> expected sha1sum.
>
> The problem seems to be caused by my local maven repository already
> having these artifacts, and *those* have different sha1sum...
> Disabling my local maven repository 'fixed' this and the build succeeds.
> And ant tryme does start the platform now.


Hello Ate,
this is a result of your previous testing of HTML/Java 1.5. You have built
the artifacts and they got into your local Maven repository. Not sure what
is the best way out of this - I usually delete affected part of my
$HOME/.m2/repository/org/netbeans/html

-jt

Re: [VOTE] Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread Ludovic HOCHET

+ 1
built from source and tryme went fine.

On 7 November 2017 at 11:17, Geertjan Wielenga
 wrote:
> Hi all,
>
> Please vote on releasing Apache NetBeans 9.0 Alpha (incubating)! If this
> voting passes, another similar voting will be started on
> gene...@incubator.apache.org, and if that passes too, then we can release
> this version.
>
> Apache NetBeans 9.0 Alpha (incubating) are the modules of Apache NetBeans
> that provide the application framework of NetBeans, that is, the NetBeans
> Platform.
>
> Build artifacts:
>
> https://builds.apache.org/view/Incubator%20Projects/job/incubator-netbeans-release/
>
> Source md5sum is 548058644764a07ef54568aa79a10aa1.
>
> The artifact to be voted on:
>
> https://builds.apache.org/view/Incubator%20Projects/job/incubator-netbeans-release/lastSuccessfulBuild/artifact/dist/netbeans-platform-source-.zip
>
> Rat report shows no unknown licenses:
>
> https://builds.apache.org/view/Incubator%20Projects/job/incubator-netbeans-release/lastSuccessfulBuild/artifact/rat-temp/nbbuild/build/rat-report.txt
>
> Included as a convenience is a binary, unzip it and run it and you'll see
> the NetBeans Platform:
>
> https://builds.apache.org/view/Incubator%20Projects/job/incubator-netbeans-release/lastSuccessfulBuild/artifact/dist/netbeans-platform-bin-.zip
>
> Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and NOTICE
> files.
>
> Please try out the package and vote!
>
> The vote is open for a minimum of 72 hours or until the necessary number of
> votes (3 binding +1s) is reached.
>
> [ ] +1 Release this package as Apache NetBeans 9.0 Alpha (incubating)
> [ ] 0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
>
> Please add "(binding)" if your vote is binding, i.e., you are an Apache
> NetBeans committer.
>
> Geertjan
> on behalf of the Apache NetBeans tea,



-- 
Ludovic
-

"Les formes qui differencient les etres importent peu
 si leur pensees s'unissent pour batir un univers..."
 Yoko Tsuno (in 'Les titans' by Roger Leloup)
 [The shapes that differenciate beings are not important
 if their thoughts unite to build a universe]

[GitHub] JaroslavTulach commented on issue #257: Backport of jtulach's fixes made after Apr 22, 2017

JaroslavTulach commented on issue #257: Backport of jtulach's fixes made after 
Apr 22, 2017
URL: 
https://github.com/apache/incubator-netbeans/pull/257#issuecomment-342799368
 
 
   I've got these changesets by using following steps. I cloned @emilianbold 
[repository](https://github.com/emilianbold/netbeans-releases/) and then I 
executed:
   ```bash
   netbeans-releases$ git log -r NB9_FF...emilian/master --no-merges  
--author=jtulach --format=%H
   bf9a5b8befa55723fc35c6c5cb1b72e176d4973e
   0ce716155e4cfeab3dc1b840c78d0c620dca0c41
   9ee3e285e758bbb1be1be129cfc053eb79cc1e77
   42b544f1c1a06b597fef1a47df6052bbfad5bf0d
   ```
   then I manually (as I have just four commits) did `git show $id` in 
Emilian's repository and then `patch -p1`  and `git commit` with copied message 
from the original commit in this repository.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] geertjanw commented on issue #257: Backport of jtulach's fixes made after Apr 22, 2017

geertjanw commented on issue #257: Backport of jtulach's fixes made after Apr 
22, 2017
URL: 
https://github.com/apache/incubator-netbeans/pull/257#issuecomment-342795158
 
 
   Awesome!


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] JaroslavTulach opened a new pull request #257: Backport of jtulach's fixes made after Apr 22, 2017

JaroslavTulach opened a new pull request #257: Backport of jtulach's fixes made 
after Apr 22, 2017
URL: https://github.com/apache/incubator-netbeans/pull/257
 
 
   As you may know the development in http://hg.netbeans.org repositories 
continued even after Sat Apr 22 (the day when Apache donation files were synced 
for the last time). The development wasn't very active, but there was some.
   
   I've made four commits since then. I'd like to backport them to Apache 
NetBeans repository as they fix real issues found in NetBeans. Please consider 
accepting my pull request.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Give JavaHelp a chance! was: Release Apache NetBeans 9.0 Alpha (incubating)

My understanding was that we're excluding JavaHelp for Apache NetBeans 9.0
Alpha:

https://github.com/apache/incubator-netbeans/pull/249

Hense, jsearch should be excluded too, I believe.

Thanks,

Gj

On Wed, Nov 8, 2017 at 12:38 PM, Antonio Vieiro  wrote:

> So, what about using DocBook Web Help [1]? After all nowadays all
> users have a web browser, don't they?
>
> They even have a maven plugin[2]. This is BSD licensed. The results
> [3] look acceptable to me.
>
> We could even try to fork the project (maybe it's unmaintained)?
>
> Cheers,
> Antonio
>
> [1] http://blog.kasunbg.org/2010/08/docbook-webhelp-project.html
> [2] http://docbkx-tools.sourceforge.net/docbkx-samples/manual.html
> [3] http://docbook.sourceforge.net/release/xsl/current/
> webhelp/docs/index.html
>
> 2017-11-08 12:19 GMT+01:00 Geertjan Wielenga <
> geertjan.wiele...@googlemail.com>:
> > Here's the issue relating to JavaHelp, would be best to track/document
> > everything there:
> >
> > https://issues.apache.org/jira/browse/NETBEANS-3
> >
> > Gj
> >
> > On Wed, Nov 8, 2017 at 11:26 AM, Jan Lahoda  wrote:
> >
> >> On Wed, Nov 8, 2017 at 10:40 AM, Ate Douma  wrote:
> >>
> >> >
> >> >
> >> > On 2017-11-08 09:52, Jaroslav Tulach wrote:
> >> >
> >> >> Hello Ate,
> >> >> thanks for trying the NetBeans Platform 9.0 Alpha bits.
> >> >>
> >> >>
> >> >>  > And that still has status "To do". Furthermore, it depends on the
> >> *GPL*
> >> >>
> >> >> external jsearch-2.0_05.jar which is a no-go... for the ASF.
> >> >> See: https://www.apache.org/legal/resolved.html#category-x
> >> >> 
> >> >>
> >> >> ...
> >> >>  >
> >> >>
> >> >> Note that the binary also includes the jsearch jar.
> >> >> And while the binary isn't the release itself, if/when a
> convenience
> >> >> binary is provided *then* it needs to be in compliance with the
> >> >> distribution rules. So no GPL artifacts allowed.
> >> >>
> >> >>
> >> >> Yes, NetBeans depends on JavaHelp and JavaHelp has been developed
> under
> >> >> GPLv2 with CP exception. However the last commit has been made ten
> years
> >> >> ago by me or Jesse Glick - e.g. nobody cares about JavaHelp anymore.
> >> That
> >> >> means there are no business reasons to keep JavaHelp under GPLv2. As
> >> such
> >> >> we are trying to convince Oracle to relicense JavaHelp and release it
> >> under
> >> >> more Apache friendly license.  toThere are at least two good reasons
> to
> >> do
> >> >> it:
> >> >>
> >> >> #1 - simplify NetBeans Apache incubation
> >> >> #2 - simplify acceptance of JavaEE into Eclipse Foundation (yes,
> JavaEE
> >> >> also needs JavaHelp for some reason)
> >> >>
> >> >> While we saw a bit of resistance when we used #1 as argument for
> >> >> re-licensing JavaHelp, things started to change when #2 issue showed
> >> up. As
> >> >> such we believe that the JavaHelp licensing issue will be resolved
> soon
> >> >> (measuring that in the glacier speed changes are happening in
> Oracle).
> >> In
> >> >> any case I believe in a year or two we can expected JavaHelp with a
> >> >> friendly license.
> >> >>
> >> >> Btw. there already is https://github.com/javaee/javahelp with CDDL
> >> >> license. A proof the JavaEE guys are solving the same problem. Maybe
> we
> >> can
> >> >> just use JavaHelp from that source and our GPL problems are gone.
> >> >>
> >> > Seems like a, or even the, direction to solve this.
> >> > If those 'JavaEE guys' can be persuaded to tag/release soon, then yes,
> >> > Netbeans can use (externally depend on) that JavaHelp version under
> the
> >> > CDDL license.
> >> > So I suggest start persuading them :-)
> >> >
> >> > In any case I don't think we need urgent surgery/lobotomy for 1st
> >> NetBeans
> >> >> Alpha (incubating) release. It may be wiser to wait until the problem
> >> >> solves itself >
> >> >> All I am asking: Please give JavaHelp a chance!
> >> >>
> >> >
> >> > Well, as long as there is no alternative under an acceptable license,
> >> > the GPL license remains a blocker IMO to include the current version.
> >> >
> >>
> >> Just to be sure: it is OK to build against a GPL library, right?
> (Having it
> >> optional at runtime.) We can strip the jsearch.jar for now, that's not
> that
> >> big deal IMO (I can do that tonight, but not right now). But we have a
> >> different version of JavaHelp against which we compile the NetBeans
> help;
> >> and we have some more GPL libraries against which it would be much
> easier
> >> to compile.
> >>
> >> Jan
> >>
> >>
> >> > Unless, we can get an explicit exception for the restriction from the
> >> > Apache Legal Committee.
> >> > Which is not impossible but needs to be asked first, e.g. needs
> creating
> >> > a https://issues.apache.org/jira/browse/LEGAL ticket with the clear
> >> > use-case and explanation of what we need here.
> >> >
> >> > Ate
> >> >
> >> > -jt
> >> >>
> >> >>
> >>
>

Re: Give JavaHelp a chance! was: Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread Antonio Vieiro

So, what about using DocBook Web Help [1]? After all nowadays all
users have a web browser, don't they?

They even have a maven plugin[2]. This is BSD licensed. The results
[3] look acceptable to me.

We could even try to fork the project (maybe it's unmaintained)?

Cheers,
Antonio

[1] http://blog.kasunbg.org/2010/08/docbook-webhelp-project.html
[2] http://docbkx-tools.sourceforge.net/docbkx-samples/manual.html
[3] http://docbook.sourceforge.net/release/xsl/current/webhelp/docs/index.html

2017-11-08 12:19 GMT+01:00 Geertjan Wielenga :
> Here's the issue relating to JavaHelp, would be best to track/document
> everything there:
>
> https://issues.apache.org/jira/browse/NETBEANS-3
>
> Gj
>
> On Wed, Nov 8, 2017 at 11:26 AM, Jan Lahoda  wrote:
>
>> On Wed, Nov 8, 2017 at 10:40 AM, Ate Douma  wrote:
>>
>> >
>> >
>> > On 2017-11-08 09:52, Jaroslav Tulach wrote:
>> >
>> >> Hello Ate,
>> >> thanks for trying the NetBeans Platform 9.0 Alpha bits.
>> >>
>> >>
>> >>  > And that still has status "To do". Furthermore, it depends on the
>> *GPL*
>> >>
>> >> external jsearch-2.0_05.jar which is a no-go... for the ASF.
>> >> See: https://www.apache.org/legal/resolved.html#category-x
>> >> 
>> >>
>> >> ...
>> >>  >
>> >>
>> >> Note that the binary also includes the jsearch jar.
>> >> And while the binary isn't the release itself, if/when a convenience
>> >> binary is provided *then* it needs to be in compliance with the
>> >> distribution rules. So no GPL artifacts allowed.
>> >>
>> >>
>> >> Yes, NetBeans depends on JavaHelp and JavaHelp has been developed under
>> >> GPLv2 with CP exception. However the last commit has been made ten years
>> >> ago by me or Jesse Glick - e.g. nobody cares about JavaHelp anymore.
>> That
>> >> means there are no business reasons to keep JavaHelp under GPLv2. As
>> such
>> >> we are trying to convince Oracle to relicense JavaHelp and release it
>> under
>> >> more Apache friendly license.  toThere are at least two good reasons to
>> do
>> >> it:
>> >>
>> >> #1 - simplify NetBeans Apache incubation
>> >> #2 - simplify acceptance of JavaEE into Eclipse Foundation (yes, JavaEE
>> >> also needs JavaHelp for some reason)
>> >>
>> >> While we saw a bit of resistance when we used #1 as argument for
>> >> re-licensing JavaHelp, things started to change when #2 issue showed
>> up. As
>> >> such we believe that the JavaHelp licensing issue will be resolved soon
>> >> (measuring that in the glacier speed changes are happening in Oracle).
>> In
>> >> any case I believe in a year or two we can expected JavaHelp with a
>> >> friendly license.
>> >>
>> >> Btw. there already is https://github.com/javaee/javahelp with CDDL
>> >> license. A proof the JavaEE guys are solving the same problem. Maybe we
>> can
>> >> just use JavaHelp from that source and our GPL problems are gone.
>> >>
>> > Seems like a, or even the, direction to solve this.
>> > If those 'JavaEE guys' can be persuaded to tag/release soon, then yes,
>> > Netbeans can use (externally depend on) that JavaHelp version under the
>> > CDDL license.
>> > So I suggest start persuading them :-)
>> >
>> > In any case I don't think we need urgent surgery/lobotomy for 1st
>> NetBeans
>> >> Alpha (incubating) release. It may be wiser to wait until the problem
>> >> solves itself >
>> >> All I am asking: Please give JavaHelp a chance!
>> >>
>> >
>> > Well, as long as there is no alternative under an acceptable license,
>> > the GPL license remains a blocker IMO to include the current version.
>> >
>>
>> Just to be sure: it is OK to build against a GPL library, right? (Having it
>> optional at runtime.) We can strip the jsearch.jar for now, that's not that
>> big deal IMO (I can do that tonight, but not right now). But we have a
>> different version of JavaHelp against which we compile the NetBeans help;
>> and we have some more GPL libraries against which it would be much easier
>> to compile.
>>
>> Jan
>>
>>
>> > Unless, we can get an explicit exception for the restriction from the
>> > Apache Legal Committee.
>> > Which is not impossible but needs to be asked first, e.g. needs creating
>> > a https://issues.apache.org/jira/browse/LEGAL ticket with the clear
>> > use-case and explanation of what we need here.
>> >
>> > Ate
>> >
>> > -jt
>> >>
>> >>
>>

[GitHub] lbruun commented on a change in pull request #161: [NETBEANS-96] New PAC Script evaluation environment

lbruun commented on a change in pull request #161: [NETBEANS-96] New PAC Script 
evaluation environment
URL: https://github.com/apache/incubator-netbeans/pull/161#discussion_r149642386
 
 

 ##
 File path: core.network/src/org/netbeans/core/network/utils/HostnameUtils.java
 ##
 @@ -0,0 +1,72 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.netbeans.core.network.utils;
+
+import com.sun.jna.Platform;
+
+/**
+ * Utility functions for finding the local computer's name. 
+ * 
+ *
+ * @author lbruun
+ */
+public class HostnameUtils {
+
+private HostnameUtils() {}
+
+
+/**
+ * Gets the name which is likely to be the local host's primary
+ * name on the network.
+ * 
+ * 
+ * IMPLEMENTATION:
+ * 
+ * 
+ *   On Unix-like OSes (incl Mac OS X) this is the value as returned 
from
+ *   the {@code gethostname()} function from the standard C Library. 

+ *   On Windows it is the value as returned from the
+ *   {@code gethostname()} function from {@code Ws2_32} library.
+ *   (without domain name). Note that this Windows function will do a 
+ *   name service lookup and the method is therefore potentially 
blocking, 
+ *   although it is more than likely that Windows has cached this 
result 
+ *   on computer startup in its DNS Client Cache and therefore the 
+ *   result will be returned very fast.
+ * 
+ * 
+ * @return host name
+ * @throws NativeException if there was an error executing the
+ *system call.
+ */
+public static String getNetworkHostname() throws NativeException {
 
 Review comment:
   Well, this is partly due to history. If I remember correctly, I used to use 
different functions on MacOSX and Linux. But through trials and tests I finally 
settled on using the same C lib function on everything but Windows. I may 
revert that.
   
   The `hname` packages exist mainly as a way to get the host's _kernel name_, 
so that we can use that in an insane ride to find the host's own IP address as 
it is generally known on the network. This functionality is mandated for PAC 
evaluator. 
   
   But when I started on the hname package, I thought of it as a general 
purpose package for everything related to the host's naming. For example, I 
wanted to add methods for getting the host's _display name_, e.g. "Joey's 
Laptop" and this is done very differently between OSes. This is another reason 
for the sub-packages per OS. I don't know if I'll ever get around to adding 
that. Right now the focus was on getting a working PAC evaluator as the 
existing one is broken. And frankly the host's display name has little usage 
except for use in About box and things like that.  :-)
   
   I would like to keep the subpackages and the delegation for now even if it 
is a lot of ceremony for nothing.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Give JavaHelp a chance! was: Release Apache NetBeans 9.0 Alpha (incubating)

Here's the issue relating to JavaHelp, would be best to track/document
everything there:

https://issues.apache.org/jira/browse/NETBEANS-3

Gj

On Wed, Nov 8, 2017 at 11:26 AM, Jan Lahoda  wrote:

> On Wed, Nov 8, 2017 at 10:40 AM, Ate Douma  wrote:
>
> >
> >
> > On 2017-11-08 09:52, Jaroslav Tulach wrote:
> >
> >> Hello Ate,
> >> thanks for trying the NetBeans Platform 9.0 Alpha bits.
> >>
> >>
> >>  > And that still has status "To do". Furthermore, it depends on the
> *GPL*
> >>
> >> external jsearch-2.0_05.jar which is a no-go... for the ASF.
> >> See: https://www.apache.org/legal/resolved.html#category-x
> >> 
> >>
> >> ...
> >>  >
> >>
> >> Note that the binary also includes the jsearch jar.
> >> And while the binary isn't the release itself, if/when a convenience
> >> binary is provided *then* it needs to be in compliance with the
> >> distribution rules. So no GPL artifacts allowed.
> >>
> >>
> >> Yes, NetBeans depends on JavaHelp and JavaHelp has been developed under
> >> GPLv2 with CP exception. However the last commit has been made ten years
> >> ago by me or Jesse Glick - e.g. nobody cares about JavaHelp anymore.
> That
> >> means there are no business reasons to keep JavaHelp under GPLv2. As
> such
> >> we are trying to convince Oracle to relicense JavaHelp and release it
> under
> >> more Apache friendly license.  toThere are at least two good reasons to
> do
> >> it:
> >>
> >> #1 - simplify NetBeans Apache incubation
> >> #2 - simplify acceptance of JavaEE into Eclipse Foundation (yes, JavaEE
> >> also needs JavaHelp for some reason)
> >>
> >> While we saw a bit of resistance when we used #1 as argument for
> >> re-licensing JavaHelp, things started to change when #2 issue showed
> up. As
> >> such we believe that the JavaHelp licensing issue will be resolved soon
> >> (measuring that in the glacier speed changes are happening in Oracle).
> In
> >> any case I believe in a year or two we can expected JavaHelp with a
> >> friendly license.
> >>
> >> Btw. there already is https://github.com/javaee/javahelp with CDDL
> >> license. A proof the JavaEE guys are solving the same problem. Maybe we
> can
> >> just use JavaHelp from that source and our GPL problems are gone.
> >>
> > Seems like a, or even the, direction to solve this.
> > If those 'JavaEE guys' can be persuaded to tag/release soon, then yes,
> > Netbeans can use (externally depend on) that JavaHelp version under the
> > CDDL license.
> > So I suggest start persuading them :-)
> >
> > In any case I don't think we need urgent surgery/lobotomy for 1st
> NetBeans
> >> Alpha (incubating) release. It may be wiser to wait until the problem
> >> solves itself >
> >> All I am asking: Please give JavaHelp a chance!
> >>
> >
> > Well, as long as there is no alternative under an acceptable license,
> > the GPL license remains a blocker IMO to include the current version.
> >
>
> Just to be sure: it is OK to build against a GPL library, right? (Having it
> optional at runtime.) We can strip the jsearch.jar for now, that's not that
> big deal IMO (I can do that tonight, but not right now). But we have a
> different version of JavaHelp against which we compile the NetBeans help;
> and we have some more GPL libraries against which it would be much easier
> to compile.
>
> Jan
>
>
> > Unless, we can get an explicit exception for the restriction from the
> > Apache Legal Committee.
> > Which is not impossible but needs to be asked first, e.g. needs creating
> > a https://issues.apache.org/jira/browse/LEGAL ticket with the clear
> > use-case and explanation of what we need here.
> >
> > Ate
> >
> > -jt
> >>
> >>
>

[GitHub] lbruun commented on a change in pull request #161: [NETBEANS-96] New PAC Script evaluation environment

lbruun commented on a change in pull request #161: [NETBEANS-96] New PAC Script 
evaluation environment
URL: https://github.com/apache/incubator-netbeans/pull/161#discussion_r149638473
 
 

 ##
 File path: 
core.network/src/org/netbeans/core/network/utils/hname/win/HostnameUtilsWin.java
 ##
 @@ -0,0 +1,110 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.netbeans.core.network.utils.hname.win;
+
+import com.sun.jna.Native;
+import com.sun.jna.platform.win32.Kernel32Util;
+import com.sun.jna.platform.win32.Win32Exception;
+import java.util.logging.Level;
+import java.util.logging.Logger;
+import org.netbeans.core.network.utils.IpAddressUtils;
+import org.netbeans.core.network.utils.NativeException;
+
+/**
+ * Hostname utilities for Microsoft Windows OS.
+ */
+public class HostnameUtilsWin {
+
+private static final Logger LOGGER = 
Logger.getLogger(HostnameUtilsWin.class.getName());
+
+/**
+ * Gets the computer name.
+ * 
+ * This is the also known as the NetBIOS name, although NetBIOS is 
+ * hardly used anymore. It is the same value as can be seen from the
+ * {@code COMPUTERNAME} environment variable.
+ * 
+ * 
+ * Windows API equivalent: {@code GetComputerName()} function from 
+ * {@code Kernel32} library.
+ * 
+ * @return computer name
+ * @throws NativeException if there was an error executing the
+ *system call.
+ */
+public static String getComputerName() throws NativeException {
 
 Review comment:
   True, that it is not used in *my* implementation. I used to use it, but then 
I switched to using `getHostName` instead.  There are pros and cons on these 
two Win32 methods and someone implementing differently than me may feel 
differently about it. So I kept it.
   
   The dependency on JNA Platform will come back with a vengeance in the next 
iterations on the module where I improve further on the module. So no point in 
removing it now. Remember, as it says in the top text: The improved PAC script 
evaluator is just the beginning. To give you a taste: The next steps will for 
example add vastly improved config discovery and for this JNA Platform is 
needed. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] lbruun commented on a change in pull request #161: [NETBEANS-96] New PAC Script evaluation environment

lbruun commented on a change in pull request #161: [NETBEANS-96] New PAC Script 
evaluation environment
URL: https://github.com/apache/incubator-netbeans/pull/161#discussion_r149635987
 
 

 ##
 File path: core.network/src/org/netbeans/core/network/utils/IpAddressUtils.java
 ##
 @@ -0,0 +1,501 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.netbeans.core.network.utils;
+
+import java.net.Inet4Address;
+import java.net.Inet6Address;
+import java.net.InetAddress;
+import java.net.UnknownHostException;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.Comparator;
+import java.util.List;
+import java.util.concurrent.Callable;
+import java.util.concurrent.ExecutionException;
+import java.util.concurrent.Future;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.TimeoutException;
+import java.util.regex.Pattern;
+import org.netbeans.api.annotations.common.NonNull;
+import org.openide.util.Exceptions;
+import org.openide.util.RequestProcessor;
+
+/**
+ * IP address utilities. Mainly providing functionality
+ * for doing name resolve with explicit timeout.
+ *
+ * 
+ * TODO: Support for reverse lookup with timeout isn't implemented. Hasn't been
+ * any need for it.
+ * 
+ * @author lbruun
+ */
+public class IpAddressUtils {
+
+private static final Pattern IPV4_PATTERN = 
Pattern.compile("^\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}$");
+private static final RequestProcessor RP = new 
RequestProcessor("DNSBackgroundResolvers", 10);
+
+private IpAddressUtils() {}
+
+/**
+ * Filters the result of a method according to IP protocol preference.
+ */
+public enum IpTypePreference {
+/**
+ * Only IPv4 address(es) in the returned value. 
+ */
+IPV4_ONLY,
+/**
+ * Only IPv6 address(es) in the returned value. 
+ */
+IPV6_ONLY,
+/**
+ * Any of IPv4 or IPv6 addresses are acceptable in the returned value,
+ * but IPv4 address is preferred over IPv6. If the method returns
+ * an array then IPv4 addresses will come before IPv6 addresses.
+ */
+ANY_IPV4_PREF,
+/**
+ * Any of IPv4 or IPv6 addresses are acceptable in the returned value,
+ * but IPv6 address is preferred over IPv4. If the method returns
+ * an array then IPv6 addresses will come before IPv4 addresses.
+ */
+ANY_IPV6_PREF,
+/**
+ * Any of IPv4 or IPv6 addresses are acceptable in the returned value,
+ * but their internal preference is determined by the setting in the
+ * JDK, namely the {@code java.net.preferIPv6Addresses} system 
property.
+ * If this property is {@code true} then using this preference will be
+ * exactly as {@link #ANY_IPV6_PREF}, if {@code false} it will be 
+ * exactly as {@link #ANY_IPV4_PREF}.
+ */
+ANY_JDK_PREF
+}
+
+/**
+ * Performs a name service lookup with a timeout. 
+ * 
+ * This method can be used when the JRE's default DNS timeout is not
+ * acceptable. The method is essentially a wrapper around 
+ * {@link java.net.InetAddress#getAllByName(java.lang.String) 
InetAddress.getAllByName()}.
+ * 
+ * A reasonable timeout value is 4 seconds (4000 ms) as this value
+ * will - with the JRE's default settings - allow each DNS server in a
+ * list of 4 servers to be queried once.
+ * 
+ * If the {@code host} is a literal representation
+ * of an IPv4 address (using dot notation, for example {@code 
"192.168.1.44"}) 
+ * or an IPv6 address (any form accepted by {@link java.net.Inet6Address}),
+ * then the method will convert the text into {@code InetAddress} and 
+ * return immediately. The timeout does not apply to this case.
+ * 
+ * 
+ * 
+ * 
+ * Java's default DNS timeout:
+ * 
+ * The default timeout DNS lookup is described 
+ * http://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-dns.html#PROP";>
+ * in the documentation for JNDI in properties:
+ * 
+ *   {@code com.example.jndi.dns.timeout.initial}  (defaults to 
1 sec

[GitHub] ebarboni commented on issue #248: adding crlf characters for the failing tests in api.templates

ebarboni commented on issue #248: adding crlf characters for the failing tests 
in api.templates
URL: 
https://github.com/apache/incubator-netbeans/pull/248#issuecomment-342781246
 
 
   @JaroslavTulach maybe we should connect jenkins to dev mailing list   ?
   see [1] section how do I allow Jenkins to mail to my project's "dev" list?
   
   [1] 
https://wiki.apache.org/general/Jenkins?action=show&redirect=Hudson#Are_there_recommended_or_mandatory_Jenkins_settings_for_ASF_projects.3F


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] ebarboni commented on issue #252: wip attempt to get ignore from .gitgnore

ebarboni commented on issue #252: wip attempt to get ignore from .gitgnore
URL: 
https://github.com/apache/incubator-netbeans/pull/252#issuecomment-342778223
 
 
   I tried to map gitignore to exclude pattern first. But the pattern 
/*/external/*/** for example has not simple mapping in ant fileset. it was 
ignoring everything on external instead of ignoring every thing in subfolder 
from external.
   
   So I change my mind to get ignore from git directly 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] ebarboni opened a new pull request #256: NETBEANS-127 use path to relativize file to root folder instead of regexp

ebarboni opened a new pull request #256: NETBEANS-127 use path to relativize 
file to root folder instead of regexp
URL: https://github.com/apache/incubator-netbeans/pull/256
 
 
   tested manualy seems to work on both operating system


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Give JavaHelp a chance! was: Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread Jan Lahoda

On Wed, Nov 8, 2017 at 10:40 AM, Ate Douma  wrote:

>
>
> On 2017-11-08 09:52, Jaroslav Tulach wrote:
>
>> Hello Ate,
>> thanks for trying the NetBeans Platform 9.0 Alpha bits.
>>
>>
>>  > And that still has status "To do". Furthermore, it depends on the *GPL*
>>
>> external jsearch-2.0_05.jar which is a no-go... for the ASF.
>> See: https://www.apache.org/legal/resolved.html#category-x
>> 
>>
>> ...
>>  >
>>
>> Note that the binary also includes the jsearch jar.
>> And while the binary isn't the release itself, if/when a convenience
>> binary is provided *then* it needs to be in compliance with the
>> distribution rules. So no GPL artifacts allowed.
>>
>>
>> Yes, NetBeans depends on JavaHelp and JavaHelp has been developed under
>> GPLv2 with CP exception. However the last commit has been made ten years
>> ago by me or Jesse Glick - e.g. nobody cares about JavaHelp anymore. That
>> means there are no business reasons to keep JavaHelp under GPLv2. As such
>> we are trying to convince Oracle to relicense JavaHelp and release it under
>> more Apache friendly license.  toThere are at least two good reasons to do
>> it:
>>
>> #1 - simplify NetBeans Apache incubation
>> #2 - simplify acceptance of JavaEE into Eclipse Foundation (yes, JavaEE
>> also needs JavaHelp for some reason)
>>
>> While we saw a bit of resistance when we used #1 as argument for
>> re-licensing JavaHelp, things started to change when #2 issue showed up. As
>> such we believe that the JavaHelp licensing issue will be resolved soon
>> (measuring that in the glacier speed changes are happening in Oracle). In
>> any case I believe in a year or two we can expected JavaHelp with a
>> friendly license.
>>
>> Btw. there already is https://github.com/javaee/javahelp with CDDL
>> license. A proof the JavaEE guys are solving the same problem. Maybe we can
>> just use JavaHelp from that source and our GPL problems are gone.
>>
> Seems like a, or even the, direction to solve this.
> If those 'JavaEE guys' can be persuaded to tag/release soon, then yes,
> Netbeans can use (externally depend on) that JavaHelp version under the
> CDDL license.
> So I suggest start persuading them :-)
>
> In any case I don't think we need urgent surgery/lobotomy for 1st NetBeans
>> Alpha (incubating) release. It may be wiser to wait until the problem
>> solves itself >
>> All I am asking: Please give JavaHelp a chance!
>>
>
> Well, as long as there is no alternative under an acceptable license,
> the GPL license remains a blocker IMO to include the current version.
>

Just to be sure: it is OK to build against a GPL library, right? (Having it
optional at runtime.) We can strip the jsearch.jar for now, that's not that
big deal IMO (I can do that tonight, but not right now). But we have a
different version of JavaHelp against which we compile the NetBeans help;
and we have some more GPL libraries against which it would be much easier
to compile.

Jan


> Unless, we can get an explicit exception for the restriction from the
> Apache Legal Committee.
> Which is not impossible but needs to be asked first, e.g. needs creating
> a https://issues.apache.org/jira/browse/LEGAL ticket with the clear
> use-case and explanation of what we need here.
>
> Ate
>
> -jt
>>
>>

Re: [VOTE] Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread Jan Lahoda

On Wed, Nov 8, 2017 at 10:44 AM, Ate Douma  wrote:

> On 2017-11-08 07:54, Jan Lahoda wrote:
>
>> Hi Ate,
>>
>> Thanks a lot for your review and comments.
>>
>> On Wed, Nov 8, 2017 at 12:04 AM, Ate Douma  wrote:
>>
>> I get a different build error:
>>>
>>> BUILD FAILED
>>> /home/ate/tmp/netbeans/netbeans-platform-source-platform-9.
>>> 0-alpha/nbbuild/build.xml:122:
>>> Download of 276009D3F0A27079A80D241C3183EC712305A42A-net.java.html.boot.
>>> script-1.5.jar
>>> produced content with hash 5DE9DD70EDCD9B30E0671ACC813F6F0C80E951AA when
>>> 276009D3F0A27079A80D241C3183EC712305A42A was expected
>>>
>>>
>> Sorry, not sure what is happening, I tried to download:
>> https://search.maven.org/remotecontent?filepath=org/netbeans
>> /html/net.java.html.boot.script/1.5/net.java.html.boot.script-1.5.jar
>>
>> and it seems to have sha1sum:
>> 276009d3f0a27079a80d241c3183ec712305a42a
>>
>
> Indeed, if I download the above manually I can confirm it to have the
> expected sha1sum.
>
> The problem seems to be caused by my local maven repository already
> having these artifacts, and *those* have different sha1sum...
> Disabling my local maven repository 'fixed' this and the build succeeds.
> And ant tryme does start the platform now.
>
>
>>
>> But disregarding the above, I think a more serious, blocking, issue is
>>> that AFAICT *not* all platform modules have been reviewed yet.
>>> I notice this release candidate includes the apisupport.harness module.
>>> And that still has status "To do". Furthermore, it depends on the *GPL*
>>> external jsearch-2.0_05.jar which is a no-go... for the ASF.
>>> See: https://www.apache.org/legal/resolved.html#category-x
>>>
>>
>>
>> Oops, sorry I missed this one  I think there's no other solution than to
>> simply remove that. The build of a platform application modules that have
>> help will then (I believe) fail, but users should  be able to supply the
>> jar manually.
>>
>
> Just provide a README (and not just for this reason, see my other
> problem starting the binary) which explains users what they need to do
> *if* they want/need to use help.
>
> With regards to the current release candidate I've to vote -1 based on
> the current findings as IMO this one is blocking.
>
> (An alternative would be to make such a build pass with a
>> warning, but since that would lead to a wrongly built module, it is better
>> to continue failing IMO.)
>>
>> (We may need to enhance the license checking task to fail on GPL.)
>>
>
> It most definitely should fail on encountering GPL.
>
>
>>
>>>
>>> I haven't looked in more detail yet, but before spending more time on it
>>> I'd like to know if the inclusion of the harness module is an oversight
>>> which can be quickly fixed. Regardless, I think this should be fixed
>>> first.
>>>
>>>
>> I was thinking of removing the harness, but a) we would need to finish
>> work
>> on harness sometime soon anyway; b) I think the platform is more useful
>> with the harness than without it. So, I was fixing problems in the harness
>> modules I've noticed.
>>
>>
>>> Note that the binary also includes the jsearch jar.
>>> And while the binary isn't the release itself, if/when a convenience
>>> binary is provided *then* it needs to be in compliance with the
>>> distribution rules. So no GPL artifacts allowed.
>>>
>>> I also see the bundled LICENSE and NOTICE files in the binary zip
>>> are a bit weirdly formatted and the NOTICE file in particular.
>>> Seems both are produced by concatenating several files together, but
>>> the result is confusing, especially the NOTICE file.
>>>
>>>
>> Yes, the NOTICE is a concatenation of several files, as i suspect it is
>> not
>> feasible to have a manually updated NOTICE file for each distribution we
>> do. The form can surely be improved.
>>
>>
>>> The NOTICE file should only contain what is needed, nothing
>>> more. Of the current content only the OSGi Alliance notice seems to be
>>> needed, beside the base NOTICE header.
>>>
>>>
>> It unfortunately wasn't clear which notices are needed and which not, so I
>> was trying to err on the side of including them. Fortunately, it should be
>> very easy to reduce the notices.
>>
>>
> A possible solution is to use/add an additional NOTICE-APPEND file, for
> those modules that need it, which only contains the bits needing to be
> appended, so without the standard Apache header.
> Then the ant task just needs to aggregate/append those files (when
> encountered) to the root NOTICE file.
>

This is almost exactly what is done: there may be -notice.txt files in
*/external, which are merged (if the binary is used) to the NOTICE. I guess
there is a problem with "the bits needing to be appended", which is still
unclear to me (i.e. which exact notices need to be appended and which not,
I've read the pages about that but still unclear to me).


>
>
>
>>
>>> The LICENSE file correctly lists and appends the 3rd party licenses,
>>> but:
>>> a) The jsearch GPL-2-CP license obviously shouldn't be there (see

Re: [VOTE] Release Apache NetBeans 9.0 Alpha (incubating)

On 2017-11-08 07:54, Jan Lahoda wrote:

Hi Ate,

Thanks a lot for your review and comments.

On Wed, Nov 8, 2017 at 12:04 AM, Ate Douma wrote:

I get a different build error:

BUILD FAILED
/home/ate/tmp/netbeans/netbeans-platform-source-platform-9.0-alpha/nbbuild/build.xml:122:
Download of
276009D3F0A27079A80D241C3183EC712305A42A-net.java.html.boot.script-1.5.jar
produced content with hash 5DE9DD70EDCD9B30E0671ACC813F6F0C80E951AA when
276009D3F0A27079A80D241C3183EC712305A42A was expected

Sorry, not sure what is happening, I tried to download:
https://search.maven.org/remotecontent?filepath=org/netbeans/html/net.java.html.boot.script/1.5/net.java.html.boot.script-1.5.jar

and it seems to have sha1sum:
276009d3f0a27079a80d241c3183ec712305a42a

Indeed, if I download the above manually I can confirm it to have the
expected sha1sum.

The problem seems to be caused by my local maven repository already
having these artifacts, and *those* have different sha1sum...
Disabling my local maven repository 'fixed' this and the build succeeds.
And ant tryme does start the platform now.

But disregarding the above, I think a more serious, blocking, issue is
that AFAICT *not* all platform modules have been reviewed yet.
I notice this release candidate includes the apisupport.harness module.
And that still has status "To do". Furthermore, it depends on the *GPL*
external jsearch-2.0_05.jar which is a no-go... for the ASF.
See: https://www.apache.org/legal/resolved.html#category-x

Oops, sorry I missed this one I think there's no other solution than to
simply remove that. The build of a platform application modules that have
help will then (I believe) fail, but users should be able to supply the
jar manually.

Just provide a README (and not just for this reason, see my other
problem starting the binary) which explains users what they need to do
*if* they want/need to use help.

With regards to the current release candidate I've to vote -1 based on
the current findings as IMO this one is blocking.

(An alternative would be to make such a build pass with a
warning, but since that would lead to a wrongly built module, it is better
to continue failing IMO.)

(We may need to enhance the license checking task to fail on GPL.)

It most definitely should fail on encountering GPL.

I haven't looked in more detail yet, but before spending more time on it
I'd like to know if the inclusion of the harness module is an oversight
which can be quickly fixed. Regardless, I think this should be fixed first.

I was thinking of removing the harness, but a) we would need to finish work
on harness sometime soon anyway; b) I think the platform is more useful
with the harness than without it. So, I was fixing problems in the harness
modules I've noticed.

Note that the binary also includes the jsearch jar.
And while the binary isn't the release itself, if/when a convenience
binary is provided *then* it needs to be in compliance with the
distribution rules. So no GPL artifacts allowed.

I also see the bundled LICENSE and NOTICE files in the binary zip
are a bit weirdly formatted and the NOTICE file in particular.
Seems both are produced by concatenating several files together, but
the result is confusing, especially the NOTICE file.

Yes, the NOTICE is a concatenation of several files, as i suspect it is not
feasible to have a manually updated NOTICE file for each distribution we
do. The form can surely be improved.

The NOTICE file should only contain what is needed, nothing
more. Of the current content only the OSGi Alliance notice seems to be
needed, beside the base NOTICE header.

It unfortunately wasn't clear which notices are needed and which not, so I
was trying to err on the side of including them. Fortunately, it should be
very easy to reduce the notices.

A possible solution is to use/add an additional NOTICE-APPEND file, for
those modules that need it, which only contains the bits needing to be
appended, so without the standard Apache header.
Then the ant task just needs to aggregate/append those files (when
encountered) to the root NOTICE file.

The LICENSE file correctly lists and appends the 3rd party licenses,
but:
a) The jsearch GPL-2-CP license obviously shouldn't be there (see above)
b) The jemmy *external* libraries are available under CDDL or GPL-2-CP,
in which case we simply 'pick' CDDL and don't need to include/append
the GPL-2CP license too.

Ok. It was not clear how to handle dual licenses. Stripping the GPL
alternative should be simple.

This is (AFAIK) not blocking, but preferred to remove the GPL-2-CP

license text as it easily can 'trip' casual reviewers or even
automatic license scanning tools which may draw the wrong conclusion.
(and why is jemmy an external dependency and not part of the code
donation?)

Finally, I tried to start the binary.
Sorry for probably being a noob here but I can't figure out if I'm doing
something wrong or the binary it

Re: Give JavaHelp a chance! was: Release Apache NetBeans 9.0 Alpha (incubating)

On 2017-11-08 09:52, Jaroslav Tulach wrote:

Hello Ate,
thanks for trying the NetBeans Platform 9.0 Alpha bits.

 > And that still has status "To do". Furthermore, it depends on the *GPL*

external jsearch-2.0_05.jar which is a no-go... for the ASF.
See: https://www.apache.org/legal/resolved.html#category-x

... 

 >

Note that the binary also includes the jsearch jar.
And while the binary isn't the release itself, if/when a convenience
binary is provided *then* it needs to be in compliance with the
distribution rules. So no GPL artifacts allowed.

Yes, NetBeans depends on JavaHelp and JavaHelp has been developed under 
GPLv2 with CP exception. However the last commit has been made ten years 
ago by me or Jesse Glick - e.g. nobody cares about JavaHelp anymore. 
That means there are no business reasons to keep JavaHelp under GPLv2. 
As such we are trying to convince Oracle to relicense JavaHelp and 
release it under more Apache friendly license.  toThere are at least two 
good reasons to do it:

#1 - simplify NetBeans Apache incubation
#2 - simplify acceptance of JavaEE into Eclipse Foundation (yes, JavaEE 
also needs JavaHelp for some reason)

While we saw a bit of resistance when we used #1 as argument for 
re-licensing JavaHelp, things started to change when #2 issue showed up. 
As such we believe that the JavaHelp licensing issue will be resolved 
soon (measuring that in the glacier speed changes are happening in 
Oracle). In any case I believe in a year or two we can expected JavaHelp 
with a friendly license.

Btw. there already is https://github.com/javaee/javahelp with CDDL 
license. A proof the JavaEE guys are solving the same problem. Maybe we 
can just use JavaHelp from that source and our GPL problems are gone. 

Seems like a, or even the, direction to solve this.
If those 'JavaEE guys' can be persuaded to tag/release soon, then yes,
Netbeans can use (externally depend on) that JavaHelp version under the
CDDL license.
So I suggest start persuading them :-)

In 
any case I don't think we need urgent surgery/lobotomy for 1st NetBeans 
Alpha (incubating) release. It may be wiser to wait until the problem 
solves itself >

All I am asking: Please give JavaHelp a chance!

Well, as long as there is no alternative under an acceptable license,
the GPL license remains a blocker IMO to include the current version.

Unless, we can get an explicit exception for the restriction from the
Apache Legal Committee.
Which is not impossible but needs to be asked first, e.g. needs creating
a https://issues.apache.org/jira/browse/LEGAL ticket with the clear
use-case and explanation of what we need here.

Ate

-jt

[VOTE] Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread georgia Ingham

+1

Regards,
Georgia

Re: [VOTE] Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread mark stephens

+1 from me also…..

> On 8 Nov 2017, at 08:19, mario-leander.rei...@qaware.de wrote:
> 
> +1 Release this package as Apache NetBeans 9.0 Alpha (incubating)
>

Re: [VOTE] Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread Antonio Vieiro

-1, until we resolve these issues reported by Ate.

Thanks, Ate, for reporting them,
Antonio

P.S.: I'll have some time tonight (EU time) to help solve them.

2017-11-08 0:04 GMT+01:00 Ate Douma :
> I get a different build error:
>
> BUILD FAILED
> /home/ate/tmp/netbeans/netbeans-platform-source-platform-9.0-alpha/nbbuild/build.xml:122:
> Download of
> 276009D3F0A27079A80D241C3183EC712305A42A-net.java.html.boot.script-1.5.jar
> produced content with hash 5DE9DD70EDCD9B30E0671ACC813F6F0C80E951AA when
> 276009D3F0A27079A80D241C3183EC712305A42A was expected
>
> But disregarding the above, I think a more serious, blocking, issue is
> that AFAICT *not* all platform modules have been reviewed yet.
> I notice this release candidate includes the apisupport.harness module.
> And that still has status "To do". Furthermore, it depends on the *GPL*
> external jsearch-2.0_05.jar which is a no-go... for the ASF.
> See: https://www.apache.org/legal/resolved.html#category-x
>
> I haven't looked in more detail yet, but before spending more time on it
> I'd like to know if the inclusion of the harness module is an oversight
> which can be quickly fixed. Regardless, I think this should be fixed first.
>
> Note that the binary also includes the jsearch jar.
> And while the binary isn't the release itself, if/when a convenience
> binary is provided *then* it needs to be in compliance with the
> distribution rules. So no GPL artifacts allowed.
>
> I also see the bundled LICENSE and NOTICE files in the binary zip
> are a bit weirdly formatted and the NOTICE file in particular.
> Seems both are produced by concatenating several files together, but
> the result is confusing, especially the NOTICE file.
>
> The NOTICE file should only contain what is needed, nothing
> more. Of the current content only the OSGi Alliance notice seems to be
> needed, beside the base NOTICE header.
>
> The LICENSE file correctly lists and appends the 3rd party licenses,
> but:
> a) The jsearch GPL-2-CP license obviously shouldn't be there (see above)
> b) The jemmy *external* libraries are available under CDDL or GPL-2-CP,
>in which case we simply 'pick' CDDL and don't need to include/append
>the GPL-2CP license too.
>This is (AFAIK) not blocking, but preferred to remove the GPL-2-CP
>license text as it easily can 'trip' casual reviewers or even
>automatic license scanning tools which may draw the wrong conclusion.
>(and why is jemmy an external dependency and not part of the code
> donation?)
>
> Finally, I tried to start the binary.
> Sorry for probably being a noob here but I can't figure out if I'm doing
> something wrong or the binary itself has a problem.
> If I try to just run the bin/netbeans shell script, I get the following
> error:
> WARNING [org.netbeans.core.startup.Main]
> java.lang.NoClassDefFoundError: org.netbeans.license.AcceptLicense starting
> from org.netbeans.MainImpl$BootClassLoader@1c20c684 with possible defining
> loaders null and declared parents ]
> at org.netbeans.core.startup.Main.getKlass(Main.java:341)
>
>
> Ate
>

Give JavaHelp a chance! was: Release Apache NetBeans 9.0 Alpha (incubating)

Hello Ate,
thanks for trying the NetBeans Platform 9.0 Alpha bits.


> And that still has status "To do". Furthermore, it depends on the *GPL*

> external jsearch-2.0_05.jar which is a no-go... for the ASF.
> See: https://www.apache.org/legal/resolved.html#category-x
>
> ...

>

> Note that the binary also includes the jsearch jar.
> And while the binary isn't the release itself, if/when a convenience
> binary is provided *then* it needs to be in compliance with the
> distribution rules. So no GPL artifacts allowed.
>
>
Yes, NetBeans depends on JavaHelp and JavaHelp has been developed under
GPLv2 with CP exception. However the last commit has been made ten years
ago by me or Jesse Glick - e.g. nobody cares about JavaHelp anymore. That
means there are no business reasons to keep JavaHelp under GPLv2. As such
we are trying to convince Oracle to relicense JavaHelp and release it under
more Apache friendly license.  toThere are at least two good reasons to do
it:

#1 - simplify NetBeans Apache incubation
#2 - simplify acceptance of JavaEE into Eclipse Foundation (yes, JavaEE
also needs JavaHelp for some reason)

While we saw a bit of resistance when we used #1 as argument for
re-licensing JavaHelp, things started to change when #2 issue showed up. As
such we believe that the JavaHelp licensing issue will be resolved soon
(measuring that in the glacier speed changes are happening in Oracle). In
any case I believe in a year or two we can expected JavaHelp with a
friendly license.

Btw. there already is https://github.com/javaee/javahelp with CDDL license.
A proof the JavaEE guys are solving the same problem. Maybe we can just use
JavaHelp from that source and our GPL problems are gone. In any case I
don't think we need urgent surgery/lobotomy for 1st NetBeans Alpha
(incubating) release. It may be wiser to wait until the problem solves
itself.

All I am asking: Please give JavaHelp a chance!
-jt

Re: YouTube: Apache NetBeans (incubating) at Devoxx 2017




On 2017-11-07 20:00, Geertjan Wielenga wrote:

https://www.youtube.com/watch?v=n9uKRYGfTd8


The stream has been indexed, Netbeans session now starts at:
  https://www.youtube.com/watch?v=n9uKRYGfTd8&t=9h40s



At the above location, from about -54 minutes to the end (i.e., at the end
of the steam), you'll see a short presentation given this evening about
Apache NetBeans at Devoxx in Belgium -- by several people -- me, Sven,
Kirk, Johan, including Ate (one of our mentors).

Hopefully you can all find it and watch it -- I think it's pretty
interesting and we got some questions at the end too.

Apologies for not announcing this event up front -- it's quite a
significant little event that happened with several people speaking and a
complete update on where we are, plus you'll see several people possibly
for the first time for real. :-)

Gj

Re: [VOTE] Release Apache NetBeans 9.0 Alpha (incubating)

2017-11-08 Thread mario-leander.rei...@qaware.de

+1 Release this package as Apache NetBeans 9.0 Alpha (incubating)

Re: [VOTE] Release Apache NetBeans 9.0 Alpha (incubating)