[netbeans] branch master updated (60d04ff -> 98ae034)
This is an automated email from the ASF dual-hosted git repository. jtulach pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/netbeans.git. from 60d04ff Merge pull request #3163 from sdedic/bugfix/classpath-copy new a69dca3 Concentrating I/O access into two package private classes: RandomAccessFile and File new 1998eb2 Concentrating stderr access into Systems class new efeae90 Eliminate dependency on Swing and SwingUtilities.invokeLater new 938dcf0 Using java.util.logging API instead of System.err access new 01c307f Using enum to classify types of progress events new c4e3ed9 Avoid static state by introducing File.Factory new a3162ad Abstracting away access to File and RandomAccessFile new b89acf5 Proper name of the logger new 98ae034 Merge pull request #3159 from JaroslavTulach/jtulach/IndirectFileAccess The 5871 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../lib/profiler/heap/AbstractLongMap.java | 91 +-- .../netbeans/lib/profiler/heap/CacheDirectory.java | 32 +-- .../org/netbeans/lib/profiler/heap/ClassDump.java | 15 +- .../netbeans/lib/profiler/heap/DominatorTree.java | 20 +- .../src/org/netbeans/lib/profiler/heap/File.java | 62 + .../netbeans/lib/profiler/heap/HeapFactory.java| 21 +- .../netbeans/lib/profiler/heap/HeapProgress.java | 52 ++-- .../lib/profiler/heap/HprofByteBuffer.java | 11 +- .../lib/profiler/heap/HprofFileBuffer.java | 10 +- .../org/netbeans/lib/profiler/heap/HprofHeap.java | 99 --- .../profiler/heap/HprofLongMappedByteBuffer.java | 24 +- .../lib/profiler/heap/HprofMappedByteBuffer.java | 15 +- .../org/netbeans/lib/profiler/heap/JavaIoFile.java | 303 + .../org/netbeans/lib/profiler/heap/LongBuffer.java | 16 +- .../org/netbeans/lib/profiler/heap/LongMap.java| 8 +- .../netbeans/lib/profiler/heap/NearestGCRoot.java | 22 +- .../org/netbeans/lib/profiler/heap/NumberList.java | 20 +- .../org/netbeans/lib/profiler/heap/Progress.java | 112 .../lib/profiler/heap/RandomAccessFile.java| 36 +++ .../lib/profiler/heap/StackFrameSegment.java | 2 +- .../lib/profiler/heap/StackTraceSegment.java | 2 +- .../netbeans/lib/profiler/heap/StringSegment.java | 2 +- .../org/netbeans/lib/profiler/heap/Systems.java| 47 .../org/netbeans/lib/profiler/heap/TreeObject.java | 10 +- 24 files changed, 743 insertions(+), 289 deletions(-) create mode 100644 profiler/lib.profiler/src/org/netbeans/lib/profiler/heap/File.java create mode 100644 profiler/lib.profiler/src/org/netbeans/lib/profiler/heap/JavaIoFile.java create mode 100644 profiler/lib.profiler/src/org/netbeans/lib/profiler/heap/Progress.java create mode 100644 profiler/lib.profiler/src/org/netbeans/lib/profiler/heap/RandomAccessFile.java create mode 100644 profiler/lib.profiler/src/org/netbeans/lib/profiler/heap/Systems.java - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Assigned] (NETBEANS-6000) netbeans 12.4 error
[ https://issues.apache.org/jira/browse/NETBEANS-6000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nezar jhons ayad reassigned NETBEANS-6000: -- Attachment: TextInputControl_217.dump Fix Version/s: 12.4 Affects Version/s: 12.4 Assignee: nezar jhons ayad Due Date: 14/Sep/21 Priority: Critical (was: Major) > netbeans 12.4 error > > > Key: NETBEANS-6000 > URL: https://issues.apache.org/jira/browse/NETBEANS-6000 > Project: NetBeans > Issue Type: Bug >Affects Versions: 12.4 >Reporter: nezar jhons ayad >Assignee: nezar jhons ayad >Priority: Critical > Fix For: 12.4 > > Attachments: TextInputControl_217.dump > > > Annotation: An error occurred during parsing of > 'javafx.controls/javafx/scene/control/TextInputControl.java in C:\Program > Files\Java\zulu16.30.15-ca-fx-jdk16.0.1-win_x64\lib\src.zip'. Please report a > bug against java/source and attach dump file > 'C:\Users\Nezar\AppData\Roaming\NetBeans\12.4\var\log\TextInputControl_217.dump'. > Annotation: An error occurred during parsing of > 'javafx.controls/javafx/scene/control/TextInputControl.java in C:\Program > Files\Java\zulu16.30.15-ca-fx-jdk16.0.1-win_x64\lib\src.zip'. Please report a > bug against java/source and attach dump file > 'C:\Users\Nezar\AppData\Roaming\NetBeans\12.4\var\log\TextInputControl_217.dump'. > An error occurred during parsing of > 'javafx.controls/javafx/scene/control/TextInputControl.java in C:\Program > Files\Java\zulu16.30.15-ca-fx-jdk16.0.1-win_x64\lib\src.zip'. Please report a > bug against java/source and attach dump file > 'C:\Users\Nezar\AppData\Roaming\NetBeans\12.4\var\log\TextInputControl_217.dump'. > An error occurred during parsing of > 'javafx.controls/javafx/scene/control/TextInputControl.java in C:\Program > Files\Java\zulu16.30.15-ca-fx-jdk16.0.1-win_x64\lib\src.zip'. Please report a > bug against java/source and attach dump file > 'C:\Users\Nezar\AppData\Roaming\NetBeans\12.4\var\log\TextInputControl_217.dump'. > Caused: java.lang.AssertionError > at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) > at jdk.compiler/com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62) > at > jdk.compiler/com.sun.tools.javac.comp.Check.validateTypeAnnotation(Check.java:3055) > at > jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitAnnotation(Attr.java:5448) > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCAnnotation.accept(JCTree.java:2731) > at > jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) > at > jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57) > at > jdk.compiler/com.sun.tools.javac.tree.TreeScanner.visitModifiers(TreeScanner.java:367) > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCModifiers.accept(JCTree.java:2760) > at > jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) > at > jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitClassDef(Attr.java:5532) > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:790) > at > jdk.compiler/com.sun.tools.javac.comp.Attr.validateTypeAnnotations(Attr.java:5437) > at > jdk.compiler/com.sun.tools.javac.code.TypeAnnotations.lambda$validateTypeAnnotationsSignatures$1(TypeAnnotations.java:134) > at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:200) > at > jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144) > at > jdk.compiler/com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:157) > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterDone(JavaCompiler.java:1750) > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1071) > at > jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:345) > at > jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:282) > at > org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(JavacParser.java:710) > at > org.netbeans.modules.java.source.parsing.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:399) > at > org.netbeans.api.java.source.CompilationController.toPhase(CompilationController.java:88) > at > org.netbeans.api.java.source.ui.ElementJavadoc.lambda$getElementDocFromSource$16(ElementJavadoc.java:846) > at org.netbeans.api.java.source.JavaSource$MultiTask.run(JavaSource.java:502) > at > org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586) > at > org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:130) > at > org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:114) > at >
[jira] [Created] (NETBEANS-6000) netbeans 12.4 error
nezar jhons ayad created NETBEANS-6000: -- Summary: netbeans 12.4 error Key: NETBEANS-6000 URL: https://issues.apache.org/jira/browse/NETBEANS-6000 Project: NetBeans Issue Type: Bug Reporter: nezar jhons ayad Annotation: An error occurred during parsing of 'javafx.controls/javafx/scene/control/TextInputControl.java in C:\Program Files\Java\zulu16.30.15-ca-fx-jdk16.0.1-win_x64\lib\src.zip'. Please report a bug against java/source and attach dump file 'C:\Users\Nezar\AppData\Roaming\NetBeans\12.4\var\log\TextInputControl_217.dump'. Annotation: An error occurred during parsing of 'javafx.controls/javafx/scene/control/TextInputControl.java in C:\Program Files\Java\zulu16.30.15-ca-fx-jdk16.0.1-win_x64\lib\src.zip'. Please report a bug against java/source and attach dump file 'C:\Users\Nezar\AppData\Roaming\NetBeans\12.4\var\log\TextInputControl_217.dump'. An error occurred during parsing of 'javafx.controls/javafx/scene/control/TextInputControl.java in C:\Program Files\Java\zulu16.30.15-ca-fx-jdk16.0.1-win_x64\lib\src.zip'. Please report a bug against java/source and attach dump file 'C:\Users\Nezar\AppData\Roaming\NetBeans\12.4\var\log\TextInputControl_217.dump'. An error occurred during parsing of 'javafx.controls/javafx/scene/control/TextInputControl.java in C:\Program Files\Java\zulu16.30.15-ca-fx-jdk16.0.1-win_x64\lib\src.zip'. Please report a bug against java/source and attach dump file 'C:\Users\Nezar\AppData\Roaming\NetBeans\12.4\var\log\TextInputControl_217.dump'. Caused: java.lang.AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) at jdk.compiler/com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62) at jdk.compiler/com.sun.tools.javac.comp.Check.validateTypeAnnotation(Check.java:3055) at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitAnnotation(Attr.java:5448) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCAnnotation.accept(JCTree.java:2731) at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57) at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.visitModifiers(TreeScanner.java:367) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCModifiers.accept(JCTree.java:2760) at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitClassDef(Attr.java:5532) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:790) at jdk.compiler/com.sun.tools.javac.comp.Attr.validateTypeAnnotations(Attr.java:5437) at jdk.compiler/com.sun.tools.javac.code.TypeAnnotations.lambda$validateTypeAnnotationsSignatures$1(TypeAnnotations.java:134) at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:200) at jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144) at jdk.compiler/com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:157) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterDone(JavaCompiler.java:1750) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1071) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:345) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:282) at org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(JavacParser.java:710) at org.netbeans.modules.java.source.parsing.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:399) at org.netbeans.api.java.source.CompilationController.toPhase(CompilationController.java:88) at org.netbeans.api.java.source.ui.ElementJavadoc.lambda$getElementDocFromSource$16(ElementJavadoc.java:846) at org.netbeans.api.java.source.JavaSource$MultiTask.run(JavaSource.java:502) at org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:130) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:114) at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181) at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178) at org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153) at org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335) at org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118) at org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67) at org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178) at
[jira] [Created] (NETBEANS-5999) netbeans 12.4
nezar jhons ayad created NETBEANS-5999: -- Summary: netbeans 12.4 Key: NETBEANS-5999 URL: https://issues.apache.org/jira/browse/NETBEANS-5999 Project: NetBeans Issue Type: Bug Reporter: nezar jhons ayad AppData\Roaming\NetBeans\12.4\var\log\TextInputControl_186.dump'. Caused: java.lang.AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) at jdk.compiler/com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62) at jdk.compiler/com.sun.tools.javac.comp.Check.validateTypeAnnotation(Check.java:3055) at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitAnnotation(Attr.java:5448) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCAnnotation.accept(JCTree.java:2731) at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57) at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.visitModifiers(TreeScanner.java:367) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCModifiers.accept(JCTree.java:2760) at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitClassDef(Attr.java:5532) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:790) at jdk.compiler/com.sun.tools.javac.comp.Attr.validateTypeAnnotations(Attr.java:5437) at jdk.compiler/com.sun.tools.javac.code.TypeAnnotations.lambda$validateTypeAnnotationsSignatures$1(TypeAnnotations.java:134) at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:200) at jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144) at jdk.compiler/com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:157) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterDone(JavaCompiler.java:1750) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1071) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:345) at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:282) at org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(JavacParser.java:710) at org.netbeans.modules.java.source.parsing.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:399) at org.netbeans.api.java.source.CompilationController.toPhase(CompilationController.java:88) at org.netbeans.api.java.source.ui.ElementJavadoc.lambda$getElementDocFromSource$16(ElementJavadoc.java:846) at org.netbeans.api.java.source.JavaSource$MultiTask.run(JavaSource.java:502) at org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:130) at org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:114) at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181) at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178) at org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153) at org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335) at org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118) at org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67) at org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178) at org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:81) at org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:452) at org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:423) at org.netbeans.api.java.source.ui.ElementJavadoc.getElementDocFromSource(ElementJavadoc.java:845) at org.netbeans.api.java.source.ui.ElementJavadoc.getElementDoc(ElementJavadoc.java:742) at org.netbeans.api.java.source.ui.ElementJavadoc.(ElementJavadoc.java:369) at org.netbeans.api.java.source.ui.ElementJavadoc.create(ElementJavadoc.java:172) at org.netbeans.modules.editor.java.JavaCompletionProvider$JavaCompletionQuery$3.create(JavaCompletionProvider.java:235) at org.netbeans.modules.editor.java.JavaCompletionProvider$JavaCompletionQuery$3.create(JavaCompletionProvider.java:231) at org.netbeans.modules.java.completion.JavaDocumentationTask.resolve(JavaDocumentationTask.java:91) at org.netbeans.modules.java.completion.BaseTask.run(BaseTask.java:94) at org.netbeans.modules.java.completion.JavaDocumentationTask.run(JavaDocumentationTask.java:42) at org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586) at
[netbeans] branch master updated: Return a copy instead of cached array
This is an automated email from the ASF dual-hosted git repository.
sdedic pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
The following commit(s) were added to refs/heads/master by this push:
new 3fc65de Return a copy instead of cached array
new 60d04ff Merge pull request #3163 from sdedic/bugfix/classpath-copy
3fc65de is described below
commit 3fc65de9579d6e81da8a6ddf6de2d4939347e3f8
Author: Svata Dedic
AuthorDate: Sun Sep 12 10:13:44 2021 +0200
Return a copy instead of cached array
---
.../src/org/netbeans/api/java/classpath/ClassPath.java | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
a/ide/api.java.classpath/src/org/netbeans/api/java/classpath/ClassPath.java
b/ide/api.java.classpath/src/org/netbeans/api/java/classpath/ClassPath.java
index 83364f6..9842730 100644
--- a/ide/api.java.classpath/src/org/netbeans/api/java/classpath/ClassPath.java
+++ b/ide/api.java.classpath/src/org/netbeans/api/java/classpath/ClassPath.java
@@ -241,7 +241,7 @@ public final class ClassPath {
long current;
synchronized (this) {
if (rootsCache != null) {
-return this.rootsCache;
+return rootsCache.clone();
}
current = this.invalidRoots;
}
@@ -256,9 +256,9 @@ public final class ClassPath {
if (rootsCache == null || rootsListener == null) {
attachRootsListener();
listenOnRoots(rootPairs);
-this.rootsCache = roots;
+this.rootsCache = roots.clone();
} else {
-roots = this.rootsCache;
+roots = rootsCache.clone();
}
}
}
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
svn commit: r49924 - in /dev/netbeans/netbeans/12.5-installers/macosx: ./ Apache-NetBeans-12.5-bin-macosx.dmg Apache-NetBeans-12.5-bin-macosx.dmg.asc Apache-NetBeans-12.5-bin-macosx.dmg.sha512
Author: johnmcdonnell Date: Mon Sep 13 17:31:00 2021 New Revision: 49924 Log: Creating Apache NetBeans 12.5 MAC OSX Installer Added: dev/netbeans/netbeans/12.5-installers/macosx/ dev/netbeans/netbeans/12.5-installers/macosx/Apache-NetBeans-12.5-bin-macosx.dmg (with props) dev/netbeans/netbeans/12.5-installers/macosx/Apache-NetBeans-12.5-bin-macosx.dmg.asc dev/netbeans/netbeans/12.5-installers/macosx/Apache-NetBeans-12.5-bin-macosx.dmg.sha512 Added: dev/netbeans/netbeans/12.5-installers/macosx/Apache-NetBeans-12.5-bin-macosx.dmg == Binary file - no diff available. Propchange: dev/netbeans/netbeans/12.5-installers/macosx/Apache-NetBeans-12.5-bin-macosx.dmg -- svn:mime-type = application/octet-stream Added: dev/netbeans/netbeans/12.5-installers/macosx/Apache-NetBeans-12.5-bin-macosx.dmg.asc == --- dev/netbeans/netbeans/12.5-installers/macosx/Apache-NetBeans-12.5-bin-macosx.dmg.asc (added) +++ dev/netbeans/netbeans/12.5-installers/macosx/Apache-NetBeans-12.5-bin-macosx.dmg.asc Mon Sep 13 17:31:00 2021 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCAAdFiEE3ouPsrIjyE9FFC3JPtR3dQwJ0Y0FAmE/h5AACgkQPtR3dQwJ +0Y3NLw/+Kqrg56ar6H4eCWg2XTEvoyKFUC10jMFA7DFnt+NnBHLi1QPkb3jUWyD0 +1sdN7hNsOrRE6DQ3r1QDLlNIN9+vxCT13XpanReFmuu0duv1hfAGdyVB56OlfJst ++JPA/PrjRGinCcPInhJrKsBpKe4zpQq/GCpwwGY936I+WRUfR4V8KfpF0FttZedS +ZW0k9TcM7o+Hdx6Ip3Lp+msIa4o4iDSivGj2mdiJQG8rwQnxXvxgj1OqAlUw2kSA +8A/vE+8bU1u6SYJReWzbpzH3GchHiTH5u6Jn2Py3S12+G+rdMBom6R4VdNAElYIA +QRu/dNuXiiF7/0aAaJDWCvotqgXaIL03RFaivDgebM+5GzJFt+vqo0UpQ+sFJQt2 +6Ebz2CCXxpCbtfacTigF7+4tTtUWCqIl6M7+R5JLgTw9cIP5AxwsNH5joMe7WMIo +tKjgGPyLdu4qaF+gdUexVSycl7CdG4RKr61f0wlOTvtcJ53EwReYdP9fkTG5rHpP +mGWE18auojWt/VP4stgla3oFiWhyExhPGQeKwjzX/ATR1aJbRX/VeVwBtFWOkzFH +gKMpcXNxy2fm/YG7pB9Thaq6v5ura5wpqwyRM8YGqdsPztjKx6qjLOT5vwR1G3LD +xzaF650P5swpoLlhX38cww1qACA4Ua4vamBhuI5Z7SXCN+Y94UU= +=TREZ +-END PGP SIGNATURE- Added: dev/netbeans/netbeans/12.5-installers/macosx/Apache-NetBeans-12.5-bin-macosx.dmg.sha512 == --- dev/netbeans/netbeans/12.5-installers/macosx/Apache-NetBeans-12.5-bin-macosx.dmg.sha512 (added) +++ dev/netbeans/netbeans/12.5-installers/macosx/Apache-NetBeans-12.5-bin-macosx.dmg.sha512 Mon Sep 13 17:31:00 2021 @@ -0,0 +1 @@ +341041fbd6c3595bff57b93d20c312d4b3fc16fa59152513dc5e32b6882faf55e9682ce785cdfd8223742a36c07c73d20a4d327d0401d14192c9142cd091cb81 Apache-NetBeans-12.5-bin-macosx.dmg - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans IDE
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Summary: Using groovy compiler for parsing, code completion and navigation in NetBeans IDE (was: Using groovy compiler for parsing, code completion and navigation in NetBeans) > Using groovy compiler for parsing, code completion and navigation in NetBeans > IDE > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute the IDE related fixes to > the Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of writing Groovy in the NetBeans > IDE (and its derivatives like VSCode) better, richer, easier to use, faster > to gain response and overall more reliable. In particular the IDE has to be > able to deal with broken code (user code in editor is broken most of the > time) - as such we expect fixes in the area of error recovery to make the > parser more bulletproof and robust. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present them to the user in a reasonable and > valuable way. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of writing Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. In particular the IDE has to be able to deal with broken code (user code in editor is broken most of the time) - as such we expect fixes in the area of error recovery to make the parser more bulletproof and robust. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present them to the user in a reasonable and valuable way. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. In particular the IDE has to be able to deal with broken code (user code in editor is broken most of the time) - as such we expect fixes in the area of error recovery to make the parser more bulletproof and robust. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present them to the user in a reasonable and valuable way. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute the IDE related fixes to > the Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of writing Groovy in the NetBeans > IDE (and its derivatives like VSCode) better, richer, easier to use, faster > to gain response and overall more reliable. In particular the IDE has to be > able to deal with
[jira] [Commented] (NETBEANS-2360) HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux
[ https://issues.apache.org/jira/browse/NETBEANS-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17414303#comment-17414303 ] Eirik Bakke commented on NETBEANS-2360: --- I tested the sun.java2d.uiScale property, but it doesn't support fractional scalings either. So I'll keep using GDK_SCALE, which is more official. Would still be good to figure out how to detect the 2x scaling on openSUSE Tumbleweed/KDE. [~hlavki] Do you have multiple monitors, by the way, or just the one shown in your control panel screenshot? > HiDPI scaling (and anti-aliasing on KDE) not applied automatically on Linux > --- > > Key: NETBEANS-2360 > URL: https://issues.apache.org/jira/browse/NETBEANS-2360 > Project: NetBeans > Issue Type: Bug > Components: platform - LaunchersCLI >Affects Versions: 11.0, 12.2 > Environment: Kubuntu 18.03 > Oracle JDK 11.0.2 >Reporter: Eirik Bakke >Priority: Major > Labels: HiDPI, Linux, pull-request-available > Attachments: image-2021-09-12-21-01-33-807.png, > image-2021-09-12-21-05-06-852.png, kubunt.jpg > > Time Spent: 50m > Remaining Estimate: 0h > > Running NetBeans 11 on Kubuntu 18.03, GUI text size does not seem to take > into account the system's default HiDPI scaling. This was reported in a > Twitter thread on https://twitter.com/nicktail/status/1114789604337405952 . > Note that Window decorations seem to be the correct size. > Setting the GDK_SCALE environment variable seems to fix the problem, if I > understand the originally reporter correctly. This could probably be done > easily from the NetBeans launcher script (netbeans/bin). But it wouldn't fix > the problem in multi-monitor setups. We should investigate what could be done > to make scaling work properly in multi-monitor setups involving one HiDPI > screen and one non-HiDPI screen. > Before merging a patch to the launcher script, it should be tested on a > couple of different Linux environments, using both HiDPI and non-HiDPI > screens. Note that the UNIX launcher script is also used on MacOS. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. In particular the IDE has to be able to deal with broken code (user code in editor is broken most of the time) - as such we expect fixes in the area of error recovery to make the parser more bulletproof and robust. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present them to the user in a reasonable and valuable way. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present them to the user in a reasonable and valuable way. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute the IDE related fixes to > the Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE (and its derivatives like VSCode) better, richer, easier to use, faster > to gain response and overall more reliable. In particular the IDE has to be > able to deal with broken code (user code in editor is broken most of the > time) - as such we expect fixes in the area of error recovery to make the > parser more bulletproof and robust. > Some of the reported issues may feel
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present them to the user in a reasonable and valuable way. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute the IDE related fixes to > the Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE (and its derivatives like VSCode) better, richer, easier to use, faster > to gain response and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present them to the user in a reasonable and > valuable way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute the IDE related fixes to > the Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE (and its derivatives like VSCode) better, richer, easier to use, faster > to gain response and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present it to the user. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute the IDE related fixes to > the Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE and derivatives better, richer, easier to use, faster to gain response > and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present it to the user. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail:
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real compiler allowed NetBeans to keep the WYSIWYG experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real compiler allowed NetBeans to keep the WYSIWYG experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it turns on the > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real compiler allowed > NetBeans to keep the WYSIWYG experience (the errors reported in the editor > are exactly the same as on command line or continuous integration) with > relatively low effort. However maintaining a fork turned out to be costly and > we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to > do even better. We want to contribute IDE related fixes to the Groovy > compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE and derivatives better, richer, easier to use, faster to gain response > and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present it to the user. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the WYSIWYG experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real compiler allowed NetBeans to keep the WYSIWYG experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the WYSIWYG experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute IDE related fixes to the > Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE and derivatives better, richer, easier to use, faster to gain response > and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present it to the user. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the WYSIWYG experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute IDE related fixes to the > Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE and derivatives better, richer, easier to use, faster to gain response > and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present it to the user. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real compiler allowed NetBeans to keep the WYSIWYG experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it turns on the was: Umbrella issue, that could help to collect dependent errors filed in Groovy. Maybe it could be split to an issue tracking possible improvements and an issue that tracks improvment necessary for the next release. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real compiler allowed > NetBeans to keep the WYSIWYG experience (the errors reported in the editor > are exactly the same as on command line or continuous integration) with > relatively low effort. However maintaining a fork turned out to be costly and > we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to > do even better. We want to contribute IDE related fixes to the Groovy > compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE and derivatives better, richer, easier to use, faster to gain response > and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it turns on the -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Summary: Using groovy compiler for parsing, code completion and navigation in NetBeans (was: Groovy compiler / parser bugs affecting NB code completion) > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > Umbrella issue, that could help to collect dependent errors filed in Groovy. > Maybe it could be split to an issue tracking possible improvements and an > issue that tracks improvment necessary for the next release. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
svn commit: r49923 [2/3] - in /dev/netbeans/netbeans/12.5-installers: ./ linux/ windows/
Added:
dev/netbeans/netbeans/12.5-installers/linux/Apache-NetBeans-12.5-bin-linux-x64.sh
==
---
dev/netbeans/netbeans/12.5-installers/linux/Apache-NetBeans-12.5-bin-linux-x64.sh
(added)
+++
dev/netbeans/netbeans/12.5-installers/linux/Apache-NetBeans-12.5-bin-linux-x64.sh
Mon Sep 13 15:55:28 2021
@@ -0,0 +1,1659761 @@
+#!/bin/sh
+#
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+#
+
+ARG_JAVAHOME="--javahome"
+ARG_VERBOSE="--verbose"
+ARG_OUTPUT="--output"
+ARG_EXTRACT="--extract"
+ARG_JAVA_ARG_PREFIX="-J"
+ARG_TEMPDIR="--tempdir"
+ARG_CLASSPATHA="--classpath-append"
+ARG_CLASSPATHP="--classpath-prepend"
+ARG_HELP="--help"
+ARG_SILENT="--silent"
+ARG_NOSPACECHECK="--nospacecheck"
+ARG_LOCALE="--locale"
+
+USE_DEBUG_OUTPUT=0
+PERFORM_FREE_SPACE_CHECK=1
+SILENT_MODE=0
+EXTRACT_ONLY=0
+SHOW_HELP_ONLY=0
+LOCAL_OVERRIDDEN=0
+APPEND_CP=
+PREPEND_CP=
+LAUNCHER_APP_ARGUMENTS=
+LAUNCHER_JVM_ARGUMENTS=
+ERROR_OK=0
+ERROR_TEMP_DIRECTORY=2
+ERROR_TEST_JVM_FILE=3
+ERROR_JVM_NOT_FOUND=4
+ERROR_JVM_UNCOMPATIBLE=5
+ERROR_EXTRACT_ONLY=6
+ERROR_INPUTOUPUT=7
+ERROR_FREESPACE=8
+ERROR_INTEGRITY=9
+ERROR_MISSING_RESOURCES=10
+ERROR_JVM_EXTRACTION=11
+ERROR_JVM_UNPACKING=12
+ERROR_VERIFY_BUNDLED_JVM=13
+
+VERIFY_OK=1
+VERIFY_NOJAVA=2
+VERIFY_UNCOMPATIBLE=3
+
+MSG_ERROR_JVM_NOT_FOUND="nlu.jvm.notfoundmessage"
+MSG_ERROR_USER_ERROR="nlu.jvm.usererror"
+MSG_ERROR_JVM_UNCOMPATIBLE="nlu.jvm.uncompatible"
+MSG_ERROR_INTEGRITY="nlu.integrity"
+MSG_ERROR_FREESPACE="nlu.freespace"
+MSG_ERROP_MISSING_RESOURCE="nlu.missing.external.resource"
+MSG_ERROR_TMPDIR="nlu.cannot.create.tmpdir"
+
+MSG_ERROR_EXTRACT_JVM="nlu.cannot.extract.bundled.jvm"
+MSG_ERROR_UNPACK_JVM_FILE="nlu.cannot.unpack.jvm.file"
+MSG_ERROR_VERIFY_BUNDLED_JVM="nlu.error.verify.bundled.jvm"
+
+MSG_RUNNING="nlu.running"
+MSG_STARTING="nlu.starting"
+MSG_EXTRACTING="nlu.extracting"
+MSG_PREPARE_JVM="nlu.prepare.jvm"
+MSG_JVM_SEARCH="nlu.jvm.search"
+MSG_ARG_JAVAHOME="nlu.arg.javahome"
+MSG_ARG_VERBOSE="nlu.arg.verbose"
+MSG_ARG_OUTPUT="nlu.arg.output"
+MSG_ARG_EXTRACT="nlu.arg.extract"
+MSG_ARG_TEMPDIR="nlu.arg.tempdir"
+MSG_ARG_CPA="nlu.arg.cpa"
+MSG_ARG_CPP="nlu.arg.cpp"
+MSG_ARG_DISABLE_FREE_SPACE_CHECK="nlu.arg.disable.space.check"
+MSG_ARG_LOCALE="nlu.arg.locale"
+MSG_ARG_SILENT="nlu.arg.silent"
+MSG_ARG_HELP="nlu.arg.help"
+MSG_USAGE="nlu.msg.usage"
+
+isSymlink=
+
+entryPoint() {
+initSymlinkArgument
+ CURRENT_DIRECTORY=`pwd`
+ LAUNCHER_NAME=`echo $0`
+ parseCommandLineArguments "$@"
+ initializeVariables
+ setLauncherLocale
+ debugLauncherArguments "$@"
+ if [ 1 -eq $SHOW_HELP_ONLY ] ; then
+ showHelp
+ fi
+
+message "$MSG_STARTING"
+createTempDirectory
+ checkFreeSpace "$TOTAL_BUNDLED_FILES_SIZE" "$LAUNCHER_EXTRACT_DIR"
+
+extractJVMData
+ if [ 0 -eq $EXTRACT_ONLY ] ; then
+searchJava
+ fi
+
+ extractBundledData
+ verifyIntegrity
+
+ if [ 0 -eq $EXTRACT_ONLY ] ; then
+ executeMainClass
+ else
+ exitProgram $ERROR_OK
+ fi
+}
+
+initSymlinkArgument() {
+testSymlinkErr=`test -L / 2>&1 > /dev/null`
+if [ -z "$testSymlinkErr" ] ; then
+isSymlink=-L
+else
+isSymlink=-h
+fi
+}
+
+debugLauncherArguments() {
+ debug "Launcher Command : $0"
+ argCounter=1
+while [ $# != 0 ] ; do
+ debug "... argument [$argCounter] = $1"
+ argCounter=`expr "$argCounter" + 1`
+ shift
+ done
+}
+isLauncherCommandArgument() {
+ case "$1" in
+ $ARG_VERBOSE | $ARG_NOSPACECHECK | $ARG_OUTPUT | $ARG_HELP |
$ARG_JAVAHOME | $ARG_TEMPDIR | $ARG_EXTRACT | $ARG_SILENT | $ARG_LOCALE |
$ARG_CLASSPATHP | $ARG_CLASSPATHA)
+ echo 1
+ ;;
+ *)
+ echo 0
+ ;;
+ esac
+}
+
+parseCommandLineArguments() {
+ while [ $# != 0 ]
+ do
+ case "$1" in
+ $ARG_VERBOSE)
+USE_DEBUG_OUTPUT=1;;
+
svn commit: r49923 [1/3] - in /dev/netbeans/netbeans/12.5-installers: ./ linux/ windows/
Author: skygo Date: Mon Sep 13 15:55:28 2021 New Revision: 49923 Log: Prepare installer for Apache NetBeans 12.5 Added: dev/netbeans/netbeans/12.5-installers/ dev/netbeans/netbeans/12.5-installers/linux/ dev/netbeans/netbeans/12.5-installers/linux/Apache-NetBeans-12.5-bin-linux-x64.sh dev/netbeans/netbeans/12.5-installers/linux/Apache-NetBeans-12.5-bin-linux-x64.sh.asc dev/netbeans/netbeans/12.5-installers/linux/Apache-NetBeans-12.5-bin-linux-x64.sh.sha512 dev/netbeans/netbeans/12.5-installers/windows/ dev/netbeans/netbeans/12.5-installers/windows/Apache-NetBeans-12.5-bin-windows-x64.exe (with props) dev/netbeans/netbeans/12.5-installers/windows/Apache-NetBeans-12.5-bin-windows-x64.exe.asc dev/netbeans/netbeans/12.5-installers/windows/Apache-NetBeans-12.5-bin-windows-x64.exe.sha512 - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
svn commit: r49923 [3/3] - in /dev/netbeans/netbeans/12.5-installers: ./ linux/ windows/
Added: dev/netbeans/netbeans/12.5-installers/linux/Apache-NetBeans-12.5-bin-linux-x64.sh.asc == --- dev/netbeans/netbeans/12.5-installers/linux/Apache-NetBeans-12.5-bin-linux-x64.sh.asc (added) +++ dev/netbeans/netbeans/12.5-installers/linux/Apache-NetBeans-12.5-bin-linux-x64.sh.asc Mon Sep 13 15:55:28 2021 @@ -0,0 +1,17 @@ +-BEGIN PGP SIGNATURE- + +iQJFBAABCgAvFiEEj+HCbxXgMg50C67YSiYBztqTgvMFAmE/bIARHHNreWdvQGFw +YWNoZS5vcmcACgkQSiYBztqTgvMK7BAAxWRsPQQKPYYHiraweHanpw9QxWzky63x +kXeBG0Rs6qSDoCQJWyLwefaHDgYuxK+Vz01WM2AA7ObstmHKPVO5WeR5naOB5Iut +Zc8JDrvNoEwMhueIpqp/I3oHcvaeIDxVvn5UNkMcln9OiF5SgQL8LEg/zCrHBCK9 +/qnJp2Uy1iU7923pX1VPRs8TK25qORyoMrAqQVWwmf5LrfLPAewK0583pd1oubb5 +cBVIAfQvoFD900V9bP3uRWAE/xPpY/mpQ+rSa3rkUsHduniaDXyLxQBxUj9Yv3yC +hk5nSjoIpNEE/3xurui1FGLt/T6u1HSm6JttiIDjxJNn/d/fcSEDP/5RdPC2h2Z5 +jVSRkh73nLTyuAcICPFBnvmKefnhZUT9a1DgFb1wMVp333RDI23yLA+lxsDnE1g3 +zQsafGOM5CJSj2d0Vb3mtVhSwLE/5DMPckOZiDHC1vCaYaMMVtsraq8i/Ur/kbIU +fhRSje8OHz46WEBoI+EOl0sPPpJ0nPVlZGS3gaIEtpea/pS+03e/E0tPLt0gBBYr +m2QbRJoVQdfpZsC1Zg+HzT8uL8NsqfKAVJAaP91ehAVvYqXTQegIywxuzsJ4ZIwL +IEB1/KgiA9QvaAdPfvZQWUWUBAIsXh6vaMZkdF76OLA5NrLh/lCBnh1aEKuML7EM +M4T0o5riIKs= +=39D5 +-END PGP SIGNATURE- Added: dev/netbeans/netbeans/12.5-installers/linux/Apache-NetBeans-12.5-bin-linux-x64.sh.sha512 == --- dev/netbeans/netbeans/12.5-installers/linux/Apache-NetBeans-12.5-bin-linux-x64.sh.sha512 (added) +++ dev/netbeans/netbeans/12.5-installers/linux/Apache-NetBeans-12.5-bin-linux-x64.sh.sha512 Mon Sep 13 15:55:28 2021 @@ -0,0 +1 @@ +6522c0be433765bb0eea6b75a35e120498574fa8be32d4f571be0b09964c744cc0f838d7148a7307e55e8bf24b5afbfedaf7299afdb1de27dc45819e23d6d550 Apache-NetBeans-12.5-bin-linux-x64.sh Added: dev/netbeans/netbeans/12.5-installers/windows/Apache-NetBeans-12.5-bin-windows-x64.exe == Binary file - no diff available. Propchange: dev/netbeans/netbeans/12.5-installers/windows/Apache-NetBeans-12.5-bin-windows-x64.exe -- svn:mime-type = application/octet-stream Added: dev/netbeans/netbeans/12.5-installers/windows/Apache-NetBeans-12.5-bin-windows-x64.exe.asc == --- dev/netbeans/netbeans/12.5-installers/windows/Apache-NetBeans-12.5-bin-windows-x64.exe.asc (added) +++ dev/netbeans/netbeans/12.5-installers/windows/Apache-NetBeans-12.5-bin-windows-x64.exe.asc Mon Sep 13 15:55:28 2021 @@ -0,0 +1,17 @@ +-BEGIN PGP SIGNATURE- + +iQJFBAABCgAvFiEEj+HCbxXgMg50C67YSiYBztqTgvMFAmE/cmARHHNreWdvQGFw +YWNoZS5vcmcACgkQSiYBztqTgvMhRg/9EpZzxLhM9VZNVVp0goqxzqYxUy/oIhQe +5VTMLP+ZXEiOd+lPtp11+yyg2AhDYzXkLXtwTDupNSJRYGfr6ZgqZHdnik+lCJeo +gd8+9mljK8x9Y0zVHj1rD6M5sX2PUj+yZ037GqSSGhrFB0mqV2L51954Aj8/yjxc +O3x/PeQXyvTqP+kvFOoW/H7JS2eG2AbcH9el/b3qj22PA6uGRWzQmtPiCPrtOPdS +T89SAoObvmA5/bhS3fCUSLiBXfH23EXuegxzvUCf9c0rEB9G4p55ylKSBLLab0dB +JZrBnU6gWARH3nzaB36/vL8GrTnKZLSFuMPAE6YsKkttblSUVN3BJzMmjfl3WUtN +jLejpVP6PUgKRQQzE9A5XSG3lJgHOb9dOE8s+GxvlnzCqPVXTcFrRWpv1pwUssfK +xxJ4nFJBGY7Qcb+BM0lPgY5EZvOuawgvweTuvdehSRYqsxqNujTSYgXJkrx59s+F +2sgordNJJW60PYk5ehn9Fzj/uUZQZSb01q3w9zm7X7drNmew/jM0a8cB9pL1w9bt +pjpTk54Cv+e4dicKtTVAQWHw/2TSmH2H2qsaS8VHfb7TnC+tu1PY0EZqU1phNkZN +yGWLh8flejyY/ikoI8//ooiWUvVmczZZATr8m+IAxnL2sZy8qRBgKaEe0farxedx +Rnlu/V8FPIg= +=PXAD +-END PGP SIGNATURE- Added: dev/netbeans/netbeans/12.5-installers/windows/Apache-NetBeans-12.5-bin-windows-x64.exe.sha512 == --- dev/netbeans/netbeans/12.5-installers/windows/Apache-NetBeans-12.5-bin-windows-x64.exe.sha512 (added) +++ dev/netbeans/netbeans/12.5-installers/windows/Apache-NetBeans-12.5-bin-windows-x64.exe.sha512 Mon Sep 13 15:55:28 2021 @@ -0,0 +1 @@ +c298e62b9fe1937de773972455e03cd756832ed9835e3c07ce25750c4efee5052d1b6f5c46d4acbcf03778ccd696540d999e194924f5be1e93e8da12ed69dc2b Apache-NetBeans-12.5-bin-windows-x64.exe - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-531) "Duplicate method name in class" when running maven app with CoS enabled
[ https://issues.apache.org/jira/browse/NETBEANS-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17414265#comment-17414265 ] Tim commented on NETBEANS-531: -- Yes, I have been getting this on 12.4 using the Maven projects. When I usually run a maven project the first time, then stop it and then try to run it again from inside the IDE I get this error. > "Duplicate method name in class" when running maven app with CoS > enabled > -- > > Key: NETBEANS-531 > URL: https://issues.apache.org/jira/browse/NETBEANS-531 > Project: NetBeans > Issue Type: Bug > Components: java - Classfile, java - Compiler, projects - Maven >Affects Versions: 9.0 > Environment: Apache NetBeans IDE Dev (Build > incubator-netbeans-release-205-on-20180202) on OpenJDK 64-Bit Server VM > 9.0.4.1+11, Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb) >Reporter: Eirik Bakke >Priority: Major > Attachments: duplicatenamesig.txt, lambda-bug.tar.gz > > > On several occasions, when running a Maven-based NetBeans Platform app from > the IDE, the app fails with the exception "java.lang.ClassFormatError: > Duplicate method name in class file > com/somepackage/project/actions/SomeClass$1". I suspect this might be related > to the Compile-on-Save infrastructure. See attached log. A clean build of the > entire project is then required in order to make the application runnable > again. > Previous versions of NetBeans required a clean build after changing > annotations (see Bugzilla bug > [221781|https://netbeans.org/bugzilla/show_bug.cgi?id=221781]). However, this > new error appears even when no annotations have been changed. The specific > error message shown here is also new to me--it did not appear in previous > NetBeans versions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
svn commit: r49918 - /dev/netbeans/netbeans-platform/12.5/ /dev/netbeans/netbeans/12.5/ /release/netbeans/netbeans-platform/12.5/ /release/netbeans/netbeans/12.5/
Author: skygo Date: Mon Sep 13 13:39:16 2021 New Revision: 49918 Log: Release of Apache NetBeans 12.5 Added: release/netbeans/netbeans-platform/12.5/ - copied from r49917, dev/netbeans/netbeans-platform/12.5/ release/netbeans/netbeans/12.5/ - copied from r49917, dev/netbeans/netbeans/12.5/ Removed: dev/netbeans/netbeans-platform/12.5/ dev/netbeans/netbeans/12.5/ - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[netbeans] branch master updated (58dade6 -> 50db454)
This is an automated email from the ASF dual-hosted git repository. sdedic pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/netbeans.git. from 58dade6 LSP: Surround With refactorings implemented. (#3157) new 76406e5 Added performance counters new efab051 Do not report unknown symbols in closures. new 106cdbb Performance: resources loaded from filesystems. new 50db454 Merge pull request #3165 from sdedic/prototype/static-typing-timing3 The 5860 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../modules/groovy/editor/api/GroovyIndexer.java | 12 +- .../groovy/editor/api/parser/GroovyParser.java | 93 -- .../editor/api/parser/NbGroovyErrorCollector.java | 52 ++- .../groovy/editor/compiler/ClassNodeCache.java | 200 +++- .../groovy/editor/compiler/CompilationUnit.java| 44 ++- .../editor/compiler/NbClassNodeResolver.java | 231 ++ .../modules/groovy/editor/compiler/PerfData.java | 184 +++ .../editor/compiler/PerfStatCompilationUnit.java | 353 + groovy/libs.groovy/nbproject/project.xml | 2 + 9 files changed, 1116 insertions(+), 55 deletions(-) create mode 100644 groovy/groovy.editor/src/org/netbeans/modules/groovy/editor/compiler/NbClassNodeResolver.java create mode 100644 groovy/groovy.editor/src/org/netbeans/modules/groovy/editor/compiler/PerfData.java create mode 100644 groovy/groovy.editor/src/org/netbeans/modules/groovy/editor/compiler/PerfStatCompilationUnit.java - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[netbeans] branch master updated: LSP: Surround With refactorings implemented. (#3157)
This is an automated email from the ASF dual-hosted git repository.
dbalek pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
The following commit(s) were added to refs/heads/master by this push:
new 58dade6 LSP: Surround With refactorings implemented. (#3157)
58dade6 is described below
commit 58dade642b6c3a123172d1dd966fc13b32b83d35
Author: Dusan Balek
AuthorDate: Mon Sep 13 09:37:03 2021 +0200
LSP: Surround With refactorings implemented. (#3157)
* LSP: Surround With refactorings implemented.
* LSP: Code templates added to code completion.
---
.../codetemplates/GsfCodeTemplateFilter.java | 14 +-
ide/editor.codetemplates/apichanges.xml| 12 +
.../nbproject/project.properties | 2 +-
ide/editor.codetemplates/nbproject/project.xml | 25 +-
.../lib/editor/codetemplates/AbbrevDetection.java | 2 +-
.../CodeTemplateCompletionProvider.java| 149 +-
.../CodeTemplateManagerOperation.java | 6 +-
.../lib/editor/codetemplates/SurroundWithFix.java | 2 +-
.../codetemplates/spi/CodeTemplateFilter.java | 18 ++
.../editor/java/JavaCodeTemplateFilter.java| 16 +-
.../netbeans/modules/editor/java/Utilities.java| 5 +-
.../java/editor/resources/DefaultAbbrevs.xml | 94 +++---
java/java.lsp.server/nbproject/project.xml | 9 +
.../ExtractSuperclassOrInterfaceRefactoring.java | 10 +-
.../java/lsp/server/protocol/MoveRefactoring.java | 8 +-
.../lsp/server/protocol/PullUpRefactoring.java | 10 +-
.../lsp/server/protocol/PushDownRefactoring.java | 15 +-
.../java/lsp/server/protocol/SurroundWithHint.java | 329 +
.../java/lsp/server/protocol/ServerTest.java | 79 +
19 files changed, 709 insertions(+), 96 deletions(-)
diff --git
a/ide/csl.api/src/org/netbeans/modules/csl/editor/codetemplates/GsfCodeTemplateFilter.java
b/ide/csl.api/src/org/netbeans/modules/csl/editor/codetemplates/GsfCodeTemplateFilter.java
index 8ddd4b2..ef98297 100644
---
a/ide/csl.api/src/org/netbeans/modules/csl/editor/codetemplates/GsfCodeTemplateFilter.java
+++
b/ide/csl.api/src/org/netbeans/modules/csl/editor/codetemplates/GsfCodeTemplateFilter.java
@@ -40,10 +40,9 @@ public class GsfCodeTemplateFilter implements
CodeTemplateFilter {
private int endOffset;
private Set templates;
-private GsfCodeTemplateFilter(JTextComponent component, int offset) {
-this.startOffset = offset;
-this.endOffset = component.getSelectionStart() == offset ?
component.getSelectionEnd() : -1;
-Document doc = component.getDocument();
+private GsfCodeTemplateFilter(Document doc, int startOffset, int
endOffset) {
+this.startOffset = startOffset;
+this.endOffset = endOffset;
CodeCompletionHandler completer = doc == null ? null :
GsfCompletionProvider.getCompletable(doc, startOffset);
if (completer != null) {
@@ -68,7 +67,12 @@ public class GsfCodeTemplateFilter implements
CodeTemplateFilter {
@Override
public CodeTemplateFilter createFilter(JTextComponent component, int
offset) {
-return new GsfCodeTemplateFilter(component, offset);
+return createFilter(component.getDocument(), offset,
component.getSelectionStart() == offset ? component.getSelectionEnd() : -1);
+}
+
+@Override
+public CodeTemplateFilter createFilter(Document doc, int startOffset,
int endOffset) {
+return new GsfCodeTemplateFilter(doc, startOffset, endOffset);
}
}
diff --git a/ide/editor.codetemplates/apichanges.xml
b/ide/editor.codetemplates/apichanges.xml
index 54177d6..63b6291 100644
--- a/ide/editor.codetemplates/apichanges.xml
+++ b/ide/editor.codetemplates/apichanges.xml
@@ -84,6 +84,18 @@ is the proper place.
+
+
+ Default method createFilter(Document, int,
int) added to CodeTemplateFilter.Factory.
+
+
+
+
+
+ Added method allows creating code template filters for the
given document and range.
+
+
+
Added ordering for code template
parameters.
diff --git a/ide/editor.codetemplates/nbproject/project.properties
b/ide/editor.codetemplates/nbproject/project.properties
index 561dc23..213ea65 100644
--- a/ide/editor.codetemplates/nbproject/project.properties
+++ b/ide/editor.codetemplates/nbproject/project.properties
@@ -20,6 +20,6 @@ javac.source=1.8
#javadoc.name=EditorCodeTemplates
javadoc.apichanges=${basedir}/apichanges.xml
javadoc.arch=${basedir}/arch.xml
-spec.version.base=1.56.0
+spec.version.base=1.57.0
test.config.stableBTD.includes=**/*Test.class
diff --git a/ide/editor.codetemplates/nbproject/project.xml
