Re: Becoming a Apache comiter - signed iCLA for the NetBeans project

[Emilian Bold]

Who is "we"?

--emi

On joi, nov. 2, 2017 at 1:08 a.m., Jiří Kovalský  
wrote:

> Yes, Jan is not listed there but we would like him to get the committer 
> access. What do we need to do in order to make this happen? Thanks a lot, 
> -Jirka Dne 1.11.2017 v 22:52 Craig Russell napsal(a): > Hi Jan, > >> On Nov 
> 1, 2017, at 7:59 AM, Jan Pirek wrote: >> >> Hello, >> based on the procedure 
> in the 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_NETBEANS_How-2Bto-2BParticipate=DwIFAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4=sdCVVlpIaWI3cEtqSo7JA2TN0FCp3p37WQllc4SEYpU=TLl_cEvP3X4HRoINhCQvHlCZF7b-v4AmUQOHZpIyTeA=
>  > > Could you please tell us what part of that page you are referencing? As 
> far as I can see, you are not listed as an original committer. > > Regards, > 
> > Craig > >> , I am sending you signed iCLA required to become a commiter to 
> the NetBeans project. >> >> Jiri Kovalsky CC'ed here can confirm my identity 
> if needed. >> >> Thanks, >> jan >> >> -- >> Jan Pirek >> Visual Builder Cloud 
> Service >> Oracle >> >>  > > Craig L Russell > Secretary, Apache Software 
> Foundation > c...@apache.org 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__db.apache.org_jdo=DwIFAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4=sdCVVlpIaWI3cEtqSo7JA2TN0FCp3p37WQllc4SEYpU=hV9rVjR6pyepBT1G-z-9_wkZh9z8d2ZXPuSHpUomqjc=
>  > @oracle.com>

[GitHub] jlahoda commented on issue #213: org.jdesktop.layout library is under LGPL and cannot be used.

[GitBox]

jlahoda commented on issue #213: org.jdesktop.layout library is under LGPL and 
cannot be used.
URL: 
https://github.com/apache/incubator-netbeans/pull/213#issuecomment-341274646
 
 
   @junichi11, right, thanks. I've forgot about that (and missed it when 
looking at the patch). Sorry for that. Will fix tomorrow.
   


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] junichi11 commented on issue #213: org.jdesktop.layout library is under LGPL and cannot be used.

[GitBox]

junichi11 commented on issue #213: org.jdesktop.layout library is under LGPL 
and cannot be used.
URL: 
https://github.com/apache/incubator-netbeans/pull/213#issuecomment-341271195
 
 
   @jlahoda  It seems that the license headers are removed from *.form files 
automatically.


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: Becoming a Apache comiter - signed iCLA for the NetBeans project

[Geertjan Wielenga]

Like everyone else, we’ll need to start a vote process for him to vote him
in, soon.

Gj

On Thu, 2 Nov 2017 at 00:08, Jiří Kovalský  wrote:

> Yes, Jan is not listed there but we would like him to get the committer
> access. What do we need to do in order to make this happen?
>
> Thanks a lot,
> -Jirka
>
> Dne 1.11.2017 v 22:52 Craig Russell napsal(a):
> > Hi Jan,
> >
> >> On Nov 1, 2017, at 7:59 AM, Jan Pirek  wrote:
> >>
> >> Hello,
> >> based on the procedure in the
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_NETBEANS_How-2Bto-2BParticipate=DwIFAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4=sdCVVlpIaWI3cEtqSo7JA2TN0FCp3p37WQllc4SEYpU=TLl_cEvP3X4HRoINhCQvHlCZF7b-v4AmUQOHZpIyTeA=
> >
> > Could you please tell us what part of that page you are referencing? As
> far as I can see, you are not listed as an original committer.
> >
> > Regards,
> >
> > Craig
> >
> >> , I am sending you signed iCLA required to become a commiter to the
> NetBeans project.
> >>
> >> Jiri Kovalsky CC'ed here can confirm my identity if needed.
> >>
> >> Thanks,
> >> jan
> >>
> >> --
> >> Jan Pirek
> >> Visual Builder Cloud Service
> >> Oracle
> >>
> >> 
> >
> > Craig L Russell
> > Secretary, Apache Software Foundation
> > c...@apache.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__db.apache.org_jdo=DwIFAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4=sdCVVlpIaWI3cEtqSo7JA2TN0FCp3p37WQllc4SEYpU=hV9rVjR6pyepBT1G-z-9_wkZh9z8d2ZXPuSHpUomqjc=
> >
>

Re: Becoming a Apache comiter - signed iCLA for the NetBeans project

[Jiří Kovalský]

Yes, Jan is not listed there but we would like him to get the committer 
access. What do we need to do in order to make this happen?


Thanks a lot,
-Jirka

Dne 1.11.2017 v 22:52 Craig Russell napsal(a):

Hi Jan,


On Nov 1, 2017, at 7:59 AM, Jan Pirek  wrote:

Hello,
based on the procedure in the 
https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_NETBEANS_How-2Bto-2BParticipate=DwIFAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4=sdCVVlpIaWI3cEtqSo7JA2TN0FCp3p37WQllc4SEYpU=TLl_cEvP3X4HRoINhCQvHlCZF7b-v4AmUQOHZpIyTeA=


Could you please tell us what part of that page you are referencing? As far as 
I can see, you are not listed as an original committer.

Regards,

Craig


, I am sending you signed iCLA required to become a commiter to the NetBeans 
project.

Jiri Kovalsky CC'ed here can confirm my identity if needed.

Thanks,
jan

--
Jan Pirek
Visual Builder Cloud Service
Oracle




Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org 
https://urldefense.proofpoint.com/v2/url?u=http-3A__db.apache.org_jdo=DwIFAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4=sdCVVlpIaWI3cEtqSo7JA2TN0FCp3p37WQllc4SEYpU=hV9rVjR6pyepBT1G-z-9_wkZh9z8d2ZXPuSHpUomqjc=

[GitHub] ebarboni commented on issue #215: Disabling check for maven coordinates in RatReportTask.

[GitBox]

ebarboni commented on issue #215: Disabling check for maven coordinates in 
RatReportTask.
URL: 
https://github.com/apache/incubator-netbeans/pull/215#issuecomment-341263931
 
 
   +1 make sens , some artefact are impossible to get from central.


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: Becoming a Apache comiter - signed iCLA for the NetBeans project

[Craig Russell]

Hi Jan,

> On Nov 1, 2017, at 7:59 AM, Jan Pirek  wrote:
> 
> Hello,
> based on the procedure in the 
> https://cwiki.apache.org/confluence/display/NETBEANS/How+to+Participate

Could you please tell us what part of that page you are referencing? As far as 
I can see, you are not listed as an original committer.

Regards,

Craig

> , I am sending you signed iCLA required to become a commiter to the NetBeans 
> project.
> 
> Jiri Kovalsky CC'ed here can confirm my identity if needed.
> 
> Thanks,
> jan
> 
> -- 
> Jan Pirek
> Visual Builder Cloud Service
> Oracle
> 
> 

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo

[GitHub] matthiasblaesing commented on issue #216: Adjusting header in libs.osgi/external/osgi-5.0-license.txt, org.osgi?

[GitBox]

matthiasblaesing commented on issue #216: Adjusting header in 
libs.osgi/external/osgi-5.0-license.txt, org.osgi?
URL: 
https://github.com/apache/incubator-netbeans/pull/216#issuecomment-341251411
 
 
   If anyone is interest to the why I added the third entry: 
   
   - `org.osgi.compendium-4.2.0.jar` is downloaded from maven central
   - the build process created `osgi.cmpn-4.2.jar` by stripping the sources 
from the downloaded package
   
   So the third file exists and is used and bundled. Whether that changes 
anything I don't know.


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 #213: org.jdesktop.layout library is under LGPL and cannot be used.

