Re: NetBeans has landed in Apache Git
Great, I've tried it, works well. In the report, there's a list of 14,651 files under the heading "Files without CDDL (14651)". Could a distinction be made between those that have a license (i.e., some license other than CDDL) and those that do not have a license at all? I also think that it would be nice that after that split, i.e., between those with/without a license, that everything is sorted based on file type, so we can easily distinguish those in the lists that are 'form' files, 'png' files, etc, for each of these two categories. I think also that anything within META-INF does not have any "degree of creativity", i.e, these are simply registration files for implementations of APIs. Could you provide the number of these, for this page, where I'm trying to keep a record of all the file types that are a special case of some kind: https://cwiki.apache.org/confluence/display/NETBEANS/NetBeans+Transition+Process Thanks a lot, and any feedback from anyone is welcome, Gj On Sun, Sep 17, 2017 at 5:06 PM, Jan Lahoda wrote: > Hi, > > I've uploaded an updated version of the tool - fixing a bug in rewriting > headers of bundle files (where it was deleting one line after the header, > reported by Geertjan offline), making it a little bit more strict > (currently rewrites 29474 files), adding support for bat files, and adding > ability to dump a file with statistics and changed/not changed files. > > I guess after the bulk update of these headers is done, and LICENSE&NOTICE > is added, we could start a usual development? (Continuing with reviewing > the Rat report concurrently?) > > Could please someone overview the regexp here: > https://cwiki.apache.org/confluence/display/NETBEANS/ > NetBeans+Transition+Process#NetBeansTransitionProcess- > ToolforanalyzingandchangingGPL+CDDLlicenseheaders > > to see if it is OK to write such headers? Seems OK to me personally, but I > think having feedback from someone more experienced would be helpful. > > Thanks, > Jan > > On Fri, Sep 15, 2017 at 11:43 PM, Geertjan Wielenga < > geertjan.wiele...@googlemail.com> wrote: > > > I've used the tool, it's really great, not only analyzes but also > actually > > changes the licenses, 29,496 of 44,324: > > > > https://cwiki.apache.org/confluence/display/NETBEANS/ > > NetBeans+Transition+Process > > > > Could the tool be tuned to list all the files that are not in the 29,496? > > > > I have updated the table in the link above to list all the problematic > file > > types, i.e., those that are not licensed. > > > > Would be great to identify anything else that is not part of the 29,496 > > that can automatically be relicensed. > > > > Gj > > > > On Thu, Sep 14, 2017 at 3:08 PM, Geertjan Wielenga < > > geertjan.wiele...@googlemail.com> wrote: > > > > > Agree completely. > > > > > > Gj > > > > > > On Thu, Sep 14, 2017 at 3:05 PM, Jan Lahoda wrote: > > > > > >> On Thu, Sep 14, 2017 at 2:59 PM, Geertjan Wielenga < > > >> geertjan.wiele...@googlemail.com> wrote: > > >> > > >> > I think we also need to fill out the "Relicensing of > > incubator-netbeans" > > >> > table on the page > > >> > https://cwiki.apache.org/confluence/display/NETBEANS/ > > >> > NetBeans+Transition+Process, > > >> > i.e., with the various file types in a column, related numbers, and > in > > >> each > > >> > case what the problems are/could be, so that we can get a good view, > > >> and a > > >> > clearly documented perspective for future reference, of everything > > that > > >> > needs to be done for each type of file. > > >> > > > >> > > > >> I was thinking of putting there files that are in some way problematic > > >> (e.g. a missing license header, like in manifests). Assuming headers > > >> matching the regexp would be OK to change, maybe we don't need to > > clutter > > >> the table with files that contain them (unless we have another reason > to > > >> put a particular file in)? (Matching headers are (unless I did > something > > >> wrong) in >29000 files.) > > >> > > >> Jan > > >> > > >> > > >> > Gj > > >> > > > >> > > > >> > On Thu, Sep 14, 2017 at 2:52 PM, Jan Lahoda > wrote: > > >> > > > >> > > On Mon, Sep 11, 2017 at 10:00 PM, Ate Douma wrote: > > >> > > > > >> > > > Wonderful news and big next step indeed! > > >> > > > > > >> > > > Now, while I understand everyone being 'trigger happy' to start > > >> > > committing > > >> > > > improvements, fixes, etc. (and currently I already see 2 > addition > > >> > > commits) > > >> > > > the next step should be to adjust the license headers! > > >> > > > > > >> > > > > >> > > So, here: > > >> > > https://cwiki.apache.org/confluence/display/NETBEANS/ > > >> > > NetBeans+Transition+Process#NetBeansTransitionProcess- > > >> > > ChangingGPL+CDDLlicenseheaders > > >> > > > > >> > > I tried to prepare a regexp that matches most existing > (normalized) > > >> > license > > >> > > headers. If someone could check if it is OK to change matching > > >> headers, I > > >> > > think that would be great. (Please let
Re: Who's who on top of NetBeans
The page has grown a lot -- https://cwiki.apache.org/confluence/display/NETBEANS/on+top+of+NetBeans Also trying to gather, where possible, team size and user statistics, however those are gathered for specific projects. If you've added your project and can share that info, that would help -- basically trying to get a picture of the whole NetBeans Platform landscape, though it will never be a really complete picture. Gj On Wed, Sep 13, 2017 at 6:39 PM, Geertjan Wielenga < geertjan.wiele...@googlemail.com> wrote: > Hi all, > > Started this page, so we have a handy registry of all the products on top > of Apache NetBeans (incubating): > > https://cwiki.apache.org/confluence/display/NETBEANS/on+top+of+NetBeans > > Please add additional ones, for yourself, your organization, or any that > you're aware of -- I'll be adding more too but there's just so many of them > that it will take a long time on my own. I plan to add 10 per day. > > Thanks, > > Gj >
Re: Who's who on top of NetBeans
Would it be nice to also have a Country column, hence showing the wide geographical spread of NetBeans developers? E On 18/09/17 18:56, Geertjan Wielenga wrote: > The page has grown a lot -- > https://cwiki.apache.org/confluence/display/NETBEANS/on+top+of+NetBeans > > Also trying to gather, where possible, team size and user statistics, > however those are gathered for specific projects. If you've added your > project and can share that info, that would help -- basically trying to get > a picture of the whole NetBeans Platform landscape, though it will never be > a really complete picture. > > Gj > > On Wed, Sep 13, 2017 at 6:39 PM, Geertjan Wielenga < > geertjan.wiele...@googlemail.com> wrote: > >> Hi all, >> >> Started this page, so we have a handy registry of all the products on top >> of Apache NetBeans (incubating): >> >> https://cwiki.apache.org/confluence/display/NETBEANS/on+top+of+NetBeans >> >> Please add additional ones, for yourself, your organization, or any that >> you're aware of -- I'll be adding more too but there's just so many of them >> that it will take a long time on my own. I plan to add 10 per day. >> >> Thanks, >> >> Gj >>
Re: Who's who on top of NetBeans
Hi GJ, I wanted to ask if there are any tools bundled with the platform to track usage? I wanted to avoid that in the first place, because many of our users might be in hospitals, and they're pretty sensitive to any sort of tracking. I only know the download stats. On Mon, Sep 18, 2017 at 1:56 AM, Geertjan Wielenga < geertjan.wiele...@googlemail.com> wrote: > The page has grown a lot -- > https://cwiki.apache.org/confluence/display/NETBEANS/on+top+of+NetBeans > > Also trying to gather, where possible, team size and user statistics, > however those are gathered for specific projects. If you've added your > project and can share that info, that would help -- basically trying to get > a picture of the whole NetBeans Platform landscape, though it will never be > a really complete picture. > > Gj > > On Wed, Sep 13, 2017 at 6:39 PM, Geertjan Wielenga < > geertjan.wiele...@googlemail.com> wrote: > > > Hi all, > > > > Started this page, so we have a handy registry of all the products on top > > of Apache NetBeans (incubating): > > > > https://cwiki.apache.org/confluence/display/NETBEANS/on+top+of+NetBeans > > > > Please add additional ones, for yourself, your organization, or any that > > you're aware of -- I'll be adding more too but there's just so many of > them > > that it will take a long time on my own. I plan to add 10 per day. > > > > Thanks, > > > > Gj > > >
Re: Who's who on top of NetBeans
On Mon, Sep 18, 2017 at 11:50 AM, Ernest C Lötter wrote: > Would it be nice to also have a Country column, hence showing the wide > geographical spread of NetBeans developers? > > E Good plan, will do. Gj
Re: Who's who on top of NetBeans
On Mon, Sep 18, 2017 at 11:53 AM, Dmitry Avtonomov < dmitriy.avtono...@gmail.com> wrote: > Hi GJ, I wanted to ask if there are any tools bundled with the platform to > track usage? I wanted to avoid that in the first place, because many of our > users might be in hospitals, and they're pretty sensitive to any sort of > tracking. I only know the download stats. How usage of NetBeans IDE, in Oracle, has been tracked is via the Plugin Manager, i.e., per month everyone who starts up NetBeans IDE at least 3 times is counted as an active user. Not a perfect measurement either, of course. In many cases, download stats are the only real stats that make sense -- and there again I'm sure I've downloaded heaps of software in my life that I have never used or maybe started up once only. On top of all that, what an 'active user' is varies a lot per NetBeans-based product, e.g., if you're using JDemetra+ ( http://ec.europa.eu/eurostat/web/ess/-/jdemetra-officially-recommended-as-software-for-the-seasonal-adjustment-of-official-statistics), you might only be starting up a few times per year, while if you're doing seismology analysis you'd be starting up throughout the year though depending on requirements, while software created for students would mostly be used during the school year, etc etc etc. So, these are just indicators of whether a product is used at all, rather than proving anything about the actual number of active users. Gj
RE: Testing incubator build
Hi Build is working well on ubuntu bash within windows 10. Regards Eric -Message d'origine- De : Geertjan Wielenga [mailto:geertjan.wiele...@googlemail.com] Envoyé : samedi 16 septembre 2017 14:54 À : dev@netbeans.incubator.apache.org Objet : Re: Testing incubator build On Sat, Sep 16, 2017 at 2:50 PM, Marco Rossi wrote: > Yes, I confirm: it was due to my Italian locale settings. After > changed to English, I’ve successfully built and run. Thanks. Excellent. Any further feedback of any kind is welcome. Gj
AW: Testing incubator build
Build was also working on Windows 10 with normal CMD and ant 1.9.7 Gesendet von Mail für Windows 10 Von: Eric Barboni Gesendet: Montag, 18. September 2017 13:24 An: dev@netbeans.incubator.apache.org Betreff: RE: Testing incubator build Hi Build is working well on ubuntu bash within windows 10. Regards Eric -Message d'origine- De : Geertjan Wielenga [mailto:geertjan.wiele...@googlemail.com] Envoyé : samedi 16 septembre 2017 14:54 À : dev@netbeans.incubator.apache.org Objet : Re: Testing incubator build On Sat, Sep 16, 2017 at 2:50 PM, Marco Rossi wrote: > Yes, I confirm: it was due to my Italian locale settings. After > changed to English, I’ve successfully built and run. Thanks. Excellent. Any further feedback of any kind is welcome. Gj
JIRA hook to dev@
Hello, I would expect that most / some of the activity on JIRA to also trigger some emails on dev@ or some other mailing list. Is this not usual for Apache? --emi
Re: JIRA hook to dev@
I get them on comm...@netbeans.apache.org Cheers -- Emmanuel Hugonnet http://www.ehsavoie.com http://twitter.com/ehsavoie On Mon, Sep 18, 2017 at 3:27 PM, Emilian Bold wrote: > Hello, > > I would expect that most / some of the activity on JIRA to also > trigger some emails on dev@ or some other mailing list. > > Is this not usual for Apache? > > --emi >
Re: JIRA hook to dev@
Oh, thanks! --emi On Mon, Sep 18, 2017 at 4:48 PM, ehsavoie wrote: > I get them on > comm...@netbeans.apache.org > Cheers > > -- > Emmanuel Hugonnet > http://www.ehsavoie.com > http://twitter.com/ehsavoie > > On Mon, Sep 18, 2017 at 3:27 PM, Emilian Bold > wrote: > >> Hello, >> >> I would expect that most / some of the activity on JIRA to also >> trigger some emails on dev@ or some other mailing list. >> >> Is this not usual for Apache? >> >> --emi >>
Re: Clarity needed -- adjusting the license headers
On 2017-09-16 21:32, Craig Russell wrote: Hi Ate, On Sep 12, 2017, at 10:19 AM, Ate Douma wrote: 1. If the source file is submitted with a copyright notice included in it, the copyright owner (or owner's agent) must either: a. remove such notices, or b. move them to the NOTICE file associated with each applicable project release, or c. provide written permission for the ASF to make such removal or relocation of the notices. Now, in this case IMO the *SGA* (not the CCLA, which only applies for new/future code contributions) covers case c., e.g. provides the written permission for the ASF to remove/relocate the Oracle copyright notices. My understanding is that there is no distinction made between an independent SGA and a CCLA with Schedule B. They both grant the same rights to Apache. Agreed, that also is my understanding. But the Oracle CCLA has no Schedule B, so their CCLA only applies to new/future contributions. And therefore I think only the SGA applies (and is needed) here. Ate Craig Craig L Russell Secretary, Apache Software Foundation c...@apache.org http://db.apache.org/jdo
Re: Clarity needed -- adjusting the license headers
Great, thanks. Could you also take a look at the thread entitled "Assembling LICENSE and NOTICE" -- i.e., we need a mentor's perspective here to make sure we're taking the right approach. Gj On Mon, Sep 18, 2017 at 10:01 PM, Ate Douma wrote: > On 2017-09-16 21:32, Craig Russell wrote: > >> Hi Ate, >> >> On Sep 12, 2017, at 10:19 AM, Ate Douma wrote: >>> 1. If the source file is submitted with a copyright notice included in >>> it, the >>> copyright owner (or owner's agent) must either: >>>a. remove such notices, or >>>b. move them to the NOTICE file associated with each applicable >>> project >>> release, or >>>c. provide written permission for the ASF to make such removal or >>> relocation of the notices. >>> >>> Now, in this case IMO the *SGA* (not the CCLA, which only applies for >>> new/future >>> code contributions) covers case c., e.g. provides the written permission >>> for the >>> ASF to remove/relocate the Oracle copyright notices. >>> >> >> My understanding is that there is no distinction made between an >> independent SGA and a CCLA with Schedule B. They both grant the same rights >> to Apache. >> > > Agreed, that also is my understanding. > > But the Oracle CCLA has no Schedule B, so their CCLA only applies to > new/future > contributions. And therefore I think only the SGA applies (and is needed) > here. > > Ate > > > >> Craig >> >> Craig L Russell >> Secretary, Apache Software Foundation >> c...@apache.org http://db.apache.org/jdo >> >> >
[GitHub] incubator-netbeans pull request #2: Allow custom authenticator
GitHub user phansson opened a pull request: https://github.com/apache/incubator-netbeans/pull/2 Allow custom authenticator Fixes [NETBEANS-61](https://issues.apache.org/jira/browse/NETBEANS-61). Allows a Platform user to install his own version of an Authenticator which may be more appropriate for the given application than the one provided by default by the Platform. In no implementation of Authenticator is found in the Global Lookup then everything will work as before. You can merge this pull request into a Git repository by running: $ git pull https://github.com/phansson/incubator-netbeans AllowCustomAuthenticator Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-netbeans/pull/2.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2 ---
Re: Assembling LICENSE and NOTICE
On 2017-09-16 08:28, Geertjan Wielenga wrote: Hi all, Created https://issues.apache.org/jira/browse/NETBEANS-57. Trying to find an Apache project to use as reference point, looked around a bit, and Apache Spark seems to be complex enough in terms of its dependencies to follow: https://github.com/apache/spark I.e., there's a folder in the above named "licenses": https://github.com/apache/spark/tree/master/licenses Should such a folder be created in https://github.com/apache/incubator-netbeans? And then, reference those licenses in the LICENSE file: https://github.com/apache/spark/blob/master/LICENSE And also a NOTICE file should be created, like this one: https://github.com/apache/spark/blob/master/NOTICE Is that the correct approach and should anything else be considered? Warning TL;DR; ahead, but please hang on anyway... I'll offer *my* preferences, and a bit of opinion, but do note that there is no single 'best' or 'perfect' solution, fit for all projects. The ground rules are spelled out and documented at [1] and [2], and IMO should be regarded as the *legal* requirements every solution needs to comply to. [1] http://www.apache.org/legal/release-policy.html#licensing-documentation [2] http://apache.org/legal/src-headers.html#notice However, how these ground rules or legal requirements are interpreted and applied differs on detail level for just about every ASF project I've been directly involved with ... Also the common understanding and current expected way how this should or must be done has changed (or progressed if you will) over the years as well. Bottom line is: the IPMC (Incubator PMC) will have to validate and agree with the chosen solution to accept a release candidate, or not. Or may give some initial lenience for acceptable first-time mistakes, to be fixed in future releases. Again: there is no one-fits-all solution, when in doubt do ask on gene...@incubator.apache.org. And preferably *before* starting a vote for a release candidate to reduce the number of times a release candidate is voted down (which AFAICR almost *always* happens the first one or few time...). Furthermore, please accept my personal disclaimer that in most cases I also tend to overlook or miss a few bits and bytes the first few times a new project needs to get its LICENSE and NOTICE file(s) in order. It can and typically will be a tiresome exercise in the beginning, nobody should take this lightly. But once the basic process has been fleshed out and a first complete and verified release has gone through successfully, things will get easier, promise :-) Now concerning the 'correct approach'. I'd like to provide some guidelines or rules of the thumb of my own, as I've been using and advocating over the years, and which worked, and still work, for several ASF projects. But feel free to discuss/question these 'rules', to get a better understanding or possibly (hopefully) improve/fix/refine them as needed. In the end, its the Netbeans PPMC, and during incubation ultimately the IPMC, which needs to decide and accept the approach taken. a) NOTICE and LICENSE files *only* apply to what is contained within a 'package' or distribution. They do NOT and should NOT refer to or address anything NOT within that package or distribution. b) NOTICE and LICENSE files *must* be provided in the root of *each* package or distribution, or a practical/common equivalent thereof (e.g. in a jar-file these should go under META-INF/) c) The ASF git (or likewise subversion) repository should also be regarded as a 'distribution' of its own. It therefore also requires a NOTICE and LICENSE file checked in the root folder of the git tree. Per rule a) those NOTICE and LICENSE files *only* refer and apply to what has been checked into the (that!) git/subversion source tree, *nothing else*. So no references to 3rd party dependencies which are pulled in at build time! d) A *source* release typically includes everything from the (that) git source tree, in which case the git tree root NOTICE and LICENSE files are 'good to go'. But it also may (also) combine multiple git repositories, or split them up. For example a common approach is to also provide (distribute) one or more 'convenient' -sources.jar files. In which case possibly only a subset of the 'root' NOTICE and LICENSE file is needed/should be bundled. e) A binary 'convenience' distribution (which is NOT the release, and only may be distributed *together* with the corresponding source release), typically also bundles 3rd party dependencies. The NOTICE and LICENSE file packaged with such binary distribution then also MUST cover those 3rd party dependencies, see also a) above. Which means *different* (extended) NOTICE and LICENSE files will be needed, compared to the source release. For Netbeans I think this may apply to nbm files if I'm correct. And each nbm file may even require a different/dedicated NOTICE and LICENSE file, depending on its content. Also notable is how to handl
Re: Assembling LICENSE and NOTICE
Many thanks for all these details. Two things jump out at me: 1. "those NOTICE and LICENSE files *only* refer and apply to what has been checked into the (that!) git/subversion source tree, *nothing else*. So no references to 3rd party dependencies which are pulled in at build time!" That's very interesting and it means that the NOTICE and LICENSE will be very short and sweet -- i.e., the only license will be Apache, since all the source files will be relicensed to Apache. Everything else has been removed prior to the donation, i.e., everything that did not belong to Oracle, anything that has been licensed to anyone other than Oracle, has been removed prior to the donation. Yes, we need to prove that within the incubator and document how we prove that. However, I believe based on having gone through the donation process from the Oracle side, that the only license of the source tree is Apache. What does this mean for dependencies pulled in at build time? I.e., can they then be licensed in any way at all -- i.e., where are the rules/guidelines for dependencies pulled in at build time? 2. "NOTICE and LICENSE files *must* be provided in the root of *each* package or distribution, or a practical/common equivalent thereof (e.g. in a jar-file these should go under META-INF/)" I had assumed there is one NOTICE and one LICENSE file, in the root of the repo. From the above, there could be hundreds, i.e., for each package, it would seem. Can you point to somewhere as a reference point for that, e.g., a project where this is done? It sounds to me like we're going to have hundreds of NOTICE and LICENSE files in Apache NetBeans? Thanks, Geertjan On Tue, Sep 19, 2017 at 12:17 AM, Ate Douma wrote: > On 2017-09-16 08:28, Geertjan Wielenga wrote: > >> Hi all, >> >> Created https://issues.apache.org/jira/browse/NETBEANS-57. >> >> Trying to find an Apache project to use as reference point, looked around >> a >> bit, and Apache Spark seems to be complex enough in terms of its >> dependencies to follow: >> >> https://github.com/apache/spark >> >> I.e., there's a folder in the above named "licenses": >> >> https://github.com/apache/spark/tree/master/licenses >> >> Should such a folder be created in >> https://github.com/apache/incubator-netbeans? >> >> And then, reference those licenses in the LICENSE file: >> >> https://github.com/apache/spark/blob/master/LICENSE >> >> And also a NOTICE file should be created, like this one: >> >> https://github.com/apache/spark/blob/master/NOTICE >> >> Is that the correct approach and should anything else be considered? >> > > Warning TL;DR; ahead, but please hang on anyway... > > I'll offer *my* preferences, and a bit of opinion, but do note that there > is no > single 'best' or 'perfect' solution, fit for all projects. > > The ground rules are spelled out and documented at [1] and [2], and IMO > should be regarded as the *legal* requirements every solution needs to > comply > to. > > [1] http://www.apache.org/legal/release-policy.html#licensing-do > cumentation > [2] http://apache.org/legal/src-headers.html#notice > > However, how these ground rules or legal requirements are interpreted and > applied differs on detail level for just about every ASF project I've been > directly involved with ... > Also the common understanding and current expected way how this should or > must > be done has changed (or progressed if you will) over the years as well. > > Bottom line is: the IPMC (Incubator PMC) will have to validate and agree > with > the chosen solution to accept a release candidate, or not. Or may give some > initial lenience for acceptable first-time mistakes, to be fixed in future > releases. > Again: there is no one-fits-all solution, when in doubt do ask on > gene...@incubator.apache.org. > And preferably *before* starting a vote for a release candidate to reduce > the > number of times a release candidate is voted down (which AFAICR almost > *always* > happens the first one or few time...). > > Furthermore, please accept my personal disclaimer that in most cases I also > tend to overlook or miss a few bits and bytes the first few times a new > project > needs to get its LICENSE and NOTICE file(s) in order. > > It can and typically will be a tiresome exercise in the beginning, nobody > should > take this lightly. But once the basic process has been fleshed out and a > first > complete and verified release has gone through successfully, things will > get > easier, promise :-) > > Now concerning the 'correct approach'. > I'd like to provide some guidelines or rules of the thumb of my own, as > I've > been using and advocating over the years, and which worked, and still > work, for > several ASF projects. > But feel free to discuss/question these 'rules', to get a better > understanding > or possibly (hopefully) improve/fix/refine them as needed. > In the end, its the Netbeans PPMC, and during incubation ultimately the > IPMC, > which needs to decide and accept the approach taken.
Re: NetBeans has landed in Apache Git
Does the above make sense, i.e., I'm suggesting a few ways to finetune the results a bit further -- and are there other ideas for finetuning, i.e., trying to somehow incorporate those 14,651 files, so we can minimize the manual checking we'll need to do? Thanks, Gj On Mon, Sep 18, 2017 at 10:53 AM, Geertjan Wielenga < geertjan.wiele...@googlemail.com> wrote: > Great, I've tried it, works well. > > In the report, there's a list of 14,651 files under the heading "Files > without CDDL (14651)". > > Could a distinction be made between those that have a license (i.e., some > license other than CDDL) and those that do not have a license at all? > > I also think that it would be nice that after that split, i.e., between > those with/without a license, that everything is sorted based on file type, > so we can easily distinguish those in the lists that are 'form' files, > 'png' files, etc, for each of these two categories. > > I think also that anything within META-INF does not have any "degree of > creativity", i.e, these are simply registration files for implementations > of APIs. Could you provide the number of these, for this page, where I'm > trying to keep a record of all the file types that are a special case of > some kind: https://cwiki.apache.org/confluence/display/ > NETBEANS/NetBeans+Transition+Process > > Thanks a lot, and any feedback from anyone is welcome, > > Gj > > > > On Sun, Sep 17, 2017 at 5:06 PM, Jan Lahoda wrote: > >> Hi, >> >> I've uploaded an updated version of the tool - fixing a bug in rewriting >> headers of bundle files (where it was deleting one line after the header, >> reported by Geertjan offline), making it a little bit more strict >> (currently rewrites 29474 files), adding support for bat files, and adding >> ability to dump a file with statistics and changed/not changed files. >> >> I guess after the bulk update of these headers is done, and LICENSE&NOTICE >> is added, we could start a usual development? (Continuing with reviewing >> the Rat report concurrently?) >> >> Could please someone overview the regexp here: >> https://cwiki.apache.org/confluence/display/NETBEANS/NetBean >> s+Transition+Process#NetBeansTransitionProcess-Toolforanalyz >> ingandchangingGPL+CDDLlicenseheaders >> >> to see if it is OK to write such headers? Seems OK to me personally, but I >> think having feedback from someone more experienced would be helpful. >> >> Thanks, >> Jan >> >> On Fri, Sep 15, 2017 at 11:43 PM, Geertjan Wielenga < >> geertjan.wiele...@googlemail.com> wrote: >> >> > I've used the tool, it's really great, not only analyzes but also >> actually >> > changes the licenses, 29,496 of 44,324: >> > >> > https://cwiki.apache.org/confluence/display/NETBEANS/ >> > NetBeans+Transition+Process >> > >> > Could the tool be tuned to list all the files that are not in the >> 29,496? >> > >> > I have updated the table in the link above to list all the problematic >> file >> > types, i.e., those that are not licensed. >> > >> > Would be great to identify anything else that is not part of the 29,496 >> > that can automatically be relicensed. >> > >> > Gj >> > >> > On Thu, Sep 14, 2017 at 3:08 PM, Geertjan Wielenga < >> > geertjan.wiele...@googlemail.com> wrote: >> > >> > > Agree completely. >> > > >> > > Gj >> > > >> > > On Thu, Sep 14, 2017 at 3:05 PM, Jan Lahoda wrote: >> > > >> > >> On Thu, Sep 14, 2017 at 2:59 PM, Geertjan Wielenga < >> > >> geertjan.wiele...@googlemail.com> wrote: >> > >> >> > >> > I think we also need to fill out the "Relicensing of >> > incubator-netbeans" >> > >> > table on the page >> > >> > https://cwiki.apache.org/confluence/display/NETBEANS/ >> > >> > NetBeans+Transition+Process, >> > >> > i.e., with the various file types in a column, related numbers, >> and in >> > >> each >> > >> > case what the problems are/could be, so that we can get a good >> view, >> > >> and a >> > >> > clearly documented perspective for future reference, of everything >> > that >> > >> > needs to be done for each type of file. >> > >> > >> > >> > >> > >> I was thinking of putting there files that are in some way >> problematic >> > >> (e.g. a missing license header, like in manifests). Assuming headers >> > >> matching the regexp would be OK to change, maybe we don't need to >> > clutter >> > >> the table with files that contain them (unless we have another >> reason to >> > >> put a particular file in)? (Matching headers are (unless I did >> something >> > >> wrong) in >29000 files.) >> > >> >> > >> Jan >> > >> >> > >> >> > >> > Gj >> > >> > >> > >> > >> > >> > On Thu, Sep 14, 2017 at 2:52 PM, Jan Lahoda >> wrote: >> > >> > >> > >> > > On Mon, Sep 11, 2017 at 10:00 PM, Ate Douma >> wrote: >> > >> > > >> > >> > > > Wonderful news and big next step indeed! >> > >> > > > >> > >> > > > Now, while I understand everyone being 'trigger happy' to start >> > >> > > committing >> > >> > > > improvements, fixes, etc. (and currently I already see 2 >> addition >> > >> > > commits) >> > >> > > >
[GitHub] incubator-netbeans pull request #2: Allow custom authenticator
Github user emilianbold commented on a diff in the pull request:
https://github.com/apache/incubator-netbeans/pull/2#discussion_r139596689
--- Diff: o.n.core/src/org/netbeans/core/NbAuthenticator.java ---
@@ -61,6 +63,7 @@
*/
final class NbAuthenticator extends java.net.Authenticator {
--- End diff --
Why not just add `@ServiceProvider(service= Authenticator.class)` here?
---
[GitHub] incubator-netbeans pull request #2: Allow custom authenticator
Github user phansson commented on a diff in the pull request:
https://github.com/apache/incubator-netbeans/pull/2#discussion_r139601775
--- Diff: o.n.core/src/org/netbeans/core/NbAuthenticator.java ---
@@ -61,6 +63,7 @@
*/
final class NbAuthenticator extends java.net.Authenticator {
--- End diff --
I actually did that initially. (i.e. registering self as a service). But it
requires a public no-arg constructor and I didn't have time to analyze why the
original author insisted on a private constructor and since it wouldn't
actually bring any benefit - besides a bit cleaner code - I then discarded the
idea. But I have no objections to do this change.
---
[GitHub] incubator-netbeans pull request #2: Allow custom authenticator
Github user emilianbold commented on a diff in the pull request:
https://github.com/apache/incubator-netbeans/pull/2#discussion_r139596868
--- Diff: o.n.core/src/org/netbeans/core/NbAuthenticator.java ---
@@ -71,7 +74,19 @@ private NbAuthenticator() {
static void install() {
if (Boolean.valueOf(NbBundle.getMessage(GuiRunLevel.class,
"USE_Authentication"))) {
-setDefault(new NbAuthenticator());
+// Look for custom authenticator
+Authenticator authenticator =
Lookup.getDefault().lookup(Authenticator.class);
+if (authenticator == null) {
+authenticator = new NbAuthenticator();
+}
+if (authenticator.getClass().equals(NbAuthenticator.class)) {
--- End diff --
Everything else, including the log call doesn't seem necessary.
---
[GitHub] incubator-netbeans pull request #2: Allow custom authenticator
Github user emilianbold commented on a diff in the pull request:
https://github.com/apache/incubator-netbeans/pull/2#discussion_r139596801
--- Diff: o.n.core/src/org/netbeans/core/NbAuthenticator.java ---
@@ -71,7 +74,19 @@ private NbAuthenticator() {
static void install() {
if (Boolean.valueOf(NbBundle.getMessage(GuiRunLevel.class,
"USE_Authentication"))) {
-setDefault(new NbAuthenticator());
--- End diff --
... then just call
`setDefault(Lookup.getDefault().lookup(Authenticator.class))` here.
There will always be at least one instance in the lookup and the other
implementations can jump in front with the `position` attribute.
---
[GitHub] incubator-netbeans pull request #2: Allow custom authenticator
Github user emilianbold commented on a diff in the pull request:
https://github.com/apache/incubator-netbeans/pull/2#discussion_r139602349
--- Diff: o.n.core/src/org/netbeans/core/NbAuthenticator.java ---
@@ -61,6 +63,7 @@
*/
final class NbAuthenticator extends java.net.Authenticator {
--- End diff --
Ah, I see, and `NbAuthenticator` is package private too. I guess this is
just standard NetBeans architecture of not over-exposing more than necessary.
I guess:
* we could either make `NbAuthenticator` class and constructor public or
* introduce a `AuthenticatorFactory` which will be registered in the lookup
with a default factory producing `NbAuthenticator` or
* use your current solution
---
[GitHub] incubator-netbeans pull request #2: Allow custom authenticator
Github user phansson commented on a diff in the pull request:
https://github.com/apache/incubator-netbeans/pull/2#discussion_r139602369
--- Diff: o.n.core/src/org/netbeans/core/NbAuthenticator.java ---
@@ -71,7 +74,19 @@ private NbAuthenticator() {
static void install() {
if (Boolean.valueOf(NbBundle.getMessage(GuiRunLevel.class,
"USE_Authentication"))) {
-setDefault(new NbAuthenticator());
+// Look for custom authenticator
+Authenticator authenticator =
Lookup.getDefault().lookup(Authenticator.class);
+if (authenticator == null) {
+authenticator = new NbAuthenticator();
+}
+if (authenticator.getClass().equals(NbAuthenticator.class)) {
--- End diff --
After analyzing hundreds of messages files (NB log files) from my customers
there's one thing I'm certain of: you can never have too much logging. :-)
Why do you think the logging calls are unnecessary?
---
[GitHub] incubator-netbeans pull request #2: Allow custom authenticator
Github user emilianbold commented on a diff in the pull request:
https://github.com/apache/incubator-netbeans/pull/2#discussion_r139602545
--- Diff: o.n.core/src/org/netbeans/core/NbAuthenticator.java ---
@@ -71,7 +74,19 @@ private NbAuthenticator() {
static void install() {
if (Boolean.valueOf(NbBundle.getMessage(GuiRunLevel.class,
"USE_Authentication"))) {
-setDefault(new NbAuthenticator());
+// Look for custom authenticator
+Authenticator authenticator =
Lookup.getDefault().lookup(Authenticator.class);
+if (authenticator == null) {
+authenticator = new NbAuthenticator();
+}
+if (authenticator.getClass().equals(NbAuthenticator.class)) {
--- End diff --
Because it's not usual to log which instance you are using from the
`Lookup`. Since this is a static situation, you know at build-time which
instance is going to be used, unless somebody yanks your whole module with the
other implementation out.
---
[GitHub] incubator-netbeans pull request #2: Allow custom authenticator
Github user emilianbold commented on a diff in the pull request:
https://github.com/apache/incubator-netbeans/pull/2#discussion_r139607093
--- Diff: o.n.core/src/org/netbeans/core/NbAuthenticator.java ---
@@ -71,7 +74,19 @@ private NbAuthenticator() {
static void install() {
if (Boolean.valueOf(NbBundle.getMessage(GuiRunLevel.class,
"USE_Authentication"))) {
-setDefault(new NbAuthenticator());
+// Look for custom authenticator
+Authenticator authenticator =
Lookup.getDefault().lookup(Authenticator.class);
+if (authenticator == null) {
+authenticator = new NbAuthenticator();
+}
+if (authenticator.getClass().equals(NbAuthenticator.class)) {
--- End diff --
I assumed only a Platform application would need that. I didn't think that
people might want to install a 3rd party plugin in their existing IDE/Platform
app.
---
[GitHub] incubator-netbeans pull request #2: Allow custom authenticator
Github user phansson commented on a diff in the pull request:
https://github.com/apache/incubator-netbeans/pull/2#discussion_r139604336
--- Diff: o.n.core/src/org/netbeans/core/NbAuthenticator.java ---
@@ -71,7 +74,19 @@ private NbAuthenticator() {
static void install() {
if (Boolean.valueOf(NbBundle.getMessage(GuiRunLevel.class,
"USE_Authentication"))) {
-setDefault(new NbAuthenticator());
+// Look for custom authenticator
+Authenticator authenticator =
Lookup.getDefault().lookup(Authenticator.class);
+if (authenticator == null) {
+authenticator = new NbAuthenticator();
+}
+if (authenticator.getClass().equals(NbAuthenticator.class)) {
--- End diff --
Why is it static? The idea is that people can add their own
Authenticators. Heck, I might even publish my own version as a plugin in the
Plugin Portal and ask users to use my plugin if I believe I've come up with
something brilliant which is better than the standard NbAuthenticator. And
that situation [already
exists](https://bitbucket.org/phansson/netbeansnetworkauthenticator).
---
