Re: [DISCUSS] NetBeans brand and domain transition to Apache
On Tue, Sep 4, 2018 at 2:59 PM Geertjan Wielenga wrote: > No, it doesn't mean anything at all -- except that what we're trying to do > here is figure out the best way to solve this particular scenario. > > We're discussing here, you're welcome to join in. Where should the binaries > be hosted, in your opinion? That would help, if you have an opinion on > this, and then we can discuss that approach with Oracle and with Apache. > Well, first, it's simply unclear to me the status of the artifacts on nb.org. The source code are OSS artifacts, but what are the binaries? Can "anyone" distribute those binary artifacts? Or just Oracle? As I understand it, Apache is getting the domain as well as the web pages and tutorials from nb.org, yes? But Apache is not getting the binary artifacts, and, even were it able to, is not able to distribute them anyway (for unimportant reasons, I'm not questioning those, simply trying to work within the framework). So, what it's the definition of distribution? Hosted on Apache infrastructure? If you have a web page on Apache infrastructure with one pointing to http://xxx.apache.org/stuff/Netbeans9.zip and the other pointing to http://some.place.else.xyz/legacy/Netbeans8.2.zip, is that consider distribution from an Apache POV? Even if the links look identical the fact they source from different infrastructure makes it "ok"? Or does there need to be a link to some.place.else.xyz where they have their own web pages discussing downloading and distributing those artifacts? Has Oracle made any mention of what they intend to do with the old artifacts (including the HG repo and binary artifacts) after nb.org is handed over? The HG repo is potentially important, as what's been mentioned before regarding versioning and such (notably of the platform) has been "if you can't keep up, use the older version". But it's not clear to me whether after the nb.org is handed over, ANY older versions will exist. Maybe as tags in the git repo? But can those be distributed from Apache git servers (as none of it is ASLd)? Those are the questions I have. Regards, Will Hartung
Re: [DISCUSS] NetBeans brand and domain transition to Apache
On Tue, Sep 4, 2018 at 11:19 AM Geertjan Wielenga wrote: > Note that Oracle has not, and will not, donate the canonical archive of > NetBeans to Apache. Only the tips of the source code that constitute > NetBeans are being donated. > So does that mean, for example, that after nb.org gets switched over (since all apache gets is the domain name, essentially), artifacts such as the binaries of NB <= 8.2 will not be available, since they're not being donated, and we can't rebuild them? Apart from the whether we can actually distribute them or not, we're not even getting them in the first place? Regards, Will Hartung
Re: Proposal: Apache NetBeans 10 for November release
I know there are a lot of modules that > go into Java EE support, so it will be tough to make it by November, but I > thought I should at least propose. > Honestly, that's a good reason to delay it. There is a LOT afoot in the JEE space right now, as they're going through a similar event as NB is. In the end, it's all a matter of who has the time and skills to do what. Ideally the bulk of the JEE is going to just a build and release. But with the disruption, I think another quarter won't hurt it. I don't know how many folks, as eager as they may be, are going to be jumping head first in to the new releases. We have solid 8.2 support for JEE, still, and the PHP and J11 sounds like actual new growth, which is good. But, as I said, in the end, if someone does the work, and vets the JEE stuff and makes it available, no reason NOT to release it. But if you wanted to make a coordinated push, I think letting JEE settled down a bit more would be good. Regards, Will Hartung
Re: Redirecting netbeans.org to netbeans.apache.org (without breaking stuff!)?
To be honest, the netbeans.org without the content doesn't really mean a whole lot. It kind of depends on whether were getting all of nb.org all at once, or if it's going to be trickled in. The next assumption is that the plan is to, indeed, "clone" (but perhaps, reskin), the nb.org content to nb.apache.org. If that's the case, then a deep-link redirector from nb.org/some/place/deep should redirect to nb.apache.org/some/place/deep in order as best as practical preserve blog and other non-google links. Google and the search engines will swap the stuff out over time, and likely fairly quickly. But blogs are forever, so it would be nice, at least for the mid-term, to not lose those links. There's over 10 years of links and stuff out there. Plopping them at the root isn't really useful. If the plan is start a new site, and trickle in the old content, then perhaps a deep rediretor to legacy.netbeans.apache.org/some/place/deep that DOES (if possible) host the old site would be useful. If that's not possible, then, honestly, netbeans.org doesn't really hold much value. The value of nb.org is not just the content, but also where it's located. If all of those legacy links are just going to be sheered up, then there's no reason to either keep nb.org at all, nor anything else. Just start with a new netbeans.apache.org, and add in any legacy content as appropriate. And none of this addresses what happens to old artifacts, which is unclear (at least to me) whether Apache can serve at all. It would be nice for folks to readily access what netbeans.org had to offer without have to hope the Wayback machine captured it. Regards, Will Hartung
Re: [DISCUSS] NetBeans brand and domain transition to Apache
On Thu, Aug 23, 2018 at 5:10 AM, Bertrand Delacretaz wrote: > Yes - I think the only requirement at this point is that the > *ownership* of the domains is transferred to Apache, moving the > content is a separate concern. > Is it even possible for the Apache foundation to distribute older artifacts if they have, for example, GPL licensed parts within them? Can they do it from "netbeans.org" as some sort of "off shore shell company" kind of thing? (since it's "not Apache", yes I know I'm splitting hairs). The NetBeans Apache Git server contains GPL code (since, as I understand it, it has direct donations from the Oracle contribution that were committed before the license change). It's pedantic, but how does this licensed code stand under Apache policies. Is it allowed as a "legacy" component? Can the original netbeans.org content also be grandfathered in under a similar exemption? One of the issues, to me, is the impact of having a large, established web presence just vanish in to the ether, which is what would happen were netbeans.org to either just "go away" or be significantly refactored. The destruction of java.net was, and still is, a painful event to the Java community. If netbeans.org is to be significantly redone, is there a reason for it at all beyond a redirect to netbeans.apache.org? Are there other Apache projects that have any significant web presence outside of the *.apache.org system? There is a LOT of stuff and history at netbeans.org. It would be nice (IMHO) if it were to remain mostly intact, and even maintained, as an anchor within the NetBeans community, especially the old artifacts and releases but also all of the documentation and tutorials. I'd hate for it to have to be a project to port all of those pages to someplace else. But I just don't know how much of a brand presence NetBeans can have out side of Apache. Not sure what the governance guidelines are like for that. Regards, Will Hartung
Re: JDK requirements for building NB
On Tue, Aug 21, 2018 at 12:48 PM, Matthias Bläsing < mblaes...@doppel-helix.eu> wrote: > Matthias, being happy, that his employer finally got Java 8 into > production... > Seriously, welcome to my world. And we're still not 100%, we still have stuff running on Glassfish 3, for example. With a new JDK coming out every 6 months, I think it will be resource intensive enough to get the IDE to support the prevailing JDK features, much less having to update the platform to build and run on it. Tying the platform to the LTS releases (whatever "LTS release" ends up truly meaning, if anything) should lessen that burden on the NB team, simply due to lower frequency. With JDK 11 on the horizon, and being flagged as ostensibly an LTS, it would make sense to jump up, try to catch up, and strive that NB 9+ (whatever THAT turns out to be) meets and greets JDK 11 as a first class citizen. If someone wants to track the 6 month JDK cycle, that's all well and good, but if bugs to the platform aren't being back ported, and only available on JDKs that users aren't using, its a disincentive for them to adopt it in the first place. You can see a company trying to adopt the NB platform and barely even getting a real project off the ground in 6 months, much less then having to catch up and change the JDK to keep up in the middle of their project. That time to catch up, retest, fix new issues, etc. is a drag on the overall project. That's why that stuff doesn't get done today, now. Would you rather spend the time on New Feature, or adopting a new underlying runtime that offers no visible New Features. All that time for the same CRUD screens. The entire point of the LTS is that they're something that companies can rely and plan around. I don't want to call the interim release "stable betas", but rather previews of things to come in the next LTS. Obviously, JDK adoption should not be arduous. But the JDK is moving REALLY fast right now, with engine changes, the divestiture of capabilities, etc. All that logic "they can just use the previous versions" applies to this team too. We can just "use the previous version" as it can have less of a ripple affect. Everything this team does affects the many users, which can make decisions such as these even more important. Regards, Will Hartung
Re: JDK requirements for building NB
On Tue, Aug 21, 2018 at 4:46 AM, Scott Palmer wrote: > This is not quite right. Anyone using the NB platform is not forced to > upgrade the platform they base their application on. The only thing that > happens is that the platform code base can hold them back as well from > building with new JDK features. > IMO the NB code base should support building on the latest released JDK > specifically because then it doesn’t hold others back that want to use new > Java features for their NB platform applications. But there's a difference between being able to be built on the latest JDK, and requiring the latest JDK to build/run. Regarding the LTS, while there may not be a (free) release from Oracle, it's still a symbolic line in the sand of compatibility that I would assume that the OpenJDK versions would track. i.e. OpenJDK v11 would be compatible with Oracle JDK v11 (for some spectrum of compatibility), and continue to track and sync with each other over time. That is, and I don't know, but is there any expectation that OpenJDK is going to be using its own versioning scheme? If that's the case, then "supporting JDK vXXX" brings on a completely different meaning if the implementations start to diverge. Regards, Will Hartung
Re: JDK requirements for building NB
On Mon, Aug 20, 2018 at 10:38 AM, Svata Dedic wrote: > Hi, > > we / you should also consider, before dropping JDK8 as a runtime platform, > that applications that build ON TOP of NetBeans platform may have a way > conservative requirements than developers who strive to use the bleeding > technology edge. > > The changes made in JDK9 (the module system, reflection restrictions etc) > are so disruptive that dropping JDK8 from platform (+ java) clusters may > disqualify NetBeans as an application platform of choice. > As I understand it, the Powers That Be plan on anointing some versions of Java as "Long Term Support", with the others being some kind of interim Java. The next version to offer LTS is, apparently, Java 11. The current LTS version is Java 8. If you want to hook NB to a particular Java version, an LTS version would be the best choice (IMHO). As mentioned above, when NB starts to require a specific Java Version, implicitly the NB PLATFORM will have the same requirements, and that "all of a sudden" has impact on projects outside of NB proper. NB should certainly support BUILDING projects on the latest and greatest Java versions, but that's different from the runtime requirements of NB itself. It would be NICE if NB CAN run on the latest Java Version, but, IMHO, it's not worth breaking changes if an older Java Binary does not run on a current Java that is not LTS. Since the LTS versions are supposed to be 3 years apart, that gives NB breathing room. Trying to keep up with Java versions arriving every 6mos to a year is just crazy make work, time which this team does not have. Finally, the "well folks running old stuff can run old versions" only goes so far. For an internet that has infinite memory, it's pretty amazing how truly fragmented the Java world is. The destruction of java.net certainly didn't help, but even Maven doesn't have older artifacts any more. There's a lot of legacy (and not even THAT legacy, 5 years..) code that simply can not be built any more as they relied on the distributed build model of maven with the false promise that The Internet would keep things around forever. When netbeans.org dies, is Apache going to host NB 6, 7, or 8 artifacts (much less the earlier artifacts)? So, it's important (I think) that a notion of backward compatibility is given some measure of priority, since folks do rely on these projects for their work. If the perception is update early, update often, and keep up to date. Forcing users to stay on the wavefront of change, then in some circles the popularity of the platform will drop. "keeping up" takes time and effort from everyone. Time folks might rather put in to enhancing their projects or fixing their own bugs instead of time taken to just keep along with the projects they use. "NB just dropped an update, there's goes 2 sprints of work to catch back up". Regards, Will Hartung
Re: Installers
On Tue, Aug 14, 2018 at 3:40 PM, Geertjan Wielenga < geertjan.wiele...@googlemail.com.invalid> wrote: > > Excellent. So, where is your DMG solution, please? > > Can you stop sending e-mails for the moment and create the solution that > you're missing? Yes, maybe you don't know how to do that, though maybe you > can invest the time that you would have spent in replying to this in > learning how to do what it is that you believe should be done? > Apparently you're only allowed to contribute to this list if you have a pull request pending. That's fine. But, before I go, it's was not even clear there was consensus on what to do, what was desired, and was positing potential alternatives. For all I know, folks would rather have a MacPorts or Homebrew solution and tell the MacOs users "Let them eat bash scripts!". That said, looking at the git zip download, there's most certainly evidence of the ability to create the Mac installers, which was kind of my base puzzle. These existed before, where's the scripts to build it? The actual build scripts I can't find, I don't know if they are on/lost with the Hudson server (I can't seem to connect to the one linked at the nb.org page). All of the hudson.* directories seem to relate to NetBeans hudson support, not the build. Finally, the Apache infrastructure has a build bot running on a Mac Mini. If the original build scripts can be found, and the proper permissions acquired on the Mac Build bot, then, ideally, the previous build can be ported to the new infrastructure. Ideally, this shouldn't have to be a clean room reinvention of the wheel if it were deigned to be something that the group still wanted to have supported. But, I don't know. Regards.
Re: Installers
On Tue, Aug 14, 2018 at 1:04 PM, Tim Boudreau wrote: > If anyone shows up on the mailing list complaining about performance, we > > can tell them to get rid of the image and copy the bundle over. > > > 99.9% of people who have that experience will NOT show up onn the mailing > list here. They'll simply use something else - perhaps blogging about the > experience, or writing something on social media, or telling friends "don't > use NetBeans". I was just thinking about this, and, while there may be others, Apache isn't that well known for it's "desktop" software. However, there's Apache DS Studio. Here's a link to their download page. https://directory.apache.org/studio/download/download-macosx.html I mentioned this simply to show that others are doing it within the Apache eco-system, so we should be able to also. I don't know if this is enough to mitigate the performance problems of not using an installer.
Re: Installers
On Tue, Aug 14, 2018 at 3:14 AM, Geertjan Wielenga < geertjan.wiele...@googlemail.com.invalid> wrote: > I created two YouTube clips during the past few hours that show the > ZIP-based and Mac Installer-based approaches to installing Apache NetBeans: > > https://www.youtube.com/watch?v=am-7aa2hYgc > > https://www.youtube.com/watch?v=I8gdC7BBtbs > Thanks for these. As a Mac user, and, especially compared to using a DMG or a DMG with an installer, these techniques are both, simply, terrible. Functional, they "get it done", but terrible. The second example with the Mac OS bundle is a nice "how to", but that shouldn't be a "sanctioned" mechanism for random Mac users to download and install NetBeans. Having a shell based launcher that leaves a terminal window sitting around with logs spamming, isn't really an ideal solution. This would be much less of a big deal if NetBeans didn't offer a Mac install experience before, with the DMG and the Installer. A DMG with a Drag and Drop bundle would be a fine halfway step which should be doable on a non-mac system (i.e. a linux system). If anyone shows up on the mailing list complaining about performance, we can tell them to get rid of the image and copy the bundle over.
Re: Installers
A DMG file is, effectively, a Mountable ZIP file. The "typical" Mac Installation process is to open the DMG file, a window appears with the Application bundle and a link to the Applications directory, and a big arrow, essentially telling you to drag the App in to the Applications folder. That's a "mac install". That's a "friendly" mac install. Digging stuff out of zip files is not as "mac friendly". Tim's point of moving to an Installer to essentially "force" folks to actually drag the app off of the DMG is interesting, and, honestly, not surprising. Because I know I've launched apps off of the DMG. Sometimes, I have just left them there. And I can certainly appreciate how it's a problem for something like NetBeans. NetBeans is almost 6000 files (!!), that's a lot of random seeking against a compressed stream in contrast to maybe a linked executable loading it a swarm of shared libraries from the OS. No wonder it's slow. The Installer never bothered me, I like the current installer. My only concern was that it needed admin rights. Not that I don't trust it, I just don't like apps that need admin rights - mostly because it acclimates users to just hit "OK" for every program install, which just leads to trouble.
Re: Installers
On Fri, Aug 10, 2018 at 1:10 PM, Kenneth Fogel wrote: > Yes, an installer is nice but all it should do on the Windows platform is > unzip NetBeans in the folder of choice and add a shortcut. > For some reason that I don't understand, and perhaps someone could explain, the installer for MacOS requires Administration privileges. Being that it, too, is essentially a "zip file" (it's an application bundle), I never really understood why it needs admin privs to install. Maybe it's some Mac specific thing.
Re: Setting breakpoints in NetBeans IDE dev code
On Fri, Aug 10, 2018 at 7:35 AM, mark stephens < marksteph...@idrsolutions.com> wrote: > I have identified a module I want to edit. I have opened the module in > NetBeans IDE and can reinstall it with reload it in target platform from > NetBeans IDE. I am now trying to figure out if I can set breakpoints and > step through the code in the IDE. > > Is this possible and any hints? > Should Just Work(tm). Should be able to set breakpoints, then Debug the module. What problems are you having?
Re: Integration of 2nd Donation -- re-licensing.
Looking at the wiki, I guess all of this work is essentially done already. Well, that was quick!
Re: ApacheCon Montreal NetBeans Presentation Suggestions
On Tue, Aug 7, 2018 at 11:09 AM, Geertjan Wielenga < geertjan.wiele...@googlemail.com.invalid> wrote: > Parts of that could be useful, though you probably want to focus on the key > features and demos and so on -- and I think you could do everything in > Apache NetBeans 9, after installing the plugins for the features you're > demo-ing: > > https://blogs.apache.org/netbeans/entry/what-s-happened-to-my > > Since you'll be at an Apache conference, I strongly recommend that you do > not use NetBeans 8.2, but Apache NetBeans (incubating) 9.0. > Honestly, I think this is a key point to get across. Demonstrate NB 9, using 8.2 plugins. It's confusing enough with the transition as it is, but demonstrating that a) 9 is out and b) it works with legacy stuff should help encourage folks that they can not just start using it, but rely on it. I'd even demonstrate getting some plugins. Like, perhaps, installing the PHP modules in to 9 live, to show how easy it is, and that NB 9 is not just a Java SE IDE. That way you kind of get a quick "state of netbeans" in to the discussion without fixating on it, and able to move ahead with actual NB demos.
Re: Apache NetBeans Release Cycle
On Tue, Aug 7, 2018 at 7:40 AM, Peter Steele wrote: > This is a personal thing but I would like to get the updates without > downloading a new version of the ide every time. Letting the ide auto > update would be nice. I guess that could only happen when the module update > issue is resolved > > It's a balance. There's a balance between speed and stability. It's a balance between convenience and control. I tend to not tweak and customize every little thing, and simply accept and work with the defaults. So, if those go about changing on me, it's quite disruptive. I tend to be conservative in my tools and favor stability and consistency over shiny features. Netbeans already supports in flight updates, but I like that it has numbered releases that are distinct from each other. It makes it easier to migrate at my pace, not when the update button lights up or someone decides to push something down. To me, the single great feature of Netbeans is that it's one stop shopping. You download it, and you get "everything" without having to hunt and peck and grab random modules from random websites and track a zillion different paths of compatibility. That's the stability that a numbered release offers, vs a ball of mud of random, incremental updates, especially if there are inter dependencies where updating one module causes a cascade effect.
Integration of 2nd Donation -- re-licensing.
Sorry for the new thread, but I just subscribed, so I can't "reply" to the original one. Geertjan mentioned that y'all need some help simply re-licensing the new source base. That sounds like basic labor that even I could do. However, I'd need some specific instructions on how to go about it, because, simply, I don't know git. And I don't know github, not with any comfort level. So, with the goal would be to be more of an asset than a hindrance, I'd need a cheat sheet of what to check out, and how to commit and create "pull requests", or whatever, appropriately. I'd need sample commands not just "submit a pull request". Is the location of the source code still in question? I'm not quite following the discussion of whether or not it was indeed merged in to master. So. Anyway, if someone is willing to point me in the right direction, I should be able to hopefully get some modules re-licensed for y'all. Regards, Will Hartung