[GitBox]

geertjanw commented on issue #213: org.jdesktop.layout library is under LGPL 
and cannot be used.
URL: 
https://github.com/apache/incubator-netbeans/pull/213#issuecomment-341239268
 
 
   +1 for merging this.


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] svenreimers commented on issue #215: Disabling check for maven coordinates in RatReportTask.

[GitBox]

svenreimers commented on issue #215: Disabling check for maven coordinates in 
RatReportTask.
URL: 
https://github.com/apache/incubator-netbeans/pull/215#issuecomment-341234581
 
 
   Looks good for me +1


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 #215: Disabling check for maven coordinates in RatReportTask.

[GitBox]

geertjanw commented on issue #215: Disabling check for maven coordinates in 
RatReportTask.
URL: 
https://github.com/apache/incubator-netbeans/pull/215#issuecomment-341232736
 
 
   +1 Makes sense to me and great.


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 #216: Adjusting header in libs.osgi/external/osgi-5.0-license.txt, org.osgi?

[GitBox]

geertjanw closed pull request #216: Adjusting header in 
libs.osgi/external/osgi-5.0-license.txt, org.osgi?
URL: https://github.com/apache/incubator-netbeans/pull/216
 
 
   

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/libs.osgi/external/osgi-5.0-license.txt 
b/libs.osgi/external/osgi-5.0-license.txt
index 807a5531d..ce394fadf 100644
--- a/libs.osgi/external/osgi-5.0-license.txt
+++ b/libs.osgi/external/osgi-5.0-license.txt
@@ -1,6 +1,6 @@
 Name: OSGi
 Version: 5.0
-Files: osgi.core-5.0.0.jar osgi.cmpn-4.2.jar org.osgi.compendium-4.2.0.jar
+Files: osgi.core-5.0.0.jar org.osgi.compendium-4.2.0.jar
 Description: OSGi specification (core & compendium).
 License: Apache-2.0
 Origin: OSGi


 


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 #216: Adjusting header in libs.osgi/external/osgi-5.0-license.txt, org.osgi?

[GitBox]

geertjanw commented on issue #216: Adjusting header in 
libs.osgi/external/osgi-5.0-license.txt, org.osgi?
URL: 
https://github.com/apache/incubator-netbeans/pull/216#issuecomment-341232503
 
 
   Thanks!


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: Do we want multiple download servers

[Emilian Bold]

> I know this is a problem of mine, worring about these things, so I apologize 
> for being so tiresome asking questions all the time. I’ll focus on finishing 
> the licensing stuff and leave the final solution to this for later.

This is exactly the kind of questions that need to be asked. No need to 
apologize, you are doing great work!

--emi

On mie., nov. 1, 2017 at 9:39 p.m., Antonio Vieiro  wrote:

> Hi all, I know I’ve been raising lots of questions about binary dependencies 
> lately. The fact is that I don’t feel comfortable having them stored in 
> hg.netbeans.org/binaries knowing this is going away. I’d prefer having as a 
> solid build system as we can get. I’d prefer not having to upgrade/downgrade 
> versions because artifacts are not in Maven central. Currently we have 10 
> o.eclipse.mylyn.* modules that depend on binaries that are not in Maven 
> central, that’s why I’m searching alternatives to hg.netbeans.org/binaries. 
> I’m glad to hear Emilian has an alternative repo. I know this is a problem of 
> mine, worring about these things, so I apologize for being so tiresome asking 
> questions all the time. I’ll focus on finishing the licensing stuff and leave 
> the final solution to this for later. Anyway I’m glad there’s been some 
> discussion on the matter. Cheers, Antonio > El 1 nov 2017, a las 14:27, 
> Emilian Bold escribió: > > If we cannot use Maven Central or some other "big" 
> official repositories that guarantee some integrity, then we might as well 
> use our own setup. > > In the future http://hg.netbeans.org/binaries might be 
> going away, but we still have http://netbeans.osuosl.org/binaries/ which is 
> under my control and where we have a lot of bandwidth and enough space. Also 
> see the article about this 
> https://jaxenter.com/netbeans/towards-building-netbeans-new-home > > So I 
> suggest we don't make this overly complicated. Right now we can leave some 
> binaries as they are and keep using http://hg.netbeans.org/binaries until it 
> goes down. Later on we can switch to http://netbeans.osuosl.org/binaries/ 
> (and perhaps also add a new folder just for new binaries, perhaps 
> http://netbeans.osuosl.org/apache-binaries/ or something). > > --emi > >> 
>  Original Message  >> Subject: Do we want multiple download 
> servers >> Local Time: November 1, 2017 11:29 AM >> UTC Time: November 1, 
> 2017 9:29 AM >> From: anto...@vieiro.net >> To: 
> dev@netbeans.incubator.apache.org >> >> Hi all, >> >> PROBLEM: >> >> The 
> mylyn binaries are not available in Maven central. Nor in any other >> Maven 
> repository. >> >> SOLUTION: >> >> We could use the eclipse downloads system, 
> with automatic mirror >> selection, with [1]. >> >> So, for instance, to 
> download the jar file >> 
> org.eclipse.mylyn.tasks.core_3.17.0.v20150828-2026.jar for the >> 
> o.eclipse.mylyn.tasks.core module we could use the url [2], and we could >> 
> then use an appropriate SHA-1 to verify that the download is correct. >> >> 
> All mylyn binaries are available there (maybe other binaries as well). >> >> 
> Currently the build system uses a single server >> 
> (nbbuild/default-properties.xml|binaries.server). But we could specify >> 
> multiple download servers and try to download from them in order, until >> 
> the download succeeds. >> >> QUESTIONS: >> >> Would it be a good idea to add 
> support for multiple URLs into >> "binaries.server"? Is it ok to download 
> binaries from the >> www.eclipse.org/downloads URL? Do you want me to submit 
> a PR with this? >> >> Thanks, >> Antonio >> >> >> [1] >> 
> http://www.eclipse.org/downloads/download.php?file=/mylyn/drops/3.17.0/v20150909-1855/plugins
>  >> >> [2] >> 
> http://www.eclipse.org/downloads/download.php?file=/mylyn/drops/3.17.0/v20150909-1855/plugins/org.eclipse.mylyn.tasks.core_3.17.0.v20150828-2026.jar
>  @protonmail.ch>

Re: Do we want multiple download servers

[Antonio Vieiro]

Hi all,

I know I’ve been raising lots of questions about binary dependencies lately. 
The fact is that I don’t feel comfortable having them stored in 
hg.netbeans.org/binaries knowing this is going away. I’d prefer having as a 
solid build system as we can get. I’d prefer not having to upgrade/downgrade 
versions because artifacts are not in Maven central. 

Currently we have 10 o.eclipse.mylyn.* modules that depend on binaries that are 
not in Maven central, that’s why I’m searching alternatives to 
hg.netbeans.org/binaries. I’m glad to hear Emilian has an alternative repo.

I know this is a problem of mine, worring about these things, so I apologize 
for being so tiresome asking questions all the time. I’ll focus on finishing 
the licensing stuff and leave the final solution to this for later.

Anyway I’m glad there’s been some discussion on the matter.

Cheers,
Antonio


> El 1 nov 2017, a las 14:27, Emilian Bold  
> escribió:
> 
> If we cannot use Maven Central or some other "big" official repositories that 
> guarantee some integrity, then we might as well use our own setup.
> 
> In the future http://hg.netbeans.org/binaries might be going away, but we 
> still have http://netbeans.osuosl.org/binaries/ which is under my control and 
> where we have a lot of bandwidth and enough space. Also see the article about 
> this https://jaxenter.com/netbeans/towards-building-netbeans-new-home
> 
> So I suggest we don't make this overly complicated. Right now we can leave 
> some binaries as they are and keep using http://hg.netbeans.org/binaries 
> until it goes down. Later on we can switch to 
> http://netbeans.osuosl.org/binaries/ (and perhaps also add a new folder just 
> for new binaries, perhaps http://netbeans.osuosl.org/apache-binaries/ or 
> something).
> 
> --emi
> 
>>  Original Message 
>> Subject: Do we want multiple download servers
>> Local Time: November 1, 2017 11:29 AM
>> UTC Time: November 1, 2017 9:29 AM
>> From: anto...@vieiro.net
>> To: dev@netbeans.incubator.apache.org
>> 
>> Hi all,
>> 
>> PROBLEM:
>> 
>> The mylyn binaries are not available in Maven central. Nor in any other
>> Maven repository.
>> 
>> SOLUTION:
>> 
>> We could use the eclipse downloads system, with automatic mirror
>> selection, with [1].
>> 
>> So, for instance, to download the jar file
>> org.eclipse.mylyn.tasks.core_3.17.0.v20150828-2026.jar for the
>> o.eclipse.mylyn.tasks.core module we could use the url [2], and we could
>> then use an appropriate SHA-1 to verify that the download is correct.
>> 
>> All mylyn binaries are available there (maybe other binaries as well).
>> 
>> Currently the build system uses a single server
>> (nbbuild/default-properties.xml|binaries.server). But we could specify
>> multiple download servers and try to download from them in order, until
>> the download succeeds.
>> 
>> QUESTIONS:
>> 
>> Would it be a good idea to add support for multiple URLs into
>> "binaries.server"? Is it ok to download binaries from the
>> www.eclipse.org/downloads URL? Do you want me to submit a PR with this?
>> 
>> Thanks,
>> Antonio
>> 
>> 
>> [1]
>> http://www.eclipse.org/downloads/download.php?file=/mylyn/drops/3.17.0/v20150909-1855/plugins
>> 
>> [2]
>> http://www.eclipse.org/downloads/download.php?file=/mylyn/drops/3.17.0/v20150909-1855/plugins/org.eclipse.mylyn.tasks.core_3.17.0.v20150828-2026.jar

