Re: Proposed blog on malware report
Hi Sally, We propose putting the below on the Apache NetBeans blog re the GitHub malware report on the inactive malware campaign. To everyone else — Sally is VP Marketing and Publicity at Apache. Thanks, and thanks Eric for your rewrite of the text. Gj On Sun, 31 May 2020 at 22:39, Erik Costlow wrote: > If making any comment at all, I would rewrite. If there were a > vulnerability or the attack was large, I'm sure the GitHub team would have > gotten in touch. The key themes are: > > 1. The attack was small, isolated, and is over > 2. Most builds do not leverage anything netbeans-specific, such as this > ant build (I guessed at 2006) > 3. Software supply chain risk is legitimate and if action were needed > or is needed in the future, something would happen > > Researchers at GitHub have identified 26 projects on GitHub that have been > infected by malware. The initial point of infection is undetermined and all > activity with the malware has been shut down. The malware relied on > projects created using an older customized ant-based build system that has > been in limited use since 2006. This does not impact users of other build > systems like Maven or Gradle, or even most ant users. The majority of > NetBeans projects leverage native build tool integrations that is shared > with continuous integration systems. > With over 44 million repositories hosted on GitHub[2], the scope of these > 26 projects looks isolated and does not significantly impact the NetBeans > community. > Software Supply Chain attacks are not unique to any IDE and the NetBeans > contributor team will monitor the threat landscape to keep developers safe > and aware. > > [1] > https://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain > [2] > https://www.zdnet.com/article/github-tops-40-million-developers-as-python-data-science-machine-learning-popularity-surges/ > > > "Researchers at GitHub have identified 26 projects on GitHub that have been > infected by malware. The malware infiltrates the project structure of > Ant-based applications in the format generated specifically by NetBeans. > The owners of the 26 projects, which are mostly small Java applications, > have been contacted and the infected projects have been set to private on > GitHub. The malware campaign is no longer active, GitHub did not consider > it relevant enough to be in touch with the NetBeans community about it, and > there is no evidence that applications beyond the 26 in question have been > impacted. Be aware that any project structure that you use when developing > applications can be infiltrated by malware and make sure that the files you > check into your versioning system are your own or that you know where they > come from and what they do." > > > > From: Neil C Smith > Sent: Sunday, May 31, 2020 1:51 PM > To: dev > Subject: Re: Proposed blog on malware report > > On Sun, 31 May 2020, 18:08 Geertjan Wielenga, wrote: > > > Be aware that any project structure that you use when developing > > applications can be infiltrated by malware and make sure that the files > you > > check into your versioning system are your own or that you know where > they > > come from and what they do." > > > > > > Feedback welcome and needed. > > > > Looks good to me, but I'd be tempted to emphasise "when developing > applications, with any IDE or build system, ..." And also that you should > treat building untrusted code the same way you'd treat running untrusted > binaries, ie. carefully. > > Interesting that the GitHub article doesn't mention that this applies to > projects that were originally structured with Ant in NetBeans. You wouldn't > have to still be building in the IDE to be exploited here? > > Best wishes, > > Neil > > > >
Re: Default license header in generated files confuses students (was: Re: The time has come to bd farewell to the license header)
My proposal is to create a checkbox in settings (and per project too) with enabling license headers. It can be disabled by default and if you want license headers (because you know what you are doing) you can easily enable it in settings. Tomas On Mon, Jun 1, 2020 at 7:35 AM Jan Lahoda wrote: > Just a few comments: > -we could have a hint (lightbulb) allowing to easily open global or > project-specific configuration > -if we keep the text, we probably want to tweak it to speak about > per-project configuration (i.e. besides the global configuration, projects > can have their own configuration) > > Jan > > > On Sun, May 31, 2020 at 7:42 PM Matthias Bläsing < > mblaes...@doppel-helix.eu> > wrote: > > > Hi, > > > > Am Sonntag, den 31.05.2020, 17:24 + schrieb Eirik Bakke: > > > I believe the proposal here is merely to make the template empty by > > > default--people who want a default license header (to e.g. the Apache > > > license) can still use the feature, but must customize the template > > > first, like they always had to before. > > > > yes, but then you have to discover it first. The template as is, allows > > you with minimal fuss to: > > > > - remove the header > > - adjust it to your liking > > > > for minimal learning (if you want to call reading simple instructions > > learning). > > > > I bet, that if we remove the message someone will come up and complain, > > that the feature is missing or badly discoverable. > > > > > But I think this is a bigger issue for beginners, who will likely > > > just leave the defaults in, out of fear of breaking anything. When > > > you're trying to teach students how to write a for loop, all the > > > magic incantations at the beginning of a Java file are just > > > distractions. > > > > Sorry - I hear that very often: > > > > - programming students are not willing to read > > - programming students can't customize their working environment > > - programming students can't be expected to read documentation > > - programming students are stupid > > > > I think this cuts it way short. Remember: Programmars/Developers are > > normally paid good money and yes, my baseline assumption is, that > > people in this area of work can be expected to know their work domain > > and their tools. I also believe people are more intelligent that we > > thing, at least if we make them use their brain (i.e. give them > > incentives to solve problems themselves). In the years after initial > > training/learning contant change will be the norm and people not being > > able to learn might be better of learning this fact early on. > > > > Just my thoughts though > > > > Greetings > > > > Matthias, who thinks, that NetBeans problems are in other areas > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > >
Re: Default license header in generated files confuses students (was: Re: The time has come to bd farewell to the license header)
Just a few comments: -we could have a hint (lightbulb) allowing to easily open global or project-specific configuration -if we keep the text, we probably want to tweak it to speak about per-project configuration (i.e. besides the global configuration, projects can have their own configuration) Jan On Sun, May 31, 2020 at 7:42 PM Matthias Bläsing wrote: > Hi, > > Am Sonntag, den 31.05.2020, 17:24 + schrieb Eirik Bakke: > > I believe the proposal here is merely to make the template empty by > > default--people who want a default license header (to e.g. the Apache > > license) can still use the feature, but must customize the template > > first, like they always had to before. > > yes, but then you have to discover it first. The template as is, allows > you with minimal fuss to: > > - remove the header > - adjust it to your liking > > for minimal learning (if you want to call reading simple instructions > learning). > > I bet, that if we remove the message someone will come up and complain, > that the feature is missing or badly discoverable. > > > But I think this is a bigger issue for beginners, who will likely > > just leave the defaults in, out of fear of breaking anything. When > > you're trying to teach students how to write a for loop, all the > > magic incantations at the beginning of a Java file are just > > distractions. > > Sorry - I hear that very often: > > - programming students are not willing to read > - programming students can't customize their working environment > - programming students can't be expected to read documentation > - programming students are stupid > > I think this cuts it way short. Remember: Programmars/Developers are > normally paid good money and yes, my baseline assumption is, that > people in this area of work can be expected to know their work domain > and their tools. I also believe people are more intelligent that we > thing, at least if we make them use their brain (i.e. give them > incentives to solve problems themselves). In the years after initial > training/learning contant change will be the norm and people not being > able to learn might be better of learning this fact early on. > > Just my thoughts though > > Greetings > > Matthias, who thinks, that NetBeans problems are in other areas > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: Proposed blog on malware report
+1 on a prompt response Josh Juneau juneau...@gmail.com http://jj-blogger.blogspot.com https://www.apress.com/us/search?query=Juneau >> On May 31, 2020, at 4:28 PM, Glenn Holmer wrote: > On 5/31/20 3:39 PM, Erik Costlow wrote: >> If making any comment at all, I would rewrite. > > The most important thing is to get something out there and strike while > the iron's hot. This "story" has even hit Slashdot: > > https://news.slashdot.org/story/20/05/30/2031219/github-warns-java-developers-of-new-malware-poisoning-netbeans-projects > > -- > Glenn Holmer (Linux registered user #16682) > "After the vintage season came the aftermath -- and Cenbe." > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Proposed blog on malware report
On 5/31/20 3:39 PM, Erik Costlow wrote: > If making any comment at all, I would rewrite. The most important thing is to get something out there and strike while the iron's hot. This "story" has even hit Slashdot: https://news.slashdot.org/story/20/05/30/2031219/github-warns-java-developers-of-new-malware-poisoning-netbeans-projects -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Proposed blog on malware report
If making any comment at all, I would rewrite. If there were a vulnerability or the attack was large, I'm sure the GitHub team would have gotten in touch. The key themes are: 1. The attack was small, isolated, and is over 2. Most builds do not leverage anything netbeans-specific, such as this ant build (I guessed at 2006) 3. Software supply chain risk is legitimate and if action were needed or is needed in the future, something would happen Researchers at GitHub have identified 26 projects on GitHub that have been infected by malware. The initial point of infection is undetermined and all activity with the malware has been shut down. The malware relied on projects created using an older customized ant-based build system that has been in limited use since 2006. This does not impact users of other build systems like Maven or Gradle, or even most ant users. The majority of NetBeans projects leverage native build tool integrations that is shared with continuous integration systems. With over 44 million repositories hosted on GitHub[2], the scope of these 26 projects looks isolated and does not significantly impact the NetBeans community. Software Supply Chain attacks are not unique to any IDE and the NetBeans contributor team will monitor the threat landscape to keep developers safe and aware. [1] https://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain [2] https://www.zdnet.com/article/github-tops-40-million-developers-as-python-data-science-machine-learning-popularity-surges/ "Researchers at GitHub have identified 26 projects on GitHub that have been infected by malware. The malware infiltrates the project structure of Ant-based applications in the format generated specifically by NetBeans. The owners of the 26 projects, which are mostly small Java applications, have been contacted and the infected projects have been set to private on GitHub. The malware campaign is no longer active, GitHub did not consider it relevant enough to be in touch with the NetBeans community about it, and there is no evidence that applications beyond the 26 in question have been impacted. Be aware that any project structure that you use when developing applications can be infiltrated by malware and make sure that the files you check into your versioning system are your own or that you know where they come from and what they do." From: Neil C Smith Sent: Sunday, May 31, 2020 1:51 PM To: dev Subject: Re: Proposed blog on malware report On Sun, 31 May 2020, 18:08 Geertjan Wielenga, wrote: > Be aware that any project structure that you use when developing > applications can be infiltrated by malware and make sure that the files you > check into your versioning system are your own or that you know where they > come from and what they do." > > > Feedback welcome and needed. > Looks good to me, but I'd be tempted to emphasise "when developing applications, with any IDE or build system, ..." And also that you should treat building untrusted code the same way you'd treat running untrusted binaries, ie. carefully. Interesting that the GitHub article doesn't mention that this applies to projects that were originally structured with Ant in NetBeans. You wouldn't have to still be building in the IDE to be exploited here? Best wishes, Neil >
Re: [VOTE] Release Apache NetBeans 12.0 [vote candidate 1]
+1 (binding) - Cleaned up $HOME/.cache/netbeans/12* and $HOME/.netbeans/12* - Checked PGP/SHA512 of source and bin files. - Ran rat report, looks fine. - Built with: - openjdk full version "1.8.0_232-b09" - Apache Ant(TM) version 1.10.7 compiled on September 1 2019 - on 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux - Ran with Openjdk8, nbjavac installed correctly. - FlatLaf Dark looks fine on Debian 10 - Opened a few gradle projects, fine. - Installed the jVI plugin (well, of course): runs smoothly. NOTE: Didn't test the Maven artifacts themselves, although I explored the generated repo, looks fine to me (jar and nbm files have licenses). Tested some nbm with md5 and pgp signatures, and these are ok. Congratulation and thanks, all. Special thanks to our release manager Eric Barboni for a superb job. Kind regards, Antonio P.S.: The options dialog want to show up randomly after "apply". This is a known bug, AFAIK. El 31/5/20 a las 14:13, Eric Barboni escribió: Dear community, This is our first voting candidate for the 12.0 LTS release of Apache NetBeans. Note that this is our first release vote where you are required to check both sources and convenience binaries before voting! See requirements below. Apache NetBeans 12.0 constitutes all clusters in the Apache NetBeans Git repo, which together provide the NetBeans Platform (i.e., the underlying application framework), as well as all the modules that provide the Java SE, Java EE, PHP, JavaScript and Groovy features of Apache NetBeans. Build artefacts are available here: https://dist.apache.org/repos/dist/dev/netbeans/netbeans/12.0/vc1 https://dist.apache.org/repos/dist/dev/netbeans/netbeans-platform/12.0/vc1 They were built by the Jenkins pipeline and moved to their place: https://builds.apache.org/view/M-R/view/NetBeans/job/netbeans-TLP/job/netbea ns/job/release120/23 We are primarily voting on: https://dist.apache.org/repos/dist/dev/netbeans/netbeans/12.0/vc1/netbeans-1 2.0-source.zip SHA512: f172579f4d1e5bef3631c974d232c193e40739c40dc4f6d3d0f9b746d6c7fdb90b871b327487 f39bade66840650e0d594970066ae4e0625d75d4584ecb6c1a70 ./netbeans-12.0-source.zip KEYS file: https://downloads.apache.org/netbeans/KEYS -- Associated to the primary source item you will have (generated with pipeline mentioned above) *under https://dist.apache.org/repos/dist/dev/netbeans/netbeans/12.0/vc1 binaries associated to the source netbeans-12.0-bin.zip as well as update content under nbms folder *under https://dist.apache.org/repos/dist/dev/netbeans/netbeans-platform/12.0/vc1 you will find platform cluster build netbeans-platform-12.0-bin netbeans-platform-12.0-source Associated Apache Maven artefacts RELEASE120 can be found at https://repository.apache.org/content/repositories/orgapachenetbeans-1058 Artefacts are composed of jars,nbm,sources,javadocs,pom. - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: Default license header in generated files confuses students (was: Re: The time has come to bd farewell to the license header)
> yes, but then you have to discover it first This is true--but of all the features in the NetBeans IDE, why would this one warrant special advertising, every single time a new file is added? Imagine if every option came with a "Did you know you could change this option?" message... Moreover, the users who actually need the feature are advanced enough to find it. Not a big deal, but a valid usability concern was raised, by someone who uses NetBeans in an educational setting, and who observes hundreds of students using it. This kind of feedback is valuable, and should at least not be discouraged. -- Eirik -Original Message- From: Matthias Bläsing Sent: Sunday, May 31, 2020 1:42 PM To: dev@netbeans.apache.org Subject: Re: Default license header in generated files confuses students (was: Re: The time has come to bd farewell to the license header) Hi, Am Sonntag, den 31.05.2020, 17:24 + schrieb Eirik Bakke: > I believe the proposal here is merely to make the template empty by > default--people who want a default license header (to e.g. the Apache > license) can still use the feature, but must customize the template > first, like they always had to before. yes, but then you have to discover it first. The template as is, allows you with minimal fuss to: - remove the header - adjust it to your liking for minimal learning (if you want to call reading simple instructions learning). I bet, that if we remove the message someone will come up and complain, that the feature is missing or badly discoverable. > But I think this is a bigger issue for beginners, who will likely just > leave the defaults in, out of fear of breaking anything. When you're > trying to teach students how to write a for loop, all the magic > incantations at the beginning of a Java file are just distractions. Sorry - I hear that very often: - programming students are not willing to read - programming students can't customize their working environment - programming students can't be expected to read documentation - programming students are stupid I think this cuts it way short. Remember: Programmars/Developers are normally paid good money and yes, my baseline assumption is, that people in this area of work can be expected to know their work domain and their tools. I also believe people are more intelligent that we thing, at least if we make them use their brain (i.e. give them incentives to solve problems themselves). In the years after initial training/learning contant change will be the norm and people not being able to learn might be better of learning this fact early on. Just my thoughts though Greetings Matthias, who thinks, that NetBeans problems are in other areas - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Proposed blog on malware report
On Sun, 31 May 2020, 18:08 Geertjan Wielenga, wrote: > Be aware that any project structure that you use when developing > applications can be infiltrated by malware and make sure that the files you > check into your versioning system are your own or that you know where they > come from and what they do." > > > Feedback welcome and needed. > Looks good to me, but I'd be tempted to emphasise "when developing applications, with any IDE or build system, ..." And also that you should treat building untrusted code the same way you'd treat running untrusted binaries, ie. carefully. Interesting that the GitHub article doesn't mention that this applies to projects that were originally structured with Ant in NetBeans. You wouldn't have to still be building in the IDE to be exploited here? Best wishes, Neil >
Re: Default license header in generated files confuses students (was: Re: The time has come to bd farewell to the license header)
Hi, Am Sonntag, den 31.05.2020, 17:24 + schrieb Eirik Bakke: > I believe the proposal here is merely to make the template empty by > default--people who want a default license header (to e.g. the Apache > license) can still use the feature, but must customize the template > first, like they always had to before. yes, but then you have to discover it first. The template as is, allows you with minimal fuss to: - remove the header - adjust it to your liking for minimal learning (if you want to call reading simple instructions learning). I bet, that if we remove the message someone will come up and complain, that the feature is missing or badly discoverable. > But I think this is a bigger issue for beginners, who will likely > just leave the defaults in, out of fear of breaking anything. When > you're trying to teach students how to write a for loop, all the > magic incantations at the beginning of a Java file are just > distractions. Sorry - I hear that very often: - programming students are not willing to read - programming students can't customize their working environment - programming students can't be expected to read documentation - programming students are stupid I think this cuts it way short. Remember: Programmars/Developers are normally paid good money and yes, my baseline assumption is, that people in this area of work can be expected to know their work domain and their tools. I also believe people are more intelligent that we thing, at least if we make them use their brain (i.e. give them incentives to solve problems themselves). In the years after initial training/learning contant change will be the norm and people not being able to learn might be better of learning this fact early on. Just my thoughts though Greetings Matthias, who thinks, that NetBeans problems are in other areas - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: Default license header in generated files confuses students (was: Re: The time has come to bd farewell to the license header)
I believe the proposal here is merely to make the template empty by default--people who want a default license header (to e.g. the Apache license) can still use the feature, but must customize the template first, like they always had to before. The default license header has always been a slight annoyance to me. Different projects I work on have different licenses, so it has never made sense for me to try to customize the default. Instead I just end up deleting the auto-inserted comments every time. But I think this is a bigger issue for beginners, who will likely just leave the defaults in, out of fear of breaking anything. When you're trying to teach students how to write a for loop, all the magic incantations at the beginning of a Java file are just distractions. -- Eirik -Original Message- From: Matthias Bläsing Sent: Sunday, May 31, 2020 12:55 PM To: dev@netbeans.apache.org Subject: Default license header in generated files confuses students (was: Re: The time has come to bd farewell to the license header) Hi, Am Sonntag, den 31.05.2020, 16:37 + schrieb Kenneth Fogel: > Please, please, please get rid of this: > > /* > * To change this license header, choose License Headers in Project Properties. > * To change this template file, choose Tools | Templates > * and open the template in the editor. > */ > > My students think its important so refuse to remove it or go to Tools > | Templates and delete it there. Its really annoying. If you want to > keep it then put it at the end of the file with the added notation > Delete Me. > please use speaking subjects. They are not funny and not helpful. I updated it to a from my POV better summary. I don't get your point. License headers are important, the development ecosystem shifts to opensouce models (hell, even Microsoft admits that) and in that case clear licensing is a base requirement. If your students don't understand what is written there teach them, I understood you are in teaching, so use the oportunity. Just as teachers in germany have to consider correct spelling and grammer even in non- language subjects, you could make it a point by deducing points for invalid license headers. There is even a description how to "fix" the issue, so if that is to hard, maybe programming is not the right direction for the students? The header can't be placed at the end of the file as convention requires it to be at the top. There are projects out there that (rightly) refuse to include software without clear license statement. Maybe this gives this another perspective. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Proposed blog on malware report
Hi all, I propose we publish the following on the Apache NetBeans blog re the recent announcement by GitHub researchers of malware found in some NetBeans generated projects on GitHub. Title: Malware Found in 26 NetBeans Ant Projects on GitHub Content: "Researchers at GitHub have identified 26 projects on GitHub that have been infected by malware. The malware infiltrates the project structure of Ant-based applications in the format generated specifically by NetBeans. The owners of the 26 projects, which are mostly small Java applications, have been contacted and the infected projects have been set to private on GitHub. The malware campaign is no longer active, GitHub did not consider it relevant enough to be in touch with the NetBeans community about it, and there is no evidence that applications beyond the 26 in question have been impacted. Be aware that any project structure that you use when developing applications can be infiltrated by malware and make sure that the files you check into your versioning system are your own or that you know where they come from and what they do." Feedback welcome and needed. Gj
Re: Default license header in generated files confuses students (was: Re: The time has come to bd farewell to the license header)
I don't know that it's confusing (it never was to me) just not convenient...perhaps due to my own ignorance. I think of any given license as project, not IDE specific. Perhaps I should dig a bit further before commenting. On Sun, May 31, 2020 at 1:00 PM Matthias Bläsing wrote: > Hi, > > Am Sonntag, den 31.05.2020, 16:37 + schrieb Kenneth Fogel: > > Please, please, please get rid of this: > > > > /* > > * To change this license header, choose License Headers in Project > Properties. > > * To change this template file, choose Tools | Templates > > * and open the template in the editor. > > */ > > > > My students think its important so refuse to remove it or go to Tools > > | Templates and delete it there. Its really annoying. If you want to > > keep it then put it at the end of the file with the added notation > > Delete Me. > > > > please use speaking subjects. They are not funny and not helpful. I > updated it to a from my POV better summary. > > I don't get your point. License headers are important, the development > ecosystem shifts to opensouce models (hell, even Microsoft admits that) > and in that case clear licensing is a base requirement. > > If your students don't understand what is written there teach them, I > understood you are in teaching, so use the oportunity. Just as teachers > in germany have to consider correct spelling and grammer even in non- > language subjects, you could make it a point by deducing points for > invalid license headers. > > There is even a description how to "fix" the issue, so if that is to > hard, maybe programming is not the right direction for the students? > > The header can't be placed at the end of the file as convention > requires it to be at the top. There are projects out there that > (rightly) refuse to include software without clear license statement. > > Maybe this gives this another perspective. > > Greetings > > Matthias > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > -- Carl J. Mosca
Default license header in generated files confuses students (was: Re: The time has come to bd farewell to the license header)
Hi, Am Sonntag, den 31.05.2020, 16:37 + schrieb Kenneth Fogel: > Please, please, please get rid of this: > > /* > * To change this license header, choose License Headers in Project Properties. > * To change this template file, choose Tools | Templates > * and open the template in the editor. > */ > > My students think its important so refuse to remove it or go to Tools > | Templates and delete it there. Its really annoying. If you want to > keep it then put it at the end of the file with the added notation > Delete Me. > please use speaking subjects. They are not funny and not helpful. I updated it to a from my POV better summary. I don't get your point. License headers are important, the development ecosystem shifts to opensouce models (hell, even Microsoft admits that) and in that case clear licensing is a base requirement. If your students don't understand what is written there teach them, I understood you are in teaching, so use the oportunity. Just as teachers in germany have to consider correct spelling and grammer even in non- language subjects, you could make it a point by deducing points for invalid license headers. There is even a description how to "fix" the issue, so if that is to hard, maybe programming is not the right direction for the students? The header can't be placed at the end of the file as convention requires it to be at the top. There are projects out there that (rightly) refuse to include software without clear license statement. Maybe this gives this another perspective. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: The time has come to bd farewell to the license header
I am guessing you think it's also OK to cut those tags off pillows that say "do not remove under penalty of law". LOL...yes, that message should go, thank you for bring it up. Carl On Sun, May 31, 2020 at 12:37 PM Kenneth Fogel wrote: > Please, please, please get rid of this: > > /* > * To change this license header, choose License Headers in Project > Properties. > * To change this template file, choose Tools | Templates > * and open the template in the editor. > */ > > My students think its important so refuse to remove it or go to Tools | > Templates and delete it there. Its really annoying. If you want to keep it > then put it at the end of the file with the added notation Delete Me. > > Ken > > -- Carl J. Mosca
RE: The time has come to bd farewell to the license header
I agree this would be a good thing to get rid of by default. -- Eirik -Original Message- From: Kenneth Fogel Sent: Sunday, May 31, 2020 12:37 PM To: dev@netbeans.apache.org Subject: The time has come to bd farewell to the license header Please, please, please get rid of this: /* * To change this license header, choose License Headers in Project Properties. * To change this template file, choose Tools | Templates * and open the template in the editor. */ My students think its important so refuse to remove it or go to Tools | Templates and delete it there. Its really annoying. If you want to keep it then put it at the end of the file with the added notation Delete Me. Ken - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
The time has come to bd farewell to the license header
Please, please, please get rid of this: /* * To change this license header, choose License Headers in Project Properties. * To change this template file, choose Tools | Templates * and open the template in the editor. */ My students think its important so refuse to remove it or go to Tools | Templates and delete it there. Its really annoying. If you want to keep it then put it at the end of the file with the added notation Delete Me. Ken
Re: [VOTE] Release Apache NetBeans 12.0 [vote candidate 1]
On 5/31/20 7:13 AM, Eric Barboni wrote: > This is our first voting candidate for the 12.0 LTS release of Apache > NetBeans. > Note that this is our first release vote where you are required to check > both sources and convenience binaries before voting! I noticed something out of place. 1) built from source under Linux (Debian 10 "Buster") 2) started with fresh userdir 3) created a new FX project: "FXML JavaFX Maven Archetype (Gluon)" NetBeans wants to install "JavaFX Implementation for Mac OS X" rather than Linux (see linked screenshot). It appears to be a cosmetic issue, as the new project runs, debugs, and profiles normally. https://www.lyonlabs.org/temp/fx-mac.png -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: jlink in JavaFX project
https://m.youtube.com/watch?v=eSJTTHypDEw Gj On Sat, 30 May 2020 at 20:44, Matthias Bläsing wrote: > Hi, > > Am Samstag, den 30.05.2020, 18:40 + schrieb Kenneth Fogel: > > Too much command line for my liking. > > don't take this wrong, but the first thing your students should learn > is, that CLI is your friend. It is the base of all automation and tools > like docker, travis, jenkins, github-action would not be useful if not > CLI tools existed. > > The other good thing is, that CLI tools have the tendency to be closer > to the "real" background, so if the GUI tool of your choosing stops > working or reaches the end of its preprogammed limits, CLI tools often > take you farther. > > Just my 2cents > > Matthias > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
[VOTE] Release Apache NetBeans 12.0 [vote candidate 1]
Dear community, This is our first voting candidate for the 12.0 LTS release of Apache NetBeans. Note that this is our first release vote where you are required to check both sources and convenience binaries before voting! See requirements below. Apache NetBeans 12.0 constitutes all clusters in the Apache NetBeans Git repo, which together provide the NetBeans Platform (i.e., the underlying application framework), as well as all the modules that provide the Java SE, Java EE, PHP, JavaScript and Groovy features of Apache NetBeans. Build artefacts are available here: https://dist.apache.org/repos/dist/dev/netbeans/netbeans/12.0/vc1 https://dist.apache.org/repos/dist/dev/netbeans/netbeans-platform/12.0/vc1 They were built by the Jenkins pipeline and moved to their place: https://builds.apache.org/view/M-R/view/NetBeans/job/netbeans-TLP/job/netbea ns/job/release120/23 We are primarily voting on: https://dist.apache.org/repos/dist/dev/netbeans/netbeans/12.0/vc1/netbeans-1 2.0-source.zip SHA512: f172579f4d1e5bef3631c974d232c193e40739c40dc4f6d3d0f9b746d6c7fdb90b871b327487 f39bade66840650e0d594970066ae4e0625d75d4584ecb6c1a70 ./netbeans-12.0-source.zip KEYS file: https://downloads.apache.org/netbeans/KEYS -- Associated to the primary source item you will have (generated with pipeline mentioned above) *under https://dist.apache.org/repos/dist/dev/netbeans/netbeans/12.0/vc1 binaries associated to the source netbeans-12.0-bin.zip as well as update content under nbms folder *under https://dist.apache.org/repos/dist/dev/netbeans/netbeans-platform/12.0/vc1 you will find platform cluster build netbeans-platform-12.0-bin netbeans-platform-12.0-source Associated Apache Maven artefacts RELEASE120 can be found at https://repository.apache.org/content/repositories/orgapachenetbeans-1058 Artefacts are composed of jars,nbm,sources,javadocs,pom. -- Apache NetBeans Git Repo tag: 12.0-vc1 : https://github.com/apache/netbeans/tree/12.0-vc1 Release specific wiki page: https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+12.0 Before voting +1 you are required to download the signed source code package, compile it as provided, and test the resulting executable on your own platform, along with also verifying that the package meets the requirements of the ASF policy on releases - see http://www.apache.org/legal/release-policy.html#management In particular, you should (at least) follow these steps. 1. Download the artefact to be voted on and unzip it. 2. Check that the artefact does not contain any jar files, except for: - platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/ empty.jar - enterprise/glassfish.common/test/unit/data/nottaDir-4_1_2.jar - enterprise/glassfish.common/test/unit/data/subdir/nottaDir-5.0.jar - enterprise/payara.common/test/unit/data/nottaDir-4_1_2.jar - enterprise/payara.common/test/unit/data/subdir/nottaDir-5.0.jar which are only jars by their name 3. Verify the cryptographic signatures, the NOTICE and LICENSE file 4. Build it using the README provided by the artefact. 5. Look in nbbuild/netbeans for the NetBeans installation created by the build process and try running it. In addition to checking the sources, you should check the associated convenience binary zips and nbms at the artefact links above. As well as checking any artefact functions correctly, you should check that it has been correctly signed by a PMC member, and that the source being voted on is sufficient to build the relevant binary. Separate votes will be held on other convenience binaries, mostly for each installer. Those will be dependent on this vote passing. This vote is going to be open at least 72 hours, vote with +1, 0, and -1 as usual. (please justify -1) Please mark your vote with (binding) if you're an Apache NetBeans PMC member to help with voting admin. NetBeans 12.0 will be released if and when this vote passes. Thank all contributors for hard work ! Best Regards, Eric - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
