foojayio / nbplugin2 Goto Github PK

Apache Commons probably supports it already...

Note: We may have plain .tar or .tar.gz (and even tar.z?)

In one way or another, ensure that the user knows that when they're on intel an aarch64 package will not be registered -- and/or handle this gracefully.

Check if current NetBeans still requires Java 8 or if is Java 11 acceptable.

In the "Connect to OpenJDK Discovery Service" tab, after an OpenJDK version is chosen, and then next is clicked, please show the actual file name of the bundle that will be downloaded, i.e., instead of (or in addition to "You have selected: Java 11", also show the full file name that of the file that is going to be downloaded.

See how to properly unzip the symbolic links and permissions. These are not good on macOS and I had to add a hack to at least make the bin/ apps executable.

...and oldest at the end. The LTS releases in the dropdown should be in bold or underlined to distinguish them.

When clicking an item in the table, display the file name of the file that will be downloaded for that item.

It would be nice to wholly delete a JDK if you don't need it. I think right now NetBeans just unregister it but leaves the files on disk. This might require new NB APIs perhaps.

On macOS (and, I suspect Linux) we get by with the command line unzip / tar.

We should test the module on Windows too.

Pure Java unzip should work, but it was never tested on Windows

tar.gz won't be unarchived at all on Windows (though... seems a low priority).

Download should be canceled when the user cancels the whole wizard.

Maybe provide a stop button right near the progress bar?

Not sure what to do when the users goes Back in the previous wizard step?

"Install Automatically for NetBeans" label -- could this be "Download, Install, and Automatically Register in NetBeans"

"Let me manually run the installer" label -- could this be "Download Only"

In the Quick tab, only the currently actively maintained JDKs should be shown, which are right now 15, 13, 11, 8, and 7. This info can be obtained from the Disco API.

Investigate how to also register Javadoc for installed JDKs.

This might also impact the discovery API since I suspect only few distro builders do provide a javadoc URL.

Check all dependencies to be Apache Foundations acceptable and include discoclient source code in plugin.

i.e., dmg, rpm, and msi.

Polish. Many error conditions we should handle.

Add checklist bellow once actionable tasks found.

As far as I can tell, NetBeans still expects to build on Java 8. This means that discoclient, which uses that Java 11 HttpClient cannot be included.

If the foojay backend has some documentation we could re-implement discoclient using some Java 8 APIs/libraries like the Apache Commons HttpClient 3.1 which NetBeans already includes.

Add some "show files on disk" checkbox and action for downloads we don't handles like .msi, exe, etc.

We could use https://docs.oracle.com/javase/7/docs/api/java/awt/Desktop.html#open(java.io.File) everywhere.

For macOS we have the action org.netbeans.modules.applemenu.ShowInFinder https://github.com/apache/netbeans/blob/6a9d4bdfa39bfdbbd1f60d22218818d3169348c5/platform/applemenu/src/org/netbeans/modules/applemenu/ShowInFinder.java

Use regular Ant build system from NetBeans.

Uploading to Maven Central was quite time consuming last I checked.

This issue should track the various steps involved:

• Read (I think?) https://central.sonatype.org/pages/ossrh-guide.html for Sonatype signup, etc.
• Ideally, discoclient could also be used from Maven Central
• Use GitHub Actions to do a Maven release from the project, ideally using the PGP key as some secret

The initial radio button pick takes a while, I suspect because the discoclient does a HTTP request in the event queue.

Related to #21. Seems to me an impl dependency is a bit brittle and for such a simple API call we could just take the classloader and use reflection.

For newer NetBeans versions, that make that API public (assuming the PR goes through) we could use normal API calls.

I.e., when I look in the Quick tab, I should see that 8 and 11 are LTS and the others are not.

We need access to that module to directly register an unarchived JDK.

It seems multiple modules are friend modules, including Payara.

We should:

• make a PR against NetBeans for friends access
• Remove impl dependency when PR is merged

I think users will be confused looking at this:

since they already have:

• Java Standard Edition
• Remote Java Standard Edition
• Remote Universal OpenJDK Service

Now, I think all of these have wrong makes but just looking at "Remote Universal OpenJDK Service" it's no obvious at all this is a way to download locally an OpenJDK build. Especially since it's called 'Remote xxx', ie. perhaps it has something to do with the other 'Remote Java Standard Edition' thing?

Not sure what a proper name would be, but something like "Download and install OpenJDK"?

Some disk cleanup would be nice, eg delete the zip if we unarchived it.

Maybe a checkbox ticked by default in the last step of the wizard.

Rather than letting the user put the download anywhere, provide a logical place to put it as a suggestion, e.g. (on Mac OS X):

/Users/geertjanwielenga/Library/Java/JavaVirtualMachines/openjdk-15.0.2

Hook quick download into Zulu archive (zip/tgz) packages for the current architecture / platform.

In the Quick tab, after browsing to a location, could the Next button be enabled, which would trigger the download, instead of forcing the user to click the Download button, i.e., that Download button and the action the user takes isn't needed, I think.

I find the current table with all the information too exhausting.

I suspect an user will just want to come quickly then:

• select a major verions (11, 15, etc)
• always a JDK (because... we can't even register a JRE I think?)
• pick a distribution
• always for his own architecture

So, for such a hit-and-run user we are providing way too many options.

Maybe we need an "advanced" mode for some of the users (which would be... the current UI) but maybe we don't need it at all.

For JDKs that the user needs for inside NetBeans we basically should always pick a zip/tgz file and not show anything else. Assuming the user wants to globally install a JDK (which is, I assume, desirable) we should pick the MSI/DMG but then... think of a way of helping through. Maybe offering an option of automatically scanning standard install paths and then provide the user a dialog of auto-registering the freshly downloads JDK (without having to manually go again through the wizard?)

A button "download in background" that allows the wizard to finish and shows you a progress in the status bar then a notification at the end would be more user friendly.

I think @HanSolo's discoclient should also be under the foojay2020 org so everything is in one place.

But... since I just tweaked my plugin because the client is during heavy development and the API is not stable I wonder if it wouldn't help for everything to use the same source repository. Then a class rename would easily propagate everywhere instead of me manually discovering what changed.

I encountered once a brief event queue lock due to this call:

"AWT-EventQueue-0" #23 prio=6 os_prio=31 cpu=7802.37ms elapsed=74.63s tid=0x00007fbd95a63800 nid=0x10b03 waiting for monitor entry  [0x000070000f791000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at io.foojay.support.Client.setOnEvt(Client.java:79)
- waiting to lock <0x000000070d650138> (a io.foojay.support.Client)
at io.foojay.support.DownloadPanel.addNotify(DownloadPanel.java:73)
at java.awt.Container.addImpl([email protected]/Container.java:1146)
- locked <0x0000000700b48f70> (a java.awt.Component$AWTTreeLock)
at java.awt.Container.add([email protected]/Container.java:997)
at org.openide.WizardDescriptor$WizardPanel.setRightComponent(WizardDescriptor.java:2998)

So, Client.setOnEvt should either use another thread or defer those listener registrations until the class is instantiated (just like a TODO there mentions).

We should internationalize all strings in the plugin. We don't have that many and the GUI designer already uses Bundle.properties. Only a few more left to add.

Considering how few strings we have we could probably push for one or two L10Ns like German (or Dutch? :-) )

By default we could download into a dedicated path, maybe follow the ~/.sdkman/ "standard" if there is one.

The wizard could optionally allow the user to customize a download folder.