Re: Current Status & Proposed Plan for Apache NetBeans

[Sven Reimers]

Awesome.

PR's look good to me.


Sven

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

> FWIW, I've started with a Jenkins job to build release artefacts, for the
> with "9.0 alpha" platform-only release here:
> https://builds.apache.org/view/Incubator%20Projects/job/
> incubator-netbeans-release/
>
> Please note this is still a work-in-progress.
>
> The idea is that the build should do very minimal checks to verify
> releaseability. When the build passes/is blue, we could send the release
> vote e-mail.
>
> The checks performed are:
> -rat
> -ant verify-libs-and-licenses (checks consistency between -licence.txt
> files, binaries and nbbuild/licenses; IMO this is one of the
> pre-requisities to have a trustworthy DEPENDENCIES file)
>
> The job builds both the source (to-be-release) zip and a convenience
> binary.
>
> Please note that I've just submitted two PR that fix (or "fix") some of the
> problems:
> https://github.com/apache/incubator-netbeans/pull/216
> https://github.com/apache/incubator-netbeans/pull/215
>
> Feedback is welcome.
>
> Thanks,
> Jan
>
>
> On Tue, Oct 31, 2017 at 1:52 PM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
>
> > Hi all,
> >
> > We're making great progress, we have been working together well, and have
> > IP clearance related commits from a significant group constituting a
> range
> > of different people:
> >
> > https://github.com/apache/incubator-netbeans/graphs/contributors
> >
> > To dos:
> >
> > 1. There's around 300 (out of 45,000) files left to process -- the sooner
> > we can get that down to 0, either via re-licensing or via Rat exclusions,
> > the better. That should be our central focus for this week. Take a look
> at
> > the Rat report, see who is listed to work on it, and work with them to
> get
> > it done:
> >
> > https://cwiki.apache.org/confluence/display/NETBEANS/
> > List+of+Modules+to+Review
> >
> > 2. We've also been working on downloading binaries from Maven Central,
> > i.e., that's the logical and officially accepted place for binaries and
> > we're trying to leverage that as much as possible -- though that's not a
> > requirement for releasing NetBeans from Apache.
> >
> > 3. Binaries that are GPL-ed need to be handled in some way -- in terms of
> > the core of NetBeans, i.e., the NetBeans Platform, that means JavaHelp
> and
> > SwingLayout. Various solutions have been offered and discussed re
> JavaHelp,
> > while SwingLayout may simply need to be removed, as a first attempt to
> get
> > rid of it, and then we should see what the consequence of doing that is
> and
> > fixing where needed.
> >
> > 4. Plan a first Apache release. Here's a proposal:
> >
> > - Apache NetBeans 9.0 Alpha -- NetBeans Platform only (i.e., only the
> core
> > modules, possibly without JavaHelp). In this way, we'll have worked
> through
> > the process for a coherent part of Apache NetBeans and will only have
> > JavaHelp and SwingLayout to deal with in terms of GPL. (I believe SwingX
> is
> > not applicable to the platform, but the IDE.)
> >
> > - Apache NetBeans 9.0 Beta -- Everything currently in Apache NetBeans
> Git,
> > i.e., the above and then also including all the other clusters currently
> > there, i.e., Java SE tooling.
> >
> > - Apache NetBeans 9.0 -- All of the above, including NetCAT involvement.
> > This will be the officially tested version of Apache NetBeans.
> >
> > 5. I propose we aim to begin with the official release process of Apache
> > NetBeans 9.0 Alpha next week.
> >
> > 6. All the other parts of NetBeans (Java EE etc) are still in process at
> > Oracle, which is good, since it means we're able to focus on the subset
> > we're currently working on.
> >
> > Comments and feedback welcome,
> >
> > Geertjan
> >
>



-- 
Sven Reimers

* Senior Expert Software Architect
* Java Champion
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* Community Leader  NetBeans: http://community.java.net/netbeans
  Desktop Java:
http://community.java.net/javadesktop
* JUG Leader JUG Bodensee: http://www.jug-bodensee.de
* Duke's Choice Award Winner 2009

* XING: https://www.xing.com/profile/Sven_Reimers8
* LinkedIn: http://www.linkedin.com/in/svenreimers

Re: Current Status & Proposed Plan for Apache NetBeans

[Jan Lahoda]

FWIW, I've started with a Jenkins job to build release artefacts, for the
with "9.0 alpha" platform-only release here:
https://builds.apache.org/view/Incubator%20Projects/job/incubator-netbeans-release/

Please note this is still a work-in-progress.

The idea is that the build should do very minimal checks to verify
releaseability. When the build passes/is blue, we could send the release
vote e-mail.

The checks performed are:
-rat
-ant verify-libs-and-licenses (checks consistency between -licence.txt
files, binaries and nbbuild/licenses; IMO this is one of the
pre-requisities to have a trustworthy DEPENDENCIES file)

The job builds both the source (to-be-release) zip and a convenience binary.

Please note that I've just submitted two PR that fix (or "fix") some of the
problems:
https://github.com/apache/incubator-netbeans/pull/216
https://github.com/apache/incubator-netbeans/pull/215

Feedback is welcome.

Thanks,
Jan


