Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
On Sat, Apr 27, 2019, 14:22 Laszlo Kishalmi wrote: > > On 4/27/19 1:12 AM, Jan Lahoda wrote: > > Hi Laszlo, > > > > On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi < > laszlo.kisha...@gmail.com> > > wrote: > > > >> Dear all, > >> > >> As Gradle was a new out-of-the box feature, I've received some > >> issues/feedback. I've already fixed some of them. > >> > >> I would like to do a release of those changes. Those fixes might be not > >> that important, but what I'm really curious, that actually can we, and > >> how can we roll out such a partial patch release? > >> > > I think it would be awesome if we could do update releases! > > > > > >> My plan is the following: > >> > >> 1. Branch the current release into something like: > >> release110-gradle-patch-1 > >> > > I'd suggest to simply continue with the release110 patch. (The last > release > > is tagged anyway, so we are not loosing that, and in a longer term, it > > would IMO be easier to simply continue in the release branch with all > the > > changes.) > Well right now release110 branch has already some changes which shall go > into the 11.1 release > > (Just a reminder for us, maybe the release branch shall be named to > release12x if we plan to have a 12.1 in December) > > Anyway, I'd keep this effort separated from 11.1, though I guess the new > branch would be just merged into the release110 after the Gradle Patch > release happens. > To me this points to a good reason for the release branches to only live until the release at which point it is fully merged up with master and deleted, then it is tagged. In prep for a dot release, a release branch is created and cleaned up etc; rinse repeat. Then the tags release110 and release111 would be static and not confusing like a release110 with changes after the release. Thanks Wade
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
On 4/27/19 1:12 AM, Jan Lahoda wrote: Hi Laszlo, On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi wrote: Dear all, As Gradle was a new out-of-the box feature, I've received some issues/feedback. I've already fixed some of them. I would like to do a release of those changes. Those fixes might be not that important, but what I'm really curious, that actually can we, and how can we roll out such a partial patch release? I think it would be awesome if we could do update releases! My plan is the following: 1. Branch the current release into something like: release110-gradle-patch-1 I'd suggest to simply continue with the release110 patch. (The last release is tagged anyway, so we are not loosing that, and in a longer term, it would IMO be easier to simply continue in the release branch with all the changes.) Well right now release110 branch has already some changes which shall go into the 11.1 release (Just a reminder for us, maybe the release branch shall be named to release12x if we plan to have a 12.1 in December) Anyway, I'd keep this effort separated from 11.1, though I guess the new branch would be just merged into the release110 after the Gradle Patch release happens. 2. Cherry Pick the required changes 3. Increase the patch version (3rd number on the affected modules (I guess only gradle and gradle.java) 4. Set up a jenkins job for that branch to release. 5. The release artifacts would be 1. The new nbm modules from gradle and gradle.java 2. The source artifact would contain those module sources only. 3. I do not know what to put in there exactly: 1. The sources of the two modules keeping the directory structure. so that would be in groovy/gradle and groovy/gradle.java 2. LICENSE and NOTICE files 3. Is there a way to generate the DEPENDENCIES file only for two modules? We should be able to generate the correct LICENSE/NOTICE/DEPENDENCIES without too much problem. We don't currently have an ant target that would allow us to achieve what we want, but we probably should be able to write that. One of the tasks would also be that: a) we need to have the README adjusted to say how to build and use the update; b) possibly we may want a build script to help the user with that. FWIW, I've tried: $ ant -Dclusters.config.update.list=nb.cluster.update -Dnb.cluster.update.dir=update -Dnb.cluster.update=groovy/gradle,groovy/gradle.java -Dcluster.config=update build-source-config It builds something, but I think we can do much better. While that could be a way to go, though I'd rather stick with the current build process and just reduce the output artifacts, but it could be just me feeling that a bit safer choice. 6. Do the PGP signing with my key 7. Start a vote on the artifacts 8. If the vote would be successful: 1. I'd upload the source artifact next to our release 11.0 one. 2. I'd upload the binary nbm-s into the 11.0 distribution UC 3. I do not know how to updates.xml, probably I keep the one generated for the whole NB from step 5 and overwrite the current one. Not sure if we can replace the convenience NBMs and catalog.xml, we may need to place the new NBMs and new catalog.xml into a different directory and update the redirects so that the existing IDEs see the new catalog. in theory it would be an svn commit + a 24h wait time while it is being updated on the mirrors, then we can update it in the netbeans-vm. I'm almost 100% sure that it could work. Jan 9. Again I do not know how much announcement we shall make with this release, maybe a just our announcement list would be enough. Please think it through! Is this feasible, what else shall be done, do I have some misconceptions, etc. ? Also would like to have a peer feedback from our Release Manager Emilian. Thank you! Laszlo Kishalmi - 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: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
On 4/27/19 6:36 AM, Eric Bresie wrote: Hope I’m not misunderstanding here, is what is being discussed There is an applicable ticket (is there one yet for these changes by the way?) associated with the change/defect/enhancement involved Well, there are a handful of fixes, see: https://issues.apache.org/jira/issues/?filter=12346269 Maybe 2-3 other one could join. All these specific to the Gradle integration. There a development branch with the changes being developed The patches are going into the master in form of a PR, then my proposed workflow would be to branch off the current release and then cherry pick from master. Targeted item for eventual 11.0.1 sub release (patch) I would not really name it to 11.0.1 officially. Anyone wanting to try can pull from the branch, and When ready for acceptance then start the process of finalizing the sub release with that (and any additional changes assume an umbrella ticket created and linked to others being targeted ). Or is what is being discussed something more like what I seem to recall in Linux kernel development practices . They would package the main baseline code and then made available the patches with diffs between revisions so the whole code base didn’t have to be provided until it reached the more formal release candidates. Seem to recall they had “release branch” (which was more production version with limited updates) and “development branch” to support development of new updates and features. Yes something like this. Sounds like there are the sub modules and their versions and the aggregate of the overarching Netbeans release. So is the question at what point does the aggregate version get bumped/released give a collection of sub modules updates? Well, there shall be a 11.1 in June if we can make that happen. Can the “patch” just use the normal plugin update mechanism in some way? I seem to recall that being sort of how Eclipse deals with updates but once again maybe I’m misunderstanding the discussion That's the plan. Use the update mechanism already built in and has not really been utilized since we moved to Apache. This would be the first attempt to do a partial-release and that's why I started this thread to collect a community insight on this. Eric Bresie ebre...@gmail.com On April 27, 2019 at 3:12:07 AM CDT, Jan Lahoda wrote: Hi Laszlo, On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi wrote: Dear all, As Gradle was a new out-of-the box feature, I've received some issues/feedback. I've already fixed some of them. I would like to do a release of those changes. Those fixes might be not that important, but what I'm really curious, that actually can we, and how can we roll out such a partial patch release? I think it would be awesome if we could do update releases! My plan is the following: 1. Branch the current release into something like: release110-gradle-patch-1 I'd suggest to simply continue with the release110 patch. (The last release is tagged anyway, so we are not loosing that, and in a longer term, it would IMO be easier to simply continue in the release branch with all the changes.) 2. Cherry Pick the required changes 3. Increase the patch version (3rd number on the affected modules (I guess only gradle and gradle.java) 4. Set up a jenkins job for that branch to release. 5. The release artifacts would be 1. The new nbm modules from gradle and gradle.java 2. The source artifact would contain those module sources only. 3. I do not know what to put in there exactly: 1. The sources of the two modules keeping the directory structure. so that would be in groovy/gradle and groovy/gradle.java 2. LICENSE and NOTICE files 3. Is there a way to generate the DEPENDENCIES file only for two modules? We should be able to generate the correct LICENSE/NOTICE/DEPENDENCIES without too much problem. We don't currently have an ant target that would allow us to achieve what we want, but we probably should be able to write that. One of the tasks would also be that: a) we need to have the README adjusted to say how to build and use the update; b) possibly we may want a build script to help the user with that. FWIW, I've tried: $ ant -Dclusters.config.update.list=nb.cluster.update -Dnb.cluster.update.dir=update -Dnb.cluster.update=groovy/gradle,groovy/gradle.java -Dcluster.config=update build-source-config It builds something, but I think we can do much better. 6. Do the PGP signing with my key 7. Start a vote on the artifacts 8. If the vote would be successful: 1. I'd upload the source artifact next to our release 11.0 one. 2. I'd upload the binary nbm-s into the 11.0 distribution UC 3. I do not know how to updates.xml, probably I keep the one generated for the whole NB from step 5 and overwrite the current one. Not sure if we can replace the convenience NBMs and catalog.xml, we may need to place the new NBMs and new catalog.xml into a different directory and update the redirects so that the
netbeans.org redirection status
Hi all, A short summary of where we're standing regarding the netbeans.org redirection to netbeans.apache.org: - platform.netbeans.org This will redirect to https://netbeans.apache.org/features/platform/, which doesn't currently exist. - plugins.netbeans.org Seems to be working correctly. - edu.netbeans.org Seems to be working correctly. - wiki.netbeans.org Seems to be working correctly. - netbeans.org/dtds This will redirect to netbeans.apache.org/dtds, both http and https protocols are working. All DTDs are already in place. - bugzilla.netbeans.org This currently redirects to https://netbeans.apache.org/bugzilla/ which doesn't exist. NOTE: You can try out this yourself by adding: 95.216.24.32 netbeans.org to your /etc/hosts (BSD/OSX/Linux) or C:\Windows\System32\drivers\etc\hosts (Windows) and restarting your browsers. Remember to remove the line afterwards. Please let me know about any additional domains we're interested in. Cheers, Antonio - 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: Warning: can not install modules
I'd recommend starting with a fresh user directory and installing the Oracle JS Parser via the Plugin Manager after start up. Gj On Sat, Apr 27, 2019 at 7:00 PM Eric Bresie wrote: > Downloaded recent 11.0 NB from download site. > > And on startup received the following: > > Warning - could not install some modules: > Nashorn Integration - No module providing the capability > com.oracle.js.parser.implementation could be found. > 27 further modules could not be installed due to the above problems. > > > > I am running > > C:\git\netbeans.dev>java -version > java version "1.8.0_201" > Java(TM) SE Runtime Environment (build 1.8.0_201-b09) > Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode) > > > I do have newer versions on the system present including openjdk and update > java 12 but the above shows what is the current default version. > > Is this maybe some corrupted temp / cached files maybe confusing the > startup (as I do find even in the new install it is still picking up the > last project I was working on) > > Any ideas? > > Eric Bresie > ebre...@gmail.com > http://www.linkedin.com/in/ebresie >
Re: Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Hope I’m not misunderstanding here, is what is being discussed There is an applicable ticket (is there one yet for these changes by the way?) associated with the change/defect/enhancement involved There a development branch with the changes being developed Targeted item for eventual 11.0.1 sub release (patch) Anyone wanting to try can pull from the branch, and When ready for acceptance then start the process of finalizing the sub release with that (and any additional changes assume an umbrella ticket created and linked to others being targeted ). Or is what is being discussed something more like what I seem to recall in Linux kernel development practices . They would package the main baseline code and then made available the patches with diffs between revisions so the whole code base didn’t have to be provided until it reached the more formal release candidates. Seem to recall they had “release branch” (which was more production version with limited updates) and “development branch” to support development of new updates and features. Sounds like there are the sub modules and their versions and the aggregate of the overarching Netbeans release. So is the question at what point does the aggregate version get bumped/released give a collection of sub modules updates? Can the “patch” just use the normal plugin update mechanism in some way? I seem to recall that being sort of how Eclipse deals with updates but once again maybe I’m misunderstanding the discussion Eric Bresie ebre...@gmail.com > On April 27, 2019 at 3:12:07 AM CDT, Jan Lahoda wrote: > Hi Laszlo, > > On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi > wrote: > > > Dear all, > > > > As Gradle was a new out-of-the box feature, I've received some > > issues/feedback. I've already fixed some of them. > > > > I would like to do a release of those changes. Those fixes might be not > > that important, but what I'm really curious, that actually can we, and > > how can we roll out such a partial patch release? > > > > I think it would be awesome if we could do update releases! > > > > > > My plan is the following: > > > > 1. Branch the current release into something like: > > release110-gradle-patch-1 > > > > I'd suggest to simply continue with the release110 patch. (The last release > is tagged anyway, so we are not loosing that, and in a longer term, it > would IMO be easier to simply continue in the release branch with all the > changes.) > > 2. Cherry Pick the required changes > > 3. Increase the patch version (3rd number on the affected modules (I > > guess only gradle and gradle.java) > > 4. Set up a jenkins job for that branch to release. > > 5. The release artifacts would be > > 1. The new nbm modules from gradle and gradle.java > > 2. The source artifact would contain those module sources only. > > 3. I do not know what to put in there exactly: > > 1. The sources of the two modules keeping the directory > > structure. so that would be in groovy/gradle and > > groovy/gradle.java > > 2. LICENSE and NOTICE files > > 3. Is there a way to generate the DEPENDENCIES file only for > > two modules? > > > > We should be able to generate the correct LICENSE/NOTICE/DEPENDENCIES > without too much problem. We don't currently have an ant target that would > allow us to achieve what we want, but we probably should be able to write > that. One of the tasks would also be that: a) we need to have the README > adjusted to say how to build and use the update; b) possibly we may want a > build script to help the user with that. > > FWIW, I've tried: > $ ant -Dclusters.config.update.list=nb.cluster.update > -Dnb.cluster.update.dir=update > -Dnb.cluster.update=groovy/gradle,groovy/gradle.java > -Dcluster.config=update build-source-config > > It builds something, but I think we can do much better. > > > > 6. Do the PGP signing with my key > > 7. Start a vote on the artifacts > > 8. If the vote would be successful: > > 1. I'd upload the source artifact next to our release 11.0 one. > > 2. I'd upload the binary nbm-s into the 11.0 distribution UC > > 3. I do not know how to updates.xml, probably I keep the one > > generated for the whole NB from step 5 and overwrite the current > > one. > > > > Not sure if we can replace the convenience NBMs and catalog.xml, we may > need to place the new NBMs and new catalog.xml into a different directory > and update the redirects so that the existing IDEs see the new catalog. > > Jan > > 9. Again I do not know how much announcement we shall make with this > > release, maybe a just our announcement list would be enough. > > > > > Please think it through! Is this feasible, what else shall be done, do I > > have some misconceptions, etc. ? > > > > Also would like to have a peer feedback from our Release Manager Emilian. > > > > Thank you! > > > > Laszlo Kishalmi > > > >
Re: Re: [NOTICE] Git repo migration
Thanks, created this: https://issues.apache.org/jira/browse/INFRA-18290 Gj On Sat, Apr 27, 2019 at 4:02 PM Eric Bresie wrote: > Was looking at the Gitbox list of projects > > https://gitbox.apache.org/repos/asf > > And noticed the descriptions still have incubator in them. > > Eric Bresie > ebre...@gmail.com > > On April 26, 2019 at 4:24:58 PM CDT, Antonio wrote: > > FYI: Website not updated correctly. I've fired > > > > https://issues.apache.org/jira/browse/INFRA-18287 > > > > Cheers, > > Antonio > > > > El 26/04/2019 a las 22:21, Antonio escribió: > > > For the record: > > > > > > The gitbox pointer in the netbeans-website jenkins job wasn't updated > > > properly (the -incubator part was not removed), so I had to modify it > > > manually. > > > > > > OTOH please report any broken web links if any. > > > > > > Cheers, > > > Antonio > > > > > > > > > > > > El 25/04/2019 a las 23:27, Antonio escribió: > > > > Updating some links in the website > > > > > > > > https://github.com/apache/netbeans-website/pull/355 > > > > > > > > The download links keep pointing to the incubator directories in > > > > mirrors, though (links without incubating don't work). > > > > > > > > Cheers, > > > > Antonio > > > > > > > > El 25/04/2019 a las 21:58, Geertjan Wielenga escribió: > > > > > Many thanks for pushing to get that done. > > > > > > > > > > Tweeted it jere: > https://twitter.com/netbeans/status/1121502219977752578 > > > > > > > > > > Thanks, > > > > > > > > > > Gj > > > > > > > > > > On Thu, Apr 25, 2019 at 10:44 PM Eric Barboni > wrote: > > > > > > > > > > > Hi folks > > > > > > > > > > > > migration of git repo occurs. > > > > > > > > > > > > It would be nice to report if anything is wrong. > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > >
Re: Re: [NOTICE] Git repo migration
Was looking at the Gitbox list of projects https://gitbox.apache.org/repos/asf And noticed the descriptions still have incubator in them. Eric Bresie ebre...@gmail.com > On April 26, 2019 at 4:24:58 PM CDT, Antonio wrote: > FYI: Website not updated correctly. I've fired > > https://issues.apache.org/jira/browse/INFRA-18287 > > Cheers, > Antonio > > El 26/04/2019 a las 22:21, Antonio escribió: > > For the record: > > > > The gitbox pointer in the netbeans-website jenkins job wasn't updated > > properly (the -incubator part was not removed), so I had to modify it > > manually. > > > > OTOH please report any broken web links if any. > > > > Cheers, > > Antonio > > > > > > > > El 25/04/2019 a las 23:27, Antonio escribió: > > > Updating some links in the website > > > > > > https://github.com/apache/netbeans-website/pull/355 > > > > > > The download links keep pointing to the incubator directories in > > > mirrors, though (links without incubating don't work). > > > > > > Cheers, > > > Antonio > > > > > > El 25/04/2019 a las 21:58, Geertjan Wielenga escribió: > > > > Many thanks for pushing to get that done. > > > > > > > > Tweeted it jere: https://twitter.com/netbeans/status/1121502219977752578 > > > > > > > > Thanks, > > > > > > > > Gj > > > > > > > > On Thu, Apr 25, 2019 at 10:44 PM Eric Barboni wrote: > > > > > > > > > Hi folks > > > > > > > > > > migration of git repo occurs. > > > > > > > > > > It would be nice to report if anything is wrong. > > > > > > > > > > > > > > > > > > > > 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 > > >
Re: [NOTICE] Git repo migration
Hi, For the record: we need to update the links we use to download the API documentation @ bits.netbeans.org. I can do that. Cheers, Antonio El 25/04/2019 a las 21:44, Eric Barboni escribió: Hi folks migration of git repo occurs. It would be nice to report if anything is wrong. 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
OSU OpenPOWER
Hi all, As you may know we're using some infrastructure @ OSU (Oregon State University) to host some binaries we're using in our builds. They're requesting feedback for users in the "OpenPOWER Cluster", with a deadline of April the 30th for sending it. Are we users of this cluster? Should we answer that survey? Is this an Apache wide agreement or just a NetBeans specific one? Would it be possible to document our relationship with OSU somewhere under the "infra" node [1] in Confluence? Thanks, Antonio [1] https://cwiki.apache.org/confluence/display/NETBEANS/Infra - 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: [NOTICE] Git repo migration
Hi John, I renamed my clone in github.com (click on settings and set the new name). Then I updated my remotes with git (git remote show/remove/add) and that was it. I don't know if this is strictly required, though. Cheers, Antonio El 27/04/2019 a las 13:32, John McDonnell escribió: Quite possibly a stupid question, but been too busy to keep up this week, so might have lost it being mentioned... Forks in GutHub, of the old incubator repo, do we need to create new forks or is there a simple way to update the fork in github? Regards John On Fri, 26 Apr 2019 at 22:33, Antonio wrote: FYI: Website not updated correctly. I've fired https://issues.apache.org/jira/browse/INFRA-18287 Cheers, Antonio El 26/04/2019 a las 22:21, Antonio escribió: For the record: The gitbox pointer in the netbeans-website jenkins job wasn't updated properly (the -incubator part was not removed), so I had to modify it manually. OTOH please report any broken web links if any. Cheers, Antonio El 25/04/2019 a las 23:27, Antonio escribió: Updating some links in the website https://github.com/apache/netbeans-website/pull/355 The download links keep pointing to the incubator directories in mirrors, though (links without incubating don't work). Cheers, Antonio El 25/04/2019 a las 21:58, Geertjan Wielenga escribió: Many thanks for pushing to get that done. Tweeted it jere: https://twitter.com/netbeans/status/1121502219977752578 Thanks, Gj On Thu, Apr 25, 2019 at 10:44 PM Eric Barboni wrote: Hi folks migration of git repo occurs. It would be nice to report if anything is wrong. 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 - 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: [NOTICE] Git repo migration
Quite possibly a stupid question, but been too busy to keep up this week, so might have lost it being mentioned... Forks in GutHub, of the old incubator repo, do we need to create new forks or is there a simple way to update the fork in github? Regards John On Fri, 26 Apr 2019 at 22:33, Antonio wrote: > FYI: Website not updated correctly. I've fired > > https://issues.apache.org/jira/browse/INFRA-18287 > > Cheers, > Antonio > > El 26/04/2019 a las 22:21, Antonio escribió: > > For the record: > > > > The gitbox pointer in the netbeans-website jenkins job wasn't updated > > properly (the -incubator part was not removed), so I had to modify it > > manually. > > > > OTOH please report any broken web links if any. > > > > Cheers, > > Antonio > > > > > > > > El 25/04/2019 a las 23:27, Antonio escribió: > >> Updating some links in the website > >> > >> https://github.com/apache/netbeans-website/pull/355 > >> > >> The download links keep pointing to the incubator directories in > >> mirrors, though (links without incubating don't work). > >> > >> Cheers, > >> Antonio > >> > >> El 25/04/2019 a las 21:58, Geertjan Wielenga escribió: > >>> Many thanks for pushing to get that done. > >>> > >>> Tweeted it jere: > https://twitter.com/netbeans/status/1121502219977752578 > >>> > >>> Thanks, > >>> > >>> Gj > >>> > >>> On Thu, Apr 25, 2019 at 10:44 PM Eric Barboni > wrote: > >>> > Hi folks > > migration of git repo occurs. > > It would be nice to report if anything is wrong. > > > > 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 > > > >
Re: [NETBEANS-2455] Splash Screens!
Hi Laszlo, - For browsers: http://netbeans.apache.org/images/splash.svg - For batik: http://netbeans.apache.org/images/netbeans-splash-batik.svg This batik compatible version renders ugly in browsers, but renders properly with batik in any platform. It embeds the font in SVG. Font is Open Font License 1.1, which is APLv2 compatible AFAIK9. I've tested it with the APLv2 Flamingo SVG converter http://ebourg.github.io/flamingo-svg-transcoder/ , that you can run with JavaWebStart, and which also has an Ant task that could be of help for rendering in a pipeline. Cheers, Antonio El 27/04/2019 a las 8:46, Laszlo Kishalmi escribió: Well, I was able to figure out a no-text version, but thank you. Java has a feature which displays a splash screen from a MANIFEST.MF attribute. We are actually using that, that's why our slash.png shall be renamed to gif. That feature is not really maintained/needed any more. E.g.: AFAIK, On Mac that is the reason why a gray rectangle appears before the Splash screen. By removing the static image splash screen (we are updating that later anyway), and creating our own splash, we can do better things with it, like HiDPI Splash, etc., Java Starts much faster now that Java 6 when this splash screen feature was introduced. The machines we are using got faster as well. But do not go that far, let's find out what can I do with the no text splash screen... On 4/26/19 10:57 PM, Antonio wrote: No text version here: http://netbeans.apache.org/images/splash-notext.svg Regarding INFRA-18287: website is now updating properly through gitbox. Cheers, Antonio El 27/04/2019 a las 6:48, Antonio escribió: Hi, Yep, the SVG downloads the font from the inlined CSS from Google Fonts, so I imagine this will have issues in command line tools but not on browsers. For command line tools I imagine one would have to download the font and install it locally somewhere so imagemagick or others can find it. Anyway the SVG was a quick & dirty example that we can hack away. We could remove the text, for example, and keep only the background stuff and the logo. And then print-out the text with imagemagick (+1 dependency) or ideally with swing (+0 dependencies). I'll give some more hacking to it :-) Cheers, Antonio El 27/04/2019 a las 1:41, Laszlo Kishalmi escribió: I was happy too early. It seems only Firefox/Chrome could correctly render that SVG, command line converters I've tried: imagemagic, inkscape and librsvg-bin had issues. So I go back to my original plan get the empty splash (from firefox I can make one) and try to draw something on that with Java later. On 4/26/19 3:55 PM, Laszlo Kishalmi wrote: I love the svg! Now we just need to agree on the design. I like both version, but don't forget the progress bar an the status texts as well. Till then, I'm going to make some experiment generating the splash on build time from the svg. On 4/26/19 2:44 PM, Antonio wrote: Here's a splash image in plain text. Updating the release number is a piece of cake :-) http://netbeans.apache.org/images/splash.svg Cheers, Antonio P.S.: Font is 'Anton' (Open Font License) https://fonts.google.com/specimen/Anton El 26/04/2019 a las 8:53, Laszlo Kishalmi escribió: Dear all, We need Splash Screens for the Development Version to our master branch. It looks quite stupid to see the dev version showing a 10 version on splash even after the 11.0 got released. Also we need the know-how to be public how to generate the splash screen image. A simple Splash Screen background image would be good as well! Thank you in advance! Laszlo Kishalmi - 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 - 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 - 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 - 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: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
On Sat, Apr 27, 2019 at 8:11 AM Enrico Olivelli wrote: > Hi, > IMHO If the changed files are inside the main nb repository you should > release a new version of the whole repository. > To me, it seems wasteful to force the PMC to review >70k files when only a "handful" actually changed, in a handful of modules, just because they happen to be physically located in the same repository as many other modules. > So it would be a 11.0.1 nb, with at least the zip of the sources of the > whole repository. > That fact that users would be able to upgrade the single module is just a > detail. > > For instance in Apache Maven, that is comprised of 100+ independent module, > we have a release of Maven core and every sub module (maven plugin) is > released independently. > But every project has its own repository + sources zip + convenience > binary. > Note that every NetBeans module is also to some degree independent - with some work, we can probably generate a source zip for it, and they have a natural convenience binary format as well. > > I am not suggesting to split NB, I am just saying that you should release > the whole buildable sources bundle and not only a part. > > AFAIK in Apache we are releasing 'source code', and it is important that > who downloads it is able to build it. > I don't think "being able to build" leads to "must have the complete source code for all the modules". A pre-requisite for building might be having the previous full release available, and I don't see a huge issue in that. (If it was only about a build, we could probably build against just the last binary, but for tests, we need some of the full sources which contain tests for other modules.) I think this can be made so that the inconvenience is limited and acceptable. I'd rather invest some energy into improving the infrastructure to make the partial build as convenient as possible than into re-reviewing e.g. PHP support when only Gradle changes. Jan > > Just my 2 cents > > Enrico > > > > Il sab 27 apr 2019, 07:57 Laszlo Kishalmi ha > scritto: > > > Dear all, > > > > As Gradle was a new out-of-the box feature, I've received some > > issues/feedback. I've already fixed some of them. > > > > I would like to do a release of those changes. Those fixes might be not > > that important, but what I'm really curious, that actually can we, and > > how can we roll out such a partial patch release? > > > > My plan is the following: > > > > 1. Branch the current release into something like: > > release110-gradle-patch-1 > > 2. Cherry Pick the required changes > > 3. Increase the patch version (3rd number on the affected modules (I > > guess only gradle and gradle.java) > > 4. Set up a jenkins job for that branch to release. > > 5. The release artifacts would be > > 1. The new nbm modules from gradle and gradle.java > > 2. The source artifact would contain those module sources only. > > 3. I do not know what to put in there exactly: > > 1. The sources of the two modules keeping the directory > > structure. so that would be in groovy/gradle and > > groovy/gradle.java > > 2. LICENSE and NOTICE files > > 3. Is there a way to generate the DEPENDENCIES file only for > > two modules? > > 6. Do the PGP signing with my key > > 7. Start a vote on the artifacts > > 8. If the vote would be successful: > > 1. I'd upload the source artifact next to our release 11.0 one. > > 2. I'd upload the binary nbm-s into the 11.0 distribution UC > > 3. I do not know how to updates.xml, probably I keep the one > > generated for the whole NB from step 5 and overwrite the current > > one. > > 9. Again I do not know how much announcement we shall make with this > > release, maybe a just our announcement list would be enough. > > > > Please think it through! Is this feasible, what else shall be done, do I > > have some misconceptions, etc. ? > > > > Also would like to have a peer feedback from our Release Manager Emilian. > > > > Thank you! > > > > Laszlo Kishalmi > > > > >
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Il giorno sab 27 apr 2019 alle ore 09:02 Laszlo Kishalmi ha scritto: > > Well, I'd avoid changing the version number of the IDE and with that > releasing the complete code-base. I agree. NB is more that one single module. > > The users would be able to build the patch release by downloading the > 11.0 sources and overwrite the files released in the patch, it just > another step in the process and does not make it impossible to build. > > AFAIK Apache releases are just a set of source code. yes, that is was I am trying to say. Enrico > > https://lists.apache.org/thread.html/ccff6dc3152cde4a278a30ef2fdba14c5a1cb54eae56dfcbc9b867ad@%3Cdev.netbeans.apache.org%3E > > On 4/26/19 11:11 PM, Enrico Olivelli wrote: > > Hi, > > IMHO If the changed files are inside the main nb repository you should > > release a new version of the whole repository. > > So it would be a 11.0.1 nb, with at least the zip of the sources of the > > whole repository. > > That fact that users would be able to upgrade the single module is just a > > detail. > > > > For instance in Apache Maven, that is comprised of 100+ independent module, > > we have a release of Maven core and every sub module (maven plugin) is > > released independently. > > But every project has its own repository + sources zip + convenience binary. > > > > I am not suggesting to split NB, I am just saying that you should release > > the whole buildable sources bundle and not only a part. > > > > AFAIK in Apache we are releasing 'source code', and it is important that > > who downloads it is able to build it. > > > > Just my 2 cents > > > > Enrico > > > > > > > > Il sab 27 apr 2019, 07:57 Laszlo Kishalmi ha > > scritto: > > > >> Dear all, > >> > >> As Gradle was a new out-of-the box feature, I've received some > >> issues/feedback. I've already fixed some of them. > >> > >> I would like to do a release of those changes. Those fixes might be not > >> that important, but what I'm really curious, that actually can we, and > >> how can we roll out such a partial patch release? > >> > >> My plan is the following: > >> > >> 1. Branch the current release into something like: > >> release110-gradle-patch-1 > >> 2. Cherry Pick the required changes > >> 3. Increase the patch version (3rd number on the affected modules (I > >> guess only gradle and gradle.java) > >> 4. Set up a jenkins job for that branch to release. > >> 5. The release artifacts would be > >> 1. The new nbm modules from gradle and gradle.java > >> 2. The source artifact would contain those module sources only. > >> 3. I do not know what to put in there exactly: > >> 1. The sources of the two modules keeping the directory > >> structure. so that would be in groovy/gradle and > >> groovy/gradle.java > >> 2. LICENSE and NOTICE files > >> 3. Is there a way to generate the DEPENDENCIES file only for > >> two modules? > >> 6. Do the PGP signing with my key > >> 7. Start a vote on the artifacts > >> 8. If the vote would be successful: > >> 1. I'd upload the source artifact next to our release 11.0 one. > >> 2. I'd upload the binary nbm-s into the 11.0 distribution UC > >> 3. I do not know how to updates.xml, probably I keep the one > >> generated for the whole NB from step 5 and overwrite the current > >> one. > >> 9. Again I do not know how much announcement we shall make with this > >> release, maybe a just our announcement list would be enough. > >> > >> Please think it through! Is this feasible, what else shall be done, do I > >> have some misconceptions, etc. ? > >> > >> Also would like to have a peer feedback from our Release Manager Emilian. > >> > >> Thank you! > >> > >> Laszlo Kishalmi > >> > >> > > - > 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 > > > - 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: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Well, I'd avoid changing the version number of the IDE and with that releasing the complete code-base. The users would be able to build the patch release by downloading the 11.0 sources and overwrite the files released in the patch, it just another step in the process and does not make it impossible to build. AFAIK Apache releases are just a set of source code. https://lists.apache.org/thread.html/ccff6dc3152cde4a278a30ef2fdba14c5a1cb54eae56dfcbc9b867ad@%3Cdev.netbeans.apache.org%3E On 4/26/19 11:11 PM, Enrico Olivelli wrote: Hi, IMHO If the changed files are inside the main nb repository you should release a new version of the whole repository. So it would be a 11.0.1 nb, with at least the zip of the sources of the whole repository. That fact that users would be able to upgrade the single module is just a detail. For instance in Apache Maven, that is comprised of 100+ independent module, we have a release of Maven core and every sub module (maven plugin) is released independently. But every project has its own repository + sources zip + convenience binary. I am not suggesting to split NB, I am just saying that you should release the whole buildable sources bundle and not only a part. AFAIK in Apache we are releasing 'source code', and it is important that who downloads it is able to build it. Just my 2 cents Enrico Il sab 27 apr 2019, 07:57 Laszlo Kishalmi ha scritto: Dear all, As Gradle was a new out-of-the box feature, I've received some issues/feedback. I've already fixed some of them. I would like to do a release of those changes. Those fixes might be not that important, but what I'm really curious, that actually can we, and how can we roll out such a partial patch release? My plan is the following: 1. Branch the current release into something like: release110-gradle-patch-1 2. Cherry Pick the required changes 3. Increase the patch version (3rd number on the affected modules (I guess only gradle and gradle.java) 4. Set up a jenkins job for that branch to release. 5. The release artifacts would be 1. The new nbm modules from gradle and gradle.java 2. The source artifact would contain those module sources only. 3. I do not know what to put in there exactly: 1. The sources of the two modules keeping the directory structure. so that would be in groovy/gradle and groovy/gradle.java 2. LICENSE and NOTICE files 3. Is there a way to generate the DEPENDENCIES file only for two modules? 6. Do the PGP signing with my key 7. Start a vote on the artifacts 8. If the vote would be successful: 1. I'd upload the source artifact next to our release 11.0 one. 2. I'd upload the binary nbm-s into the 11.0 distribution UC 3. I do not know how to updates.xml, probably I keep the one generated for the whole NB from step 5 and overwrite the current one. 9. Again I do not know how much announcement we shall make with this release, maybe a just our announcement list would be enough. Please think it through! Is this feasible, what else shall be done, do I have some misconceptions, etc. ? Also would like to have a peer feedback from our Release Manager Emilian. Thank you! Laszlo Kishalmi - 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: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Hi, IMHO If the changed files are inside the main nb repository you should release a new version of the whole repository. So it would be a 11.0.1 nb, with at least the zip of the sources of the whole repository. That fact that users would be able to upgrade the single module is just a detail. For instance in Apache Maven, that is comprised of 100+ independent module, we have a release of Maven core and every sub module (maven plugin) is released independently. But every project has its own repository + sources zip + convenience binary. I am not suggesting to split NB, I am just saying that you should release the whole buildable sources bundle and not only a part. AFAIK in Apache we are releasing 'source code', and it is important that who downloads it is able to build it. Just my 2 cents Enrico Il sab 27 apr 2019, 07:57 Laszlo Kishalmi ha scritto: > Dear all, > > As Gradle was a new out-of-the box feature, I've received some > issues/feedback. I've already fixed some of them. > > I would like to do a release of those changes. Those fixes might be not > that important, but what I'm really curious, that actually can we, and > how can we roll out such a partial patch release? > > My plan is the following: > > 1. Branch the current release into something like: > release110-gradle-patch-1 > 2. Cherry Pick the required changes > 3. Increase the patch version (3rd number on the affected modules (I > guess only gradle and gradle.java) > 4. Set up a jenkins job for that branch to release. > 5. The release artifacts would be > 1. The new nbm modules from gradle and gradle.java > 2. The source artifact would contain those module sources only. > 3. I do not know what to put in there exactly: > 1. The sources of the two modules keeping the directory > structure. so that would be in groovy/gradle and > groovy/gradle.java > 2. LICENSE and NOTICE files > 3. Is there a way to generate the DEPENDENCIES file only for > two modules? > 6. Do the PGP signing with my key > 7. Start a vote on the artifacts > 8. If the vote would be successful: > 1. I'd upload the source artifact next to our release 11.0 one. > 2. I'd upload the binary nbm-s into the 11.0 distribution UC > 3. I do not know how to updates.xml, probably I keep the one > generated for the whole NB from step 5 and overwrite the current > one. > 9. Again I do not know how much announcement we shall make with this > release, maybe a just our announcement list would be enough. > > Please think it through! Is this feasible, what else shall be done, do I > have some misconceptions, etc. ? > > Also would like to have a peer feedback from our Release Manager Emilian. > > Thank you! > > Laszlo Kishalmi > >
