Re: Future of JavaHelp (or a replacement) in NetBeans?
Am 23.09.18 um 21:20 schrieb Jan Tosovsky: On 2018-09-18 Peter Nabbefeld wrote: While JavaHelp might be licensed under AL2, it still suffers from UI support. What about some JavaHelp 3.0 (which probably needs a new name), building on Lucene but with a replaceable GUI (probably based on Servo renderer)? JavaHelp format is kind of standard, it can be produced by many tools. So before inventing the new format we could just improve the client. That's what I'd prefer, too, but that presumes, Oracle will relicense JavaHelp, in which case e.g. the error handling (and logging) could be improved. Otherwise it may be necessary to use sth. else. In this case, it might be sth. specific to the needs of NetBeans. But I agree it is hard decision which technology to use: Swing CSS support is poor JavaFX is not part of JDK 11+ any more So only viable option seem to be rewriting the client to some JavaScript based Single Page App (it would read .jar and render it in same way as hsviewer, but directly in a browser). I've found sth. about a new HTML renderer called "Servo", developped by Mozilla and Samsung, so I thought it to be a good idea, to propose it's usage for a new UI. But I must admit, I definitely don't know anything further, yet. Kind regards Peter Jan - 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 Reloaded (Summary)
Too many nested comments inline already, sorry, so I try to summarize. Please feel free to remove the discussion at the bottom, if You agree it is not needed anymore. 1. I don't like documentation handled differently based on friend-state. There should always be sufficient information on every module. 2. Most people will not be able to use a module with insufficient information. As a result, information will be extended for public modules only, because people start to try using them and ask for information on points they don't understand. Friend-only modules will not have any more support. So, many jewels will never be officially become usable by the community. 3. I don't like to make the available documentation a criteria of the friend-state. Just because I'd like to see more of the modules and even the start phase of NetBeans documented. It would be great, if the original authors would have done that, all the others need to look at the often poorly documented code and find out, what the original author wanted to do with it. In some cases this is far from being obvious. In this case, it doesn't help much, that the code is open-source - You'll also be unable to read some old texts, just because You cannot read the letters. 4. Yes, the main stability criterium for APIs for me is no changes for some time - it's usually an indicator, that it has been used sufficiently. But, of course, if I want to use some API, I'll probably find some problems. 5. Thinking about [4], the friend-state could probably be managed easier-to-use, as a first step, e.g. adding sth. like "personal.friends=module(s)-to-be-used-as-friend" in user.properties. This could take the burden of cloning and building the whole NetBeans for just trying some friend-only API. Probably, in this case don't build nbm files but only install locally (deploy in running IDE or run a separate IDE), so it cannot be pushed to plugin repository by accident. Just an idea. 6. The possibility to extend HTML syntax using html.editor.lib is only one of its possibilities, but that's only one of the affected modules, so if we want to discuss that, we should use another thread. 7. Same for CSL/GSF/etc. - my fault. Thought You could help me with these. Should have opened new thread. Kind regards Peter Am 23.09.18 um 21:16 schrieb Jan Lahoda: On Sun, Sep 23, 2018 at 7:23 PM Peter Nabbefeld wrote: Am 23.09.18 um 18:17 schrieb Jan Lahoda: [...] I think that having a reasonable documentation was traditionally one of the requirements for a public API modules. (I doubt csl.api went through the API review process.) (next sentence is meant to be sarcastic): So, if I'm too lazy to write some documentation, I get the benefit to never need to think about how to do some changes, as nobody will get the chance to use it. Okay, that's just to make clear this requirement may be misleading. And Not sure what's misleading here. Traditionally, public API always had to be documented. Friend API not so much (because it was supposed to only be used by "friends".) So if we want to keep the traditional quality (of public APIs), friend APIs that are converted to Public APIs should be (among others) documented. what about the colleages - they shouldn't be able to understand the code, either? Sufficient documentation should not be a requirement for a public API, but for every API - otherwise the functionality should be considered not to be integrated into NetBeans at all. [...] I don't see two major NetBeans releases within 6 months, currently. But, depending on the size of some module, IMHO, two or three major releases of NetBeans should show most weaknesses of an API to stabilize it. If a distinct functionality does not (yet) work as expected, declare it as such, and make this part "private" (i.e. a friend-only module only accessible from the API to be made public). There're many well-designed Looking at html.editor.lib (another module mentioned in this context), I wonder if that's considered to work "as expected", or if there are parts that should be "private". Looking at the module, I am frankly a bit lost on where should I begin to use it. (I assume I'd add a task using parsing.api to "text/html", and then see if the Parser.Result I get is HtmlParsingResult, but why are there 4 more classes with ParseResult in name?) Concerning the html.editor.lib module there's an API to extend the HTML syntax, e.g. adding tags used by some of the JavaScript frameworks, which is important for me. I didn't spot this in the module (by which I don't mean it is not there), but it sounds like a small part of the module. So, is there a particular reason why there can't be a module, e.g. html.api or html.source, containing reviewed APIs, rather than opening everything? As an example. After thinking of this for a little, I guess the ideal approach for changing a friend module to public API module would be if folks interested in
Re: Work Offline as a Global Setting for the Platform?
Hello, FWIW, I think a `Work Offline` global property sounds a great idea. Sometimes, connections go down. You won`t have to stop that idea growing within. From: Laszlo Kishalmi To: dev Sent: Sunday, 23 September 2018, 3:35 Subject: Work Offline as a Global Setting for the Platform? Hi all, Even in the on-line always connected world, what do you think of the value of a global Work Offline property supported by the platform? It just popped in my mind reading the JavaHelp replacement thread, and I myself has some offline/online workflows as well. - 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: Work Offline as a Global Setting for the Platform?
Hi, I really need to work with my nb platform apps offline and in the past I had only a few issues to fight with, to make my apps working offline: - xml file with reference schema files with http://... - strange behavoir if during plugin download/installation the computer gos offline - unconvinient behavoir of a modified netbeans welcome-window, which points to external websites Are there further netbeans modules which can make problems if the pc gos offline? best regards Oliver > Well, the always online mentality is not a good one because many > corporations block sites, we have the plugin portal blocked as an example. > > Some of us with poor internet also suffer a bad experience, it’s getting > better here but I had dialup only 3 years ago, much of Australia still has > bad internet until the fibre rollout is complete. > > Then there’s the commuters that work on trains. > > > On 23 Sep 2018, at 12:34, Laszlo Kishalmi > > wrote: > > > > Hi all, > > > > Even in the on-line always connected world, what do you think of the value > > of a global Work Offline property supported by the platform? It just > > popped in my mind reading the JavaHelp replacement thread, and I myself > > has some offline/online workflows as well. > > > > > > > > - > > 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
Podling Report Reminder - October 2018
Dear podling, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 17 October 2018, 10:30 am PDT. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted 2 weeks before the board meeting, to allow sufficient time for review and submission (Wed, October 03). Please submit your report with sufficient time to allow the Incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is 2 weeks prior to the board meeting. Candidate names should not be made public before people are actually elected, so please do not include the names of potential committers or PPMC members in your report. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. * How does the podling rate their own maturity. This should be appended to the Incubator Wiki page at: https://wiki.apache.org/incubator/October2018 Note: This is manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC - 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: Jenkins Builds
Sure. These kinds of issues have happened many times before and will happen many times again. Will try to track it down on the Oracle end. Gj On Sun, Sep 23, 2018 at 9:26 PM, Matthias Bläsing wrote: > Hi Geertjan, > > Am Sonntag, den 23.09.2018, 21:13 +0200 schrieb Geertjan Wielenga: > > On Sun, Sep 23, 2018 at 5:46 PM, Antonio wrote: > > > > > It seems this is an SSL related problem [1]. Maybe this is due to > > > domain > > > donation? > > > > > > > > > Will try to find out. > > it would be great if you could raise this with oracle infra. The server > is still at oracle (yes we need to figure the migration out, but that > is a different question): > > nslookup hg.netbeans.org > > resolves to: > > Non-authoritative answer: > Name: hg.netbeans.org > Address: 137.254.60.37 > > And for that IP address whois reports: > > whois 137.254.60.37 > > resolves to: > > [...] > Organization: Oracle Corporation (ORACLE-4-Z) > [...] > > > Trying to connect to the system we get: > > matthias@athena:~$ curl http://hg.netbeans.org > curl: (56) Recv failure: Connection reset by peer > matthias@athena:~$ > > > matthias@athena:~$ curl https://hg.netbeans.org > curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to > hg.netbeans.org:443 > matthias@athena:~$ > > Either the server needs some love or a firewall system between "the > internet" and the server. > > > This is not meant as a blame game, but to give information to make it > easier for infra to get onto this. > > Matthias > > - > 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: Jenkins Builds
Hi Geertjan, Am Sonntag, den 23.09.2018, 21:13 +0200 schrieb Geertjan Wielenga: > On Sun, Sep 23, 2018 at 5:46 PM, Antonio wrote: > > > It seems this is an SSL related problem [1]. Maybe this is due to > > domain > > donation? > > > > > Will try to find out. it would be great if you could raise this with oracle infra. The server is still at oracle (yes we need to figure the migration out, but that is a different question): nslookup hg.netbeans.org resolves to: Non-authoritative answer: Name: hg.netbeans.org Address: 137.254.60.37 And for that IP address whois reports: whois 137.254.60.37 resolves to: [...] Organization: Oracle Corporation (ORACLE-4-Z) [...] Trying to connect to the system we get: matthias@athena:~$ curl http://hg.netbeans.org curl: (56) Recv failure: Connection reset by peer matthias@athena:~$ matthias@athena:~$ curl https://hg.netbeans.org curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to hg.netbeans.org:443 matthias@athena:~$ Either the server needs some love or a firewall system between "the internet" and the server. This is not meant as a blame game, but to give information to make it easier for infra to get onto this. Matthias - 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: Future of JavaHelp (or a replacement) in NetBeans?
On 2018-09-18 Peter Nabbefeld wrote: > > While JavaHelp might be licensed under AL2, it still suffers from UI > support. > > What about some JavaHelp 3.0 (which probably needs a new name), building > on Lucene but with a replaceable GUI (probably based on Servo renderer)? > JavaHelp format is kind of standard, it can be produced by many tools. So before inventing the new format we could just improve the client. But I agree it is hard decision which technology to use: Swing CSS support is poor JavaFX is not part of JDK 11+ any more So only viable option seem to be rewriting the client to some JavaScript based Single Page App (it would read .jar and render it in same way as hsviewer, but directly in a browser). Jan - 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 Reloaded (Summary)
On Sun, Sep 23, 2018 at 7:23 PM Peter Nabbefeld wrote: > > > Am 23.09.18 um 18:17 schrieb Jan Lahoda: > > [...] > > > > I think that having a reasonable documentation was traditionally one of > the > > requirements for a public API modules. (I doubt csl.api went through the > > API review process.) > > > (next sentence is meant to be sarcastic): > So, if I'm too lazy to write some documentation, I get the benefit to > never need to think about how to do some changes, as nobody will get the > chance to use it. > > Okay, that's just to make clear this requirement may be misleading. And > Not sure what's misleading here. Traditionally, public API always had to be documented. Friend API not so much (because it was supposed to only be used by "friends".) So if we want to keep the traditional quality (of public APIs), friend APIs that are converted to Public APIs should be (among others) documented. > what about the colleages - they shouldn't be able to understand the > code, either? Sufficient documentation should not be a requirement for a > public API, but for every API - otherwise the functionality should be > considered not to be integrated into NetBeans at all. > > > [...] > >> I don't see two major NetBeans releases within 6 months, currently. But, > >> depending on the size of some module, IMHO, two or three major releases > >> of NetBeans should show most weaknesses of an API to stabilize it. If a > >> distinct functionality does not (yet) work as expected, declare it as > >> such, and make this part "private" (i.e. a friend-only module only > >> accessible from the API to be made public). There're many well-designed > >> > > Looking at html.editor.lib (another module mentioned in this context), I > > wonder if that's considered to work "as expected", or if there are parts > > that should be "private". Looking at the module, I am frankly a bit lost > on > > where should I begin to use it. (I assume I'd add a task using > parsing.api > > to "text/html", and then see if the Parser.Result I get is > > HtmlParsingResult, but why are there 4 more classes with ParseResult in > > name?) > > Concerning the html.editor.lib module there's an API to extend the HTML > syntax, e.g. adding tags used by some of the JavaScript frameworks, > which is important for me. > I didn't spot this in the module (by which I don't mean it is not there), but it sounds like a small part of the module. So, is there a particular reason why there can't be a module, e.g. html.api or html.source, containing reviewed APIs, rather than opening everything? As an example. > > > > After thinking of this for a little, I guess the ideal approach for > > changing a friend module to public API module would be if folks > interested > > in the given API would get together, reviewed the API, improved it as > > needed (and as possible, because with 20+ friends, it may be unrealistic > to > > do certain changes), added documentation, etc. and proposed to make the > > updated version public. > > > > It is of course possible to simply remove the "for friends only" flag, > but > > that's not going to improve the API and documentation. > > > > Jan > > > > [...] > > > > And, yes, all the APIs should be reviewed, as already mentioned above. > Good to hear that! As NetBeans is located at Apache now (i.e. no double-license anymore), > IMHO everybody should be able to understand even the most internal > functionality. As a result, this can no more be used as an argument for > Not sure what was the problem before - the source code was for one and a half decade open even before Apache, anyone could have understand anything they wanted? friend-only state. As a result, I see the only criteria being stability. > Less sure about this - if the "stability" means "didn't change in last X years", then e.g. html.editor.lib might pass that criterion, which by itself would not make the API better, more maintainable or more documented. > > Could You probably help to document CSL and GSF? Probably by giving an > Sorry, but probably no. There are a few reasons for that: a) my time on this project is severely limited (we are talking about my personal spare time only), so this task would compete with many other tasks for my time. b) I know very little about CSL (there may be my name on some classes in that module - that does not mean I wrote them for this module. It typically means I wrote them for java.editor/java.hints/java.source, and the classes were copied including the author tag and severely modified.) c) I was personally never convinced the CSL is the right approach - there are "low level" APIs for implementing the language features, and CSL is built on top of them - some consider it easier to use. I would probably be tempted to redesign the approach. So, I guess it would be better if someone more knowledgeable and enthusiastic about CSL documented that. overview how to do sth. like integrating JavaScript and HTML (without > the exact details, it's
Re: Jenkins Builds
On Sun, Sep 23, 2018 at 5:46 PM, Antonio wrote: > It seems this is an SSL related problem [1]. Maybe this is due to domain > donation? > Will try to find out. The various domains are in kind of a limbo right now, see: https://wiki.apache.org/incubator/October2018 That could be the reason here. The best part is that once we have the domains all available and running via Apache, we'll simply be able to go to infra.chat and ask Apache infra what the problem might be. Potentially, Apache infra is moving the domains over right now, though it's unclear -- also, we need to put that contain that is part of our builds coming from hg.netbeans.org/binares/ somewhere else -- where would be the better place for that? Maybe the server Emilian has found somewhere? Gj > > Cheers, > Antonio > > > [1] > $ curl -I -v https://hg.netbeans.org/binaries/ > * Trying 137.254.60.37... > * TCP_NODELAY set > * Connected to hg.netbeans.org (137.254.60.37) port 443 (#0) > * ALPN, offering h2 > * ALPN, offering http/1.1 > * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT5 > 6:!aNULL:!LOW:!RC4:@STRENGTH > * successfully set certificate verify locations: > * CAfile: /etc/ssl/certs/ca-certificates.crt > CApath: /etc/ssl/certs > * TLSv1.2 (OUT), TLS header, Certificate Status (22): > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > * TLSv1.2 (IN), TLS handshake, Server hello (2): > * TLSv1.2 (IN), TLS handshake, Certificate (11): > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > * TLSv1.2 (IN), TLS handshake, Server finished (14): > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > * TLSv1.2 (OUT), TLS change cipher, Client hello (1): > * TLSv1.2 (OUT), TLS handshake, Finished (20): > * TLSv1.2 (IN), TLS change cipher, Client hello (1): > * Unknown SSL protocol error in connection to hg.netbeans.org:443 > * Curl_http_done: called premature == 1 > * stopped the pause stream! > * Closing connection 0 > curl: (35) Unknown SSL protocol error in connection to hg.netbeans.org:443 > > > On 23/09/18 15:58, John McDonnell wrote: > >> @Geertjan Wielenga Can you find out >> >> what's wrong with hg.netbeans.org/binaries please? >> >> The cloning issue is resolved for now, but the next error in the build is: >> >> Could not download >> 1DE46CC85D147D9F91AF59D4A0107091C8B112D6-java-cup-11a.jar from >> http://hg.netbeans.org/binaries/: java.io.IOException: Could not download >> 1DE46CC85D147D9F91AF59D4A0107091C8B112D6-java-cup-11a.jar to >> /home/jenkins/.hgexternalcache/1DE46CC85D147D9F91AF59D4A0107 >> 091C8B112D6-java-cup-11a.jar: >> java.net.SocketException: Connection reset >> >> As for the issue with NetBeans maven artifacts, It seems the existing >> Jenkins job was configured to use the nb-repository-plugin maven plugin to >> generate artifacts. >> I think the next steps would here be to hook that up, and point to the >> apache maven nexus. >> >> I used the following commands to generate these locally: >> >> $ ant build build-nbms generate-uc-catalog build-source-zips >> >> $ mvn org.codehaus.mojo:nb-repository-plugin:1.3:populate >> -DdeployUrl=file:///Users/john/codebase/incubator-netbeans/ >> nbbuild/build/.m2 >> -DnetbeansNbmDirectory=/Users/john/codebase/incubator-netbea >> ns/nbbuild/nbms >> -DnetbeansInstallDirectory=/Users/john/codebase/incubator-ne >> tbeans/nbbuild/netbeans >> -DnetbeansSourcesDirectory=/Users/john/codebase/incubator-ne >> tbeans/nbbuild/build/source-zips >> -DforcedVersion=DEV -DgroupIdPrefix=org.apache.netbeans >> >> Regards >> >> John >> >> On Sun, 23 Sep 2018 at 14:43, Peter Nabbefeld >> wrote: >> >> Hello, >>> >>> as I've read on the users list, the netbeans.org domain has been >>> officially donated to Apache, so Maven plugins etc. should be put there, >>> now. (Message was from Geertjan Wielenga, on Subject "[Platform] Maven >>> artefacts". For me, question remains what will happen to NB 8.2 plugins. >>> >>> So, primarily I'd expect the necessary infrastructure needs to be >>> created first. >>> >>> Kind regards >>> >>> Peter >>> >>> >>> Am 23.09.18 um 15:31 schrieb John McDonnell: >>> Hi, I was looking into the maven artifacts issue earlier and noticed the >>> linux >>> build has been failing[1]. Anyone any ideas before I reach out to infra? Regards John [1]: ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://github.com/apache/incubator-netbeans.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:888) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1155) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1 208) at >>> hudson.model.AbstractBuild$AbstractBuildExecution.defaultChe >>> ckout(AbstractBuild.java:574) >>> at >>>
Re: downloaded binaries questions
Hi Glenn, Am Sonntag, den 23.09.2018, 13:12 -0500 schrieb Glenn Holmer: > 1) Where is the format of the external/*-license.txt file documented > (e.g. ide/db.drivers/external/postgresql-9.4.1209-license.txt)? There is no formal documentation I'm aware of. If you are interested in the code, that parses that file, the two classes: org.netbeans.nbbuild.extlibs.CreateLicenseSummary org.netbeans.nbbuild.extlibs.VerifyLibsAndLicenses should hold the answers. > 2) Do I understand correctly that whether a binary is downloaded from > Maven or from hg.netbeans.org (Ant property "binaries.server") depends > on whether the entry in external/binaries-list can be parsed as a Maven > coordinate by org.netbeans.nbbuild.extlibs.DownloadBinaries.java? yes, that is correct. HTH Matthias - 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: Jenkins Builds
On Sun, Sep 23, 2018 at 3:43 PM, Peter Nabbefeld wrote: > Hello, > > as I've read on the users list, the netbeans.org domain has been > officially donated to Apache, so Maven plugins etc. should be put there, > now. (Message was from Geertjan Wielenga, on Subject "[Platform] Maven > artefacts". Simplest way to keep track of the latest developments is via the quarterly incubator reports, i.e., here's the latest one, please read it to see where the various developments in Apache NetBeans are right now: https://wiki.apache.org/incubator/October2018 This is where the above was announced: https://lists.apache.org/thread.html/c80bbb49495902ae48d480c484c7f02b3a118ab6e91c27051a482025@%3Cdev.netbeans.apache.org%3E > For me, question remains what will happen to NB 8.2 plugins. > > So, primarily I'd expect the necessary infrastructure needs to be created > first. > Yes, what do you suggest to be done here, and where? What is your proposal here? For me as well, for everyone as well, it is unclear where the plugins (and not necessarily just for 8.2) should be hosted. They cannot be hosted on our VM at Apache, since Apache distributes source code only, not binaries. An exception is the convenience binary of the sources released at Apache, i.e., that's why we can make the ZIP file containing the binary distribution of the released source code available. But what about the plugins? Can they be hosted on your organization's servers? We do have various organizations who have already offered that kind of space, would be good to start documenting that, would be good if a variety of organizations would make that space available. A next question is where should the application currently at plugins.netbeans.org be hosted? So, the point is, you seem to be asking questions expecting there to be answers provided by somebody -- who that somebody is is unclear, we are all in the same boat together, and we're all trying to figure out the way forward for various artefacts together. The best way to ask a question on an Apache dev mailing list is to suggest several answers that you have come up with yourself as a way forward, rather than hoping/expecting/assuming that there are answers that someone is going to provide. This is the most difficult aspect of understanding what we are doing here together, it's going to take a lot of time for this aspect to really sink in -- it's what makes the process inspiring, potentially, but also frustrating, and we all hope you'll think along with everyone else about the best solutions and not get too frustrated in the process. Gj > > Kind regards > > Peter > > > Am 23.09.18 um 15:31 schrieb John McDonnell: > > Hi, >> >> I was looking into the maven artifacts issue earlier and noticed the linux >> build has been failing[1]. >> >> Anyone any ideas before I reach out to infra? >> >> Regards >> >> John >> >> [1]: ERROR: Error fetching remote repo 'origin' >> hudson.plugins.git.GitException: Failed to fetch from >> https://github.com/apache/incubator-netbeans.git >> at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:888) >> at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1155) >> at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186) >> at hudson.scm.SCM.checkout(SCM.java:504) >> at hudson.model.AbstractProject.checkout(AbstractProject.java:1 >> 208) >> at hudson.model.AbstractBuild$AbstractBuildExecution.defaultChe >> ckout(AbstractBuild.java:574) >> at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy >> .java:86) >> at hudson.model.AbstractBuild$AbstractBuildExecution.run(Abstra >> ctBuild.java:499) >> at hudson.model.Run.execute(Run.java:1794) >> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) >> at hudson.model.ResourceController.execute(ResourceController. >> java:97) >> at hudson.model.Executor.run(Executor.java:429) >> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags >> --progress https://github.com/apache/incubator-netbeans.git >> +refs/heads/*:refs/remotes/origin/*" returned status code 128: >> >> > > - > 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: downloaded binaries questions
Hi Glenn, 1. They're not documented, probably they should be. The way we're doing it right now is to take a look at how it's done in one module and then apply it to another module. 2. That's my understanding, yes. Gj On Sun, Sep 23, 2018 at 8:12 PM, Glenn Holmer wrote: > Some questions about downloading external binaries at build time: > > 1) Where is the format of the external/*-license.txt file documented > (e.g. ide/db.drivers/external/postgresql-9.4.1209-license.txt)? > > 2) Do I understand correctly that whether a binary is downloaded from > Maven or from hg.netbeans.org (Ant property "binaries.server") depends > on whether the entry in external/binaries-list can be parsed as a Maven > coordinate by org.netbeans.nbbuild.extlibs.DownloadBinaries.java? > > -- > Glenn Holmer (Linux registered user #16682) > "After the vintage season came the aftermath -- and Cenbe." > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: Public vs. Friend API Reloaded (Summary)
Am 23.09.18 um 19:35 schrieb Matthias Bläsing: Hi, Am Sonntag, den 23.09.2018, 19:23 +0200 schrieb Peter Nabbefeld: I think that having a reasonable documentation was traditionally one of the requirements for a public API modules. (I doubt csl.api went through the API review process.) (next sentence is meant to be sarcastic): So, if I'm too lazy to write some documentation, I get the benefit to never need to think about how to do some changes, as nobody will get the chance to use it. no - the USER of the code is to lazy to take part in the creation of documentation and stabilization of the API. Seriously - often the most vocal people do the least work and then complain, that the people doing the work don't follow their reasoning. Greetings Matthias That's not the point, and You removed important context. - 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: downloaded binaries questions
Hi, I've found this, but it's probably outdated: http://wiki.netbeans.org/DevFaqExternalLibraries Kind regards Peter Am 23.09.18 um 20:12 schrieb Glenn Holmer: Some questions about downloading external binaries at build time: 1) Where is the format of the external/*-license.txt file documented (e.g. ide/db.drivers/external/postgresql-9.4.1209-license.txt)? 2) Do I understand correctly that whether a binary is downloaded from Maven or from hg.netbeans.org (Ant property "binaries.server") depends on whether the entry in external/binaries-list can be parsed as a Maven coordinate by org.netbeans.nbbuild.extlibs.DownloadBinaries.java? - 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
downloaded binaries questions
Some questions about downloading external binaries at build time: 1) Where is the format of the external/*-license.txt file documented (e.g. ide/db.drivers/external/postgresql-9.4.1209-license.txt)? 2) Do I understand correctly that whether a binary is downloaded from Maven or from hg.netbeans.org (Ant property "binaries.server") depends on whether the entry in external/binaries-list can be parsed as a Maven coordinate by org.netbeans.nbbuild.extlibs.DownloadBinaries.java? -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." - To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Public vs. Friend API Reloaded (Summary)
Hi, Am Sonntag, den 23.09.2018, 19:23 +0200 schrieb Peter Nabbefeld: > > I think that having a reasonable documentation was traditionally > > one of the > > requirements for a public API modules. (I doubt csl.api went > > through the > > API review process.) > > > > (next sentence is meant to be sarcastic): > So, if I'm too lazy to write some documentation, I get the benefit to > never need to think about how to do some changes, as nobody will get the > chance to use it. no - the USER of the code is to lazy to take part in the creation of documentation and stabilization of the API. Seriously - often the most vocal people do the least work and then complain, that the people doing the work don't follow their reasoning. Greetings Matthias - 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 Reloaded (Summary)
On Sun, Sep 23, 2018 at 5:40 PM Peter Nabbefeld
wrote:
>
>
> Am 23.09.18 um 17:02 schrieb Jan Lahoda:
> > On Sun, Sep 23, 2018 at 3:22 PM Peter Nabbefeld
> > wrote:
> >
> >> 1) Yes, usually the API is reasonably stable in most areas after being
> >> used as a friend-only API for some releases, so if it is difficult to
> >> change, this will be a rare event. So, You'll have rarely to do many
> >> changes and can do some effort in these rare cases, if really necessary.
> >> IMHO that should be fine.
> >>
> > So, I thought one of the modules we are talking about here is csl.api,
> but
> > it turned out that *is* a public API currently (which, frankly, scares
> me a
> > little bit). So I took a look at gsf.testrunner and the last API change
> > appears to be from 2015 (according to apichanges.xml), which does not
> seem
> > to be *that* long ago.
>
> CSL and GSF are sth. I've not quite well understood:
> There's some information available how to start, but if it comes to
> details, I'm quickly lost. I'm also not sure, if these are different
>
I think that having a reasonable documentation was traditionally one of the
requirements for a public API modules. (I doubt csl.api went through the
API review process.)
> kinds of language tools or if they're building one on the top of the other.
>
> Probably that's some kind of "implied friend-only" by organization, i.e.
> the lack of information causes it not to be used, though publicly
> available.
> >
> >> 2) About Your inline comment: Well, it may happen, that functionality
> >> will be weighted more than API design. OTOH, I'd see this as an issue
> >> for a compatibility layer: Let the old API stay alive, while creating a
> >> new one. Then deprecate it, and remove the compatibility layer one or
> >> two major releases of NB later.
> >>
> > This way I'd expect modules to be stable, but also more usable by the
> >> community.
> >>
> > Given two major release may be 6 months in our current scheme, this
> sounds
> > neither particularly stable, nor particularly convenient for someone
> doing
> > the change (creating a compatibility layer is likely to have a fairly
> high
> > cost).
>
> I don't see two major NetBeans releases within 6 months, currently. But,
> depending on the size of some module, IMHO, two or three major releases
> of NetBeans should show most weaknesses of an API to stabilize it. If a
> distinct functionality does not (yet) work as expected, declare it as
> such, and make this part "private" (i.e. a friend-only module only
> accessible from the API to be made public). There're many well-designed
>
Looking at html.editor.lib (another module mentioned in this context), I
wonder if that's considered to work "as expected", or if there are parts
that should be "private". Looking at the module, I am frankly a bit lost on
where should I begin to use it. (I assume I'd add a task using parsing.api
to "text/html", and then see if the Parser.Result I get is
HtmlParsingResult, but why are there 4 more classes with ParseResult in
name?)
After thinking of this for a little, I guess the ideal approach for
changing a friend module to public API module would be if folks interested
in the given API would get together, reviewed the API, improved it as
needed (and as possible, because with 20+ friends, it may be unrealistic to
do certain changes), added documentation, etc. and proposed to make the
updated version public.
It is of course possible to simply remove the "for friends only" flag, but
that's not going to improve the API and documentation.
Jan
APIs in NetBeans, some even integrated twice or more times, just because
> they are managed like the "Holy Gral". One example may be the hinting
> system, which is differently implemented e.g. for Java and HTML. Some
> rules will have to be specified language-specific, but probably some
> parts could be unified.
>
> Regards
> Peter
>
>
> >
> > Jan
> >
> >
> >> Kind regards
> >>
> >> Peter
> >>
> >>
> >> Am 23.09.18 um 13:49 schrieb Jan Lahoda:
> >>> So, if I understand correctly, the view is a combination of c) ("it is
> OK
> >>> if doing changes to the API is difficult", like writing compatibility
> >>> layers, more elaborate migration tutorials, updating existing plugins
> >> etc.)
> >>> and b) (making an occasional incompatible change).
> >>>
> >>> I think I am fine with that, I just want to ensure the consequences are
> >>> understood. It is of course absolutely possible that a specific API
> won't
> >>> need any enhancements, and so will be fine.
> >>>
> >>> One more comment inline.
> >>>
> >>> On Sun, Sep 23, 2018 at 12:55 PM Peter Nabbefeld <
> peter.nabbef...@gmx.de
> >>>
> >>> wrote:
> >>>
> The problem here is:
>
> 1. If every API is friend-only, nobody will be able to depend on those
> without first becoming a friend. Or You have to depend on
> implementation
> version. So, these APIs will never be reviewed by the broader
> community
> and will never be ready for
Re: Future of JavaHelp (or a replacement) in NetBeans?
Jep, agree. I also tried DocBook and broke my neck on it. Did cost too much time. Too keep it simply we could go with the standard Online help but with an offline option so the help can be read if not connected. Conversion would be minimal as one "only" would need to migrate the control XML files deciding the book order (topics etc.) but most of the core text stays the same as they already are in HTML. Bernd On 9/23/2018 8:55 AM, Tim Boudreau wrote: On Sun, Sep 23, 2018 at 5:18 AM Oliver Rettig wrote: Hi Jan, this sound interesting for me. In the past I have also thought about DocBook Having written two books using DocBook, one word: Don't. Something simple and text-based, especially something you can fill the gaps in with HTML markup if you've just GOT to do something fancy, is more than enough. Markdown or one of the many cousins it has is simple and noise free. With DocBook, on the other hand, you get - A gargantuan DTD you have to pick a subset of to keep your sanity, and then police that uses stay within that subset - you don't need something that includes every subvariant of a footnote or endnote ever invented for an academic paper - Last time I dealt with it, there were no Java XML parsers that could actually handle the stylesheets - Markup that is far less suggestive of what the end result is going to look like You could do most of the structuring of help with a simple convention for naming and nestling subfolders, with a very simple markup language. DocBook for this is kind of like launching an aircraft carrier to swat a fly. -Tim . Can you share the XSLT stylesheets to get an idea how it works and how looks? There exist some ant tasks http://ant4docbook.sourceforge.net/ maybe based on we can create some default procedure to integreate help into our platform apps. At the moment I also use docuwiki to make documentation for my patform apps availble: http://upperlimb.orat.de/doku.php There is a plugin to create the tox.xml and map.xml file from java-help https://github.com/i-net-software/dokuwiki-plugin-siteexport So at the moment I create my documentation by dokuwiki ant than I create my java-help based on this. The advantage is that some custumers inclusive me can easy write together on the documentation and from time to time I update ma java-doc from this. Any ideas are welcome:-) best regards Oliver Btw, not NB related, we switched from JavaHelp to a set of static HTML pages (generated using custom XSLT stylesheets from DocBook XML source): + no internet access is required + preserving context help linking + easier styling + responsive layout - limited search capabilities (keywords processed by lucene are exported into simple text file, no complex queries can be used) That search can be hardly improved without serving HTML pages via local webserver (which was rejected by lead developers). Without webserver there are many security constraints like inability to load external content dynamically or problematic cookie/local storage management. We also publish same document to online CMS portal, here with the full search capabilities. It is available there as a set of pages with advanced navigation (outline, breadcrumbs, prev/next buttons), but also as a single PDF file (which is stil requested by many users - it can be stored as single file and printed easily). These outputs we produce again from single DocBook XML source. It is up to the user if he choose online/offline (context) help. The default option is online help. That offline variant is considered as a fallback in case of none or poor internet connection. Jan -Original Message- From: Bernd Ruehlicke Sent: Saturday, September 22, 2018 5:22 PM To: dev@netbeans.incubator.apache.org Subject: Re: Future of JavaHelp (or a replacement) in NetBeans? Uh ... my application is often used in areas without any network connection. Even though the UI is not the most beautiful in the world it is a very helpful tool and I use JavaHelp quite extensively. Of course I am in line with Time, a chance is needed but we should have the case in mind for off-line users. With JavaHelp I like that it is integrated to my application and not some website - it ships with it integrated nicely. This could of course be solve easy by simply add a Help->Update Offline Help and it simply dumps the current online help to disk for offline usage. Maybe even automatically avoiding a menu item, using the same idea as the Update Server that on startup the app is checking of the online documentation has been updated and pops up a suggestion to the user to "Want to update offline documentation", i.e. the online help
Re: Jenkins Builds
It seems this is an SSL related problem [1]. Maybe this is due to domain donation? Cheers, Antonio [1] $ curl -I -v https://hg.netbeans.org/binaries/ * Trying 137.254.60.37... * TCP_NODELAY set * Connected to hg.netbeans.org (137.254.60.37) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * Unknown SSL protocol error in connection to hg.netbeans.org:443 * Curl_http_done: called premature == 1 * stopped the pause stream! * Closing connection 0 curl: (35) Unknown SSL protocol error in connection to hg.netbeans.org:443 On 23/09/18 15:58, John McDonnell wrote: @Geertjan Wielenga Can you find out what's wrong with hg.netbeans.org/binaries please? The cloning issue is resolved for now, but the next error in the build is: Could not download 1DE46CC85D147D9F91AF59D4A0107091C8B112D6-java-cup-11a.jar from http://hg.netbeans.org/binaries/: java.io.IOException: Could not download 1DE46CC85D147D9F91AF59D4A0107091C8B112D6-java-cup-11a.jar to /home/jenkins/.hgexternalcache/1DE46CC85D147D9F91AF59D4A0107091C8B112D6-java-cup-11a.jar: java.net.SocketException: Connection reset As for the issue with NetBeans maven artifacts, It seems the existing Jenkins job was configured to use the nb-repository-plugin maven plugin to generate artifacts. I think the next steps would here be to hook that up, and point to the apache maven nexus. I used the following commands to generate these locally: $ ant build build-nbms generate-uc-catalog build-source-zips $ mvn org.codehaus.mojo:nb-repository-plugin:1.3:populate -DdeployUrl=file:///Users/john/codebase/incubator-netbeans/nbbuild/build/.m2 -DnetbeansNbmDirectory=/Users/john/codebase/incubator-netbeans/nbbuild/nbms -DnetbeansInstallDirectory=/Users/john/codebase/incubator-netbeans/nbbuild/netbeans -DnetbeansSourcesDirectory=/Users/john/codebase/incubator-netbeans/nbbuild/build/source-zips -DforcedVersion=DEV -DgroupIdPrefix=org.apache.netbeans Regards John On Sun, 23 Sep 2018 at 14:43, Peter Nabbefeld wrote: Hello, as I've read on the users list, the netbeans.org domain has been officially donated to Apache, so Maven plugins etc. should be put there, now. (Message was from Geertjan Wielenga, on Subject "[Platform] Maven artefacts". For me, question remains what will happen to NB 8.2 plugins. So, primarily I'd expect the necessary infrastructure needs to be created first. Kind regards Peter Am 23.09.18 um 15:31 schrieb John McDonnell: Hi, I was looking into the maven artifacts issue earlier and noticed the linux build has been failing[1]. Anyone any ideas before I reach out to infra? Regards John [1]: ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://github.com/apache/incubator-netbeans.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:888) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1155) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress https://github.com/apache/incubator-netbeans.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: - 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:
Re: Public vs. Friend API Reloaded (Summary)
Am 23.09.18 um 17:02 schrieb Jan Lahoda:
On Sun, Sep 23, 2018 at 3:22 PM Peter Nabbefeld
wrote:
1) Yes, usually the API is reasonably stable in most areas after being
used as a friend-only API for some releases, so if it is difficult to
change, this will be a rare event. So, You'll have rarely to do many
changes and can do some effort in these rare cases, if really necessary.
IMHO that should be fine.
So, I thought one of the modules we are talking about here is csl.api, but
it turned out that *is* a public API currently (which, frankly, scares me a
little bit). So I took a look at gsf.testrunner and the last API change
appears to be from 2015 (according to apichanges.xml), which does not seem
to be *that* long ago.
CSL and GSF are sth. I've not quite well understood:
There's some information available how to start, but if it comes to
details, I'm quickly lost. I'm also not sure, if these are different
kinds of language tools or if they're building one on the top of the other.
Probably that's some kind of "implied friend-only" by organization, i.e.
the lack of information causes it not to be used, though publicly available.
2) About Your inline comment: Well, it may happen, that functionality
will be weighted more than API design. OTOH, I'd see this as an issue
for a compatibility layer: Let the old API stay alive, while creating a
new one. Then deprecate it, and remove the compatibility layer one or
two major releases of NB later.
This way I'd expect modules to be stable, but also more usable by the
community.
Given two major release may be 6 months in our current scheme, this sounds
neither particularly stable, nor particularly convenient for someone doing
the change (creating a compatibility layer is likely to have a fairly high
cost).
I don't see two major NetBeans releases within 6 months, currently. But,
depending on the size of some module, IMHO, two or three major releases
of NetBeans should show most weaknesses of an API to stabilize it. If a
distinct functionality does not (yet) work as expected, declare it as
such, and make this part "private" (i.e. a friend-only module only
accessible from the API to be made public). There're many well-designed
APIs in NetBeans, some even integrated twice or more times, just because
they are managed like the "Holy Gral". One example may be the hinting
system, which is differently implemented e.g. for Java and HTML. Some
rules will have to be specified language-specific, but probably some
parts could be unified.
Regards
Peter
Jan
Kind regards
Peter
Am 23.09.18 um 13:49 schrieb Jan Lahoda:
So, if I understand correctly, the view is a combination of c) ("it is OK
if doing changes to the API is difficult", like writing compatibility
layers, more elaborate migration tutorials, updating existing plugins
etc.)
and b) (making an occasional incompatible change).
I think I am fine with that, I just want to ensure the consequences are
understood. It is of course absolutely possible that a specific API won't
need any enhancements, and so will be fine.
One more comment inline.
On Sun, Sep 23, 2018 at 12:55 PM Peter Nabbefeld
The problem here is:
1. If every API is friend-only, nobody will be able to depend on those
without first becoming a friend. Or You have to depend on implementation
version. So, these APIs will never be reviewed by the broader community
and will never be ready for usage.
2. If the API is public, You may break other implementors plugins.
You'll usually never do that to just annoy them, but because You've got
some serious problem without changing it. As a result, the API should
become more stable, more usable, and of better quality in general.
Not sure about this: when an API is not designed to be enhancible
compatibly, and is not sufficient (i.e. needs to be enhanced), I suspect
preference will be given to making the change compatibly, even at the
cost
of making the API less nice. So, over time, the API will probably be more
complete, but possibly less clean.
Thanks,
Jan
Probably, for the time the major version of NB doesn't change, there
should be a compatibility layer, if possible.
3. If the API changes, there needs of course to be a migration tutorial,
which must be upgraded if there are still any questions around about how
to upgrade the plugin.
4. Plugin developers are: plugin developers, so it should not be a big
issue for them to update their dependent module, if there's a tutorial.
5. As sometimes developers loose interest in further maintaining their
plugin, there should be the source available somewhere, so other
developers could take care of those. Ideally, the plugins should also be
licensed under AL2.0, so they could be supplied in some Apache contrib
repository.
So, IMHO modules should be friend-only for a maximum of 2 or 3 releases.
After this, I'd expect them to be reasonable stable to make them public,
so the community could experiment with those and probably
Re: Public vs. Friend API Reloaded (Summary)
On Sun, Sep 23, 2018 at 3:22 PM Peter Nabbefeld
wrote:
> 1) Yes, usually the API is reasonably stable in most areas after being
> used as a friend-only API for some releases, so if it is difficult to
> change, this will be a rare event. So, You'll have rarely to do many
> changes and can do some effort in these rare cases, if really necessary.
> IMHO that should be fine.
>
So, I thought one of the modules we are talking about here is csl.api, but
it turned out that *is* a public API currently (which, frankly, scares me a
little bit). So I took a look at gsf.testrunner and the last API change
appears to be from 2015 (according to apichanges.xml), which does not seem
to be *that* long ago.
>
> 2) About Your inline comment: Well, it may happen, that functionality
> will be weighted more than API design. OTOH, I'd see this as an issue
> for a compatibility layer: Let the old API stay alive, while creating a
> new one. Then deprecate it, and remove the compatibility layer one or
> two major releases of NB later.
>
This way I'd expect modules to be stable, but also more usable by the
> community.
>
Given two major release may be 6 months in our current scheme, this sounds
neither particularly stable, nor particularly convenient for someone doing
the change (creating a compatibility layer is likely to have a fairly high
cost).
Jan
>
> Kind regards
>
> Peter
>
>
> Am 23.09.18 um 13:49 schrieb Jan Lahoda:
> > So, if I understand correctly, the view is a combination of c) ("it is OK
> > if doing changes to the API is difficult", like writing compatibility
> > layers, more elaborate migration tutorials, updating existing plugins
> etc.)
> > and b) (making an occasional incompatible change).
> >
> > I think I am fine with that, I just want to ensure the consequences are
> > understood. It is of course absolutely possible that a specific API won't
> > need any enhancements, and so will be fine.
> >
> > One more comment inline.
> >
> > On Sun, Sep 23, 2018 at 12:55 PM Peter Nabbefeld >
> > wrote:
> >
> >> The problem here is:
> >>
> >> 1. If every API is friend-only, nobody will be able to depend on those
> >> without first becoming a friend. Or You have to depend on implementation
> >> version. So, these APIs will never be reviewed by the broader community
> >> and will never be ready for usage.
> >>
> >
> >> 2. If the API is public, You may break other implementors plugins.
> >> You'll usually never do that to just annoy them, but because You've got
> >> some serious problem without changing it. As a result, the API should
> >> become more stable, more usable, and of better quality in general.
> >>
> > Not sure about this: when an API is not designed to be enhancible
> > compatibly, and is not sufficient (i.e. needs to be enhanced), I suspect
> > preference will be given to making the change compatibly, even at the
> cost
> > of making the API less nice. So, over time, the API will probably be more
> > complete, but possibly less clean.
> >
> > Thanks,
> > Jan
> >
> > Probably, for the time the major version of NB doesn't change, there
> >> should be a compatibility layer, if possible.
> >>
> >> 3. If the API changes, there needs of course to be a migration tutorial,
> >> which must be upgraded if there are still any questions around about how
> >> to upgrade the plugin.
> >>
> >> 4. Plugin developers are: plugin developers, so it should not be a big
> >> issue for them to update their dependent module, if there's a tutorial.
> >>
> >> 5. As sometimes developers loose interest in further maintaining their
> >> plugin, there should be the source available somewhere, so other
> >> developers could take care of those. Ideally, the plugins should also be
> >> licensed under AL2.0, so they could be supplied in some Apache contrib
> >> repository.
> >>
> >> So, IMHO modules should be friend-only for a maximum of 2 or 3 releases.
> >> After this, I'd expect them to be reasonable stable to make them public,
> >> so the community could experiment with those and probably make proposals
> >> for a better API. If the API changes then, most developers depending on
> >> the module will even be happy about the new possibilities. But they
> >> should also tell, if some change may make their usage of the module
> >> impossible, of course, so the problems could be considered early.
> >>
> >> Kind regards
> >>
> >> Peter
> >>
> >>
> >>
> >> Am 23.09.18 um 12:04 schrieb Jan Lahoda:
> >>> On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz <
> christian.l...@gmx.net>
> >>> wrote:
> >>>
> Hey guys,
>
> please see my last 3 comments of this ticket. It explains, why it is
> important to have public APIs instead of Friends:
>
> >>
> https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
>
> >>> My personal opinion only.
> >>>
> >>> I think noone doubts the a public API is better for plugins.
Re: Jenkins Builds
@Geertjan Wielenga Can you find out what's wrong with hg.netbeans.org/binaries please? The cloning issue is resolved for now, but the next error in the build is: Could not download 1DE46CC85D147D9F91AF59D4A0107091C8B112D6-java-cup-11a.jar from http://hg.netbeans.org/binaries/: java.io.IOException: Could not download 1DE46CC85D147D9F91AF59D4A0107091C8B112D6-java-cup-11a.jar to /home/jenkins/.hgexternalcache/1DE46CC85D147D9F91AF59D4A0107091C8B112D6-java-cup-11a.jar: java.net.SocketException: Connection reset As for the issue with NetBeans maven artifacts, It seems the existing Jenkins job was configured to use the nb-repository-plugin maven plugin to generate artifacts. I think the next steps would here be to hook that up, and point to the apache maven nexus. I used the following commands to generate these locally: $ ant build build-nbms generate-uc-catalog build-source-zips $ mvn org.codehaus.mojo:nb-repository-plugin:1.3:populate -DdeployUrl=file:///Users/john/codebase/incubator-netbeans/nbbuild/build/.m2 -DnetbeansNbmDirectory=/Users/john/codebase/incubator-netbeans/nbbuild/nbms -DnetbeansInstallDirectory=/Users/john/codebase/incubator-netbeans/nbbuild/netbeans -DnetbeansSourcesDirectory=/Users/john/codebase/incubator-netbeans/nbbuild/build/source-zips -DforcedVersion=DEV -DgroupIdPrefix=org.apache.netbeans Regards John On Sun, 23 Sep 2018 at 14:43, Peter Nabbefeld wrote: > Hello, > > as I've read on the users list, the netbeans.org domain has been > officially donated to Apache, so Maven plugins etc. should be put there, > now. (Message was from Geertjan Wielenga, on Subject "[Platform] Maven > artefacts". For me, question remains what will happen to NB 8.2 plugins. > > So, primarily I'd expect the necessary infrastructure needs to be > created first. > > Kind regards > > Peter > > > Am 23.09.18 um 15:31 schrieb John McDonnell: > > Hi, > > > > I was looking into the maven artifacts issue earlier and noticed the > linux > > build has been failing[1]. > > > > Anyone any ideas before I reach out to infra? > > > > Regards > > > > John > > > > [1]: ERROR: Error fetching remote repo 'origin' > > hudson.plugins.git.GitException: Failed to fetch from > > https://github.com/apache/incubator-netbeans.git > > at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:888) > > at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1155) > > at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186) > > at hudson.scm.SCM.checkout(SCM.java:504) > > at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) > > at > hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) > > at > jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) > > at > hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) > > at hudson.model.Run.execute(Run.java:1794) > > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) > > at > hudson.model.ResourceController.execute(ResourceController.java:97) > > at hudson.model.Executor.run(Executor.java:429) > > Caused by: hudson.plugins.git.GitException: Command "git fetch --tags > > --progress https://github.com/apache/incubator-netbeans.git > > +refs/heads/*:refs/remotes/origin/*" returned status code 128: > > > > > - > 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: Jenkins Builds
Hello, as I've read on the users list, the netbeans.org domain has been officially donated to Apache, so Maven plugins etc. should be put there, now. (Message was from Geertjan Wielenga, on Subject "[Platform] Maven artefacts". For me, question remains what will happen to NB 8.2 plugins. So, primarily I'd expect the necessary infrastructure needs to be created first. Kind regards Peter Am 23.09.18 um 15:31 schrieb John McDonnell: Hi, I was looking into the maven artifacts issue earlier and noticed the linux build has been failing[1]. Anyone any ideas before I reach out to infra? Regards John [1]: ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://github.com/apache/incubator-netbeans.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:888) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1155) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1794) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress https://github.com/apache/incubator-netbeans.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: - 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 Reloaded (Summary)
1) Yes, usually the API is reasonably stable in most areas after being
used as a friend-only API for some releases, so if it is difficult to
change, this will be a rare event. So, You'll have rarely to do many
changes and can do some effort in these rare cases, if really necessary.
IMHO that should be fine.
2) About Your inline comment: Well, it may happen, that functionality
will be weighted more than API design. OTOH, I'd see this as an issue
for a compatibility layer: Let the old API stay alive, while creating a
new one. Then deprecate it, and remove the compatibility layer one or
two major releases of NB later.
This way I'd expect modules to be stable, but also more usable by the
community.
Kind regards
Peter
Am 23.09.18 um 13:49 schrieb Jan Lahoda:
So, if I understand correctly, the view is a combination of c) ("it is OK
if doing changes to the API is difficult", like writing compatibility
layers, more elaborate migration tutorials, updating existing plugins etc.)
and b) (making an occasional incompatible change).
I think I am fine with that, I just want to ensure the consequences are
understood. It is of course absolutely possible that a specific API won't
need any enhancements, and so will be fine.
One more comment inline.
On Sun, Sep 23, 2018 at 12:55 PM Peter Nabbefeld
wrote:
The problem here is:
1. If every API is friend-only, nobody will be able to depend on those
without first becoming a friend. Or You have to depend on implementation
version. So, these APIs will never be reviewed by the broader community
and will never be ready for usage.
2. If the API is public, You may break other implementors plugins.
You'll usually never do that to just annoy them, but because You've got
some serious problem without changing it. As a result, the API should
become more stable, more usable, and of better quality in general.
Not sure about this: when an API is not designed to be enhancible
compatibly, and is not sufficient (i.e. needs to be enhanced), I suspect
preference will be given to making the change compatibly, even at the cost
of making the API less nice. So, over time, the API will probably be more
complete, but possibly less clean.
Thanks,
Jan
Probably, for the time the major version of NB doesn't change, there
should be a compatibility layer, if possible.
3. If the API changes, there needs of course to be a migration tutorial,
which must be upgraded if there are still any questions around about how
to upgrade the plugin.
4. Plugin developers are: plugin developers, so it should not be a big
issue for them to update their dependent module, if there's a tutorial.
5. As sometimes developers loose interest in further maintaining their
plugin, there should be the source available somewhere, so other
developers could take care of those. Ideally, the plugins should also be
licensed under AL2.0, so they could be supplied in some Apache contrib
repository.
So, IMHO modules should be friend-only for a maximum of 2 or 3 releases.
After this, I'd expect them to be reasonable stable to make them public,
so the community could experiment with those and probably make proposals
for a better API. If the API changes then, most developers depending on
the module will even be happy about the new possibilities. But they
should also tell, if some change may make their usage of the module
impossible, of course, so the problems could be considered early.
Kind regards
Peter
Am 23.09.18 um 12:04 schrieb Jan Lahoda:
On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz
wrote:
Hey guys,
please see my last 3 comments of this ticket. It explains, why it is
important to have public APIs instead of Friends:
https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
My personal opinion only.
I think noone doubts the a public API is better for plugins. However, I
think that it is necessary that at least one of the following is true:
a) someone signs up to make a proper public API, that we will be able to
enhance compatibly
b) we accept that there are smaller or bigger incompatible API changes
(size of the incompatible change depends on the nature of the change and
of
the existing API)
c) we accept that some changes to the API will be very difficult to do
(compatibly), maybe even so difficult that they won't be made (so
difficult
that noone will sign up to do the change)
So, I wonder what are the views of others on these.
Thanks,
Jan
The Thing is, no one know, what other nice Plugins will come in the
future, but everytime, someone creates a Plugin which Needs to be
friend,
depends on only the next release that someone adds it. That means, that
this Plugin will first work only for the next release, if someone
decided
to add this Plugin as a friend. Same happens for every other Plugins
that
Comes later.
It is not that everytime a user want to use the newest
Re: Public vs. Friend API Reloaded (Summary)
So, if I understand correctly, the view is a combination of c) ("it is OK
if doing changes to the API is difficult", like writing compatibility
layers, more elaborate migration tutorials, updating existing plugins etc.)
and b) (making an occasional incompatible change).
I think I am fine with that, I just want to ensure the consequences are
understood. It is of course absolutely possible that a specific API won't
need any enhancements, and so will be fine.
One more comment inline.
On Sun, Sep 23, 2018 at 12:55 PM Peter Nabbefeld
wrote:
> The problem here is:
>
> 1. If every API is friend-only, nobody will be able to depend on those
> without first becoming a friend. Or You have to depend on implementation
> version. So, these APIs will never be reviewed by the broader community
> and will never be ready for usage.
>
> 2. If the API is public, You may break other implementors plugins.
> You'll usually never do that to just annoy them, but because You've got
> some serious problem without changing it. As a result, the API should
> become more stable, more usable, and of better quality in general.
>
Not sure about this: when an API is not designed to be enhancible
compatibly, and is not sufficient (i.e. needs to be enhanced), I suspect
preference will be given to making the change compatibly, even at the cost
of making the API less nice. So, over time, the API will probably be more
complete, but possibly less clean.
Thanks,
Jan
Probably, for the time the major version of NB doesn't change, there
> should be a compatibility layer, if possible.
>
> 3. If the API changes, there needs of course to be a migration tutorial,
> which must be upgraded if there are still any questions around about how
> to upgrade the plugin.
>
> 4. Plugin developers are: plugin developers, so it should not be a big
> issue for them to update their dependent module, if there's a tutorial.
>
> 5. As sometimes developers loose interest in further maintaining their
> plugin, there should be the source available somewhere, so other
> developers could take care of those. Ideally, the plugins should also be
> licensed under AL2.0, so they could be supplied in some Apache contrib
> repository.
>
> So, IMHO modules should be friend-only for a maximum of 2 or 3 releases.
> After this, I'd expect them to be reasonable stable to make them public,
> so the community could experiment with those and probably make proposals
> for a better API. If the API changes then, most developers depending on
> the module will even be happy about the new possibilities. But they
> should also tell, if some change may make their usage of the module
> impossible, of course, so the problems could be considered early.
>
> Kind regards
>
> Peter
>
>
>
> Am 23.09.18 um 12:04 schrieb Jan Lahoda:
> > On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz
> > wrote:
> >
> >> Hey guys,
> >>
> >> please see my last 3 comments of this ticket. It explains, why it is
> >> important to have public APIs instead of Friends:
> >>
> https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
> >>
> >>
> > My personal opinion only.
> >
> > I think noone doubts the a public API is better for plugins. However, I
> > think that it is necessary that at least one of the following is true:
> > a) someone signs up to make a proper public API, that we will be able to
> > enhance compatibly
> > b) we accept that there are smaller or bigger incompatible API changes
> > (size of the incompatible change depends on the nature of the change and
> of
> > the existing API)
> > c) we accept that some changes to the API will be very difficult to do
> > (compatibly), maybe even so difficult that they won't be made (so
> difficult
> > that noone will sign up to do the change)
> >
> > So, I wonder what are the views of others on these.
> >
> > Thanks,
> > Jan
> >
> >
> >> The Thing is, no one know, what other nice Plugins will come in the
> >> future, but everytime, someone creates a Plugin which Needs to be
> friend,
> >> depends on only the next release that someone adds it. That means, that
> >> this Plugin will first work only for the next release, if someone
> decided
> >> to add this Plugin as a friend. Same happens for every other Plugins
> that
> >> Comes later.
> >>
> >> It is not that everytime a user want to use the newest IDE, often
> someone
> >> stays at the IDE if there is Nothing really new for him/her to Change
> >> update. That means, that he/she could miss the Plugin, if it is relevant
> >> for him. In this release.
> >>
> >> And what happens, if someone removes the Plugin as a friend? That
> happens
> >> for Geertjans KendoUI Plugin. The Plugin worked some versions before,
> not
> >> now anymore, because it was removed from being a friend.
> >>
> >> Making APIs public makes much more sense for 3rd-party Plugin
> developers.
> >> I think HTML, JS, CSS, C/C++ PHP and
Re: Public vs. Friend API Reloaded (Summary)
The problem here is:
1. If every API is friend-only, nobody will be able to depend on those
without first becoming a friend. Or You have to depend on implementation
version. So, these APIs will never be reviewed by the broader community
and will never be ready for usage.
2. If the API is public, You may break other implementors plugins.
You'll usually never do that to just annoy them, but because You've got
some serious problem without changing it. As a result, the API should
become more stable, more usable, and of better quality in general.
Probably, for the time the major version of NB doesn't change, there
should be a compatibility layer, if possible.
3. If the API changes, there needs of course to be a migration tutorial,
which must be upgraded if there are still any questions around about how
to upgrade the plugin.
4. Plugin developers are: plugin developers, so it should not be a big
issue for them to update their dependent module, if there's a tutorial.
5. As sometimes developers loose interest in further maintaining their
plugin, there should be the source available somewhere, so other
developers could take care of those. Ideally, the plugins should also be
licensed under AL2.0, so they could be supplied in some Apache contrib
repository.
So, IMHO modules should be friend-only for a maximum of 2 or 3 releases.
After this, I'd expect them to be reasonable stable to make them public,
so the community could experiment with those and probably make proposals
for a better API. If the API changes then, most developers depending on
the module will even be happy about the new possibilities. But they
should also tell, if some change may make their usage of the module
impossible, of course, so the problems could be considered early.
Kind regards
Peter
Am 23.09.18 um 12:04 schrieb Jan Lahoda:
On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz
wrote:
Hey guys,
please see my last 3 comments of this ticket. It explains, why it is
important to have public APIs instead of Friends:
https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
My personal opinion only.
I think noone doubts the a public API is better for plugins. However, I
think that it is necessary that at least one of the following is true:
a) someone signs up to make a proper public API, that we will be able to
enhance compatibly
b) we accept that there are smaller or bigger incompatible API changes
(size of the incompatible change depends on the nature of the change and of
the existing API)
c) we accept that some changes to the API will be very difficult to do
(compatibly), maybe even so difficult that they won't be made (so difficult
that noone will sign up to do the change)
So, I wonder what are the views of others on these.
Thanks,
Jan
The Thing is, no one know, what other nice Plugins will come in the
future, but everytime, someone creates a Plugin which Needs to be friend,
depends on only the next release that someone adds it. That means, that
this Plugin will first work only for the next release, if someone decided
to add this Plugin as a friend. Same happens for every other Plugins that
Comes later.
It is not that everytime a user want to use the newest IDE, often someone
stays at the IDE if there is Nothing really new for him/her to Change
update. That means, that he/she could miss the Plugin, if it is relevant
for him. In this release.
And what happens, if someone removes the Plugin as a friend? That happens
for Geertjans KendoUI Plugin. The Plugin worked some versions before, not
now anymore, because it was removed from being a friend.
Making APIs public makes much more sense for 3rd-party Plugin developers.
I think HTML, JS, CSS, C/C++ PHP and whatever is there is stable enough for
years to say: yes, make them public. And will there some exceptions, that
the devs figure out, someone can fix it Maybe as a patch or for the next
release, which is acceptable.
Cheers
Chris
Von: Laszlo Kishalmi
Gesendet: Sonntag, 23. September 2018 04:45
An: dev@netbeans.incubator.apache.org
Betreff: Re: Public vs. Friend API Reloaded (Summary)
Hi all,
This list is what we have inside the current codebase (Without Yenta on
other locations.)
I put those here which have 10+ friend marked. (The complete list is
attached)
Upon this list it could be a good choice to try make the following public
(maybe for NetBeans 10):
• gsf.testrunner
• gsf.testrunner.ui
I know that a few external language plugins are using those as well, and
the API is quite a good shape anyway.
What do you think?
Generated using: find . -name project.xml -exec grep -H -c friend\> {}
\;|sort -r -gt : -k 2 |grep -v :0
./ide/dlight.nativeexecution/nbproject/project.xml:147
./ide/dlight.nativeexecution.nb/nbproject/project.xml:145
./ide/web.common/nbproject/project.xml:68
./ide/gsf.testrunner/nbproject/project.xml:40
Re: Public vs. Friend API Reloaded (Summary)
On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz
wrote:
> Hey guys,
>
> please see my last 3 comments of this ticket. It explains, why it is
> important to have public APIs instead of Friends:
> https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
>
>
My personal opinion only.
I think noone doubts the a public API is better for plugins. However, I
think that it is necessary that at least one of the following is true:
a) someone signs up to make a proper public API, that we will be able to
enhance compatibly
b) we accept that there are smaller or bigger incompatible API changes
(size of the incompatible change depends on the nature of the change and of
the existing API)
c) we accept that some changes to the API will be very difficult to do
(compatibly), maybe even so difficult that they won't be made (so difficult
that noone will sign up to do the change)
So, I wonder what are the views of others on these.
Thanks,
Jan
> The Thing is, no one know, what other nice Plugins will come in the
> future, but everytime, someone creates a Plugin which Needs to be friend,
> depends on only the next release that someone adds it. That means, that
> this Plugin will first work only for the next release, if someone decided
> to add this Plugin as a friend. Same happens for every other Plugins that
> Comes later.
>
> It is not that everytime a user want to use the newest IDE, often someone
> stays at the IDE if there is Nothing really new for him/her to Change
> update. That means, that he/she could miss the Plugin, if it is relevant
> for him. In this release.
>
> And what happens, if someone removes the Plugin as a friend? That happens
> for Geertjans KendoUI Plugin. The Plugin worked some versions before, not
> now anymore, because it was removed from being a friend.
>
> Making APIs public makes much more sense for 3rd-party Plugin developers.
> I think HTML, JS, CSS, C/C++ PHP and whatever is there is stable enough for
> years to say: yes, make them public. And will there some exceptions, that
> the devs figure out, someone can fix it Maybe as a patch or for the next
> release, which is acceptable.
>
>
> Cheers
>
> Chris
>
>
>
> Von: Laszlo Kishalmi
> Gesendet: Sonntag, 23. September 2018 04:45
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Public vs. Friend API Reloaded (Summary)
>
> Hi all,
> This list is what we have inside the current codebase (Without Yenta on
> other locations.)
> I put those here which have 10+ friend marked. (The complete list is
> attached)
> Upon this list it could be a good choice to try make the following public
> (maybe for NetBeans 10):
> • gsf.testrunner
> • gsf.testrunner.ui
> I know that a few external language plugins are using those as well, and
> the API is quite a good shape anyway.
> What do you think?
> Generated using: find . -name project.xml -exec grep -H -c friend\> {}
> \;|sort -r -gt : -k 2 |grep -v :0
> ./ide/dlight.nativeexecution/nbproject/project.xml:147
> ./ide/dlight.nativeexecution.nb/nbproject/project.xml:145
> ./ide/web.common/nbproject/project.xml:68
> ./ide/gsf.testrunner/nbproject/project.xml:40
> ./php/php.api.phpmodule/nbproject/project.xml:39
> ./java/java.api.common/nbproject/project.xml:39
> ./ide/options.editor/nbproject/project.xml:39
> ./java/maven/nbproject/project.xml:37
> ./enterprise/j2ee.common/nbproject/project.xml:34
> ./profiler/profiler.api/nbproject/project.xml:32
> ./profiler/lib.profiler/nbproject/project.xml:32
> ./java/maven.embedder/nbproject/project.xml:31
> ./webcommon/web.clientproject.api/nbproject/project.xml:29
> ./profiler/lib.profiler.common/nbproject/project.xml:29
> ./ide/gsf.testrunner.ui/nbproject/project.xml:28
> ./php/php.api.executable/nbproject/project.xml:27
> ./ide/html.editor.lib/nbproject/project.xml:26
> ./enterprise/j2ee.api.ejbmodule/nbproject/project.xml:25
> ./ide/web.browser.api/nbproject/project.xml:24
> ./ide/lib.terminalemulator/nbproject/project.xml:24
> ./profiler/lib.profiler.ui/nbproject/project.xml:23
> ./java/maven.model/nbproject/project.xml:23
> ./java/j2ee.core.utilities/nbproject/project.xml:23
> ./enterprise/websvc.jaxwsmodel/nbproject/project.xml:23
> ./ide/team.commons/nbproject/project.xml:22
> ./ide/html.editor/nbproject/project.xml:22
> ./profiler/profiler/nbproject/project.xml:21
> ./platform/libs.jna/nbproject/project.xml:21
> ./php/php.api.editor/nbproject/project.xml:21
> ./java/java.preprocessorbridge/nbproject/project.xml:20
> ./ide/web.common.ui/nbproject/project.xml:20
> ./ide/terminal/nbproject/project.xml:20
> ./ide/terminal.nb/nbproject/project.xml:20
> ./java/j2ee.persistenceapi/nbproject/project.xml:19
> ./enterprise/javaee.specs.support/nbproject/project.xml:19
> ./webcommon/javascript2.lexer/nbproject/project.xml:17
> ./ide/xml.multiview/nbproject/project.xml:17
> ./ide/versioning.util/nbproject/project.xml:17
>
Re: Future of JavaHelp (or a replacement) in NetBeans?
Hi Jan, this sound interesting for me. In the past I have also thought about DocBook. Can you share the XSLT stylesheets to get an idea how it works and how looks? There exist some ant tasks http://ant4docbook.sourceforge.net/ maybe based on we can create some default procedure to integreate help into our platform apps. At the moment I also use docuwiki to make documentation for my patform apps availble: http://upperlimb.orat.de/doku.php There is a plugin to create the tox.xml and map.xml file from java-help https://github.com/i-net-software/dokuwiki-plugin-siteexport So at the moment I create my documentation by dokuwiki ant than I create my java-help based on this. The advantage is that some custumers inclusive me can easy write together on the documentation and from time to time I update ma java-doc from this. Any ideas are welcome:-) best regards Oliver > Btw, not NB related, we switched from JavaHelp to a set of static HTML pages > (generated using custom XSLT stylesheets from DocBook XML source): + no > internet access is required > + preserving context help linking > + easier styling > + responsive layout > - limited search capabilities (keywords processed by lucene are exported > into simple text file, no complex queries can be used) > > That search can be hardly improved without serving HTML pages via local > webserver (which was rejected by lead developers). Without webserver there > are many security constraints like inability to load external content > dynamically or problematic cookie/local storage management. > > We also publish same document to online CMS portal, here with the full > search capabilities. It is available there as a set of pages with advanced > navigation (outline, breadcrumbs, prev/next buttons), but also as a single > PDF file (which is stil requested by many users - it can be stored as > single file and printed easily). These outputs we produce again from single > DocBook XML source. > > It is up to the user if he choose online/offline (context) help. The default > option is online help. That offline variant is considered as a fallback in > case of none or poor internet connection. > > Jan > > > -Original Message- > > From: Bernd Ruehlicke > > Sent: Saturday, September 22, 2018 5:22 PM > > To: dev@netbeans.incubator.apache.org > > Subject: Re: Future of JavaHelp (or a replacement) in NetBeans? > > > > Uh ... my application is often used in areas without any network > > connection. Even though the UI is not the most beautiful in the world it > > is a very helpful tool and I use JavaHelp quite extensively. Of course I > > am in line with Time, a chance is needed but we should have the case in > > mind for off-line users. With JavaHelp I like that it is integrated to > > my application and not some website - it ships with it integrated > > nicely. This could of course be solve easy by simply add a Help->Update > > Offline Help and it simply dumps the current online help to disk for > > offline usage. Maybe even automatically avoiding a menu item, using the > > same idea as the Update Server that on startup the app is checking of > > the online documentation has been updated and pops up a suggestion to > > the user to "Want to update offline documentation", i.e. the online help
Re: Needed: Release Manager for Apache NetBeans 10
Until we put together the official new feature page on netbeans.apache.org, this is where we're gathering all the features -- so, if anyone has had their pull requests merged, and if those pull requests result in some kind of enhancement that is going to be noticeable by a user, please consider briefly documenting your enhancement here is the last step of your process: https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+10 Gj On Sun, Sep 23, 2018 at 11:04 AM, Geertjan Wielenga < geertjan.wiele...@googlemail.com> wrote: > > Hi Laszlo, > > Fantastic list of items and you clearly are going to be a great release > manager. > > One related item is that, or as a reminder, is that there'll be one or > more voting candidates that you'll be putting together, which we could call > Alpha, Beta, etc, but in Apache terminology will be voting candidate 1, > voting candidate 2, etc. > > The first of these that you put together will be used by the NetCAT > community, assuming we continue with the NetCAT approach, and assuming is > approved by NetCAT, will then go to a vote on the Apache NetBeans developer > mailing list, after which it will go to the IPMC vote (i.e., the incubator > PMC). > > If a vote fails on any of these levels, we'll need to fix an issue or > something else, and then you'll create another voting candidate. > > Whichever voting candidate passes all votes will be the newly released > Apache NetBeans 10. > > Note that we have all of October for the above process: > > https://cwiki.apache.org/confluence/display/NETBEANS/ > Apache+NetBeans+Release+Roadmap > > Hope that what I'm doing here is simply reiterating what we all already > know to be true, i.e., there's nothing controversial or new in this mail, > just restating the process as we know it to be. > > Gj > > > On Sun, Sep 23, 2018 at 7:43 AM, Laszlo Kishalmi < > laszlo.kisha...@gmail.com> wrote: > >> Hi Geertjan, >> >> First, my timezone is Pacific time. I've read through the docs. It seems >> I'm going to have a bit more task, than before, but I guess the first time >> was the hardest one. >> >>1. After we finalize the scope, merge whatever PR is out to be >>merged, we need to create a release branch, then it needs to be cleansed >>from those parts which were not ready to be delivered. >>2. On the binaries we need to decide whether shall we create binary >>release flavors like PHP, Java SE or if it got ready in time Jakarta EE >>3. We need to create a feature (New and Noteworthy) page >>4. In JIRA we need a new version (or two versions for 10.0 an 11.0). >>BTW I do not know if the 9.0 has been marked as closed. Do we have a JIRA >>admin guy or we need to requests these modifications? >>5. Once the code is shaping up on release branch, creating tags, >>binaries and signatures are ok. >>6. There will be some voting >>7. We need to put 9.0 version in the archives. >>8. I also try for a real snap for Linux release this time, I'm not >>that far from that. >> >> Have I missed any major important thing? >> >> P.S.: I'm planning to formulate the release process as a JIRA task with >> detailed bite sized sub-tasks, so it can be tracked, and probably cloned >> for further releases. >> >> >> >> >> On 09/22/2018 02:02 AM, Geertjan Wielenga wrote: >> >> Hi Laszlo, >> >> The things that are involved in managing the release are described in >> "Producing a Release Candidate" below: >> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+Release+README >> >> It would be good to go through that and see where you anticipate problems >> and just get an overview of what you'll be doing. >> >> Gj >> >> On Sat, Sep 22, 2018 at 9:52 AM, Geertjan Wielenga >> wrote: >> >> >> And what's your timezone? People working on Apache NetBeans come from all >> timezones, I believe. >> >> Thanks, >> >> Gj >> >> On Sat, Sep 22, 2018 at 8:57 AM, Geertjan Wielenga >> wrote: >> >> >> Awesome! >> >> Gj >> >> On Sat, Sep 22, 2018 at 1:44 AM, Laszlo Kishalmi >> wrote: >> >> >> I volunteer this time. >> >> I hope timezone shift won't be an issue. >> >> >> >> On 09/21/2018 12:41 AM, Geertjan Wielenga wrote: >> >> >> Some potential candidates for this role, i.e., which is pretty >> impressive, >> the fact that we have this many who could IMHO already do this from a >> perspective of insight, though the main problem in most/each cases is >> probably time: >> >> - Antonio Vieiro >> - Sven Reimers >> - Matthias Bläsing >> - Junichi Yamamoto >> - Eric Barboni >> - Neil C. Smith >> - Thilina Ranathunga >> - Laszlo Kishalmi >> - John McDonnell >> - Wade Chandler >> >> There may be more and I apologize for omitting anyone else who has been >> involved for some time, committed quite a bit in one way or another, and >> has shown IMHO the technical interest needed for this. >> >> Any volunteers from the above, or someone else -- I am sure you'll be >> supported a lot by Emilian, who was the previous
AW: AW: Ticket, Sub-Tasks and PRs
Hey Lazlo, thx for your Suggestion. Yeah it makes sense to me too. Cheers Chris Von: Laszlo Kishalmi Gesendet: Samstag, 22. September 2018 01:24 An: dev@netbeans.incubator.apache.org Betreff: Re: AW: Ticket, Sub-Tasks and PRs I'd create two separate stories linked together. These two improvements stands on their own and probably small enough to implement. Of course they are more powerful if delivered together, but we could deliver them independently bringing some value to the platform, and often bite sized stories are the best. On 09/20/2018 07:59 AM, Christian Lenz wrote: > Any suggestions to this Topic? I read the Guidelines for that: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74681408 but > no proposals for Sub-tasks. > > Ok here is my proposal, I think it depends on the feature but if you have an > amount of small Sub Tasks it could be separate commits for each Sub Task in > one PR. If you have a lot of work, it would make much more sense to have one > PR for each Sub Task. > > In my Situation, of Course both are 2 new Features/improvements, which could > be 2 separate stories but both are a bit connected to each other, because I > want to use a shortcut to open the Thing and type into a search field. > > Do you have any other suggestions for that? I’m also fine to split my ticket > into 2 tickets instead of having 2 sub Tasks of 1 ticket. > > > Cheers > > Chris > > > > Von: Christian Lenz > Gesendet: Dienstag, 18. September 2018 14:25 > An: dev@netbeans.incubator.apache.org > Betreff: Ticket, Sub-Tasks and PRs > > Dear Devs, > > I created a new ticket, for a new feature, which I want to implement: > https://issues.apache.org/jira/browse/NETBEANS-1262 > > This ticket Needs 2 implementations. One Action to create a shortcut (One > Sub-Task) and create a new searchfield to filter the list inside the Show > opened documents list popup (Second Sub-Task). > > First I want to know, whether it is correct to create for each Little > feature, which depends on the Overall feature, a sub ticket or not and second > how should I handle the PR? Should I create a new branch (In my fork or > directly in the incubator repo?) for each Sub ticket or a PR for the Ticket > itself and not for the Sub Tasks? > > > Cheers > > Chris > > - 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: Future of JavaHelp (or a replacement) in NetBeans?
Hi, I have used JavaHelp consequently in my platform apps for the last 10 years with all its disadavantages but it fulfills my main needs. So it was ok. And the best thing was it works and I have not to think about this. Now it is not available any more and I think we should better think about a substitution instead of bringing it back. I would prefer a solution with the following points included: - xml based - possibilty to create pdfs - online/offline integration - html-based view (we can use a integrated browser in our platform apps) - netbeans modules should include help-page, so that if we update a module the corresponding help-pages are updated. best regards Oliver > I've been thinking for at least a decade and a half that javahelp needs to > die. It's basically a clone of the Windows 3.1 help system. Evidence was, > last I knew, that it was rarely used by real users. > > Online help would, IMHO, be fine in this era. > > -Tim > > On Tue, Sep 18, 2018 at 6:15 AM Peter Nabbefeld > > wrote: > > Hello, > > > > as JavaHelp is currently GPL and its UI is outdated: > > What will happen to user documentation? > > > > While JavaHelp might be licensed under AL2, it still suffers from UI > > support. > > > > What about some JavaHelp 3.0 (which probably needs a new name), building > > on Lucene but with a replaceable GUI (probably based on Servo renderer)? > > > > Just an idea ... > > > > 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
Re: Needed: Release Manager for Apache NetBeans 10
Hi Laszlo, Fantastic list of items and you clearly are going to be a great release manager. One related item is that, or as a reminder, is that there'll be one or more voting candidates that you'll be putting together, which we could call Alpha, Beta, etc, but in Apache terminology will be voting candidate 1, voting candidate 2, etc. The first of these that you put together will be used by the NetCAT community, assuming we continue with the NetCAT approach, and assuming is approved by NetCAT, will then go to a vote on the Apache NetBeans developer mailing list, after which it will go to the IPMC vote (i.e., the incubator PMC). If a vote fails on any of these levels, we'll need to fix an issue or something else, and then you'll create another voting candidate. Whichever voting candidate passes all votes will be the newly released Apache NetBeans 10. Note that we have all of October for the above process: https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+Release+Roadmap Hope that what I'm doing here is simply reiterating what we all already know to be true, i.e., there's nothing controversial or new in this mail, just restating the process as we know it to be. Gj On Sun, Sep 23, 2018 at 7:43 AM, Laszlo Kishalmi wrote: > Hi Geertjan, > > First, my timezone is Pacific time. I've read through the docs. It seems > I'm going to have a bit more task, than before, but I guess the first time > was the hardest one. > >1. After we finalize the scope, merge whatever PR is out to be merged, >we need to create a release branch, then it needs to be cleansed from those >parts which were not ready to be delivered. >2. On the binaries we need to decide whether shall we create binary >release flavors like PHP, Java SE or if it got ready in time Jakarta EE >3. We need to create a feature (New and Noteworthy) page >4. In JIRA we need a new version (or two versions for 10.0 an 11.0). >BTW I do not know if the 9.0 has been marked as closed. Do we have a JIRA >admin guy or we need to requests these modifications? >5. Once the code is shaping up on release branch, creating tags, >binaries and signatures are ok. >6. There will be some voting >7. We need to put 9.0 version in the archives. >8. I also try for a real snap for Linux release this time, I'm not >that far from that. > > Have I missed any major important thing? > > P.S.: I'm planning to formulate the release process as a JIRA task with > detailed bite sized sub-tasks, so it can be tracked, and probably cloned > for further releases. > > > > > On 09/22/2018 02:02 AM, Geertjan Wielenga wrote: > > Hi Laszlo, > > The things that are involved in managing the release are described in > "Producing a Release Candidate" below: > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+Release+README > > It would be good to go through that and see where you anticipate problems > and just get an overview of what you'll be doing. > > Gj > > On Sat, Sep 22, 2018 at 9:52 AM, Geertjan Wielenga > wrote: > > > And what's your timezone? People working on Apache NetBeans come from all > timezones, I believe. > > Thanks, > > Gj > > On Sat, Sep 22, 2018 at 8:57 AM, Geertjan Wielenga > wrote: > > > Awesome! > > Gj > > On Sat, Sep 22, 2018 at 1:44 AM, Laszlo Kishalmi > wrote: > > > I volunteer this time. > > I hope timezone shift won't be an issue. > > > > On 09/21/2018 12:41 AM, Geertjan Wielenga wrote: > > > Some potential candidates for this role, i.e., which is pretty > impressive, > the fact that we have this many who could IMHO already do this from a > perspective of insight, though the main problem in most/each cases is > probably time: > > - Antonio Vieiro > - Sven Reimers > - Matthias Bläsing > - Junichi Yamamoto > - Eric Barboni > - Neil C. Smith > - Thilina Ranathunga > - Laszlo Kishalmi > - John McDonnell > - Wade Chandler > > There may be more and I apologize for omitting anyone else who has been > involved for some time, committed quite a bit in one way or another, and > has shown IMHO the technical interest needed for this. > > Any volunteers from the above, or someone else -- I am sure you'll be > supported a lot by Emilian, who was the previous release manager, as > well > as myself and the rest of the community of course. > > Thanks, > > Gj > > > On Thu, Sep 20, 2018 at 8:36 AM, Geertjan Wielenga > wrote: > > Hi all, > > Following our roadmap... > https://cwiki.apache.org/confluence/display/NETBEANS/ > Apache+NetBeans+Release+Roadmap > > ...we are approaching feature freeze. > > A release manager is needed, Emilian did a fantastic job in the Apache > NetBeans 9 release, and I am sure he can provide support and advice as > needed. > > Several indicated interest in this role the last time we discussed > this, > e.g., here: > https://lists.apache.org/thread.html/fc7d4a9d71c595f964a0e0ed102b3b25305d3d2dd77135853cedb70e@%3Cdev.netbeans.apache.org%3E > > The release manager
AW: Public vs. Friend API Reloaded (Summary)
Hey guys,
please see my last 3 comments of this ticket. It explains, why it is important
to have public APIs instead of Friends:
https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478
The Thing is, no one know, what other nice Plugins will come in the future, but
everytime, someone creates a Plugin which Needs to be friend, depends on only
the next release that someone adds it. That means, that this Plugin will first
work only for the next release, if someone decided to add this Plugin as a
friend. Same happens for every other Plugins that Comes later.
It is not that everytime a user want to use the newest IDE, often someone stays
at the IDE if there is Nothing really new for him/her to Change update. That
means, that he/she could miss the Plugin, if it is relevant for him. In this
release.
And what happens, if someone removes the Plugin as a friend? That happens for
Geertjans KendoUI Plugin. The Plugin worked some versions before, not now
anymore, because it was removed from being a friend.
Making APIs public makes much more sense for 3rd-party Plugin developers. I
think HTML, JS, CSS, C/C++ PHP and whatever is there is stable enough for years
to say: yes, make them public. And will there some exceptions, that the devs
figure out, someone can fix it Maybe as a patch or for the next release, which
is acceptable.
Cheers
Chris
Von: Laszlo Kishalmi
Gesendet: Sonntag, 23. September 2018 04:45
An: dev@netbeans.incubator.apache.org
Betreff: Re: Public vs. Friend API Reloaded (Summary)
Hi all,
This list is what we have inside the current codebase (Without Yenta on other
locations.)
I put those here which have 10+ friend marked. (The complete list is attached)
Upon this list it could be a good choice to try make the following public
(maybe for NetBeans 10):
• gsf.testrunner
• gsf.testrunner.ui
I know that a few external language plugins are using those as well, and the
API is quite a good shape anyway.
What do you think?
Generated using: find . -name project.xml -exec grep -H -c friend\> {} \;|sort
-r -gt : -k 2 |grep -v :0
./ide/dlight.nativeexecution/nbproject/project.xml:147
./ide/dlight.nativeexecution.nb/nbproject/project.xml:145
./ide/web.common/nbproject/project.xml:68
./ide/gsf.testrunner/nbproject/project.xml:40
./php/php.api.phpmodule/nbproject/project.xml:39
./java/java.api.common/nbproject/project.xml:39
./ide/options.editor/nbproject/project.xml:39
./java/maven/nbproject/project.xml:37
./enterprise/j2ee.common/nbproject/project.xml:34
./profiler/profiler.api/nbproject/project.xml:32
./profiler/lib.profiler/nbproject/project.xml:32
./java/maven.embedder/nbproject/project.xml:31
./webcommon/web.clientproject.api/nbproject/project.xml:29
./profiler/lib.profiler.common/nbproject/project.xml:29
./ide/gsf.testrunner.ui/nbproject/project.xml:28
./php/php.api.executable/nbproject/project.xml:27
./ide/html.editor.lib/nbproject/project.xml:26
./enterprise/j2ee.api.ejbmodule/nbproject/project.xml:25
./ide/web.browser.api/nbproject/project.xml:24
./ide/lib.terminalemulator/nbproject/project.xml:24
./profiler/lib.profiler.ui/nbproject/project.xml:23
./java/maven.model/nbproject/project.xml:23
./java/j2ee.core.utilities/nbproject/project.xml:23
./enterprise/websvc.jaxwsmodel/nbproject/project.xml:23
./ide/team.commons/nbproject/project.xml:22
./ide/html.editor/nbproject/project.xml:22
./profiler/profiler/nbproject/project.xml:21
./platform/libs.jna/nbproject/project.xml:21
./php/php.api.editor/nbproject/project.xml:21
./java/java.preprocessorbridge/nbproject/project.xml:20
./ide/web.common.ui/nbproject/project.xml:20
./ide/terminal/nbproject/project.xml:20
./ide/terminal.nb/nbproject/project.xml:20
./java/j2ee.persistenceapi/nbproject/project.xml:19
./enterprise/javaee.specs.support/nbproject/project.xml:19
./webcommon/javascript2.lexer/nbproject/project.xml:17
./ide/xml.multiview/nbproject/project.xml:17
./ide/versioning.util/nbproject/project.xml:17
./ide/code.analysis/nbproject/project.xml:17
./php/php.api.framework/nbproject/project.xml:16
./ide/xml.text/nbproject/project.xml:16
./ide/versioning.core/nbproject/project.xml:16
./webcommon/javascript2.types/nbproject/project.xml:15
./platform/core.startup.base/nbproject/project.xml:15
./ide/editor.settings.storage/nbproject/project.xml:15
./enterprise/websvc.clientapi/nbproject/project.xml:15
./enterprise/web.project/nbproject/project.xml:15
./websvccommon/websvc.jaxwsmodelapi/nbproject/project.xml:14
./webcommon/javascript2.editor/nbproject/project.xml:14
./platform/core.startup/nbproject/project.xml:14
./java/j2ee.persistence/nbproject/project.xml:14
./ide/xml.axi/nbproject/project.xml:14
./enterprise/websvc.jaxwsapi/nbproject/project.xml:14
./websvccommon/websvc.saas.api/nbproject/project.xml:13
./java/whitelist/nbproject/project.xml:13
./enterprise/websvc.core/nbproject/project.xml:13
Re: Needed: Release Manager for Apache NetBeans 10
> 4. In JIRA we need a new version (or two versions for 10.0 an 11.0). > BTW I do not know if the 9.0 has been marked as closed. Do we have a > JIRA admin guy or we need to requests these modifications? I've "released 9.0" on JIRA and created a 10.0 version now. Regards John On Sun, 23 Sep 2018 at 07:53, Antonio wrote: > Hi Laszlo, > > For "3. We need to create a feature page" we also want to update the > site-wide banners and the main page slider. Also the footer should point > to NetBeans 10. > > I may help with what. Last time I submitted a PR against the > incubator-netbeans-website that had to be slightly modified in the last > minute (after the official announcement, I think) to include proper > checksums in the web page. > > This webpage thing is a bit of a chicken-egg problem, the announcement > should include a link to the download page, but the download page has to > have a link to the official announcement. I imagine we have to think > which is first: if the chicken or the egg :-D > > Cheers, > Antonio > > > On 23/09/18 07:43, Laszlo Kishalmi wrote: > > Hi Geertjan, > > > > First, my timezone is Pacific time. I've read through the docs. It seems > > I'm going to have a bit more task, than before, but I guess the first > > time was the hardest one. > > > > 1. After we finalize the scope, merge whatever PR is out to be merged, > > we need to create a release branch, then it needs to be cleansed > > from those parts which were not ready to be delivered. > > 2. On the binaries we need to decide whether shall we create binary > > release flavors like PHP, Java SE or if it got ready in time Jakarta > EE > > 3. We need to create a feature (New and Noteworthy) page > > 4. In JIRA we need a new version (or two versions for 10.0 an 11.0). > > BTW I do not know if the 9.0 has been marked as closed. Do we have a > > JIRA admin guy or we need to requests these modifications? > > 5. Once the code is shaping up on release branch, creating tags, > > binaries and signatures are ok. > > 6. There will be some voting > > 7. We need to put 9.0 version in the archives. > > 8. I also try for a real snap for Linux release this time, I'm not that > > far from that. > > > > Have I missed any major important thing? > > > > P.S.: I'm planning to formulate the release process as a JIRA task with > > detailed bite sized sub-tasks, so it can be tracked, and probably cloned > > for further releases. > > > > > > > > > > On 09/22/2018 02:02 AM, Geertjan Wielenga wrote: > >> Hi Laszlo, > >> > >> The things that are involved in managing the release are described in > >> "Producing a Release Candidate" below: > >> > >> > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+Release+README > >> > >> > >> It would be good to go through that and see where you anticipate > problems > >> and just get an overview of what you'll be doing. > >> > >> Gj > >> > >> On Sat, Sep 22, 2018 at 9:52 AM, Geertjan Wielenga < > >> geertjan.wiele...@googlemail.com> wrote: > >> > >>> And what's your timezone? People working on Apache NetBeans come from > >>> all > >>> timezones, I believe. > >>> > >>> Thanks, > >>> > >>> Gj > >>> > >>> On Sat, Sep 22, 2018 at 8:57 AM, Geertjan Wielenga < > >>> geertjan.wiele...@googlemail.com> wrote: > >>> > Awesome! > > Gj > > On Sat, Sep 22, 2018 at 1:44 AM, Laszlo Kishalmi < > laszlo.kisha...@gmail.com> wrote: > > > I volunteer this time. > > > > I hope timezone shift won't be an issue. > > > > > > > > On 09/21/2018 12:41 AM, Geertjan Wielenga wrote: > > > >> Some potential candidates for this role, i.e., which is pretty > >> impressive, > >> the fact that we have this many who could IMHO already do this from > a > >> perspective of insight, though the main problem in most/each cases > is > >> probably time: > >> > >> - Antonio Vieiro > >> - Sven Reimers > >> - Matthias Bläsing > >> - Junichi Yamamoto > >> - Eric Barboni > >> - Neil C. Smith > >> - Thilina Ranathunga > >> - Laszlo Kishalmi > >> - John McDonnell > >> - Wade Chandler > >> > >> There may be more and I apologize for omitting anyone else who has > >> been > >> involved for some time, committed quite a bit in one way or > >> another, and > >> has shown IMHO the technical interest needed for this. > >> > >> Any volunteers from the above, or someone else -- I am sure you'll > be > >> supported a lot by Emilian, who was the previous release manager, as > >> well > >> as myself and the rest of the community of course. > >> > >> Thanks, > >> > >> Gj > >> > >> > >> On Thu, Sep 20, 2018 at 8:36 AM, Geertjan Wielenga < > >> geertjan.wiele...@googlemail.com> wrote: > >> > >> Hi all, > >>> Following our roadmap... > >>> > >>> https://cwiki.apache.org/confluence/display/NETBEANS/ >
Re: [mentors] + PPMC, Apache Maturity Model self-assessment and graduation
+1 to Geertjan words. I am particulary concerned about: "CD30 The code can be built in a reproducible way using widely available standard tools." We of course can build NetBeans using "widely available standard tools" (Apache Ant). But I am not sure the build is reproducible if the binaries required to build cannot be downloaded from hg.netbeans.org/binaries. For an example see this thread [1] from yesterday. We have made an effort to download binaries from elsewhere after the first donation, mainly maven repositories, but I think we're not fully independent of hg.netbeans.org as of yet. There's work to do here, IMHO. Cheers, Antonio [1] http://mail-archives.apache.org/mod_mbox/netbeans-dev/201809.mbox/%3Cd1cefd04-0be6-1ed9-301a-8a6ba8afb2ed%40kolabnow.com%3E On 22/09/18 14:44, Geertjan Wielenga wrote: It's good to hear these positive signals from the Apache NetBeans mentors, many thanks. It is truly a reflection as well of the support that the mentors and the Apache infrastructure as a whole have given Apache NetBeans -- and, bear in mind, all of it for free. Really, unbelievable, when you think about it. I think it would be best to wait until we have done/figured out the following, in no particular order: 1. all our domains (netbeans.org, planetnetbeans.org, etc) running via Apache infrastructure: https://issues.apache.org/jira/browse/INFRA-16946 2. all documentation, i.e., tutorials, etc, moved onto Apache infrastructure (coming with 3rd donation, in progress) 3. a clear direction for the location of plugins.netbeans.org 4. NetBeans javadoc running on Apache infrastructure: https://issues.apache.org/jira/browse/NETBEANS-1176 5. a solution to the installer question -- i.e., once we figure out how to create installers for all operating systems, figure out how they can be distributed I.e., I don't see how NetBeans can be a top level Apache project while the above items have not yet been resolved for one reason or another. The message we'd be sending is that Apache NetBeans provides significantly less services to its users than Oracle/Sun NetBeans did. Gj On Fri, Sep 21, 2018 at 8:12 AM, Mark Struberg wrote: +1, community is big enough and self government works reasonably well. The best part is that lots of people already developed a sense about what might potentially be not ok for the ASF. LieGrue,strub On Thursday, 20 September 2018, 11:43:46 CEST, Bertrand Delacretaz < bdelacre...@apache.org> wrote: Hi Netbeans mentors + PPMC. I feel that NetBeans is getting ready to graduate, and would welcome other opinions on this (either here or on the private@ list if really needed), especially from mentors. I think there are more donations upcoming but as the NetBeans PPMC has demonstrated it knows how to handle those I don't think they are an obstacle to graduating, also as the trademarks transfer is complete or about to be completed. For the PPMC, one useful step towards that is creating a self-assessment based on https://community.apache.org/apache-way/apache-project-maturity-model.html . The "How To Use" sections links to examples. Could someone from the PPMC take the lead on that? This can happen in parallel with graduation discussions. -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 - 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: Needed: Release Manager for Apache NetBeans 10
Hi Laszlo, For "3. We need to create a feature page" we also want to update the site-wide banners and the main page slider. Also the footer should point to NetBeans 10. I may help with what. Last time I submitted a PR against the incubator-netbeans-website that had to be slightly modified in the last minute (after the official announcement, I think) to include proper checksums in the web page. This webpage thing is a bit of a chicken-egg problem, the announcement should include a link to the download page, but the download page has to have a link to the official announcement. I imagine we have to think which is first: if the chicken or the egg :-D Cheers, Antonio On 23/09/18 07:43, Laszlo Kishalmi wrote: Hi Geertjan, First, my timezone is Pacific time. I've read through the docs. It seems I'm going to have a bit more task, than before, but I guess the first time was the hardest one. 1. After we finalize the scope, merge whatever PR is out to be merged, we need to create a release branch, then it needs to be cleansed from those parts which were not ready to be delivered. 2. On the binaries we need to decide whether shall we create binary release flavors like PHP, Java SE or if it got ready in time Jakarta EE 3. We need to create a feature (New and Noteworthy) page 4. In JIRA we need a new version (or two versions for 10.0 an 11.0). BTW I do not know if the 9.0 has been marked as closed. Do we have a JIRA admin guy or we need to requests these modifications? 5. Once the code is shaping up on release branch, creating tags, binaries and signatures are ok. 6. There will be some voting 7. We need to put 9.0 version in the archives. 8. I also try for a real snap for Linux release this time, I'm not that far from that. Have I missed any major important thing? P.S.: I'm planning to formulate the release process as a JIRA task with detailed bite sized sub-tasks, so it can be tracked, and probably cloned for further releases. On 09/22/2018 02:02 AM, Geertjan Wielenga wrote: Hi Laszlo, The things that are involved in managing the release are described in "Producing a Release Candidate" below: https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+Release+README It would be good to go through that and see where you anticipate problems and just get an overview of what you'll be doing. Gj On Sat, Sep 22, 2018 at 9:52 AM, Geertjan Wielenga < geertjan.wiele...@googlemail.com> wrote: And what's your timezone? People working on Apache NetBeans come from all timezones, I believe. Thanks, Gj On Sat, Sep 22, 2018 at 8:57 AM, Geertjan Wielenga < geertjan.wiele...@googlemail.com> wrote: Awesome! Gj On Sat, Sep 22, 2018 at 1:44 AM, Laszlo Kishalmi < laszlo.kisha...@gmail.com> wrote: I volunteer this time. I hope timezone shift won't be an issue. On 09/21/2018 12:41 AM, Geertjan Wielenga wrote: Some potential candidates for this role, i.e., which is pretty impressive, the fact that we have this many who could IMHO already do this from a perspective of insight, though the main problem in most/each cases is probably time: - Antonio Vieiro - Sven Reimers - Matthias Bläsing - Junichi Yamamoto - Eric Barboni - Neil C. Smith - Thilina Ranathunga - Laszlo Kishalmi - John McDonnell - Wade Chandler There may be more and I apologize for omitting anyone else who has been involved for some time, committed quite a bit in one way or another, and has shown IMHO the technical interest needed for this. Any volunteers from the above, or someone else -- I am sure you'll be supported a lot by Emilian, who was the previous release manager, as well as myself and the rest of the community of course. Thanks, Gj On Thu, Sep 20, 2018 at 8:36 AM, Geertjan Wielenga < geertjan.wiele...@googlemail.com> wrote: Hi all, Following our roadmap... https://cwiki.apache.org/confluence/display/NETBEANS/ Apache+NetBeans+Release+Roadmap ...we are approaching feature freeze. A release manager is needed, Emilian did a fantastic job in the Apache NetBeans 9 release, and I am sure he can provide support and advice as needed. Several indicated interest in this role the last time we discussed this, e.g., here: https://lists.apache.org/thread.html/fc7d4a9d71c595f964a0e0ed102b3b 25305d3d2dd77135853cedb70e@%3Cdev.netbeans.apache.org%3E The release manager needs to branch off the release on Sep 30 and not let any features in after that, only bug fixes. Right now, the integration with JDK 11 and PHP looks solid, Java EE, JavaScript, Groovy, would all be great to include -- but people need to step forward fast now to make that happen otherwise that will be shifted to the next release, early next year, while all those features will of course be available as is from the 8.2 Plugin Portal. Hopefully we could then have Apache NetBeans 10 Vote Candidate 1 or 2 ready for Oracle Code One as a beta or preview release, with the final release during November.