On Tue, Oct 31, 2017 at 1:52 PM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> Hi all,
>
> We're making great progress, we have been working together well, and have
> IP clearance related commits from a significant group constituting a range
> of different people:
>
> https://github.com/apache/incubator-netbeans/graphs/contributors
>
> To dos:
>
> 1. There's around 300 (out of 45,000) files left to process -- the sooner
> we can get that down to 0, either via re-licensing or via Rat exclusions,
> the better. That should be our central focus for this week. Take a look at
> the Rat report, see who is listed to work on it, and work with them to get
> it done:
>
> https://cwiki.apache.org/confluence/display/NETBEANS/
> List+of+Modules+to+Review
>
> 2. We've also been working on downloading binaries from Maven Central,
> i.e., that's the logical and officially accepted place for binaries and
> we're trying to leverage that as much as possible -- though that's not a
> requirement for releasing NetBeans from Apache.
>
> 3. Binaries that are GPL-ed need to be handled in some way -- in terms of
> the core of NetBeans, i.e., the NetBeans Platform, that means JavaHelp and
> SwingLayout. Various solutions have been offered and discussed re JavaHelp,
> while SwingLayout may simply need to be removed, as a first attempt to get
> rid of it, and then we should see what the consequence of doing that is and
> fixing where needed.
>
> 4. Plan a first Apache release. Here's a proposal:
>
> - Apache NetBeans 9.0 Alpha -- NetBeans Platform only (i.e., only the core
> modules, possibly without JavaHelp). In this way, we'll have worked through
> the process for a coherent part of Apache NetBeans and will only have
> JavaHelp and SwingLayout to deal with in terms of GPL. (I believe SwingX is
> not applicable to the platform, but the IDE.)
>
> - Apache NetBeans 9.0 Beta -- Everything currently in Apache NetBeans Git,
> i.e., the above and then also including all the other clusters currently
> there, i.e., Java SE tooling.
>
> - Apache NetBeans 9.0 -- All of the above, including NetCAT involvement.
> This will be the officially tested version of Apache NetBeans.
>
> 5. I propose we aim to begin with the official release process of Apache
> NetBeans 9.0 Alpha next week.
>
> 6. All the other parts of NetBeans (Java EE etc) are still in process at
> Oracle, which is good, since it means we're able to focus on the subset
> we're currently working on.
>
> Comments and feedback welcome,
>
> Geertjan
>

[GitHub] jlahoda opened a new pull request #216: Adjusting header in libs.osgi/external/osgi-5.0-license.txt, org.osgi?

[GitBox]

jlahoda opened a new pull request #216: Adjusting header in 
libs.osgi/external/osgi-5.0-license.txt, org.osgi?
URL: https://github.com/apache/incubator-netbeans/pull/216
 
 
   ?.compendium-4.2.0.jar is used now, not osgi.cmpn-4.2.jar.


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 #215: Disabling check for maven coordinates in RatReportTask.

[GitBox]

jlahoda opened a new pull request #215: Disabling check for maven coordinates 
in RatReportTask.
URL: https://github.com/apache/incubator-netbeans/pull/215
 
 
   The RatReportTask is checking that external binaries are downloaded using 
maven coordinates. While In principle that check is not bad, I'd like to remove 
it. There's a couple reasons for that:
   1. I don't think it is a hard-error at this time to download binaries not 
using maven coordinates.
   2. we have the ant verify-libs-and-licenses working again (for platform at 
least). This is checking consistency between the license files, binaries and 
nbbuild/licenses. If at some point it should become a hard error to not 
download from maven, then verify-libs-and-licenses seems like a better place to 
do the check.
   3. I think it would be cleaner if RatReportTask would just convert the rat 
report to junit test files, and not do any checks itself.
   
   The main driving force behind this patch is that I am trying to set-up a 
"release" job (a job that produced release artefacts), and I'd like it to run 
Rat and verify-libs-and-licenses and when the build is passing/blue, we could 
try to release. And I don't think it is realistic to only use maven coordinates 
in near enough future.


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: Support for (Java) Pattern Matching

[Jan Lahoda]

On Wed, Nov 1, 2017 at 5:49 PM, Jesse Glick  wrote:

> On Wed, Nov 1, 2017 at 8:35 AM, Jan Lahoda  wrote:
> > you propose to open the PR from the
> > personal fork and leave it open for moths or years so that the code is
> > "perpetually" submitted to the ASF and can (hopefully!) be used, while
> the
> > actual development is still happening on a branch in a personal fork
> (which
> > is the source for the PR). Sounds like a workaround to me (the pull
> request
> > is not really requesting anything to be pulled for most of the lifetime
> of
> > the PR).
>
> A PR should be a unit of work that could plausibly be merged and
> released. If you are releasing betas from some `patterns` branch in
> origin, then most PRs to it would just be things like fixing some bug
> in pattern support. I presume these would not typically be stalled for
> more than a few weeks on end, even if a vacation intervenes. The
> initial basic support for patterns might be one largish PR.
>
> > it definitely seems smoother to me to do "git push" then to do "git
> push", go to a browser, open github, open a PR, and possibly wait and merge
> it to an ASF repo
>
> Well, sure. There are CLI tools to automate steps, but really the
> benefits of peer review more than counterbalance any technical
> inconvenience in my experience. Even when you do not get any feedback
> on a PR and wind up merging it yourself as a committer, knowing that
> someone _might_ be reviewing it forces you to think a bit more about
> presenting your work.
>

On one hand yes, on the other one: even the pushed (merged) code is still
open, and anyone can review it and provide feedback. The PR can make it
more convenient in some cases, but a commit may be reviewed any time
anyway, so I'd assume such forces to be in place all the time. Overall, I
am afraid I am not aware of a feedback neither the jdk-javac nor the
jdk/amber/patterns branch, and I am not sure if just using a PR would make
a difference in that.

Anyway, I am thinking of trying to use the long-term work-in-progress PR
for the impl. of
https://cwiki.apache.org/confluence/display/NETBEANS/JDK+Modules+Support+in+NetBeans+Module+System,
I hope that may lead to some more feedback.

Jan


> Obviously every development team has different policies and styles,
> and you can find ways to accommodate them all; it is a question of
> what culture you want to define.
>

Re: Current Status & Proposed Plan for Apache NetBeans

[Geertjan Wielenga]

On Wed, Nov 1, 2017 at 5:54 PM, Jesse Glick  wrote:

> On Wed, Nov 1, 2017 at 7:52 AM, Jan Lahoda  wrote:
> > There was a significant time between the snapshot for the donation was
> made
> > and the donation actually happened. That's unfortunate, but I don't think
> > anybody here could do anything about that (Geertjan tried, AFAIK).
>
> To be clear, I have no problem with that decision. I am just
> suggesting that it be clearly communicated somewhere prominent.
>
> https://github.com/apache/incubator-netbeans/blob/master/README.md
>
> for example could note the last-synchronized Mercurial revision and
> explain the potential implications for contributors. (At least until
> automated synchronization is up and running, or the relevant portions
> of the Mercurial repository are officially closed.)
>


Sure, makes sense, will do.

Gj

Re: Current Status & Proposed Plan for Apache NetBeans

[Jesse Glick]

On Wed, Nov 1, 2017 at 7:52 AM, Jan Lahoda  wrote:
> There was a significant time between the snapshot for the donation was made
> and the donation actually happened. That's unfortunate, but I don't think
> anybody here could do anything about that (Geertjan tried, AFAIK).

To be clear, I have no problem with that decision. I am just
suggesting that it be clearly communicated somewhere prominent.

https://github.com/apache/incubator-netbeans/blob/master/README.md

for example could note the last-synchronized Mercurial revision and
explain the potential implications for contributors. (At least until
automated synchronization is up and running, or the relevant portions
of the Mercurial repository are officially closed.)

Re: Current Status & Proposed Plan for Apache NetBeans

[Jan Lahoda]

AFAIK, the zip was created from the donation_review branch on the
http://hg.netbeans.org/releases repository. IIRC, the branch was originally
branched from default sometime in December last year, but then was updated
with default branch changes sometime in April. If I am looking right, the
last common changeset is "426cf49d9cea9fb8ffc4ac63b87ea6a4a6e08196":
$ hg debugancestor donation_review default
303705:426cf49d9cea9fb8ffc4ac63b87ea6a4a6e08196

So we are talking about changes between this changeset and the tip of the
default branch (in either the releases repository, or the jet-main
repository, these should be mostly in synch if all goes well).

