Dear community,
let's update the Apache NetBeans Language Server extension on VSCode
Marketplace with improved version 16.0.301 and updated 3rd party npms without
CVEs.
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/16.0.301/
The primary voting artifact is the source
https:/
Hi,
I think Matthias Bläsing (correct me if I’m wrong) knows how to sign, but the
question here is why do we need to sign plugins that were already verified for
earlier NetBeans versions, what changed in NetBeans 17 that we need the signing
now?
I did get the same response for my plugins and I
Hi a more detailed explanation, believe they need to be signed with a key
included on keystore a more.
*1-* Use java key tool on command line
keytool -genkey -keyalg RSA -alias *my-key-alias-key* -keystore
*keystore.jks* -validity 365
Answer all question and password.
*2-* Include on pom.xml
Hi,
yes, I know how I can sign JARs/NBMs, the point is: This was not
necessary for multiple NetBeans releases. I'm missing the explanation
why something, that was fine for at least 5, releases is now a problem.
That communication did not happen and was not discussed here.
Greetings
Matthias
Am
I believe they need to be signed with a key included on keystore
*1-* Use java key tool:
keytool -genkey -keyalg RSA -alias my-key-alias-key -keystore keystore.jks
-validity 365
*2-* Include on pom.xml
org.apache.netbeans.utilities
nbm-maven-plugin
Hi,
I asked for reverification of three plugins. These plugins:
- PlantUML-NB
- LDIF Editor
- LDAP Explorer
are verified for NB 11.0/12.0 till NB 16 version. Nothing was changed
on the plugins for 17 and now the plugins are not good enough anymore.
So what is going on?
They are rejected, becaus
I think you are hitting a series of "edge" cases. I put the edge in quotes
as, most probably, they shouldn't be.
1. I've seen the CRC32C exception in Gradle from time to time, especially
when dealing with modular applications.
2. Yes it's true Java Toolchain is not fully supported in NB17, the
boo
Hi all,
Doing my usual trawl through the issue space leading up to releases.
It's not quite as bad as the JIRA was .. yet! :-)
We've got about 13 pages of issues with needs:triage on them at the
moment. A lot of those have responses on them already. It's possible
we should have used a different
Yes.. well maybe...
For that project the source level is set to 17, but the Java Runtime for
Gradle execution is set to JDK 19. The build.gradle file uses the
toolchain mechanism to specify JDK 17. The JDK 19 reference is likely left
over from some experiments. They are all valid JDK folders, but
On Mon, 30 Jan 2023 at 00:16, Scott Palmer wrote:
> More failures to rename...
> ...
> Even though the source level of ... is set to: 17, java.util.zip.CRC32C
> cannot be found on the system module
> path:
That seems suspicious. Are you sure the jdkhome for the IDE and any
per-project platform
10 matches
Mail list logo
