Re: Public vs. Friend API?
> > I can be prepared on my side when I use something unstable and can adopt > the change. > You can. If you're writing an IDE module, your users can't. They just upgrade the IDE and find something doesn't work anymore, say "this sucks" and go download Eclipse. There are friend APIs in NetBeans that have not seen a single change in going on a decade. All of those IMO, should simply get the "friend" label removed from them - if it hasn't changed in that long, it's clearly stable in every practical meaning of the word. I'm just suggesting a way to make that automatic, instead of someone having to go do that process manually, because what's predictable is that maybe it gets done in one release, and then it doesn't happen again for another decade until this exact conversation is happening again. -Tim
Re: Public vs. Friend API?
> > > So there's no reason the module system itself couldn't just discard > > "friend" status for any friend API and allow any module to depend on it, > > where the running release version is >= the first-appeared-in-release + 2 > > (or whatever number). So, a friend API that appears in release 9 is > > automatically a public API in release 11, no human intervention required > > (the Ant build harness and Maven plugin would also have to do this > > computation). > > > > I still don't see why this isn't looking at the problem backwards. True > friend APIs and not-yet-stable public APIs seem to be orthogonal problems. > I was there when friend APIs were being invented. The *entire* purpose was for a developer to evolve an API, in collaboration with others whose requirements might lead to incompatible changes in it, prior to being subject to the stringent backward compatibility requirements Sun required of public APIs. IMO, there *is no such thing as a "true friend" API.* If you don't want to publish an API, put all of your code in one module - the compatibility contract is between that module and itself. If module X depends on module Y, and nothing else may depend on Y, and X cannot function without Y, then you have *a single logical module.* You might think it looks nicer carved up into two pieces, but at that point you're doing code feng shui, not engineering. Assuming even non-stable APIs are stable for at least one release of the > IDE / platform, what benefit does this actually provide? Surely it is for > the user of the API to specify a non-stable dependency, not the provider to > act as gatekeeper? > The logical outcome of friend APIs is nobody creates anything else, unless there is a mechanism that says "stabilize your API or you're going to have to keep binary compatibility with whatever you've got when the clock runs out." The ongoing growth of stable APIs is what moves the platform and IDE forward, allowing new functionality to stand on the shoulders of what is already there. Friend APIs keep that from happening. If you have "non-stable dependencies", eventually that is all that will exist. Nobody would prefer to keep compatibility if they don't have to. -Tim
Re: [VOTE] Release Apache NetBeans 9.0 (incubating) [vote candidate 3]
my first netbeans build be gentle with me ;-) 1 BUILD SUCCESSFUL 1 BUILD FAILED BUILD SUCCESSFUL Total time: 24 minutes 55 seconds sysadmin@station9:/media/sysadmin/data0/temp/incubator-netbeans-master$ java -version openjdk version "1.8.0_171" OpenJDK Runtime Environment (build 1.8.0_171-8u171-b11-0ubuntu0.16.04.1-b11) OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode) Distributor ID:elementary Description:elementary OS 0.4.1 Loki Release:0.4.1 Codename:loki BUILD FAILED /mnt/data0/temp/incubator-netbeans-master/nbbuild/build.xml:153: Compile failed; see the compiler error output for details. Total time: 3 minutes 11 seconds pb@mobile7:/mnt/data0/temp/incubator-netbeans-master$ java -version openjdk version "10.0.1" 2018-04-17 OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1) OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode) Distributor ID:Ubuntu Description:Pop!_OS 18.04 LTS Release:18.04 Codename:bionic generate-sources-internal: [pcompile] Generating 6 resource files to /mnt/data0/temp/incubator-netbeans-master/nbbuild/build/langtools/build/gensrc/jdk.jshell [mkdir] Created dir: /mnt/data0/temp/incubator-netbeans-master/nbbuild/build/langtools/build/nb [javac] Compiling 1031 source files to /mnt/data0/temp/incubator-netbeans-master/nbbuild/build/langtools/build/nb [javac] /mnt/data0/temp/incubator-netbeans-master/nbbuild/build/langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java:35: error: package sun.reflect.annotation is not visible [javac] import sun.reflect.annotation.*; [javac] ^ [javac] (package sun.reflect.annotation is declared in module java.base, which does not export it to module java.compiler) [javac] /mnt/data0/temp/incubator-netbeans-master/nbbuild/build/langtools/src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java:31: error: package javax.xml.parsers is not visible [javac] import javax.xml.parsers.*; [javac] ^ [javac] (package javax.xml.parsers is declared in module java.xml, but module java.compiler does not read it) [javac] /mnt/data0/temp/incubator-netbeans-master/nbbuild/build/langtools/src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java:33: error: package org.xml.sax is not visible [javac] import org.xml.sax.*; [javac] ^ [javac] (package org.xml.sax is declared in module java.xml, but module java.compiler does not read it) [javac] /mnt/data0/temp/incubator-netbeans-master/nbbuild/build/langtools/src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java:34: error: package org.xml.sax.helpers is not visible [javac] import org.xml.sax.helpers.DefaultHandler; [javac] ^ [javac] (package org.xml.sax.helpers is declared in module java.xml, but module java.compiler does not read it) [javac] /mnt/data0/temp/incubator-netbeans-master/nbbuild/build/langtools/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/LayoutParser.java:31: error: package javax.xml.parsers is not visible [javac] import javax.xml.parsers.*; [javac] ^ [javac] (package javax.xml.parsers is declared in module java.xml, but module java.compiler does not read it) [javac] /mnt/data0/temp/incubator-netbeans-master/nbbuild/build/langtools/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/LayoutParser.java:36: error: package org.xml.sax is not visible [javac] import org.xml.sax.*; [javac] ^ [javac] (package org.xml.sax is declared in module java.xml, but module java.compiler does not read it) [javac] /mnt/data0/temp/incubator-netbeans-master/nbbuild/build/langtools/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/LayoutParser.java:37: error: package org.xml.sax.helpers is not visible [javac] import org.xml.sax.helpers.DefaultHandler; [javac] ^ [javac] (package org.xml.sax.helpers is declared in module java.xml, but module java.compiler does not read it) [javac] /mnt/data0/temp/incubator-netbeans-master/nbbuild/build/langtools/src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java:105: error: method does not override or implement a method from a supertype [javac] @Override [javac] ^ [javac] /mnt/data0/temp/incubator-netbeans-master/nbbuild/build/langtools/src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java:122: error: method does not override or implement a method from a supertype [javac] @Override [javac] ^ [javac]
Re: 2nd windows screen icon for nb9 shows nb82 shape/color icon
Hi Gary, Will you please try with this PR https://github.com/apache/incubator-netbeans/pull/633 Or update-icons branch of my fork https://github.com/thilina01/incubator-netbeans/tree/update-icons?files=1 To see if the mentioned icons updated? On Sat, Jul 14, 2018, 4:53 AM Gary Bello wrote: > main screen icon show new nb9 icon > > i have windows 10 with 2 displays - 2nd display is extended from the main - > not a duplicate. > > Both displays have a task bar that show icons of running programs. > > I built nb9 from the master git branch - not the release90 branch. > > This if from a build just a few minutes ago and fresh git pull of master > branch; > > do clean, then build-nozip; > > > -Gary >
Re: 2nd windows screen icon for nb9 shows nb82 shape/color icon
Are there multiple image sizes in the icon file? Were all of them replaced with the new icon? > On Jul 13, 2018, at 7:23 PM, Gary Bello wrote: > > main screen icon show new nb9 icon > > i have windows 10 with 2 displays - 2nd display is extended from the main - > not a duplicate. > > Both displays have a task bar that show icons of running programs. > > I built nb9 from the master git branch - not the release90 branch. > > This if from a build just a few minutes ago and fresh git pull of master > branch; > > do clean, then build-nozip; > > > -Gary - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
JigSaw-ing NetBeans?
Well this question is to Jaroslav Tulach mostly. From Java 9 there are three modularization system in Java. OSGI, NetBeans and Java's JigSaw. My question is could NetBeans be ported on JigSaw? What would we gain form that movement (if any), and what would be the pain points. I'd even would like to see a deep analysis on this topic on Jarda's blog. Thank you in advance! Laszlo Kishalmi - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API?
Well, I guess all this "friendly"-ness use case shall be re-evaluated. For me an unstable or incubation flag would be more than sufficient, and the build might warn me or optionally fail if I'd use an unstable/incubation level of module. I can be prepared on my side when I use something unstable and can adopt the change. Though we have other type of users, who seriously invested in NetBeans Platform. Geertjan probably know the most of them, a survey on their site would be good to have. Right now there is a possibility to tweak friendliness using Yenta (search it on Google). Just a sample set of modules, from my own plugin code. These could be real public from 8.0 at least: "org.netbeans.modules.gsf.testrunner", "org.netbeans.modules.gsf.testrunner.ui", "org.netbeans.modules.java.testrunner.ui", "org.netbeans.modules.junit", "org.netbeans.modules.junit.ui" On 07/12/2018 04:11 PM, Peter Nabbefeld wrote: Hello all, I personally don't like "Friend" APIs, as really I like the idea of an open, extensible IDE. From my point of view, Friend APIs make it difficult or impossible to extend NetBeans for personal use: - You have to ask for being added to the friends list. This is especially a problem, if You want to implement some private-use feature, e.g. for Your employer. - Alternatively You could depend on the implementation version; but I don't see how to do that, if You're using Maven. - Third possibility is just patching the modules to remove the friends and make the API public - very ugly, and You have to do it after every update. OTOH, having a friends-only API leads to fewer dependencies on the API, thus less impact from changes to the API, which makes work easier for the developers, of course. However, if an API isn't stable, yet, it could also just be flagged as "Under Development", thus telling users of those, that it is subject to change. Also, as it is possible to use default methods in interfaces from Java 8, it should be less of a problem to extend an existing API. But You can use the API on Your own risk without any conflicts. An exception of course is having APIs only for modularity, if classes are spread over different modules and need an API to interact with each other. In this case the API's purpose is not to integrate extensions, but to split responsibilities - in this case I fully agree these are not for public use. I'd be interested in comments on this - so, what do You think? Kind regards Peter - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
2nd windows screen icon for nb9 shows nb82 shape/color icon
main screen icon show new nb9 icon i have windows 10 with 2 displays - 2nd display is extended from the main - not a duplicate. Both displays have a task bar that show icons of running programs. I built nb9 from the master git branch - not the release90 branch. This if from a build just a few minutes ago and fresh git pull of master branch; do clean, then build-nozip; -Gary
Re: Public vs. Friend API?
On Fri, 13 Jul 2018, 20:15 Tim Boudreau, wrote: > So there's no reason the module system itself couldn't just discard > "friend" status for any friend API and allow any module to depend on it, > where the running release version is >= the first-appeared-in-release + 2 > (or whatever number). So, a friend API that appears in release 9 is > automatically a public API in release 11, no human intervention required > (the Ant build harness and Maven plugin would also have to do this > computation). > I still don't see why this isn't looking at the problem backwards. True friend APIs and not-yet-stable public APIs seem to be orthogonal problems. Assuming even non-stable APIs are stable for at least one release of the IDE / platform, what benefit does this actually provide? Surely it is for the user of the API to specify a non-stable dependency, not the provider to act as gatekeeper? I guess what I'd like to see is something that is neither friend nor implementation here. And never using friend API for third-party stuff either - JNA caused me no end of issues over the years! Best wishes, Neil >
Re: [VOTE] Release Apache NetBeans 9.0 (incubating) [vote candidate 3]
+1 binding (IPMC, Mentor) I've verified the signatures and digests, checked the License, Notice and Disclaimer files and finally build the source and tested the result with success. Congratulations to everyone involved on a the great work and result! Regards, Ate On 2018-07-08 11:40, Emilian Bold wrote: Hi all, Please vote on releasing Apache NetBeans 9.0 (incubating)! If this voting candidate passes, another similar voting will be started on gene...@incubator.apache.org, and if that passes too, then we can release this version. This build will also undergo validation through NetCAT. Apache NetBeans 9.0 (incubating) constitutes all the modules in the Apache NetBeans Git repo, which together provide the NetBeans Platform (i.e., the underlying application framework), as well as all the modules that provide the Java SE-related features of Apache NetBeans. In short, Apache NetBeans 9.0 (incubating) is a full IDE for Java SE development. Build artifacts available here: https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-vc3 The specific artifact to be voted on: https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-vc3/incubating-netbeans-java-9.0-source.zip Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and NOTICE files, as well as a README file with build instructions, which are the same as these: https://gitbox.apache.org/repos/asf?p=incubator-netbeans.git;a=blob_plain;f=README.md;h=eccd3c6cc707ba9ca219bcfb72979435d85f5f7a;hb=97904961e496383d6150aef9b78fa8dff8f3e1ce SHA1: ed2098c173460ec81f05635055066da06a7ea82b KEYS file: https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS Apache NetBeans Git Repo tag: 9.0-vc3 : https://gitbox.apache.org/repos/asf?p=incubator-netbeans.git;a=tag;h=refs/tags/9.0-vc3 Note: NetBeans license violation checks are managed via the rat-exclusions.txt file: https://gitbox.apache.org/repos/asf?p=incubator-netbeans.git;a=blob;f=nbbuild/rat-exclusions.txt;h=36cb8a3eae40bd7fc41c63c6055bce42f7916859;hb=97904961e496383d6150aef9b78fa8dff8f3e1ce Rat report shows no unknown licenses, except for license files: https://builds.apache.org/job/incubator-netbeans-release/334/artifact/rat-java-temp/nbbuild/build/rat-report.txt Included as a convenience binary, not relevant for the voting purposes (unzip it, run it and you'll see Apache NetBeans): https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-vc3/incubating-netbeans-java-9.0-bin.zip Also included as a convenience binary the NBMs: https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-vc3/nbms New & Noteworthy features of the 9.0 Release: https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+9.0+New+and+Noteworthy Release specific wiki page: https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+9.0+Final+Release How (and what) to try out the release: 1. Download the artifact to be voted on and unzip it. 2. Verify the cryptographic signatures, the NOTICE and LICENSE file 3. Build it using the README provided by the artifact. 4. Look in nbbuild/netbeans for the NetBeans installation created by the build process. 5. Run the NetBeans executable and (if you're running on JDK 8) you'll be prompted to install nb-javac, after agreeing to its licensing terms, and (if you're running on JDK 9), you'll be able to use javac directly from JDK 9 and, optionally, you'll be prompted to install nb-javac, after agreeing to its licensing terms. If the above succeeds, i.e., Apache NetBeans installs and starts up vote +1 in this thread. Note that according to http://www.apache.org/legal/release-policy.html#release-approval : Before casting +1 binding votes, individuals are REQUIRED to download all signed source code packages onto their own hardware, verify that they meet all requirements of ASF policy on releases as described below, validate all cryptographic signatures, compile as provided, and test the result on their own platform. Please try out the package, using the instructions above, and vote! The vote is open for a minimum of 72 hours or until the necessary number of votes (3 binding +1s) is reached. [ ] +1 Release this package as Apache NetBeans 9.0 (incubating) [ ] 0 I don't feel strongly about it, but I'm okay with the release [ ] -1 Do not release this package because... Please add "(binding)" if your vote is binding, i.e., you are an Apache NetBeans PPMC member, i.e., your name is on this page: http://home.apache.org/committers-by-project.html#netbeans , although note the only real binding votes in the incubator are those of the IPMC, i.e., in the next vote thread, after this one passes. Emilian Bold on behalf of the Apache NetBeans PPMC - To unsubscribe, e-mail:
How to merge HTML palette categories?
Hello, I'd like to turn this layer snippet into code: url="nbresloc:/org/netbeans/modules/web/wicket/palette/label/Label.xml"> url="nbresloc:/org/netbeans/modules/web/wicket/palette/ajaxfield/AjaxField.xml"> url="nbresloc:/org/netbeans/modules/web/wicket/palette/dropdown/DropDown.xml"> url="nbresloc:/org/netbeans/modules/web/wicket/palette/editablefield/Editable.xml"> ... I know, the "but what to do with the " Kind regards Peter - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API?
Pull requests are good; automation is better. NetBeans knows its own release version. The only (potentially) missing information is what release the friend API first appeared in. So there's no reason the module system itself couldn't just discard "friend" status for any friend API and allow any module to depend on it, where the running release version is >= the first-appeared-in-release + 2 (or whatever number). So, a friend API that appears in release 9 is automatically a public API in release 11, no human intervention required (the Ant build harness and Maven plugin would also have to do this computation). That would also light a fire under developers to actually stabilize APIs. -Tim On Fri, Jul 13, 2018 at 9:34 AM Neil C Smith wrote: > On Fri, 13 Jul 2018 at 14:26, Geertjan Wielenga > wrote: > > > > Put together a proposal on the Apache NetBeans Wiki and we can discuss > it. > > The wiki page I linked to on the old site does have some proposals > here that look interesting and detailed. We should make sure we don't > lose that page as well - we haven't migrated everything and this > doesn't seem to be there. At the moment it's mainly DevFAQ. Do you > know where that page is sitting in the old wiki? Not always easy to > tell when Google takes you there directly, unless I've missed > something staring me in the face?! :-) > > Best wishes, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > -- http://timboudreau.com
RE: [VOTE] Release Apache NetBeans 9.0 (incubating) [vote candidate2]
+1 Sent from Mail for Windows 10 From: chegekinut...@gmail.com Sent: 06 July 2018 14:15 To: d...@netbeans.apache.org Subject: Re: [VOTE] Release Apache NetBeans 9.0 (incubating) [vote candidate2] +1 On 2018/07/06 08:50:38, Emilian Bold wrote: > Hi all,> > > Please vote on releasing Apache NetBeans 9.0 (incubating)!> > > If this voting candidate passes, another similar voting will be started on gene...@incubator.apache.org, and if that passes too, then we can release this version. This build will also undergo validation through NetCAT.> > > Apache NetBeans 9.0 (incubating) constitutes all the modules in the Apache NetBeans Git repo, which together provide the NetBeans Platform (i.e., the underlying application framework), as well as all the modules that provide the Java SE-related features of Apache NetBeans.> > > In short, Apache NetBeans 9.0 (incubating) is a full IDE for Java SE development.> > > Build artifacts available here:> > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating- netbeans-java/incubating-9.0-vc2> > > The specific artifact to be voted on:> > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating- netbeans-java/incubating-9.0-vc2/incubating-netbeans-java-9.0- source.zip> > > Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and NOTICE files, as well as a README file with build instructions, which are the same as these:> > > https://github.com/apache/incubator-netbeans/blob/master/README.md> > > SHA1: 2a54b34a343fc720c5983d48ef41467163f1a6f0> > > KEYS file:> > > https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS> > > Apache NetBeans Git Repo tag: 9.0-vc2 :> > > https://github.com/apache/incubator-netbeans/tree/9.0-vc2> > > Note: NetBeans license violation checks are managed via the rat- exclusions.txt file:> > > https://github.com/apache/incubator-netbeans/blob/master/nbbuild/rat- exclusions.txt> > > Rat report shows no unknown licenses, except for license files:> > > https://builds.apache.org/job/incubator-netbeans-release/328/artifact /rat-java-temp/nbbuild/build/rat-report.txt> > > Included as a convenience binary, not relevant for the voting purposes (unzip it, run it and you'll see Apache NetBeans):> > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating- netbeans-java/incubating-9.0-vc2/incubating-netbeans-java-9.0-bin.zip> > > Also included as a convenience binary the NBMs:> > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating- netbeans-java/incubating-9.0-vc2/nbms> > > New & Noteworthy features of the 9.0 Release:> > > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+ 9.0+New+and+Noteworthy> > > Release specific wiki page:> > > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+ 9.0+Final+Release> > > How (and what) to try out the release:> > > 1. Download the artifact to be voted on and unzip it.> > 2. Verify the cryptographic signatures, the NOTICE and LICENSE file> > 3. Build it using the README provided by the artifact.> > 4. Look in nbbuild/netbeans for the NetBeans installation created by the build process.> > 5. Run the NetBeans executable and (if you're running on JDK 8) you'll be prompted to install nb-javac, after agreeing to its licensing terms, and (if you're running on JDK 9), you'll be able to use javac directly from JDK 9 and, optionally, you'll be prompted to install nb- javac, after agreeing to its licensing terms.> > > If the above succeeds, i.e., Apache NetBeans installs and starts up vote +1 in this thread.> > > Note that according to http://www.apache.org/legal/release-policy.htm l#release-approval :> > > > Before casting +1 binding votes, individuals are REQUIRED to download all> > > signed source code packages onto their own hardware, verify that they meet> > > all requirements of ASF policy on releases as described below, validate all> > > cryptographic signatures, compile as provided, and test the result on their> > > own platform.> > > Please try out the package, using the instructions above, and vote!> > > The vote is open for a minimum of 72 hours or until the necessary number of votes (3 binding +1s) is reached.> > > [ ] +1 Release this package as Apache NetBeans 9.0 (incubating)> > [ ] 0 I don't feel strongly about it, but I'm okay with the release> > [ ] -1 Do not release this package because...> > > Please add "(binding)" if your vote is binding, i.e., you are an Apache NetBeans PPMC member, i.e., your name is on this page: http://ho me.apache.org/committers-by-project.html#netbeans , although note the only real binding votes in the incubator are those of the IPMC, i.e., in the next vote thread, after this one passes.> > > Emilian Bold> > on behalf of the Apache NetBeans PPMC> > > > --- --> > To unsubscribe, e-mail:
RE: [VOTE] Release Apache NetBeans 9.0 (incubating) [vote candidate2]
+1 Sent from Mail for Windows 10 From: chegekinut...@gmail.com Sent: 06 July 2018 14:15 To: d...@netbeans.apache.org Subject: Re: [VOTE] Release Apache NetBeans 9.0 (incubating) [vote candidate2] +1 On 2018/07/06 08:50:38, Emilian Bold wrote: > Hi all,> > > Please vote on releasing Apache NetBeans 9.0 (incubating)!> > > If this voting candidate passes, another similar voting will be started on gene...@incubator.apache.org, and if that passes too, then we can release this version. This build will also undergo validation through NetCAT.> > > Apache NetBeans 9.0 (incubating) constitutes all the modules in the Apache NetBeans Git repo, which together provide the NetBeans Platform (i.e., the underlying application framework), as well as all the modules that provide the Java SE-related features of Apache NetBeans.> > > In short, Apache NetBeans 9.0 (incubating) is a full IDE for Java SE development.> > > Build artifacts available here:> > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating- netbeans-java/incubating-9.0-vc2> > > The specific artifact to be voted on:> > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating- netbeans-java/incubating-9.0-vc2/incubating-netbeans-java-9.0- source.zip> > > Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and NOTICE files, as well as a README file with build instructions, which are the same as these:> > > https://github.com/apache/incubator-netbeans/blob/master/README.md> > > SHA1: 2a54b34a343fc720c5983d48ef41467163f1a6f0> > > KEYS file:> > > https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS> > > Apache NetBeans Git Repo tag: 9.0-vc2 :> > > https://github.com/apache/incubator-netbeans/tree/9.0-vc2> > > Note: NetBeans license violation checks are managed via the rat- exclusions.txt file:> > > https://github.com/apache/incubator-netbeans/blob/master/nbbuild/rat- exclusions.txt> > > Rat report shows no unknown licenses, except for license files:> > > https://builds.apache.org/job/incubator-netbeans-release/328/artifact /rat-java-temp/nbbuild/build/rat-report.txt> > > Included as a convenience binary, not relevant for the voting purposes (unzip it, run it and you'll see Apache NetBeans):> > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating- netbeans-java/incubating-9.0-vc2/incubating-netbeans-java-9.0-bin.zip> > > Also included as a convenience binary the NBMs:> > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating- netbeans-java/incubating-9.0-vc2/nbms> > > New & Noteworthy features of the 9.0 Release:> > > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+ 9.0+New+and+Noteworthy> > > Release specific wiki page:> > > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+ 9.0+Final+Release> > > How (and what) to try out the release:> > > 1. Download the artifact to be voted on and unzip it.> > 2. Verify the cryptographic signatures, the NOTICE and LICENSE file> > 3. Build it using the README provided by the artifact.> > 4. Look in nbbuild/netbeans for the NetBeans installation created by the build process.> > 5. Run the NetBeans executable and (if you're running on JDK 8) you'll be prompted to install nb-javac, after agreeing to its licensing terms, and (if you're running on JDK 9), you'll be able to use javac directly from JDK 9 and, optionally, you'll be prompted to install nb- javac, after agreeing to its licensing terms.> > > If the above succeeds, i.e., Apache NetBeans installs and starts up vote +1 in this thread.> > > Note that according to http://www.apache.org/legal/release-policy.htm l#release-approval :> > > > Before casting +1 binding votes, individuals are REQUIRED to download all> > > signed source code packages onto their own hardware, verify that they meet> > > all requirements of ASF policy on releases as described below, validate all> > > cryptographic signatures, compile as provided, and test the result on their> > > own platform.> > > Please try out the package, using the instructions above, and vote!> > > The vote is open for a minimum of 72 hours or until the necessary number of votes (3 binding +1s) is reached.> > > [ ] +1 Release this package as Apache NetBeans 9.0 (incubating)> > [ ] 0 I don't feel strongly about it, but I'm okay with the release> > [ ] -1 Do not release this package because...> > > Please add "(binding)" if your vote is binding, i.e., you are an Apache NetBeans PPMC member, i.e., your name is on this page: http://ho me.apache.org/committers-by-project.html#netbeans , although note the only real binding votes in the incubator are those of the IPMC, i.e., in the next vote thread, after this one passes.> > > Emilian Bold> > on behalf of the Apache NetBeans PPMC> > > > --- --> > To unsubscribe, e-mail:
Re: Migrating plugins to Netbeans 9/JDK 9
Is there a repo where you can point to where we can get your code and reproduce this and identify the problem? Gj On Friday, July 13, 2018, Steve Hannah wrote: > Is there a recommended approach for migrating Netbeans plugins to Netbeans > 9/JDK9? Can I expect to achieve a plugin that works on JDK9/NB9 and is > backwards compatible with NB8, or should I be forking and maintaining two > plugins? > > My early attempts haven't been all that successful. I have been trying to > modify an existing Netbeans Plugin and Suite project, but after fixing one > dependency issue after another, and trying to run the Suite, I get a bunch > of errors like > > org.netbeans.modules.debugger.jpda.ui - The module named > org.netbeans.modules.options.java was needed and not found. > org.netbeans.modules.java.source.queries - None of the modules providing > the capability > org.netbeans.modules.java.source.queries.spi.QueriesController could be > installed. > org.apache.tools.ant.module - The module named > org.netbeans.modules.options.java was needed and not found. > org.netbeans.modules.apisupport.installer - The module > org.apache.tools.ant.module would also need to be installed. > org.netbeans.modules.ant.freeform - The module org.apache.tools.ant.module > would also need to be installed. > org.netbeans.modules.ant.browsetask - The module > org.apache.tools.ant.module would also need to be installed. > > And there are no project types available to create in the resulting NB > instance (I guess because it couldn't find any of the modules). > > Steve >
Migrating plugins to Netbeans 9/JDK 9
Is there a recommended approach for migrating Netbeans plugins to Netbeans 9/JDK9? Can I expect to achieve a plugin that works on JDK9/NB9 and is backwards compatible with NB8, or should I be forking and maintaining two plugins? My early attempts haven't been all that successful. I have been trying to modify an existing Netbeans Plugin and Suite project, but after fixing one dependency issue after another, and trying to run the Suite, I get a bunch of errors like org.netbeans.modules.debugger.jpda.ui - The module named org.netbeans.modules.options.java was needed and not found. org.netbeans.modules.java.source.queries - None of the modules providing the capability org.netbeans.modules.java.source.queries.spi.QueriesController could be installed. org.apache.tools.ant.module - The module named org.netbeans.modules.options.java was needed and not found. org.netbeans.modules.apisupport.installer - The module org.apache.tools.ant.module would also need to be installed. org.netbeans.modules.ant.freeform - The module org.apache.tools.ant.module would also need to be installed. org.netbeans.modules.ant.browsetask - The module org.apache.tools.ant.module would also need to be installed. And there are no project types available to create in the resulting NB instance (I guess because it couldn't find any of the modules). Steve
Re: Public vs. Friend API?
On Fri, 13 Jul 2018 at 14:26, Geertjan Wielenga wrote: > > Put together a proposal on the Apache NetBeans Wiki and we can discuss it. The wiki page I linked to on the old site does have some proposals here that look interesting and detailed. We should make sure we don't lose that page as well - we haven't migrated everything and this doesn't seem to be there. At the moment it's mainly DevFAQ. Do you know where that page is sitting in the old wiki? Not always easy to tell when Google takes you there directly, unless I've missed something staring me in the face?! :-) Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API?
Put together a proposal on the Apache NetBeans Wiki and we can discuss it. Discussion in this thread is indeed going to stop very soon unless an actual concrete proposal is put together. Gj On Friday, July 13, 2018, Peter Nabbefeld wrote: > > Yes, I know. I just wanted to make sure discussion doesn't stop at this > point. In the past, I'd already some discussions of this type, mostly > ending some time later anywhere else. > > So, while Johannes was *really* helpful, I just want to keep the direction > of the topic, as I see the move to Apache as a chance, to finally implement > a better API release process. This chance will probably never come back. > > Kind regards > > Peter > > > > Am 13.07.2018 um 12:03 schrieb Geertjan Wielenga: > >> Yes, of course. But Johannes was responding to this statement of yours and >> trying to help you and show you how to do this: >> >> - Alternatively You could depend on the implementation version; but I >> don't >> >>> see how to do that, if You're using Maven. >>> >> >> Gj >> >> On Fri, Jul 13, 2018 at 12:01 PM, Peter Nabbefeld > > >> wrote: >> >> Hi Johannes, >>> >>> thank You for the info! I'll have to find out what I was missing then. >>> Nevertheless, IMHO a module depending on an implementation is not very >>> convenient, as it will always fail to load when the dependency changed in >>> any way, not necessarily the API (in that case the spec version should >>> probably change, too). >>> >>> Kind regards >>> Peter >>> >>> >>> >>> Am 13.07.2018 um 10:33 schrieb Johannes Boesl: >>> >>> Hi there, just for completeness. It's well possible to depend on implementation version using maven. Here is an abstract from one of my poms: org.codehaus.mojo nbm-maven-plugin de.adito.aditow eb.nbm.designerbase.* org.netbeans.modules:org-n etbeans-modules-projectui impl org.netbeans.modules.projectui = 201609300101 org.netbeans.modules:org-netbeans-modules-git impl org.netbeans.modules.git = 201609300101 org.netbeans.modules:org-n etbeans-modules-versioning-util impl org.netbeans.modules.versioning.util = 201609300101 org.netbeans.api:org-netbe ans-modules-csl-api impl org.netbeans.modules.csl.api/2 = 2 eager With kind regards, Johannes Boesl Am 13.07.2018 um 01:11 schrieb Peter Nabbefeld: Hello all, > > I personally don't like "Friend" APIs, as really I like the idea of an > open, extensible IDE. > > From my point of view, Friend APIs make it difficult or impossible to > extend NetBeans for personal use: > - You have to ask for being added to the friends list. This is > especially a problem, if You want to implement some private-use > feature, e.g. for Your employer. > - Alternatively You could depend on the implementation version; but I > don't see how to do that, if You're using Maven. > - Third possibility is just patching the modules to remove the friends > and make the API public - very ugly, and You have to do it after every > update. > > OTOH, having a friends-only API leads to fewer dependencies on the > API, thus less impact from changes to the API, which makes work easier > for the developers, of course. > > However, if an API isn't stable, yet, it could also just be flagged as > "Under Development", thus telling users of those, that it is subject > to change. Also, as it is possible to use default methods in > interfaces from Java 8, it should be less of a problem to extend an > existing API. But You can use the API on Your own risk without any > conflicts. > > An exception of course is having APIs only for modularity, if classes > are spread over different modules and need an API to interact with > each other. In this case the API's purpose is not to integrate > extensions, but to split responsibilities - in this case I fully agree > these are not for public use. > > I'd be interested in comments on this - so, what do You think? > > Kind regards > > Peter > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-help@netbeans.incubator. > apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org >>> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org >>> >>> For further information about the NetBeans mailing lists, visit: >>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >>>
Re: [VOTE] Release Apache NetBeans 9.0 (incubating) [vote candidate 3]
On Sun, Jul 8, 2018 at 11:40 AM Emilian Bold wrote: > ...Build artifacts available here: > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-vc3 +1, binding, IPMC, for releasing SHA1(incubating-netbeans-java-9.0-source.zip)= ed2098c173460ec81f05635055066da06a7ea82b I have not looked at the convenience binaries. Signatures and digests are ok LICENSE, NOTICE, DISCLAIMER look good to me. DEPENDENCIES looks good and includes clarifications for optional or compile-time only GPL dependencies. I didn't find any problematic binary files in the archive, although they are many of them, using the "file" command to analyze them, at https://gist.github.com/bdelacretaz/4d6daef16e3b4d373e343c8ccafbc6a1 Build with "ant" and then "ant tryme" passes and starts the IDE. Build with "ant rat" passes. The exclusions list at nbbuild/rat-exclusions.txt is long but well commented. Congrats on the work done! -Bertrand - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API?
Yes, I know. I just wanted to make sure discussion doesn't stop at this point. In the past, I'd already some discussions of this type, mostly ending some time later anywhere else. So, while Johannes was *really* helpful, I just want to keep the direction of the topic, as I see the move to Apache as a chance, to finally implement a better API release process. This chance will probably never come back. Kind regards Peter Am 13.07.2018 um 12:03 schrieb Geertjan Wielenga: Yes, of course. But Johannes was responding to this statement of yours and trying to help you and show you how to do this: - Alternatively You could depend on the implementation version; but I don't see how to do that, if You're using Maven. Gj On Fri, Jul 13, 2018 at 12:01 PM, Peter Nabbefeld wrote: Hi Johannes, thank You for the info! I'll have to find out what I was missing then. Nevertheless, IMHO a module depending on an implementation is not very convenient, as it will always fail to load when the dependency changed in any way, not necessarily the API (in that case the spec version should probably change, too). Kind regards Peter Am 13.07.2018 um 10:33 schrieb Johannes Boesl: Hi there, just for completeness. It's well possible to depend on implementation version using maven. Here is an abstract from one of my poms: org.codehaus.mojo nbm-maven-plugin de.adito.aditow eb.nbm.designerbase.* org.netbeans.modules:org-netbeans-modules-projectui impl org.netbeans.modules.projectui = 201609300101 org.netbeans.modules:org-netbeans-modules-git impl org.netbeans.modules.git = 201609300101 org.netbeans.modules:org-n etbeans-modules-versioning-util impl org.netbeans.modules.versioning.util = 201609300101 org.netbeans.api:org-netbeans-modules-csl-api impl org.netbeans.modules.csl.api/2 = 2 eager With kind regards, Johannes Boesl Am 13.07.2018 um 01:11 schrieb Peter Nabbefeld: Hello all, I personally don't like "Friend" APIs, as really I like the idea of an open, extensible IDE. From my point of view, Friend APIs make it difficult or impossible to extend NetBeans for personal use: - You have to ask for being added to the friends list. This is especially a problem, if You want to implement some private-use feature, e.g. for Your employer. - Alternatively You could depend on the implementation version; but I don't see how to do that, if You're using Maven. - Third possibility is just patching the modules to remove the friends and make the API public - very ugly, and You have to do it after every update. OTOH, having a friends-only API leads to fewer dependencies on the API, thus less impact from changes to the API, which makes work easier for the developers, of course. However, if an API isn't stable, yet, it could also just be flagged as "Under Development", thus telling users of those, that it is subject to change. Also, as it is possible to use default methods in interfaces from Java 8, it should be less of a problem to extend an existing API. But You can use the API on Your own risk without any conflicts. An exception of course is having APIs only for modularity, if classes are spread over different modules and need an API to interact with each other. In this case the API's purpose is not to integrate extensions, but to split responsibilities - in this case I fully agree these are not for public use. I'd be interested in comments on this - so, what do You think? Kind regards Peter - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API?
Yes, of course. But Johannes was responding to this statement of yours and trying to help you and show you how to do this: - Alternatively You could depend on the implementation version; but I don't > see how to do that, if You're using Maven. Gj On Fri, Jul 13, 2018 at 12:01 PM, Peter Nabbefeld wrote: > > Hi Johannes, > > thank You for the info! I'll have to find out what I was missing then. > Nevertheless, IMHO a module depending on an implementation is not very > convenient, as it will always fail to load when the dependency changed in > any way, not necessarily the API (in that case the spec version should > probably change, too). > > Kind regards > Peter > > > > Am 13.07.2018 um 10:33 schrieb Johannes Boesl: > >> Hi there, >> >> just for completeness. It's well possible to depend on implementation >> version using maven. Here is an abstract from one of my poms: >> >>org.codehaus.mojo >> nbm-maven-plugin >> de.adito.aditow >> eb.nbm.designerbase.* >> >> org.netbeans.modules:org-netbeans-modules-projectui >> impl org.netbeans.modules.projectui = >> 201609300101 >> org.netbeans.modules:org-netbeans-modules-git impl >> org.netbeans.modules.git = 201609300101 >> org.netbeans.modules:org-n >> etbeans-modules-versioning-util impl >> org.netbeans.modules.versioning.util = 201609300101 >> >> org.netbeans.api:org-netbeans-modules-csl-api >> impl org.netbeans.modules.csl.api/2 = >> 2 >> eager >> >> >> With kind regards, >> Johannes Boesl >> >> >> Am 13.07.2018 um 01:11 schrieb Peter Nabbefeld: >> >>> Hello all, >>> >>> I personally don't like "Friend" APIs, as really I like the idea of an >>> open, extensible IDE. >>> >>> From my point of view, Friend APIs make it difficult or impossible to >>> extend NetBeans for personal use: >>> - You have to ask for being added to the friends list. This is >>> especially a problem, if You want to implement some private-use >>> feature, e.g. for Your employer. >>> - Alternatively You could depend on the implementation version; but I >>> don't see how to do that, if You're using Maven. >>> - Third possibility is just patching the modules to remove the friends >>> and make the API public - very ugly, and You have to do it after every >>> update. >>> >>> OTOH, having a friends-only API leads to fewer dependencies on the >>> API, thus less impact from changes to the API, which makes work easier >>> for the developers, of course. >>> >>> However, if an API isn't stable, yet, it could also just be flagged as >>> "Under Development", thus telling users of those, that it is subject >>> to change. Also, as it is possible to use default methods in >>> interfaces from Java 8, it should be less of a problem to extend an >>> existing API. But You can use the API on Your own risk without any >>> conflicts. >>> >>> An exception of course is having APIs only for modularity, if classes >>> are spread over different modules and need an API to interact with >>> each other. In this case the API's purpose is not to integrate >>> extensions, but to split responsibilities - in this case I fully agree >>> these are not for public use. >>> >>> I'd be interested in comments on this - so, what do You think? >>> >>> Kind regards >>> >>> Peter >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org >>> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org >>> >>> For further information about the NetBeans mailing lists, visit: >>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >>> >>> >>> >>> >>> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: Public vs. Friend API?
Hi Johannes, thank You for the info! I'll have to find out what I was missing then. Nevertheless, IMHO a module depending on an implementation is not very convenient, as it will always fail to load when the dependency changed in any way, not necessarily the API (in that case the spec version should probably change, too). Kind regards Peter Am 13.07.2018 um 10:33 schrieb Johannes Boesl: Hi there, just for completeness. It's well possible to depend on implementation version using maven. Here is an abstract from one of my poms: org.codehaus.mojo nbm-maven-plugin de.adito.aditoweb.nbm.designerbase.* org.netbeans.modules:org-netbeans-modules-projectui impl org.netbeans.modules.projectui = 201609300101 org.netbeans.modules:org-netbeans-modules-git impl org.netbeans.modules.git = 201609300101 org.netbeans.modules:org-netbeans-modules-versioning-util impl org.netbeans.modules.versioning.util = 201609300101 org.netbeans.api:org-netbeans-modules-csl-api impl org.netbeans.modules.csl.api/2 = 2 eager With kind regards, Johannes Boesl Am 13.07.2018 um 01:11 schrieb Peter Nabbefeld: Hello all, I personally don't like "Friend" APIs, as really I like the idea of an open, extensible IDE. From my point of view, Friend APIs make it difficult or impossible to extend NetBeans for personal use: - You have to ask for being added to the friends list. This is especially a problem, if You want to implement some private-use feature, e.g. for Your employer. - Alternatively You could depend on the implementation version; but I don't see how to do that, if You're using Maven. - Third possibility is just patching the modules to remove the friends and make the API public - very ugly, and You have to do it after every update. OTOH, having a friends-only API leads to fewer dependencies on the API, thus less impact from changes to the API, which makes work easier for the developers, of course. However, if an API isn't stable, yet, it could also just be flagged as "Under Development", thus telling users of those, that it is subject to change. Also, as it is possible to use default methods in interfaces from Java 8, it should be less of a problem to extend an existing API. But You can use the API on Your own risk without any conflicts. An exception of course is having APIs only for modularity, if classes are spread over different modules and need an API to interact with each other. In this case the API's purpose is not to integrate extensions, but to split responsibilities - in this case I fully agree these are not for public use. I'd be interested in comments on this - so, what do You think? Kind regards Peter - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [VOTE] Release Apache NetBeans 9.0 (incubating) [vote candidate 3]
+1 Checksum correct I built from sources and netbeans starts with no problem I have tested on Linux Product Version: Apache NetBeans IDE 9.0 (Build 20180712-unknown-revn) Java: 1.8.0_171; Java HotSpot(TM) 64-Bit Server VM 25.171-b11 Runtime: Java(TM) SE Runtime Environment 1.8.0_171-b11 System: Linux version 4.13.0-45-generic running on amd64; UTF-8; en_US (nb) I have tested on Windows Product Version: Apache NetBeans IDE 9.0 (Build 20180712-unknown-revn) Java: 1.8.0_171; Java HotSpot(TM) 64-Bit Server VM 25.171-b11 Runtime: Java(TM) SE Runtime Environment 1.8.0_171-b11 System: Windows 10 version 10.0 running on amd64; Cp1252; es_MX(nb) Regards, Tito Sanchez On 2018/07/08 09:40:32, Emilian Bold wrote: > Hi all, > > Please vote on releasing Apache NetBeans 9.0 (incubating)! > > If this voting candidate passes, another similar voting will be started on > gene...@incubator.apache.org, and if that passes too, then we can release > this version. This build will also undergo validation through NetCAT. > > Apache NetBeans 9.0 (incubating) constitutes all the modules in the Apache > NetBeans Git repo, which together provide the NetBeans Platform (i.e., the > underlying application framework), as well as all the modules that provide > the Java SE-related features of Apache NetBeans. > > In short, Apache NetBeans 9.0 (incubating) is a full IDE for Java SE > development. > > Build artifacts available here: > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-vc3 > > The specific artifact to be voted on: > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-vc3/incubating-netbeans-java-9.0-source.zip > > Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and NOTICE > files, as well as a README file with build instructions, which are the same > as these: > > https://gitbox.apache.org/repos/asf?p=incubator-netbeans.git;a=blob_plain;f=README.md;h=eccd3c6cc707ba9ca219bcfb72979435d85f5f7a;hb=97904961e496383d6150aef9b78fa8dff8f3e1ce > > SHA1: ed2098c173460ec81f05635055066da06a7ea82b > > KEYS file: > > https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS > > Apache NetBeans Git Repo tag: 9.0-vc3 : > > https://gitbox.apache.org/repos/asf?p=incubator-netbeans.git;a=tag;h=refs/tags/9.0-vc3 > > Note: NetBeans license violation checks are managed via the > rat-exclusions.txt file: > > https://gitbox.apache.org/repos/asf?p=incubator-netbeans.git;a=blob;f=nbbuild/rat-exclusions.txt;h=36cb8a3eae40bd7fc41c63c6055bce42f7916859;hb=97904961e496383d6150aef9b78fa8dff8f3e1ce > > Rat report shows no unknown licenses, except for license files: > > https://builds.apache.org/job/incubator-netbeans-release/334/artifact/rat-java-temp/nbbuild/build/rat-report.txt > > Included as a convenience binary, not relevant for the voting purposes (unzip > it, run it and you'll see Apache NetBeans): > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-vc3/incubating-netbeans-java-9.0-bin.zip > > Also included as a convenience binary the NBMs: > > https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans-java/incubating-9.0-vc3/nbms > > New & Noteworthy features of the 9.0 Release: > > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+9.0+New+and+Noteworthy > > Release specific wiki page: > > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+9.0+Final+Release > > How (and what) to try out the release: > > 1. Download the artifact to be voted on and unzip it. > 2. Verify the cryptographic signatures, the NOTICE and LICENSE file > 3. Build it using the README provided by the artifact. > 4. Look in nbbuild/netbeans for the NetBeans installation created by the > build process. > 5. Run the NetBeans executable and (if you're running on JDK 8) you'll be > prompted to install nb-javac, after agreeing to its licensing terms, and (if > you're running on JDK 9), you'll be able to use javac directly from JDK 9 > and, optionally, you'll be prompted to install nb-javac, after agreeing to > its licensing terms. > > If the above succeeds, i.e., Apache NetBeans installs and starts up vote +1 > in this thread. > > Note that according to > http://www.apache.org/legal/release-policy.html#release-approval : > > > Before casting +1 binding votes, individuals are REQUIRED to download all > > signed source code packages onto their own hardware, verify that they meet > > all requirements of ASF policy on releases as described below, validate all > > cryptographic signatures, compile as provided, and test the result on their > > own platform. > > Please try out the package, using the instructions above, and vote! > > The vote is open for a minimum of 72 hours or until the necessary number of > votes (3 binding +1s) is reached. > > [ ] +1 Release this package as Apache NetBeans 9.0 (incubating)
Re: Public vs. Friend API?
Hi there, just for completeness. It's well possible to depend on implementation version using maven. Here is an abstract from one of my poms: org.codehaus.mojo nbm-maven-plugin de.adito.aditoweb.nbm.designerbase.* org.netbeans.modules:org-netbeans-modules-projectui impl org.netbeans.modules.projectui = 201609300101 org.netbeans.modules:org-netbeans-modules-git impl org.netbeans.modules.git = 201609300101 org.netbeans.modules:org-netbeans-modules-versioning-util impl org.netbeans.modules.versioning.util = 201609300101 org.netbeans.api:org-netbeans-modules-csl-api impl org.netbeans.modules.csl.api/2 = 2 eager With kind regards, Johannes Boesl Am 13.07.2018 um 01:11 schrieb Peter Nabbefeld: > > Hello all, > > I personally don't like "Friend" APIs, as really I like the idea of an > open, extensible IDE. > > From my point of view, Friend APIs make it difficult or impossible to > extend NetBeans for personal use: > - You have to ask for being added to the friends list. This is > especially a problem, if You want to implement some private-use > feature, e.g. for Your employer. > - Alternatively You could depend on the implementation version; but I > don't see how to do that, if You're using Maven. > - Third possibility is just patching the modules to remove the friends > and make the API public - very ugly, and You have to do it after every > update. > > OTOH, having a friends-only API leads to fewer dependencies on the > API, thus less impact from changes to the API, which makes work easier > for the developers, of course. > > However, if an API isn't stable, yet, it could also just be flagged as > "Under Development", thus telling users of those, that it is subject > to change. Also, as it is possible to use default methods in > interfaces from Java 8, it should be less of a problem to extend an > existing API. But You can use the API on Your own risk without any > conflicts. > > An exception of course is having APIs only for modularity, if classes > are spread over different modules and need an API to interact with > each other. In this case the API's purpose is not to integrate > extensions, but to split responsibilities - in this case I fully agree > these are not for public use. > > I'd be interested in comments on this - so, what do You think? > > Kind regards > > Peter > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: Public vs. Friend API?
HTML and Palette have been mentioned as examples here only. When I'm ready to change sth., I'll provide a pull request together with starting a separate discussion. However, I remember being stopped from Friend APIs some long time ago, so IMHO this should be discussed. I understand, there're two different points of view: 1. API user's view: Give me as many APIs as possible, so I can do almost everything with the IDE. 2. IDE developers view: Provide as few as possible, only absolutely necessary, so IDE changes can be freely developed without impact to API users. These two views have to be considered for API state, and I'd be happy, if this discussion would lead to a better understanding of these and probably some rules, how to handle these. Hopefully this will lead to some rules for the Apache NetBeans project, how API state could be handled in a better and especially more transparent process. Regards Peter Am 13.07.2018 um 08:33 schrieb Geertjan Wielenga: Maybe a starting point could be for you to provide a pull request with the changes you'd like and then we can discuss that and agree together whether or not those changes make sense. Gj On Fri, Jul 13, 2018 at 8:27 AM, Peter Nabbefeld wrote: If this process (hardening the API and releasing it as public) would have been followed, it would be great. Unfortunately, it seems there're a bunch of useful APIs now which are not even part of the javadoc at bits.netbeans.org (and therefore mostly unknown) and seem to never be released. Some other APIs (like Palette API) seem to have extensions in many parts (= collections of modules building a functional part, like HTML support) of NetBeans, which could probably be made more general and then moved into the "Main API" (Palette, in this case), so everybody could use those. E.g. html module seems to have the ability to activate parts of different HTML APIs via layer, and some interface is there defined (but not yet used) to do this programmatically (probably using annotations). IMHO, this could be useful for other parts, too. So, while NetBeans moves to Apache, I'd like to further discuss the process of extending and hardening APIs. Regards Peter Am 13.07.2018 um 04:28 schrieb Tim Boudreau: The original idea of friend apis was to allow development of an api with the understanding that nobody gets things perfect the first time, so clients v could be developed but at the risk of dealing with breakage. The point was for the api to be in friend mode until it matures, at which point it becomes official compatible api. That's the part that never happened - no mechanism pushing moving apis out of friend mode. I'd suggest a rule that that happens automatically if a friend api has been around for more than 2-3 releases. Enforcement of that could probably be automated with a bit of auto bug filing cleverness. -Tim On Thu, Jul 12, 2018 at 7:11 PM Peter Nabbefeld wrote: Hello all, I personally don't like "Friend" APIs, as really I like the idea of an open, extensible IDE. From my point of view, Friend APIs make it difficult or impossible to extend NetBeans for personal use: - You have to ask for being added to the friends list. This is especially a problem, if You want to implement some private-use feature, e.g. for Your employer. - Alternatively You could depend on the implementation version; but I don't see how to do that, if You're using Maven. - Third possibility is just patching the modules to remove the friends and make the API public - very ugly, and You have to do it after every update. OTOH, having a friends-only API leads to fewer dependencies on the API, thus less impact from changes to the API, which makes work easier for the developers, of course. However, if an API isn't stable, yet, it could also just be flagged as "Under Development", thus telling users of those, that it is subject to change. Also, as it is possible to use default methods in interfaces from Java 8, it should be less of a problem to extend an existing API. But You can use the API on Your own risk without any conflicts. An exception of course is having APIs only for modularity, if classes are spread over different modules and need an API to interact with each other. In this case the API's purpose is not to integrate extensions, but to split responsibilities - in this case I fully agree these are not for public use. I'd be interested in comments on this - so, what do You think? Kind regards Peter - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists -- http://timboudreau.com - To unsubscribe, e-mail:
Re: Public vs. Friend API?
On Fri, 13 Jul 2018, 00:11 Peter Nabbefeld, wrote: > I personally don't like "Friend" APIs, as really I like the idea of an > open, extensible IDE. ... However, if an API isn't stable, yet, it could > also just be flagged as > "Under Development" > +110% Linking something for completeness - https://github.com/apache/incubator-netbeans/pull/415 IMO this concept needs rethinking, at least as something to mark unstable APIs (might have a limited role in small module groupings). We should make better use of semantic versioning, maybe extend module versioning to support / warn on -beta suffixes, and not break APIs in point releases. This old wiki page looks interesting, although only skimmed so far. Found it while searching for something else related. http://wiki.netbeans.org/NbmPackageStability Best wishes, Neil
Re: Public vs. Friend API?
Maybe a starting point could be for you to provide a pull request with the changes you'd like and then we can discuss that and agree together whether or not those changes make sense. Gj On Fri, Jul 13, 2018 at 8:27 AM, Peter Nabbefeld wrote: > > If this process (hardening the API and releasing it as public) would have > been followed, it would be great. Unfortunately, it seems there're a bunch > of useful APIs now which are not even part of the javadoc at > bits.netbeans.org (and therefore mostly unknown) and seem to never be > released. > > Some other APIs (like Palette API) seem to have extensions in many parts > (= collections of modules building a functional part, like HTML support) of > NetBeans, which could probably be made more general and then moved into the > "Main API" (Palette, in this case), so everybody could use those. E.g. html > module seems to have the ability to activate parts of different HTML APIs > via layer, and some interface is there defined (but not yet used) to do > this programmatically (probably using annotations). IMHO, this could be > useful for other parts, too. > > So, while NetBeans moves to Apache, I'd like to further discuss the > process of extending and hardening APIs. > > Regards > Peter > > > > Am 13.07.2018 um 04:28 schrieb Tim Boudreau: > >> The original idea of friend apis was to allow development of an api with >> the understanding that nobody gets things perfect the first time, so >> clients v could be developed but at the risk of dealing with breakage. >> >> The point was for the api to be in friend mode until it matures, at which >> point it becomes official compatible api. That's the part that never >> happened - no mechanism pushing moving apis out of friend mode. >> >> I'd suggest a rule that that happens automatically if a friend api has >> been >> around for more than 2-3 releases. Enforcement of that could probably be >> automated with a bit of auto bug filing cleverness. >> >> -Tim >> >> On Thu, Jul 12, 2018 at 7:11 PM Peter Nabbefeld >> wrote: >> >> Hello all, >>> >>> I personally don't like "Friend" APIs, as really I like the idea of an >>> open, extensible IDE. >>> >>> From my point of view, Friend APIs make it difficult or impossible to >>> extend NetBeans for personal use: >>> - You have to ask for being added to the friends list. This is >>> especially a problem, if You want to implement some private-use feature, >>> e.g. for Your employer. >>> - Alternatively You could depend on the implementation version; but I >>> don't see how to do that, if You're using Maven. >>> - Third possibility is just patching the modules to remove the friends >>> and make the API public - very ugly, and You have to do it after every >>> update. >>> >>> OTOH, having a friends-only API leads to fewer dependencies on the API, >>> thus less impact from changes to the API, which makes work easier for >>> the developers, of course. >>> >>> However, if an API isn't stable, yet, it could also just be flagged as >>> "Under Development", thus telling users of those, that it is subject to >>> change. Also, as it is possible to use default methods in interfaces >>> from Java 8, it should be less of a problem to extend an existing API. >>> But You can use the API on Your own risk without any conflicts. >>> >>> An exception of course is having APIs only for modularity, if classes >>> are spread over different modules and need an API to interact with each >>> other. In this case the API's purpose is not to integrate extensions, >>> but to split responsibilities - in this case I fully agree these are not >>> for public use. >>> >>> I'd be interested in comments on this - so, what do You think? >>> >>> Kind regards >>> >>> Peter >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org >>> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org >>> >>> For further information about the NetBeans mailing lists, visit: >>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >>> >>> >>> >>> -- >>> >> http://timboudreau.com >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: Public vs. Friend API?
If this process (hardening the API and releasing it as public) would have been followed, it would be great. Unfortunately, it seems there're a bunch of useful APIs now which are not even part of the javadoc at bits.netbeans.org (and therefore mostly unknown) and seem to never be released. Some other APIs (like Palette API) seem to have extensions in many parts (= collections of modules building a functional part, like HTML support) of NetBeans, which could probably be made more general and then moved into the "Main API" (Palette, in this case), so everybody could use those. E.g. html module seems to have the ability to activate parts of different HTML APIs via layer, and some interface is there defined (but not yet used) to do this programmatically (probably using annotations). IMHO, this could be useful for other parts, too. So, while NetBeans moves to Apache, I'd like to further discuss the process of extending and hardening APIs. Regards Peter Am 13.07.2018 um 04:28 schrieb Tim Boudreau: The original idea of friend apis was to allow development of an api with the understanding that nobody gets things perfect the first time, so clients v could be developed but at the risk of dealing with breakage. The point was for the api to be in friend mode until it matures, at which point it becomes official compatible api. That's the part that never happened - no mechanism pushing moving apis out of friend mode. I'd suggest a rule that that happens automatically if a friend api has been around for more than 2-3 releases. Enforcement of that could probably be automated with a bit of auto bug filing cleverness. -Tim On Thu, Jul 12, 2018 at 7:11 PM Peter Nabbefeld wrote: Hello all, I personally don't like "Friend" APIs, as really I like the idea of an open, extensible IDE. From my point of view, Friend APIs make it difficult or impossible to extend NetBeans for personal use: - You have to ask for being added to the friends list. This is especially a problem, if You want to implement some private-use feature, e.g. for Your employer. - Alternatively You could depend on the implementation version; but I don't see how to do that, if You're using Maven. - Third possibility is just patching the modules to remove the friends and make the API public - very ugly, and You have to do it after every update. OTOH, having a friends-only API leads to fewer dependencies on the API, thus less impact from changes to the API, which makes work easier for the developers, of course. However, if an API isn't stable, yet, it could also just be flagged as "Under Development", thus telling users of those, that it is subject to change. Also, as it is possible to use default methods in interfaces from Java 8, it should be less of a problem to extend an existing API. But You can use the API on Your own risk without any conflicts. An exception of course is having APIs only for modularity, if classes are spread over different modules and need an API to interact with each other. In this case the API's purpose is not to integrate extensions, but to split responsibilities - in this case I fully agree these are not for public use. I'd be interested in comments on this - so, what do You think? Kind regards Peter - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists -- http://timboudreau.com - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Suscribe
Suscribe Tito Sanchez tmsanc...@gmail.com