Jan

On Wed, Nov 1, 2017 at 4:57 PM, Matthias Bläsing 
wrote:

> Hey,
>
> Am Mittwoch, den 01.11.2017, 13:16 +0100 schrieb Bertrand Delacretaz:
> >
> > On Wed, Nov 1, 2017 at 12:52 PM, Jan Lahoda  wrote:
> > > ...To the best of my knowledge, getting the changes (for donated
> > > modules) from
> > > hg.nb.org to the incubator-netbeans repository is a work in
> > > progress...
> >
> > I don't know how many changes this represents, but IMO the simplest
> > way to bring them here is to have their authors contribute them again
> > to Apache NetBeans.
> >
>
> to know the extend of the problem, it would be good to know which
> mercurial revision the donation was build from. From there the
> changesets could be traced, that touched the donated modules and thus a
> list could be created.
>
> This assumes, that the donation was create from one of the core
> repositories.
>
> Can this be done?
>
> Thanks
>
> Matthias
>

Re: Current Status & Proposed Plan for Apache NetBeans

[Geertjan Wielenga]

Well, it's something that's being worked on from the Oracle side, we'll
keep everyone updated re this.

At the same time, it's not an urgent item right now at this stage -- what
is urgent and what we need to be narrowly focused on is that we need to
wrap things up (Apache Rat, GPL-ed binaries) and do the 1st Apache NetBeans
release for initially the core of NetBeans, i.e., the NetBeans Platform.

Gj

On Wed, Nov 1, 2017 at 4:57 PM, Matthias Bläsing 
wrote:

> Hey,
>
> Am Mittwoch, den 01.11.2017, 13:16 +0100 schrieb Bertrand Delacretaz:
> >
> > On Wed, Nov 1, 2017 at 12:52 PM, Jan Lahoda  wrote:
> > > ...To the best of my knowledge, getting the changes (for donated
> > > modules) from
> > > hg.nb.org to the incubator-netbeans repository is a work in
> > > progress...
> >
> > I don't know how many changes this represents, but IMO the simplest
> > way to bring them here is to have their authors contribute them again
> > to Apache NetBeans.
> >
>
> to know the extend of the problem, it would be good to know which
> mercurial revision the donation was build from. From there the
> changesets could be traced, that touched the donated modules and thus a
> list could be created.
>
> This assumes, that the donation was create from one of the core
> repositories.
>
> Can this be done?
>
> Thanks
>
> Matthias
>

Re: Current Status & Proposed Plan for Apache NetBeans

[Matthias Bläsing]

Hey,

Am Mittwoch, den 01.11.2017, 13:16 +0100 schrieb Bertrand Delacretaz:
> 
> On Wed, Nov 1, 2017 at 12:52 PM, Jan Lahoda  wrote:
> > ...To the best of my knowledge, getting the changes (for donated
> > modules) from
> > hg.nb.org to the incubator-netbeans repository is a work in
> > progress...
> 
> I don't know how many changes this represents, but IMO the simplest
> way to bring them here is to have their authors contribute them again
> to Apache NetBeans.
> 

to know the extend of the problem, it would be good to know which
mercurial revision the donation was build from. From there the
changesets could be traced, that touched the donated modules and thus a
list could be created.

This assumes, that the donation was create from one of the core
repositories.

Can this be done?

Thanks

Matthias

Re: Do we want multiple download servers

[Bertrand Delacretaz]

On Wed, Nov 1, 2017 at 3:12 PM, Emilian Bold  wrote:
> ...Since Apache does provide "convenience" binaries, ie. it does serve 
> dependencies,
> how is it suddenly strange to have a place to store only the dependencies?...

It's different if those binaries are from Apache projects or third parties.

Also, starting to be another Maven Central has costs and legal
implications, we cannot just do it without asking our infrastructure
team.

The current ASF mechanism for distributing *our* binaries and releases
is https://www.apache.org/mirrors/

-Bertrand

Re: Do we want multiple download servers

[Emilian Bold]

You know, in the old days when you just released a .tar.gz it was perfectly 
acceptable to have a lib/ folder in the archive with your dependencies.

Because there was no Maven Central or whatever and doing wget from 10 different 
FTP server for all the dependencies was seen as inconvenient.

Since Apache does provide "convenience" binaries, ie. it does serve 
dependencies, how is it suddenly strange to have a place to store only the 
dependencies?

In these modern times what we actually need is Git LFS and store those 
libraries there https://git-lfs.github.com

--emi

> Original Message 
>Subject: Re: Do we want multiple download servers
>Local Time: November 1, 2017 4:01 PM
>UTC Time: November 1, 2017 2:01 PM
>From: bdelacre...@apache.org
>To: dev@netbeans.incubator.apache.org
>
>On Wed, Nov 1, 2017 at 2:57 PM, Emilian Bold emilian.b...@protonmail.ch wrote:
>>...is there any reason INFRA could not provide us a basic FTP account to 
>>carry on http://hg.netbeans.org/binaries under Apache?...
>>
>> It depends on the cost, and hosting third-party binaries that we do
>> not control might be a problem.
>>
>> But maybe not - best is to write a concise problem description that we
>> can discuss here and maybe forward to INFRA.
>>
>> -Bertrand
>

Re: Support for (Java) Pattern Matching

[Jan Lahoda]

On Wed, Nov 1, 2017 at 12:49 PM, Neil C Smith  wrote:

> On Wed, Nov 1, 2017 at 6:32 AM Jan Lahoda  wrote:
>
> > -code provenance: when one opens a pull request against
> > apache/(incubating-)netbeans, then I think the code can be considered to
> be
> > submitted to ASF (per iCLA). Pushing a commit to a personal github
> > repository does not feel that way. So, for a long-running branch in a
> > personal repository, if the author of the branch cannot send the pull
> > request to merge it for whatever reason, how do we transfer the code to
> the
> > mainline (if we want it)? If the branch is in a ASF repo, it has already
> > been submitted to ASF, and anyone can continue without too much
> > (non-technical) issues.
> >
> > -how about releases from the branches. It may be desirable to do a
> > "preview" "release" for the branch (e.g. "pattern" preview; although I'd
> > prefer if we handled Java language features in the master, but even if we
> > succeed in that, it will take a long time to achieve). I don't think we
> can
> > release from a personal github.
> >
> >
> I'm tempted to say, with respect, you're making straw man arguments,
> although I think Jesse's email does imply longer lasting personal branches
> than might be desired.
>
> Git is distributed.  You have to have at least one clone (fork) to work
> with anyway, at least locally, so some commits happen elsewhere.  Your
> argument seems to rest on the fact that there would somehow be a difference
> in the scenarios between when you'd push to the main repo vs when you would
> push to your personal remote and file a PR.  Why?
>

(I believe this is different from what Jesse proposes because in your
proposal there would be only a short time between push to the personal repo
and a merge to the ASF repo.)

I don't have much against such approach (in a sense, it might be easier for
me if I'd just push to my github, and Geertjan merged the change for me).
OTOH, it definitely seems smoother to me to do "git push" then to do "git
push", go to a browser, open github, open a PR, and possibly wait and merge
it to an ASF repo. So I wonder if this is not discouraging contributions
unnecessarily.

Jan


>
> I'm 100% in agreement with the idea that all collaboration happens within
> the Apache repo (or within PR's to it before they merge) - even if this
> wasn't the Apache way.  But as Jesse says, this is a natural GitHub
> workflow, it's not onerous, and from the surveys I've seen narrowly the
> majority way of working (without starting Geertjan on the lack of merit of
> surveys! ;-) ).  That doesn't mean we have to choose it, but at some point
> we need a defined workflow that everyone knows how to use.
>
> Best wishes,
>
> Neil
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>

Re: Do we want multiple download servers

[Emilian Bold]

Actually, is there any reason INFRA could not provide us a basic FTP account to 
carry on http://hg.netbeans.org/binaries under Apache?

Then we wouldn't have to use OSUOSL, which are also an Apache mirror provider, 
so they already have a separate deal with the ASF.

This whole setup is just a way to keep the git repo size under control.

Because alternatively we could just commit 3rd party JARs, considering they 
*are* an IP cleared project dependency.

--emi

> Original Message 
>Subject: Re: Do we want multiple download servers
>Local Time: November 1, 2017 3:32 PM
>UTC Time: November 1, 2017 1:32 PM
>From: bdelacre...@apache.org
>To: dev@netbeans.incubator.apache.org
>
>Hi,
>
> On Wed, Nov 1, 2017 at 2:27 PM, Emilian Bold emilian.b...@protonmail.ch wrote:
>>...In the future http://hg.netbeans.org/binaries might be going away, but we 
>>still have http://netbeans.osuosl.org/binaries/
>> which is under my control...
>>
>> Note that any such resources should be put under control of the
>> NetBeans PPMC, for bus factor reasons.
>>
>> Also, before graduating, a list of non-Apache resource on which the
>> project depends should be established.
>>
>> -Bertrand

Re: Do we want multiple download servers

[Bertrand Delacretaz]

Hi,

On Wed, Nov 1, 2017 at 2:27 PM, Emilian Bold  wrote:
> ...In the future http://hg.netbeans.org/binaries might be going away, but we 
> still have http://netbeans.osuosl.org/binaries/
> which is under my control...

Note that any such resources should be put under control of the
NetBeans PPMC, for bus factor reasons.

Also, before graduating, a list of non-Apache resource on which the
project depends should be established.

-Bertrand

Re: Do we want multiple download servers

[Emilian Bold]

If we cannot use Maven Central or some other "big" official repositories that 
guarantee some integrity, then we might as well use our own setup.

In the future http://hg.netbeans.org/binaries might be going away, but we still 
have http://netbeans.osuosl.org/binaries/ which is under my control and where 
we have a lot of bandwidth and enough space. Also see the article about this 
https://jaxenter.com/netbeans/towards-building-netbeans-new-home

So I suggest we don't make this overly complicated. Right now we can leave some 
binaries as they are and keep using http://hg.netbeans.org/binaries until it 
goes down. Later on we can switch to http://netbeans.osuosl.org/binaries/ (and 
perhaps also add a new folder just for new binaries, perhaps 
http://netbeans.osuosl.org/apache-binaries/ or something).

--emi

> Original Message 
>Subject: Do we want multiple download servers
>Local Time: November 1, 2017 11:29 AM
>UTC Time: November 1, 2017 9:29 AM
>From: anto...@vieiro.net
>To: dev@netbeans.incubator.apache.org
>
>Hi all,
>
> PROBLEM:
>
> The mylyn binaries are not available in Maven central. Nor in any other
> Maven repository.
>
> SOLUTION:
>
> We could use the eclipse downloads system, with automatic mirror
> selection, with [1].
>
> So, for instance, to download the jar file
> org.eclipse.mylyn.tasks.core_3.17.0.v20150828-2026.jar for the
> o.eclipse.mylyn.tasks.core module we could use the url [2], and we could
> then use an appropriate SHA-1 to verify that the download is correct.
>
> All mylyn binaries are available there (maybe other binaries as well).
>
> Currently the build system uses a single server
> (nbbuild/default-properties.xml|binaries.server). But we could specify
> multiple download servers and try to download from them in order, until
> the download succeeds.
>
> QUESTIONS:
>
> Would it be a good idea to add support for multiple URLs into
> "binaries.server"? Is it ok to download binaries from the
>www.eclipse.org/downloads URL? Do you want me to submit a PR with this?
>
> Thanks,
> Antonio
>
>
> [1]
>http://www.eclipse.org/downloads/download.php?file=/mylyn/drops/3.17.0/v20150909-1855/plugins
>
> [2]
>http://www.eclipse.org/downloads/download.php?file=/mylyn/drops/3.17.0/v20150909-1855/plugins/org.eclipse.mylyn.tasks.core_3.17.0.v20150828-2026.jar
>

Re: Support for (Java) Pattern Matching

[Jan Lahoda]

On Wed, Nov 1, 2017 at 12:51 PM, Jesse Glick  wrote:

> On Wed, Nov 1, 2017 at 2:31 AM, Jan Lahoda  wrote:
> > when one opens a pull request against
> > apache/(incubating-)netbeans, then I think the code can be considered to
> be
> > submitted to ASF (per iCLA).
>
> IANAL but that sounds right.
>
> > for a long-running branch in a
> > personal repository, if the author of the branch cannot send the pull
> > request to merge it for whatever reason
>
> I recommend just filing a PR the moment you start the branch and have
> some initial commits. It can be marked as a work in progress / not for
> immediate merge / etc. with various labels. (It is possible to create
> PR search permalinks on GitHub which filter by label.) If your
> experiment never comes to anything, close the PR if you like. You can
> always reopen it and pick up where you left off, with review comments
> and everything intact.
>

So, if I understand it correctly, you propose to open the PR from the
personal fork and leave it open for moths or years so that the code is
"perpetually" submitted to the ASF and can (hopefully!) be used, while the
actual development is still happening on a branch in a personal fork (which
is the source for the PR). Sounds like a workaround to me (the pull request
is not really requesting anything to be pulled for most of the lifetime of
the PR).


>
> (Normally when merging a PR I would delete the corresponding fork
> branch, both on GitHub and in my local clone, to tidy up; but if you
> are closing a PR you expect to maybe resume work on later, you can
> just leave the branch in the remote. You could probably even recreate
> the branch based on the last commit hash visible in the PR, though I
> cannot recall ever trying that.)
>
> On this topic: the Eclipse foundation apparently has some tool they
> run automatically on PRs which verifies that all commits have been
> signed and that the signature matches someone with a CLA on file. This
> shows up as a GitHub status check, so you can see right in the PR
> whether the contribution is coming from someone who has done the right
> paperwork. If as a new contributor you forget about this, there will
> be a red X until you file a CLA, fix your Git settings, and amend your
> commit to include a signature.
>
> > how about releases from the branches. It may be desirable to do a
> > "preview" "release" for the branch (e.g. "pattern" preview; although I'd
> > prefer if we handled Java language features in the master, but even if we
> > succeed in that, it will take a long time to achieve). I don't think we
> can
> > release from a personal github.
>
> Certainly you would not want to cut official releases from a fork
> branch. If this is an official preview of some kind—like a beta
> release?—then there should I suppose be some origin branch for that
> purpose. You can still use PRs to propose specific additions to that
> branch; you just set the target branch accordingly when filing the PR.
>

I guess I am a little bit lost in the terminology here. If
incubator-netbeans/master is the branch from which the official final
releases are made, there may be a different branch say "patterns" somewhere
that contains support for Java language patterns. It is conceivable to me
that we may do an official (in the ASF sense) "patterns preview" release,
where people could try patterns, and there could be more bugs than in the
final release. AFAIK. This was being done for a long time for various
upcoming Java features. If we can have the future Java features supported
in master, that'd be great, but for that we either need some significant
improvements on the jdk-javac branch, or some other realistic proposal to
achieve that.

Jan


>
> It really depends on what your policy for distributing experimental
> changes is. As you say, using feature flags or hidden settings to
> enable unstable code in normal releases is the simplest approach for
> infrastructure, but might not be practical until the code has been
> refactored enough to allow this kind of behavior to be switched
> dynamically. So if you are publishing, essentially, forks of official
> modules, you are going to run into tricky questions anyway. What
> version number could you pick which is newer than the official
> ancestor merge base, but will be older than the official release
> version when the feature is stabilized, and incomparable to unrelated
> feature forks? Etc.
>

[GitHub] geertjanw commented on issue #213: org.jdesktop.layout library is under LGPL and cannot be used.

[GitBox]

geertjanw commented on issue #213: org.jdesktop.layout library is under LGPL 
and cannot be used.
URL: 
https://github.com/apache/incubator-netbeans/pull/213#issuecomment-341092473
 
 
   Thanks for this work, great to have this covered now.


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 #211: [NETBEANS-54] Module Review refactoring.java

[GitBox]

geertjanw closed pull request #211: [NETBEANS-54] Module Review refactoring.java
URL: https://github.com/apache/incubator-netbeans/pull/211
 
 
   

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/refactoring.java/test/unit/src/org/netbeans/modules/refactoring/java/test/resources/Class.java.template
 
b/refactoring.java/test/unit/src/org/netbeans/modules/refactoring/java/test/resources/Class.java.template
index eadb04611..de7967234 100644
--- 
a/refactoring.java/test/unit/src/org/netbeans/modules/refactoring/java/test/resources/Class.java.template
+++ 
b/refactoring.java/test/unit/src/org/netbeans/modules/refactoring/java/test/resources/Class.java.template
@@ -1,3 +1,23 @@
+<#--
+
+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.
+
+-->
 <#assign licenseFirst = "/*">
 <#assign licensePrefix = " * ">
 <#assign licenseLast = " */">
diff --git 
a/refactoring.java/test/unit/src/org/netbeans/modules/refactoring/java/test/resources/license-default.txt
 
b/refactoring.java/test/unit/src/org/netbeans/modules/refactoring/java/test/resources/license-default.txt
index 7b7b68d84..6d4afc2da 100644
--- 
a/refactoring.java/test/unit/src/org/netbeans/modules/refactoring/java/test/resources/license-default.txt
+++ 
b/refactoring.java/test/unit/src/org/netbeans/modules/refactoring/java/test/resources/license-default.txt
@@ -1,3 +1,23 @@
+<#--
+
+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.
+
+-->
 <#if licenseFirst??>
 ${licenseFirst}
 


 


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 #214: disabled failing tests

[GitBox]

geertjanw closed pull request #214: disabled failing tests
URL: https://github.com/apache/incubator-netbeans/pull/214
 
 
   

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/autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/NbmsInDownloadedTabTest.java
 
b/autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/NbmsInDownloadedTabTest.java
index ea82e6a07..b6d98f522 100644
--- 
a/autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/NbmsInDownloadedTabTest.java
+++ 
b/autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/NbmsInDownloadedTabTest.java
@@ -45,7 +45,7 @@ public NbmsInDownloadedTabTest(String testName) {
 super(testName);
 }
 
-public void testNbmDependsOnLowerVersion () throws IOException {
+public void disabledtestNbmDependsOnLowerVersion () throws IOException {
 URL higherEngineURL = TestUtils.class.getResource 
("data/org-yourorghere-engine-1-2.nbm");
 assertNotNull ("URL data/org-yourorghere-engine-1-2.nbm exits", 
higherEngineURL);
 File higherEngineNbm = TestUtils.getFile(this, higherEngineURL);
diff --git 
a/autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/NewClustersRebootTest.java
 
b/autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/NewClustersRebootTestDisabled.java
similarity index 98%
rename from 
autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/NewClustersRebootTest.java
rename to 
autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/NewClustersRebootTestDisabled.java
index 0bc13bcca..d86777ec5 100644
--- 
a/autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/NewClustersRebootTest.java
+++ 
b/autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/NewClustersRebootTestDisabled.java
@@ -34,10 +34,10 @@
 import org.openide.util.Lookup;
 import org.openide.util.Utilities;
 
-public class NewClustersRebootTest extends NbTestCase {
+public class NewClustersRebootTestDisabled extends NbTestCase {
 private Logger LOG;
 
-public NewClustersRebootTest(String testName) {
+public NewClustersRebootTestDisabled(String testName) {
 super(testName);
 }
 
diff --git 
a/autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/UpdateDisabledModuleTest.java
 
b/autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/UpdateDisabledModuleTestDisabled.java
similarity index 98%
rename from 
autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/UpdateDisabledModuleTest.java
rename to 
autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/UpdateDisabledModuleTestDisabled.java
index 5b7c4ac0d..f3bd94bef 100644
--- 
a/autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/UpdateDisabledModuleTest.java
+++ 
b/autoupdate.services/test/unit/src/org/netbeans/modules/autoupdate/services/UpdateDisabledModuleTestDisabled.java
@@ -51,11 +51,11 @@
  *
  * @author Jaroslav Tulach
  */
-public class UpdateDisabledModuleTest extends NbTestCase {
+public class UpdateDisabledModuleTestDisabled extends NbTestCase {
 static Manifest man;
 private File ud;
 
-public UpdateDisabledModuleTest(String testName) {
+public UpdateDisabledModuleTestDisabled(String testName) {
 super(testName);
 }
 


 


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 #214: disabled failing tests

[GitBox]

geertjanw commented on issue #214: disabled failing tests
URL: 
https://github.com/apache/incubator-netbeans/pull/214#issuecomment-341091990
 
 
   Thanks, merging.


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: Current Status & Proposed Plan for Apache NetBeans

[Bertrand Delacretaz]

Hi,

On Wed, Nov 1, 2017 at 12:52 PM, Jan Lahoda  wrote:
> ...To the best of my knowledge, getting the changes (for donated modules) from
> hg.nb.org to the incubator-netbeans repository is a work in progress...

I don't know how many changes this represents, but IMO the simplest
way to bring them here is to have their authors contribute them again
to Apache NetBeans.

-Bertrand

Re: Current Status & Proposed Plan for Apache NetBeans

[Jan Lahoda]

There was a significant time between the snapshot for the donation was made
and the donation actually happened. That's unfortunate, but I don't think
anybody here could do anything about that (Geertjan tried, AFAIK).

So, basically, during the gap, people could either work on the original
repository, work somewhere "aside" or not work at all. Many folks decided
to continue on the original repo, and I don't think that was a wrong
decision. And that continues a little bit even after the donation, as the
new patches may need to be based on the patches that are only in the
original repo.

To the best of my knowledge, getting the changes (for donated modules) from
hg.nb.org to the incubator-netbeans repository is a work in progress, both
process and work wise. But this is likely take some time before fully
completed.

Jan


On Wed, Nov 1, 2017 at 11:07 AM, Matthias Bläsing  wrote:

> Hey Jessie,
>
> Am Dienstag, den 31.10.2017, 20:23 -0400 schrieb Jesse Glick:
> > I ask because there appear to be at least some divergent changes. For
> > example,
> >
> > https://github.com/apache/incubator-netbeans/commits/master/jshell.su
> > pport/src/org/netbeans/modules/jshell/support/ShellSession.java
> >
> > does not include
> >
> > http://hg.netbeans.org/main-silver/rev/fcaaa60addf7
>
> yes this is a big problem IMHO and I already raised it here.
>
> It seems nobody made sure, that changes are no longer done to the
> already donated modules.
>
> I understood this mail thread, that oracle would also follow the
> strategy and not modify the donated modules:
>
> https://lists.apache.org/list.html?d...@netbeans.apache.org:
> lte=4M:Closing/Switch%20read-only%20hg.netbeans.org
>
> The referenced changeset shows that this is not the case.
>
> Geertjan: you are most probably best involved in the plans of oracle
> regarding this - how will this be handled?
>
> Greetings
>
> Matthias
>
>

Re: Support for (Java) Pattern Matching

[Jesse Glick]

On Wed, Nov 1, 2017 at 2:31 AM, Jan Lahoda  wrote:
> when one opens a pull request against
> apache/(incubating-)netbeans, then I think the code can be considered to be
> submitted to ASF (per iCLA).

IANAL but that sounds right.

> for a long-running branch in a
> personal repository, if the author of the branch cannot send the pull
> request to merge it for whatever reason

I recommend just filing a PR the moment you start the branch and have
some initial commits. It can be marked as a work in progress / not for
immediate merge / etc. with various labels. (It is possible to create
PR search permalinks on GitHub which filter by label.) If your
experiment never comes to anything, close the PR if you like. You can
always reopen it and pick up where you left off, with review comments
and everything intact.

(Normally when merging a PR I would delete the corresponding fork
branch, both on GitHub and in my local clone, to tidy up; but if you
are closing a PR you expect to maybe resume work on later, you can
just leave the branch in the remote. You could probably even recreate
the branch based on the last commit hash visible in the PR, though I
cannot recall ever trying that.)

On this topic: the Eclipse foundation apparently has some tool they
run automatically on PRs which verifies that all commits have been
signed and that the signature matches someone with a CLA on file. This
shows up as a GitHub status check, so you can see right in the PR
whether the contribution is coming from someone who has done the right
paperwork. If as a new contributor you forget about this, there will
be a red X until you file a CLA, fix your Git settings, and amend your
commit to include a signature.

> how about releases from the branches. It may be desirable to do a
> "preview" "release" for the branch (e.g. "pattern" preview; although I'd
> prefer if we handled Java language features in the master, but even if we
> succeed in that, it will take a long time to achieve). I don't think we can
> release from a personal github.

Certainly you would not want to cut official releases from a fork
branch. If this is an official preview of some kind—like a beta
release?—then there should I suppose be some origin branch for that
purpose. You can still use PRs to propose specific additions to that
branch; you just set the target branch accordingly when filing the PR.

It really depends on what your policy for distributing experimental
changes is. As you say, using feature flags or hidden settings to
enable unstable code in normal releases is the simplest approach for
infrastructure, but might not be practical until the code has been
refactored enough to allow this kind of behavior to be switched
dynamically. So if you are publishing, essentially, forks of official
modules, you are going to run into tricky questions anyway. What
version number could you pick which is newer than the official
ancestor merge base, but will be older than the official release
version when the feature is stabilized, and incomparable to unrelated
feature forks? Etc.

Re: Support for (Java) Pattern Matching

[Neil C Smith]

On Wed, Nov 1, 2017 at 6:32 AM Jan Lahoda  wrote:

> -code provenance: when one opens a pull request against
> apache/(incubating-)netbeans, then I think the code can be considered to be
> submitted to ASF (per iCLA). Pushing a commit to a personal github
> repository does not feel that way. So, for a long-running branch in a
> personal repository, if the author of the branch cannot send the pull
> request to merge it for whatever reason, how do we transfer the code to the
> mainline (if we want it)? If the branch is in a ASF repo, it has already
> been submitted to ASF, and anyone can continue without too much
> (non-technical) issues.
>
> -how about releases from the branches. It may be desirable to do a
> "preview" "release" for the branch (e.g. "pattern" preview; although I'd
> prefer if we handled Java language features in the master, but even if we
> succeed in that, it will take a long time to achieve). I don't think we can
> release from a personal github.
>
>
I'm tempted to say, with respect, you're making straw man arguments,
although I think Jesse's email does imply longer lasting personal branches
than might be desired.

Git is distributed.  You have to have at least one clone (fork) to work
with anyway, at least locally, so some commits happen elsewhere.  Your
argument seems to rest on the fact that there would somehow be a difference
in the scenarios between when you'd push to the main repo vs when you would
push to your personal remote and file a PR.  Why?

I'm 100% in agreement with the idea that all collaboration happens within
the Apache repo (or within PR's to it before they merge) - even if this
wasn't the Apache way.  But as Jesse says, this is a natural GitHub
workflow, it's not onerous, and from the surveys I've seen narrowly the
majority way of working (without starting Geertjan on the lack of merit of
surveys! ;-) ).  That doesn't mean we have to choose it, but at some point
we need a defined workflow that everyone knows how to use.

Best wishes,

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

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

Re: Current Status & Proposed Plan for Apache NetBeans

[Matthias Bläsing]

Hey Jessie,

Am Dienstag, den 31.10.2017, 20:23 -0400 schrieb Jesse Glick:
> I ask because there appear to be at least some divergent changes. For
> example,
> 
> https://github.com/apache/incubator-netbeans/commits/master/jshell.su
> pport/src/org/netbeans/modules/jshell/support/ShellSession.java
> 
> does not include
> 
> http://hg.netbeans.org/main-silver/rev/fcaaa60addf7

yes this is a big problem IMHO and I already raised it here.

It seems nobody made sure, that changes are no longer done to the
already donated modules.

I understood this mail thread, that oracle would also follow the
strategy and not modify the donated modules:

https://lists.apache.org/list.html?d...@netbeans.apache.org:lte=4M:Closing/Switch%20read-only%20hg.netbeans.org

The referenced changeset shows that this is not the case.

Geertjan: you are most probably best involved in the plans of oracle
regarding this - how will this be handled?

Greetings

Matthias

Re: Support for (Java) Pattern Matching

[Jan Lahoda]

Hi Jesse,

Thanks for the comments! A comment is inline.

On Wed, Nov 1, 2017 at 1:54 AM, Jesse Glick  wrote:

> FWIW I have been working exclusively in GitHub for years now, and my
> advice is to have every change be a PR coming from a repository fork.
> Once you are accustomed to this workflow, it is not onerous, and
> provides a natural place to track discussion of changes and
> relationships to other changes. It also ensures that repositories of
> record are not polluted with dozens of long-obsolete branches; there
> are only PRs, which are either open or merged or closed without merge,
> and a handful of origin branches reflecting official release lines.
> Committers are just people trusted to push the Merge button.
>
> (My project also generally demands that a PR not be merged until there
> has been at least one code review from another committer; and an
> automated build of that PR has passed all tests, so that the target
> branch is always “clean”.)
>
> On Fri, Oct 20, 2017 at 4:50 PM, Jan Lahoda  wrote:
> > if multiple people (can)
> > contribute to a branch and the branch has a fair chance to end up in the
> > mainline, it is IMO easier to keep it in an ASF repo, than on GitHub.
>
> Even for this case I do not recommend using “origin PRs”. If you are
> proposing a change, create a topic branch in your fork and file the
> PR. If someone else has minor comments or suggestions, they can review
> and you can decide how to process their feedback. If they have
> significant changes to propose which are too complex to comfortably
> describe verbally, they can simply create a child branch and file a PR
> _against your PR_. If you agree with what they propose—perhaps after
> some discussion and refinement—you just merge the sub-PR, and their
> changes are incorporated. But the author of the PR remains of control.
> When someone else can push directly to the branch of your PR, they may
> well be “putting words in your mouth”.
>

I think we are using this process for changes that are developed for a
short time and end up in the master branch. I suppose it would be easier to
me/us to simply use our github for changes that are being developed for a
long term and only merge when things are done, but I see considerable
problems with that:
-code provenance: when one opens a pull request against
apache/(incubating-)netbeans, then I think the code can be considered to be
submitted to ASF (per iCLA). Pushing a commit to a personal github
repository does not feel that way. So, for a long-running branch in a
personal repository, if the author of the branch cannot send the pull
request to merge it for whatever reason, how do we transfer the code to the
mainline (if we want it)? If the branch is in a ASF repo, it has already
been submitted to ASF, and anyone can continue without too much
(non-technical) issues.

-how about releases from the branches. It may be desirable to do a
"preview" "release" for the branch (e.g. "pattern" preview; although I'd
prefer if we handled Java language features in the master, but even if we
succeed in that, it will take a long time to achieve). I don't think we can
release from a personal github.

Jan


>
> Once you start to use GitHub the way it is designed, your development
> style changes, and for the better.
>