[jira] [Created] (NETBEANS-5847) Allow headless NewFromTemplate

2021-07-09 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5847:
-

 Summary: Allow headless NewFromTemplate
 Key: NETBEANS-5847
 URL: https://issues.apache.org/jira/browse/NETBEANS-5847
 Project: NetBeans
  Issue Type: Bug
  Components: projects - Maven
Affects Versions: 12.5
Reporter: Svatopluk Dedic
Assignee: Svatopluk Dedic
 Fix For: Next


Gradle allows to use 'new from template' features in a headless environment, 
i.e. when running as a LSP server. Maven *WizardIterators* in 
*org.netbeans.modules.maven.newproject.idenative* could be turned into 
*CreateFromTemplateHandlers* similar to how Gradle iterator was done in 
[PR-2999|https://github.com/apache/netbeans/pull/2999]

 



--
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] [Resolved] (NETBEANS-5318) Gradle priming build in VSCode is asking again and again.

2021-07-09 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic resolved NETBEANS-5318.
---
Resolution: Fixed

> Gradle priming build in VSCode is asking again and again.
> -
>
> Key: NETBEANS-5318
> URL: https://issues.apache.org/jira/browse/NETBEANS-5318
> Project: NetBeans
>  Issue Type: Bug
>  Components: vscode
>Affects Versions: 12.3
> Environment: Ubuntu 20.04, GraalVM 21.0 Jdk 8.
>Reporter: Martin Balin
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans, pull-request-available
> Fix For: 12.4
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> Running VSNetBeans 12.3.286 with GraalVM Micronaut ext. Create Gradle MN 
> project.
> VSNB asks for Gradle priming build many times, message:
> "NetBeans is about to invoke a Gradle build process of the project: demog.
>  Executing Gradle can be potentially un-safe as it allows arbitrary code 
> execution."
> I always answered OK, but it was appearing again and again.
> After that i invoked "Java: Compile workspace" and it built and also problem 
> with underlined "package" statement went away, this is great.
> Should to be fixed for 12.3 final.
>  



--
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] [Resolved] (NETBEANS-5610) Gradle project loaded several times during project open

2021-07-09 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic resolved NETBEANS-5610.
---
Fix Version/s: 12.4
   Resolution: Fixed

> Gradle project loaded several times during project open
> ---
>
> Key: NETBEANS-5610
> URL: https://issues.apache.org/jira/browse/NETBEANS-5610
> Project: NetBeans
>  Issue Type: Bug
>  Components: lsp, projects - Gradle
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: performance, race-condition
> Fix For: 12.4
>
> Attachments: gradleproject.log
>
>
> To reproduce: get a LSP client, e.g. VSCode. get *micronaut-test* project, 
> which is multi-project. In the LSP client, open a source from *test-junit5*.
> I noticed that Gradle projects are loaded several times during LSP "project 
> open" operation. The project first aims for FALLBACK and only then for 
> FULL_ONLINE; maybe an issue with the 'priming' action.
> But immediately after that the project again loads FALLBACK (from a RP, 
> presumably a scheduled task from project open ?) and the *again* aiming FULL 
> (from the projectOpened hook).
> Finally the *parent* (root) project is opened - surprising at level FALLBACK 
> - from *WorkspaceServiceImpl.getTestRootURLs*. Not sure if this quality level 
> is sufficient for further operation: [~lkishalmi]  – what are the 
> implications of getting the container project just to FALLBACK quality ?
> // cc: [~dbalek]



--
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] [Created] (NETBEANS-5846) Gradle reports broken projects, but the build is just fine.

2021-07-08 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5846:
-

 Summary: Gradle reports broken projects, but the build is just 
fine.
 Key: NETBEANS-5846
 URL: https://issues.apache.org/jira/browse/NETBEANS-5846
 Project: NetBeans
  Issue Type: Bug
  Components: projects - Gradle
Affects Versions: 12.4, 12.5
Reporter: Svatopluk Dedic
Assignee: Laszlo Kishalmi


To reproduce: checkout the project 
{{g...@github.com:micronaut-projects/micronaut-test.git}} and open its 
subproject *test-bom*

The project load reports broken dependencies for:

 
{code:java}
classpath

+--- org.junit:junit-bom:5.7.1 -> 5.7.1 FAILED

\--- org.spockframework:spock-bom:2.0-M3-groovy-3.0 -> 2.0-M3-groovy-3.0 FAILED

{code}
as well as *gradle dependencies* command. But the message is:

 
{quote} because no repositories are defined.
{quote}
But the outermost project defines *repositories* block. *gradle build* in the 
-bom subproject succeeds - so perhaps it does not attempt to resolve the 
entries in the _classpath_  configuration ?

The net effect is that the 'bom' project is always marked with a warning and 
'resolve project problems' action does nothing. If a project's summary state is 
displayed i.e. in a LSP client, the project as a whole appears to be buggy (but 
it apparently is not).

[~lkishalmi] could you please advise why Gradle is reporting 'no repositories 
defined' ? Or how to filter out this type of no-errors from the retrieved info 
maps ? Naturally I wouldn't like to suppress _real_ resolution errors...

 



--
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] [Created] (NETBEANS-5822) REGRESSION: Groovy does not find alias occurrences

2021-06-30 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5822:
-

 Summary: REGRESSION: Groovy does not find alias occurrences
 Key: NETBEANS-5822
 URL: https://issues.apache.org/jira/browse/NETBEANS-5822
 Project: NetBeans
  Issue Type: Bug
  Components: groovy - Editor
Reporter: Svatopluk Dedic


Formerly, if a symbol was introduced by a static import, i.e.
{code:java}
import static Calendar.getInstance as now
{code}
References like
{code:java}
now().time
{code}
were find, as now() was basically unresolved (AST contained this.now().time()). 
With some fixes to resolve ClassNodes, the now() symbols is now better defined, 
so the AST only contains nodes that actually do the static method call plus 
time() call.

The occurrences finder does not find this now() any more.



--
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] [Assigned] (NETBEANS-5768) Gradle projects with settings.gradle but not build.gradle are not recognized

2021-06-28 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic reassigned NETBEANS-5768:
-

Assignee: Jaroslav Tulach  (was: Svatopluk Dedic)

> Gradle projects with settings.gradle but not build.gradle are not recognized
> 
>
> Key: NETBEANS-5768
> URL: https://issues.apache.org/jira/browse/NETBEANS-5768
> Project: NetBeans
>  Issue Type: Improvement
>  Components: projects - Gradle
>Affects Versions: 12.4
> Environment: Gradle 7.0.2
> NetBeans 12.4
> OpenJDK 16
>Reporter: Scott Palmer
>Assignee: Jaroslav Tulach
>Priority: Major
>
> Running "gradle init" to initialize a new Java application project will make 
> a project structure with a few sub projects (application and libraries), but 
> no build.gradle file in the root.  It just has the settings.gradle file that 
> points to the sub-projects.
> NetBeans project open dialog does not recognize the root folder as a project.
> A simple work around is to make an empty build.gradle file in the root folder 
> of the project, but NetBeans should be able to handle this valid project 
> structure, particularly since it is the "default" structure coming from 
> "gradle init"



--
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] [Assigned] (NETBEANS-5768) Gradle projects with settings.gradle but not build.gradle are not recognized

2021-06-28 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic reassigned NETBEANS-5768:
-

Assignee: Svatopluk Dedic  (was: Laszlo Kishalmi)

> Gradle projects with settings.gradle but not build.gradle are not recognized
> 
>
> Key: NETBEANS-5768
> URL: https://issues.apache.org/jira/browse/NETBEANS-5768
> Project: NetBeans
>  Issue Type: Improvement
>  Components: projects - Gradle
>Affects Versions: 12.4
> Environment: Gradle 7.0.2
> NetBeans 12.4
> OpenJDK 16
>Reporter: Scott Palmer
>Assignee: Svatopluk Dedic
>Priority: Major
>
> Running "gradle init" to initialize a new Java application project will make 
> a project structure with a few sub projects (application and libraries), but 
> no build.gradle file in the root.  It just has the settings.gradle file that 
> points to the sub-projects.
> NetBeans project open dialog does not recognize the root folder as a project.
> A simple work around is to make an empty build.gradle file in the root folder 
> of the project, but NetBeans should be able to handle this valid project 
> structure, particularly since it is the "default" structure coming from 
> "gradle init"



--
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] [Commented] (NETBEANS-5768) Gradle projects with settings.gradle but not build.gradle are not recognized

2021-06-28 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370442#comment-17370442
 ] 

Svatopluk Dedic commented on NETBEANS-5768:
---

I guess I could take this one ?

> Gradle projects with settings.gradle but not build.gradle are not recognized
> 
>
> Key: NETBEANS-5768
> URL: https://issues.apache.org/jira/browse/NETBEANS-5768
> Project: NetBeans
>  Issue Type: Improvement
>  Components: projects - Gradle
>Affects Versions: 12.4
> Environment: Gradle 7.0.2
> NetBeans 12.4
> OpenJDK 16
>Reporter: Scott Palmer
>Assignee: Laszlo Kishalmi
>Priority: Major
>
> Running "gradle init" to initialize a new Java application project will make 
> a project structure with a few sub projects (application and libraries), but 
> no build.gradle file in the root.  It just has the settings.gradle file that 
> points to the sub-projects.
> NetBeans project open dialog does not recognize the root folder as a project.
> A simple work around is to make an empty build.gradle file in the root folder 
> of the project, but NetBeans should be able to handle this valid project 
> structure, particularly since it is the "default" structure coming from 
> "gradle init"



--
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] [Created] (NETBEANS-5788) Groovy CC presents interfaces as classes

2021-06-16 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5788:
-

 Summary: Groovy CC presents interfaces as classes
 Key: NETBEANS-5788
 URL: https://issues.apache.org/jira/browse/NETBEANS-5788
 Project: NetBeans
  Issue Type: Bug
  Components: groovy - Code
Reporter: Svatopluk Dedic


Groovy CC returns interface items with *ElementKind.CLASS*. Filing as a bug bcs 
fixing would mean to fix test golden files, better to do as a separate task, 
not a part of feature impl.



--
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-5787) Groovy CC does not handle inner classes well.

2021-06-16 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5787:
--
Issue Type: Bug  (was: Improvement)

> Groovy CC does not handle inner classes well.
> -
>
> Key: NETBEANS-5787
> URL: https://issues.apache.org/jira/browse/NETBEANS-5787
> Project: NetBeans
>  Issue Type: Bug
>  Components: groovy - Editor
>Reporter: Svatopluk Dedic
>Priority: Major
>
> Groovy CC uses *GroovyUtils.stripPackage* or *GroovyUtils**.stripClassName*, 
> which works just textually, and cannot distinguish package / inner class 
> boundary in the identifier. Should be removed / replaced by some ClassNode or 
> Element operation.



--
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] [Created] (NETBEANS-5787) Groovy CC does not handle inner classes well.

2021-06-16 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5787:
-

 Summary: Groovy CC does not handle inner classes well.
 Key: NETBEANS-5787
 URL: https://issues.apache.org/jira/browse/NETBEANS-5787
 Project: NetBeans
  Issue Type: Improvement
  Components: groovy - Editor
Reporter: Svatopluk Dedic


Groovy CC uses *GroovyUtils.stripPackage* or *GroovyUtils**.stripClassName*, 
which works just textually, and cannot distinguish package / inner class 
boundary in the identifier. Should be removed / replaced by some ClassNode or 
Element operation.



--
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] [Resolved] (NETBEANS-5744) [LSP] Gradle continuous mode does not properly terminate app

2021-06-07 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic resolved NETBEANS-5744.
---
Resolution: Fixed

> [LSP] Gradle continuous mode does not properly terminate app
> 
>
> Key: NETBEANS-5744
> URL: https://issues.apache.org/jira/browse/NETBEANS-5744
> Project: NetBeans
>  Issue Type: Bug
>  Components: lsp, projects - Gradle
>Affects Versions: 12.5
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Critical
>  Labels: pull-request-available
> Fix For: 12.5
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> It seems that when one terminates the process, the continuous mode's daemon 
> is still active and keeps the application alive. So any source save will 
> restart the application. In case the app keeps some ports open, the *real* 
> restart made by the user will fail (the port is already used by the 
> background app).



--
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] [Commented] (NETBEANS-5732) Profiler not working with Maven Project when installed in path-with-spaces

2021-06-05 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17357771#comment-17357771
 ] 

Svatopluk Dedic commented on NETBEANS-5732:
---

 

More details: it seems that *StartupExtender* SPI is used in a way that the 
*implementor* (i.e. profiler) escapes all the parameters, so 
*StartupExtender.getArguments()* provides strings that are already escaped. The 
profiler does just that, and in addition in a very 'tricky' way, since it does 
not enclose the *entire* parameter in quotes, but quotes just part of it:
{code:java}
-agentpath:"/Applications/NetBeans/Apache NetBeans 
12.0.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib"="/Applications/NetBeans/Apache
 NetBeans 12.0.app/Contents/Resources/NetBeans/netbeans/profiler/lib",5140,10
{code}
(note the doublequotes in the middle of the string)

 

To the contrary *ExplicitProcessParameters* API was designed so that the 
contributing code does not care about escaping (since it can't assume how the 
escaping should work). And these styles are joined by Maven executor. Since the 
*StartupExtender* inputs are joined with other (unquoted) properties i.e. from 
project configuration UI, it's probably best to 'normalize' them. It isn't that 
optimal, as the literal value is going to change (i.e. the above would become 
"-agentpath:/Applications .,5140,10" (quotes around, none within)

 The code in 
[MavenCommandLineExecutor|https://github.com/apache/netbeans/blob/master/java/maven/src/org/netbeans/modules/maven/execute/MavenCommandLineExecutor.java#L425]
 does the quoting from the ancient times, and definitely *does not* respect 
much quoting inside; in case a provider puts apostrophe in the string, the 
result will be screwed up anyway, as well as if the property contains an 
already escaped doublequote (\"). So profiler's code is probably wrong 
(shouldn't do any escaping), but other StartupExtenders may suffer from the 
same approach, so it seems safer to assume quotes in those strings are meant 
for quoting ?

[~jtulach], [~mkleint]  – any opinion ?

> Profiler not working with Maven Project when installed in path-with-spaces
> --
>
> Key: NETBEANS-5732
> URL: https://issues.apache.org/jira/browse/NETBEANS-5732
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Maven
>Affects Versions: 12.4
>Reporter: Peter Hull
>Assignee: Svatopluk Dedic
>Priority: Major
> Fix For: 12.5
>
> Attachments: IDE_log.txt, nbactions.xml
>
>
> Profiler does not start when attempting to profile a Swing app using a maven 
> project on MacOS.
> Expected: profiler does start
> Actual: Shows an error in the output tab, given below:
> {{cd /Users/peterhull/Projects/mavenproject2; 
> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home 
> "/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/java/maven/bin/mvn" 
> "-Dexec.vmArgs='-agentpath:}}
> {{'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib\\'=}}
> {{'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib}}
> {{',5140,10' -XX:+HeapDumpOnOutOfMemoryError 
> '-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  '" "-Dexec.args=${exec.vmArgs} -classpath %classpath ${exec.mainClass} 
> ${exec.appArgs}" -Dexec.mainClass=com.nowhere.mavenproject2.NewJFrame 
> -Dexec.executable=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java
>  "-Dprofiler.jvmargs.all= -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> "-Dprofiler.jvmargs.arg1=-agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> -Dprofiler.jvmargs.arg2=-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -Dprofiler.jvmargs.arg3=-XX:+HeapDumpOnOutOfMemoryError -Dexec.appArgs= 
> org.codehaus.mojo:exec-maven-plugin:3.0.0:exec}}
> {{ Running NetBeans Compile On Save execution. 

[jira] [Updated] (NETBEANS-5732) Profiler not working with Maven Project when installed in path-with-spaces

2021-06-04 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5732:
--
Component/s: (was: profiler - IDE)
 projects - Maven

> Profiler not working with Maven Project when installed in path-with-spaces
> --
>
> Key: NETBEANS-5732
> URL: https://issues.apache.org/jira/browse/NETBEANS-5732
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Maven
>Affects Versions: 12.4
>Reporter: Peter Hull
>Assignee: Svatopluk Dedic
>Priority: Major
> Fix For: 12.5
>
> Attachments: IDE_log.txt, nbactions.xml
>
>
> Profiler does not start when attempting to profile a Swing app using a maven 
> project on MacOS.
> Expected: profiler does start
> Actual: Shows an error in the output tab, given below:
> {{cd /Users/peterhull/Projects/mavenproject2; 
> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home 
> "/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/java/maven/bin/mvn" 
> "-Dexec.vmArgs='-agentpath:}}
> {{'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib\\'=}}
> {{'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib}}
> {{',5140,10' -XX:+HeapDumpOnOutOfMemoryError 
> '-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  '" "-Dexec.args=${exec.vmArgs} -classpath %classpath ${exec.mainClass} 
> ${exec.appArgs}" -Dexec.mainClass=com.nowhere.mavenproject2.NewJFrame 
> -Dexec.executable=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java
>  "-Dprofiler.jvmargs.all= -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> "-Dprofiler.jvmargs.arg1=-agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> -Dprofiler.jvmargs.arg2=-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -Dprofiler.jvmargs.arg3=-XX:+HeapDumpOnOutOfMemoryError -Dexec.appArgs= 
> org.codehaus.mojo:exec-maven-plugin:3.0.0:exec}}
> {{ Running NetBeans Compile On Save execution. Phase execution is skipped and 
> output directories of dependency projects (with Compile on Save turned on) 
> will be used instead of their jar artifacts.}}
> {{ Scanning for projects...}}{{-< 
> com.nowhere:mavenproject2 >--}}
> {{ Building mavenproject2 1.0-SNAPSHOT}}
> {{ [ jar 
> ]-}}{{— exec-maven-plugin:3.0.0:exec 
> (default-cli) @ mavenproject2 —}}
> {{ Error occurred during initialization of VM}}
> {{ Could not find agent library \/Applications/NetBeans/Apache in absolute 
> path, with error: dlopen(\/Applications/NetBeans/Apache, 1): image not found}}
> {{ Command execution failed.}}
> {{ org.apache.commons.exec.ExecuteException: Process exited with an error: 1 
> (Exit value: 1)}}
> {{ at org.apache.commons.exec.DefaultExecutor.executeInternal 
> (DefaultExecutor.java:404)}}
> {{ at org.apache.commons.exec.DefaultExecutor.execute 
> (DefaultExecutor.java:166)}}
> {{ at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:982)}}
> {{ at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:929)}}
> {{ at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:457)}}
> {{ at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)}}
> {{ at 
> 

[jira] [Commented] (NETBEANS-5732) Profiler not working with Maven Project when installed in path-with-spaces

2021-06-04 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17357445#comment-17357445
 ] 

Svatopluk Dedic commented on NETBEANS-5732:
---

I traced this down to multiple conflicting space escaping.

 

> Profiler not working with Maven Project when installed in path-with-spaces
> --
>
> Key: NETBEANS-5732
> URL: https://issues.apache.org/jira/browse/NETBEANS-5732
> Project: NetBeans
>  Issue Type: Bug
>  Components: profiler - IDE
>Affects Versions: 12.4
>Reporter: Peter Hull
>Assignee: Svatopluk Dedic
>Priority: Major
> Attachments: IDE_log.txt, nbactions.xml
>
>
> Profiler does not start when attempting to profile a Swing app using a maven 
> project on MacOS.
> Expected: profiler does start
> Actual: Shows an error in the output tab, given below:
> {{cd /Users/peterhull/Projects/mavenproject2; 
> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home 
> "/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/java/maven/bin/mvn" 
> "-Dexec.vmArgs='-agentpath:}}
> {{'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib\\'=}}
> {{'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib}}
> {{',5140,10' -XX:+HeapDumpOnOutOfMemoryError 
> '-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  '" "-Dexec.args=${exec.vmArgs} -classpath %classpath ${exec.mainClass} 
> ${exec.appArgs}" -Dexec.mainClass=com.nowhere.mavenproject2.NewJFrame 
> -Dexec.executable=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java
>  "-Dprofiler.jvmargs.all= -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> "-Dprofiler.jvmargs.arg1=-agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> -Dprofiler.jvmargs.arg2=-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -Dprofiler.jvmargs.arg3=-XX:+HeapDumpOnOutOfMemoryError -Dexec.appArgs= 
> org.codehaus.mojo:exec-maven-plugin:3.0.0:exec}}
> {{ Running NetBeans Compile On Save execution. Phase execution is skipped and 
> output directories of dependency projects (with Compile on Save turned on) 
> will be used instead of their jar artifacts.}}
> {{ Scanning for projects...}}{{-< 
> com.nowhere:mavenproject2 >--}}
> {{ Building mavenproject2 1.0-SNAPSHOT}}
> {{ [ jar 
> ]-}}{{— exec-maven-plugin:3.0.0:exec 
> (default-cli) @ mavenproject2 —}}
> {{ Error occurred during initialization of VM}}
> {{ Could not find agent library \/Applications/NetBeans/Apache in absolute 
> path, with error: dlopen(\/Applications/NetBeans/Apache, 1): image not found}}
> {{ Command execution failed.}}
> {{ org.apache.commons.exec.ExecuteException: Process exited with an error: 1 
> (Exit value: 1)}}
> {{ at org.apache.commons.exec.DefaultExecutor.executeInternal 
> (DefaultExecutor.java:404)}}
> {{ at org.apache.commons.exec.DefaultExecutor.execute 
> (DefaultExecutor.java:166)}}
> {{ at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:982)}}
> {{ at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:929)}}
> {{ at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:457)}}
> {{ at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)}}
> {{ at 
> 

[jira] [Updated] (NETBEANS-5732) Profiler not working with Maven Project when installed in path-with-spaces

2021-06-04 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5732:
--
Fix Version/s: 12.5

> Profiler not working with Maven Project when installed in path-with-spaces
> --
>
> Key: NETBEANS-5732
> URL: https://issues.apache.org/jira/browse/NETBEANS-5732
> Project: NetBeans
>  Issue Type: Bug
>  Components: profiler - IDE
>Affects Versions: 12.4
>Reporter: Peter Hull
>Assignee: Svatopluk Dedic
>Priority: Major
> Fix For: 12.5
>
> Attachments: IDE_log.txt, nbactions.xml
>
>
> Profiler does not start when attempting to profile a Swing app using a maven 
> project on MacOS.
> Expected: profiler does start
> Actual: Shows an error in the output tab, given below:
> {{cd /Users/peterhull/Projects/mavenproject2; 
> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home 
> "/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/java/maven/bin/mvn" 
> "-Dexec.vmArgs='-agentpath:}}
> {{'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib\\'=}}
> {{'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib}}
> {{',5140,10' -XX:+HeapDumpOnOutOfMemoryError 
> '-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  '" "-Dexec.args=${exec.vmArgs} -classpath %classpath ${exec.mainClass} 
> ${exec.appArgs}" -Dexec.mainClass=com.nowhere.mavenproject2.NewJFrame 
> -Dexec.executable=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java
>  "-Dprofiler.jvmargs.all= -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> "-Dprofiler.jvmargs.arg1=-agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> -Dprofiler.jvmargs.arg2=-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -Dprofiler.jvmargs.arg3=-XX:+HeapDumpOnOutOfMemoryError -Dexec.appArgs= 
> org.codehaus.mojo:exec-maven-plugin:3.0.0:exec}}
> {{ Running NetBeans Compile On Save execution. Phase execution is skipped and 
> output directories of dependency projects (with Compile on Save turned on) 
> will be used instead of their jar artifacts.}}
> {{ Scanning for projects...}}{{-< 
> com.nowhere:mavenproject2 >--}}
> {{ Building mavenproject2 1.0-SNAPSHOT}}
> {{ [ jar 
> ]-}}{{— exec-maven-plugin:3.0.0:exec 
> (default-cli) @ mavenproject2 —}}
> {{ Error occurred during initialization of VM}}
> {{ Could not find agent library \/Applications/NetBeans/Apache in absolute 
> path, with error: dlopen(\/Applications/NetBeans/Apache, 1): image not found}}
> {{ Command execution failed.}}
> {{ org.apache.commons.exec.ExecuteException: Process exited with an error: 1 
> (Exit value: 1)}}
> {{ at org.apache.commons.exec.DefaultExecutor.executeInternal 
> (DefaultExecutor.java:404)}}
> {{ at org.apache.commons.exec.DefaultExecutor.execute 
> (DefaultExecutor.java:166)}}
> {{ at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:982)}}
> {{ at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:929)}}
> {{ at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:457)}}
> {{ at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)}}
> {{ at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  

[jira] [Updated] (NETBEANS-5732) Profiler not working with Maven Project when installed in path-with-spaces

2021-06-04 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5732:
--
Summary: Profiler not working with Maven Project when installed in 
path-with-spaces  (was: Profiler not working with Maven Project on MacOS)

> Profiler not working with Maven Project when installed in path-with-spaces
> --
>
> Key: NETBEANS-5732
> URL: https://issues.apache.org/jira/browse/NETBEANS-5732
> Project: NetBeans
>  Issue Type: Bug
>  Components: profiler - IDE
>Affects Versions: 12.4
>Reporter: Peter Hull
>Assignee: Svatopluk Dedic
>Priority: Major
> Attachments: IDE_log.txt, nbactions.xml
>
>
> Profiler does not start when attempting to profile a Swing app using a maven 
> project on MacOS.
> Expected: profiler does start
> Actual: Shows an error in the output tab, given below:
> {{cd /Users/peterhull/Projects/mavenproject2; 
> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home 
> "/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/java/maven/bin/mvn" 
> "-Dexec.vmArgs='-agentpath:}}
> {{'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib\\'=}}
> {{'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib}}
> {{',5140,10' -XX:+HeapDumpOnOutOfMemoryError 
> '-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  '" "-Dexec.args=${exec.vmArgs} -classpath %classpath ${exec.mainClass} 
> ${exec.appArgs}" -Dexec.mainClass=com.nowhere.mavenproject2.NewJFrame 
> -Dexec.executable=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java
>  "-Dprofiler.jvmargs.all= -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> "-Dprofiler.jvmargs.arg1=-agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> -Dprofiler.jvmargs.arg2=-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -Dprofiler.jvmargs.arg3=-XX:+HeapDumpOnOutOfMemoryError -Dexec.appArgs= 
> org.codehaus.mojo:exec-maven-plugin:3.0.0:exec}}
> {{ Running NetBeans Compile On Save execution. Phase execution is skipped and 
> output directories of dependency projects (with Compile on Save turned on) 
> will be used instead of their jar artifacts.}}
> {{ Scanning for projects...}}{{-< 
> com.nowhere:mavenproject2 >--}}
> {{ Building mavenproject2 1.0-SNAPSHOT}}
> {{ [ jar 
> ]-}}{{— exec-maven-plugin:3.0.0:exec 
> (default-cli) @ mavenproject2 —}}
> {{ Error occurred during initialization of VM}}
> {{ Could not find agent library \/Applications/NetBeans/Apache in absolute 
> path, with error: dlopen(\/Applications/NetBeans/Apache, 1): image not found}}
> {{ Command execution failed.}}
> {{ org.apache.commons.exec.ExecuteException: Process exited with an error: 1 
> (Exit value: 1)}}
> {{ at org.apache.commons.exec.DefaultExecutor.executeInternal 
> (DefaultExecutor.java:404)}}
> {{ at org.apache.commons.exec.DefaultExecutor.execute 
> (DefaultExecutor.java:166)}}
> {{ at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:982)}}
> {{ at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:929)}}
> {{ at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:457)}}
> {{ at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)}}
> {{ at 
> 

[jira] [Updated] (NETBEANS-5744) [LSP] Gradle continuous mode does not properly terminate app

2021-06-04 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5744:
--
Issue Type: Bug  (was: Improvement)

> [LSP] Gradle continuous mode does not properly terminate app
> 
>
> Key: NETBEANS-5744
> URL: https://issues.apache.org/jira/browse/NETBEANS-5744
> Project: NetBeans
>  Issue Type: Bug
>  Components: lsp, projects - Gradle
>Affects Versions: 12.5
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Critical
>  Labels: pull-request-available
> Fix For: 12.5
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> It seems that when one terminates the process, the continuous mode's daemon 
> is still active and keeps the application alive. So any source save will 
> restart the application. In case the app keeps some ports open, the *real* 
> restart made by the user will fail (the port is already used by the 
> background app).



--
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-5744) [LSP] Gradle continuous mode does not properly terminate app

2021-06-03 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5744:
--
Summary: [LSP] Gradle continuous mode does not properly terminate app  
(was: Gradle continuous mode does not properly terminate app)

> [LSP] Gradle continuous mode does not properly terminate app
> 
>
> Key: NETBEANS-5744
> URL: https://issues.apache.org/jira/browse/NETBEANS-5744
> Project: NetBeans
>  Issue Type: Improvement
>  Components: lsp, projects - Gradle
>Affects Versions: 12.5
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Critical
> Fix For: 12.5
>
>
> It seems that when one terminates the process, the continuous mode's daemon 
> is still active and keeps the application alive. So any source save will 
> restart the application. In case the app keeps some ports open, the *real* 
> restart made by the user will fail (the port is already used by the 
> background app).



--
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-5744) Gradle continuous mode does not properly terminate app

2021-06-03 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5744:
--
Component/s: lsp

> Gradle continuous mode does not properly terminate app
> --
>
> Key: NETBEANS-5744
> URL: https://issues.apache.org/jira/browse/NETBEANS-5744
> Project: NetBeans
>  Issue Type: Improvement
>  Components: lsp, projects - Gradle
>Affects Versions: 12.5
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Critical
> Fix For: 12.5
>
>
> It seems that when one terminates the process, the continuous mode's daemon 
> is still active and keeps the application alive. So any source save will 
> restart the application. In case the app keeps some ports open, the *real* 
> restart made by the user will fail (the port is already used by the 
> background app).



--
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] [Created] (NETBEANS-5744) Gradle continuous mode does not properly terminate app

2021-06-03 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5744:
-

 Summary: Gradle continuous mode does not properly terminate app
 Key: NETBEANS-5744
 URL: https://issues.apache.org/jira/browse/NETBEANS-5744
 Project: NetBeans
  Issue Type: Improvement
  Components: projects - Gradle
Affects Versions: 12.5
Reporter: Svatopluk Dedic
Assignee: Svatopluk Dedic
 Fix For: 12.5


It seems that when one terminates the process, the continuous mode's daemon is 
still active and keeps the application alive. So any source save will restart 
the application. In case the app keeps some ports open, the *real* restart made 
by the user will fail (the port is already used by the background app).



--
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] [Assigned] (NETBEANS-5732) Profiler not working with Maven Project on MacOS

2021-05-31 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic reassigned NETBEANS-5732:
-

Assignee: Svatopluk Dedic

> Profiler not working with Maven Project on MacOS
> 
>
> Key: NETBEANS-5732
> URL: https://issues.apache.org/jira/browse/NETBEANS-5732
> Project: NetBeans
>  Issue Type: Bug
>  Components: profiler - IDE
>Affects Versions: 12.4
>Reporter: Peter Hull
>Assignee: Svatopluk Dedic
>Priority: Major
> Attachments: IDE_log.txt, nbactions.xml
>
>
> Profiler does not start when attempting to profile a Swing app using a maven 
> project on MacOS.
> Expected: profiler does start
> Actual: Shows an error in the output tab, given below:
> cd /Users/peterhull/Projects/mavenproject2; 
> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home 
> "/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/java/maven/bin/mvn" 
> "-Dexec.vmArgs='-agentpath:\\'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib\\'=\\'/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib\\',5140,10' 
> -XX:+HeapDumpOnOutOfMemoryError 
> '-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  '" "-Dexec.args=${exec.vmArgs} -classpath %classpath ${exec.mainClass} 
> ${exec.appArgs}" -Dexec.mainClass=com.nowhere.mavenproject2.NewJFrame 
> -Dexec.executable=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java
>  "-Dprofiler.jvmargs.all= -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> "-Dprofiler.jvmargs.arg1=-agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> -Dprofiler.jvmargs.arg2=-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -Dprofiler.jvmargs.arg3=-XX:+HeapDumpOnOutOfMemoryError -Dexec.appArgs= 
> org.codehaus.mojo:exec-maven-plugin:3.0.0:exec
> Running NetBeans Compile On Save execution. Phase execution is skipped and 
> output directories of dependency projects (with Compile on Save turned on) 
> will be used instead of their jar artifacts.
> Scanning for projects...
> -< com.nowhere:mavenproject2 >--
> Building mavenproject2 1.0-SNAPSHOT
> [ jar ]-
> --- exec-maven-plugin:3.0.0:exec (default-cli) @ mavenproject2 ---
> Error occurred during initialization of VM
> Could not find agent library \/Applications/NetBeans/Apache in absolute path, 
> with error: dlopen(\/Applications/NetBeans/Apache, 1): image not found
> Command execution failed.
> org.apache.commons.exec.ExecuteException: Process exited with an error: 1 
> (Exit value: 1)
>  at org.apache.commons.exec.DefaultExecutor.executeInternal 
> (DefaultExecutor.java:404)
>  at org.apache.commons.exec.DefaultExecutor.execute (DefaultExecutor.java:166)
>  at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:982)
>  at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:929)
>  at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:457)
>  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
>  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
>  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
>  at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
>  at org.apache.maven.DefaultMaven.doExecute 

[jira] [Commented] (NETBEANS-5732) Profiler not working with Maven Project on MacOS

2021-05-31 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354234#comment-17354234
 ] 

Svatopluk Dedic commented on NETBEANS-5732:
---

Have you customized your maven actions (is there a nb-actions.xml in the 
project directory) ? If so, pls. attach.

> Profiler not working with Maven Project on MacOS
> 
>
> Key: NETBEANS-5732
> URL: https://issues.apache.org/jira/browse/NETBEANS-5732
> Project: NetBeans
>  Issue Type: Bug
>  Components: profiler - IDE
>Affects Versions: 12.4
>Reporter: Peter Hull
>Priority: Major
> Attachments: IDE_log.txt
>
>
> Profiler does not start when attempting to profile a Swing app using a maven 
> project on MacOS.
> Expected: profiler does start
> Actual: Shows an error in the output tab, given below:
> cd /Users/peterhull/Projects/mavenproject2; 
> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home 
> "/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/java/maven/bin/mvn" 
> "-Dexec.vmArgs='-agentpath:\\'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib\\'=\\'/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib\\',5140,10' 
> -XX:+HeapDumpOnOutOfMemoryError 
> '-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  '" "-Dexec.args=${exec.vmArgs} -classpath %classpath ${exec.mainClass} 
> ${exec.appArgs}" -Dexec.mainClass=com.nowhere.mavenproject2.NewJFrame 
> -Dexec.executable=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java
>  "-Dprofiler.jvmargs.all= -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> "-Dprofiler.jvmargs.arg1=-agentpath:'/Applications/NetBeans/Apache NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib'='/Applications/NetBeans/Apache
>  NetBeans 
> 12.4.app/Contents/Resources/NetBeans/netbeans/profiler/lib',5140,10" 
> -Dprofiler.jvmargs.arg2=-XX:HeapDumpPath=/Users/peterhull/Library/Caches/NetBeans/12.4/mavencachedirs/1004131909/org-netbeans-modules-profiler
>  -Dprofiler.jvmargs.arg3=-XX:+HeapDumpOnOutOfMemoryError -Dexec.appArgs= 
> org.codehaus.mojo:exec-maven-plugin:3.0.0:exec
> Running NetBeans Compile On Save execution. Phase execution is skipped and 
> output directories of dependency projects (with Compile on Save turned on) 
> will be used instead of their jar artifacts.
> Scanning for projects...
> -< com.nowhere:mavenproject2 >--
> Building mavenproject2 1.0-SNAPSHOT
> [ jar ]-
> --- exec-maven-plugin:3.0.0:exec (default-cli) @ mavenproject2 ---
> Error occurred during initialization of VM
> Could not find agent library \/Applications/NetBeans/Apache in absolute path, 
> with error: dlopen(\/Applications/NetBeans/Apache, 1): image not found
> Command execution failed.
> org.apache.commons.exec.ExecuteException: Process exited with an error: 1 
> (Exit value: 1)
>  at org.apache.commons.exec.DefaultExecutor.executeInternal 
> (DefaultExecutor.java:404)
>  at org.apache.commons.exec.DefaultExecutor.execute (DefaultExecutor.java:166)
>  at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:982)
>  at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:929)
>  at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:457)
>  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
>  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
>  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
>  at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> 

[jira] [Created] (NETBEANS-5721) Tighten checks for valid filenames incl. free filenames

2021-05-27 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5721:
-

 Summary: Tighten checks for valid filenames incl. free filenames
 Key: NETBEANS-5721
 URL: https://issues.apache.org/jira/browse/NETBEANS-5721
 Project: NetBeans
  Issue Type: Improvement
  Components: platform - Filesystems
Reporter: Svatopluk Dedic
Assignee: Svatopluk Dedic


An interesting (but not normative / exhaustive) list of forbidden file 
names/parts is at 
[https://stackoverflow.com/questions/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names]

Windows really prohibits an user from creating a directory named 'con' :) and 
even {{con.txt}} is banned !

 



--
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] [Created] (NETBEANS-5720) Unify filename checks to use FileUtil.findFreeFileName or .isValidFileName

2021-05-27 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5720:
-

 Summary: Unify filename checks to use FileUtil.findFreeFileName or 
.isValidFileName
 Key: NETBEANS-5720
 URL: https://issues.apache.org/jira/browse/NETBEANS-5720
 Project: NetBeans
  Issue Type: Bug
  Components: ide - UI, javaee - JSF, javafx - Project, projects - 
Maven, serverplugins - GlassFish, serverplugins - Sun Appserver 9, web - HTML 
Project
Reporter: Svatopluk Dedic
Assignee: Svatopluk Dedic


Multple definitions of invalid filenames are scattered throughout the codebase. 
Should be unified. Sample list (perhaps not exhaustive):
{code:java}
enterprise/web.jsf/src/org/netbeans/modules/web/jsf/wizards/CompositeComponentWizardPanel.java:
if ("".equals(filename) || 
INVALID_FILENAME_CHARACTERS.matcher(filename).find()) {
enterprise/weblogic.common/src/org/netbeans/modules/weblogic/common/api/DomainConfiguration.java:
private static final  Pattern FILE_NAME_PATTERN =
enterprise/glassfish.javaee/src/org/netbeans/modules/glassfish/javaee/db/VendorNameMgr.java:
private final static char []ILLEGAL_FILENAME_CHARS = {'/', '\\', 
':', '*', '?', '"', '<', '>', '|', ',', '=', ';' };
enterprise/j2ee.sun.appsrv/src/org/netbeans/modules/j2ee/sun/api/restricted/ResourceConfigurator.java:
private final static char[]   ILLEGAL_FILENAME_CHARS = {'/', '\\', ':', 
'*', '?', '"', '<', '>', '|', ',', '=', ';' };
enterprise/j2ee.sun.appsrv/src/org/netbeans/modules/j2ee/sun/api/restricted/ResourceUtils.java:
private final static char[]  ILLEGAL_FILENAME_CHARS = {'/', '\\', ':', 
'*', '?', '"', '<', '>', '|', ',' };
ide/target.iterator/src/org/netbeans/modules/target/iterator/api/TargetChooserPanel.java:
private static final Pattern INVALID_FILENAME_CHARACTERS = 
java/maven/src/org/netbeans/modules/maven/actions/CreateLibraryPanel.java://
StringValidators.REQUIRE_VALID_FILENAME,
javafx/javafx2.project/src/org/netbeans/modules/javafx2/project/fxml/FXMLTemplateWizardIterator.java:
static final char[] NO_FILENAME_CHARS = { '/', '<', '>', '\\', '|', '\"', 
'\n', '\r', '\t', '\0', '\f', '`', '?', '*', ':' }; //NOI18N
webcommon/web.clientproject.api/src/org/netbeans/modules/web/clientproject/api/util/ValidationUtilities.java:
private static final char[] INVALID_FILENAME_CHARS = new char[] {'/', '\\', 
'|', ':', '*', '?', '"', '<', '>'}; // NOI18N


{code}



--
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] [Assigned] (NETBEANS-5711) Non-shared AuxiliaryConfiguration persisted in var/

2021-05-26 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic reassigned NETBEANS-5711:
-

Assignee: (was: Laszlo Kishalmi)

> Non-shared AuxiliaryConfiguration persisted in var/
> ---
>
> Key: NETBEANS-5711
> URL: https://issues.apache.org/jira/browse/NETBEANS-5711
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle Java EE, projects - Maven
>Affects Versions: 12.4
>Reporter: Svatopluk Dedic
>Priority: Major
>
> The implementation of *gradle*  and *maven* project stores non-shared project 
> *AuxiliaryConfiguration* contents as FileObject attributes which in turn is 
> stored in *$nbuser/var* area. That are is however relatively 'transient' - 
> although it's not in *cache* dir, which can be routinely wiped out by some 
> users (e.g. in case of problems with the IDE), it is still outside of *conf* 
> area that holds IDE configuration.
> In addition, if a different userdir is used for the IDE run, these settings 
> are lost / not propagated, which can be seen as a bug or as a feature :)
> An alternative approach to *AuxiliaryConfiguration* can be developed that 
> uses *UserDefinedAttributeView* from NIO - could work on all major platforms 
> *including Windows.*
> **I am not sure about having this implemented directly in FileSystem layer as 
> some users may see the userdir-scoped storage as a feature. But definitely we 
> can make a stock implementation in Project API, that will obey a setting: to 
> work as it is now or use NIO APIs.
>  
> // cc: [~jtulach] for comments.



--
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-5711) Non-shared AuxiliaryConfiguration persisted in var/

2021-05-26 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5711:
--
Summary: Non-shared AuxiliaryConfiguration persisted in var/  (was: 
Non-shared AuxiliaryInformation persisted in var/)

> Non-shared AuxiliaryConfiguration persisted in var/
> ---
>
> Key: NETBEANS-5711
> URL: https://issues.apache.org/jira/browse/NETBEANS-5711
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle Java EE, projects - Maven
>Affects Versions: 12.4
>Reporter: Svatopluk Dedic
>Assignee: Laszlo Kishalmi
>Priority: Major
>
> The implementation of *gradle*  and *maven* project stores non-shared project 
> *AuxiliaryConfiguration* contents as FileObject attributes which in turn is 
> stored in *$nbuser/var* area. That are is however relatively 'transient' - 
> although it's not in *cache* dir, which can be routinely wiped out by some 
> users (e.g. in case of problems with the IDE), it is still outside of *conf* 
> area that holds IDE configuration.
> In addition, if a different userdir is used for the IDE run, these settings 
> are lost / not propagated, which can be seen as a bug or as a feature :)
> An alternative approach to *AuxiliaryConfiguration* can be developed that 
> uses *UserDefinedAttributeView* from NIO - could work on all major platforms 
> *including Windows.*
> **I am not sure about having this implemented directly in FileSystem layer as 
> some users may see the userdir-scoped storage as a feature. But definitely we 
> can make a stock implementation in Project API, that will obey a setting: to 
> work as it is now or use NIO APIs.
>  
> // cc: [~jtulach] for comments.



--
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] [Created] (NETBEANS-5711) Non-shared AuxiliaryInformation persisted in var/

2021-05-26 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5711:
-

 Summary: Non-shared AuxiliaryInformation persisted in var/
 Key: NETBEANS-5711
 URL: https://issues.apache.org/jira/browse/NETBEANS-5711
 Project: NetBeans
  Issue Type: Bug
  Components: projects - Gradle Java EE, projects - Maven
Affects Versions: 12.4
Reporter: Svatopluk Dedic
Assignee: Laszlo Kishalmi


The implementation of *gradle*  and *maven* project stores non-shared project 
*AuxiliaryConfiguration* contents as FileObject attributes which in turn is 
stored in *$nbuser/var* area. That are is however relatively 'transient' - 
although it's not in *cache* dir, which can be routinely wiped out by some 
users (e.g. in case of problems with the IDE), it is still outside of *conf* 
area that holds IDE configuration.

In addition, if a different userdir is used for the IDE run, these settings are 
lost / not propagated, which can be seen as a bug or as a feature :)

An alternative approach to *AuxiliaryConfiguration* can be developed that uses 
*UserDefinedAttributeView* from NIO - could work on all major platforms 
*including Windows.*

**I am not sure about having this implemented directly in FileSystem layer as 
some users may see the userdir-scoped storage as a feature. But definitely we 
can make a stock implementation in Project API, that will obey a setting: to 
work as it is now or use NIO APIs.

 

// cc: [~jtulach] for comments.



--
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] [Created] (NETBEANS-5694) Annotation to register provided action Configurations

2021-05-19 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5694:
-

 Summary: Annotation to register provided action Configurations
 Key: NETBEANS-5694
 URL: https://issues.apache.org/jira/browse/NETBEANS-5694
 Project: NetBeans
  Issue Type: Improvement
  Components: projects - Maven
Affects Versions: 12.5
Reporter: Svatopluk Dedic


Layer XML is now needed to provide action configurations for the user. An 
annotation could be provided to have that XML generated for the user.

See https://github.com/apache/netbeans/pull/2948#discussion_r634025457



--
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] [Created] (NETBEANS-5684) Clickable folds

2021-05-17 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5684:
-

 Summary: Clickable folds
 Key: NETBEANS-5684
 URL: https://issues.apache.org/jira/browse/NETBEANS-5684
 Project: NetBeans
  Issue Type: Improvement
  Components: editor - Code folding
Affects Versions: 12.4
Reporter: Svatopluk Dedic


The FoldProvider can currently give a content preview, some short form to see 
in the fold. This interface could eventually extend to supply an Action to 
execute if the user clicks on the content (which would be then rendered as a 
hyperlink, maybe with an icon ?).

In the example of [PR-2960|https://github.com/apache/netbeans/pull/2960] the 
hyperlink looks quite ugly at the first sight; but it could eventually collapse 
into something like clickable "=> Open Class.java template".



--
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] [Commented] (NETBEANS-5680) Create ProjectActions API

2021-05-17 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345937#comment-17345937
 ] 

Svatopluk Dedic commented on NETBEANS-5680:
---

Hm, what was the original reason NOT to having the project actions presented as 
(abstract) j.s.Action  or ContextAwareAction ?
{quote}e.g. have a way to obtain *BUILD*, *RUN*, *DEBUG* project actions as
{quote}
You mean having some global actions for these, with ContextAware interface to 
bind them to a particular Project ? Or still a project-provided factory to 
obtain the action instances ?

> Create ProjectActions API
> -
>
> Key: NETBEANS-5680
> URL: https://issues.apache.org/jira/browse/NETBEANS-5680
> Project: NetBeans
>  Issue Type: Improvement
>  Components: projects - Generic Infrastructure
>Affects Versions: 12.4
>Reporter: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans
>
> In [https://github.com/apache/netbeans/pull/2948] surfaced a long-standing 
> issue, that clients are asked to use a SPI interface directly. This 
> complicates adding optional functionaliy to SPI as it requires *API clients* 
> to maneuver around old/new SPI impl differences.
> A proper API counterpart for *ActionProvider*, *ActionProgress* (and maybe 
> *ProjectConfiguration*) should be created.



--
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] [Closed] (NETBEANS-5671) ActionProvider should support running Action using specific ProjectConfiguration

2021-05-14 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic closed NETBEANS-5671.
-
Resolution: Invalid

Actually Project SPI already documents that ProjectConfiguration is to be put 
in the action's context Lookup.

> ActionProvider should support running Action using specific 
> ProjectConfiguration
> 
>
> Key: NETBEANS-5671
> URL: https://issues.apache.org/jira/browse/NETBEANS-5671
> Project: NetBeans
>  Issue Type: Improvement
>  Components: projects - Generic Infrastructure, projects - Gradle, 
> projects - Maven
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans
> Fix For: 12.5
>
>
> When invoking an action programmatically, it's not possible to specify what 
> ProjectConfiguration the action should use. This may mean the action is not 
> available at all (if defined specifically in a certain Configuration), or may 
> be invoked differently - the *active* configuration is always used. The only 
> chance is to change the active configuration - which changes the project's 
> view *for everyone*, not just for the action being invoked.
> Likewise setting the active configuration back after action completes is not 
> a good idea, since the config may flip back and forth unexpectedly for the 
> user.
>  
> Note: Gradle does not support Configurations atm.
>  



--
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] [Created] (NETBEANS-5680) Create ProjectActions API

2021-05-14 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5680:
-

 Summary: Create ProjectActions API
 Key: NETBEANS-5680
 URL: https://issues.apache.org/jira/browse/NETBEANS-5680
 Project: NetBeans
  Issue Type: Improvement
  Components: projects - Generic Infrastructure
Affects Versions: 12.4
Reporter: Svatopluk Dedic


In [https://github.com/apache/netbeans/pull/2948] surfaced a long-standing 
issue, that clients are asked to use a SPI interface directly. This complicates 
adding optional functionaliy to SPI as it requires *API clients* to maneuver 
around old/new SPI impl differences.

A proper API counterpart for *ActionProvider*, *ActionProgress* (and maybe 
*ProjectConfiguration*) should be created.



--
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] [Created] (NETBEANS-5672) Plugin-based service registrations

2021-05-11 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5672:
-

 Summary: Plugin-based service registrations
 Key: NETBEANS-5672
 URL: https://issues.apache.org/jira/browse/NETBEANS-5672
 Project: NetBeans
  Issue Type: Improvement
  Components: projects - Maven
Reporter: Svatopluk Dedic
Assignee: Svatopluk Dedic
 Fix For: 12.5


Maven projects should support registrations of services / providers per plugin, 
similar to Gradle. While it is possible to register a *ProjectServiceProvider*, 
then query the maven project for a list of plugins, each such provider must 
monitor the list of plugins and adjust the behaviour appropriately.

Still the plugins used in the project are known and the maven core model level, 
so this filter can be implemented centraly, by the maven core module.



--
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] [Created] (NETBEANS-5671) ActionProvider should support running Action using specific ProjectConfiguration

2021-05-11 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5671:
-

 Summary: ActionProvider should support running Action using 
specific ProjectConfiguration
 Key: NETBEANS-5671
 URL: https://issues.apache.org/jira/browse/NETBEANS-5671
 Project: NetBeans
  Issue Type: Improvement
  Components: projects - Generic Infrastructure, projects - Gradle, 
projects - Maven
Reporter: Svatopluk Dedic
Assignee: Svatopluk Dedic
 Fix For: 12.5


When invoking an action programmatically, it's not possible to specify what 
ProjectConfiguration the action should use. This may mean the action is not 
available at all (if defined specifically in a certain Configuration), or may 
be invoked differently - the *active* configuration is always used. The only 
chance is to change the active configuration - which changes the project's view 
*for everyone*, not just for the action being invoked.

Likewise setting the active configuration back after action completes is not a 
good idea, since the config may flip back and forth unexpectedly for the user.

 

Note: Gradle does not support Configurations atm.

 



--
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-5670) MavenActionProviders should contribute configurations

2021-05-11 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5670:
--
Fix Version/s: 12.5

> MavenActionProviders should contribute configurations
> -
>
> Key: NETBEANS-5670
> URL: https://issues.apache.org/jira/browse/NETBEANS-5670
> Project: NetBeans
>  Issue Type: Improvement
>  Components: javaee - Micronaut, projects - Maven
>Reporter: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans
> Fix For: 12.5
>
>
> Currently *MavenActionProviders* can only contribute action replacements or 
> new actions. They can not contribute *configurations*. This could be useful 
> for plugins like Micronaut, that supports *mn:run* which is a suitable 
> alternative to *regular* run. It *may* be preferred by some developers, but 
> should not *replace* and disallow access to the traditional application 
> launch mode.
>  



--
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-5670) MavenActionProviders should contribute configurations

2021-05-11 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5670:
--
Labels: VSNetBeans  (was: )

> MavenActionProviders should contribute configurations
> -
>
> Key: NETBEANS-5670
> URL: https://issues.apache.org/jira/browse/NETBEANS-5670
> Project: NetBeans
>  Issue Type: Improvement
>  Components: javaee - Micronaut, projects - Maven
>Reporter: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans
>
> Currently *MavenActionProviders* can only contribute action replacements or 
> new actions. They can not contribute *configurations*. This could be useful 
> for plugins like Micronaut, that supports *mn:run* which is a suitable 
> alternative to *regular* run. It *may* be preferred by some developers, but 
> should not *replace* and disallow access to the traditional application 
> launch mode.
>  



--
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] [Assigned] (NETBEANS-5670) MavenActionProviders should contribute configurations

2021-05-11 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic reassigned NETBEANS-5670:
-

Assignee: Svatopluk Dedic

> MavenActionProviders should contribute configurations
> -
>
> Key: NETBEANS-5670
> URL: https://issues.apache.org/jira/browse/NETBEANS-5670
> Project: NetBeans
>  Issue Type: Improvement
>  Components: javaee - Micronaut, projects - Maven
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans
> Fix For: 12.5
>
>
> Currently *MavenActionProviders* can only contribute action replacements or 
> new actions. They can not contribute *configurations*. This could be useful 
> for plugins like Micronaut, that supports *mn:run* which is a suitable 
> alternative to *regular* run. It *may* be preferred by some developers, but 
> should not *replace* and disallow access to the traditional application 
> launch mode.
>  



--
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] [Created] (NETBEANS-5670) MavenActionProviders should contribute configurations

2021-05-11 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5670:
-

 Summary: MavenActionProviders should contribute configurations
 Key: NETBEANS-5670
 URL: https://issues.apache.org/jira/browse/NETBEANS-5670
 Project: NetBeans
  Issue Type: Improvement
  Components: javaee - Micronaut, projects - Maven
Reporter: Svatopluk Dedic


Currently *MavenActionProviders* can only contribute action replacements or new 
actions. They can not contribute *configurations*. This could be useful for 
plugins like Micronaut, that supports *mn:run* which is a suitable alternative 
to *regular* run. It *may* be preferred by some developers, but should not 
*replace* and disallow access to the traditional application launch mode.

 



--
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] [Commented] (NETBEANS-5629) Gradle project Lookups ordering not defined well

2021-05-03 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338197#comment-17338197
 ] 

Svatopluk Dedic commented on NETBEANS-5629:
---

{quote}You can also enhance {{ProxyLookup}} to honor {{position}} value of the 
\{{Lookup.Item }} instances it delegates to, if you think it would fix your 
problem.
{quote}
Is there a *position* attribute in *Lookup.Item* ?

 

> Gradle project Lookups ordering not defined well
> 
>
> Key: NETBEANS-5629
> URL: https://issues.apache.org/jira/browse/NETBEANS-5629
> Project: NetBeans
>  Issue Type: Bug
>Reporter: Svatopluk Dedic
>Priority: Major
>
> Individual Plugins can contribute to project Lookup. In my testcase, which 
> uses java/java-base plugins, the Lookups loaded from 
> *Projects/org-netbeans-modules-gradle/*** were loaded in the following order:
> {code:java}
> [java, , root, java-base, base]
> {code}
> When Groovy was also present, the order was
> {code:java}
> [java, groovy, , root, groovy-base, java-base, base]
> {code}
> (note - groovy after java, groovy-base before java-base). But with scala, the 
> order is:
> {code:java}
> [java, scala, , root, java-base, scala-base, base]
> {code}
> (note - scala-base AFTER java-base).
> When opening a project with 
> {code:java}
> apply plugin: 'groovy'
> {code}
> the order is yet different:
> {code:java}
> [groovy, java, , root, groovy-base, java-base, base]{code}
> The order is unreliable and I guess under some circumstances even the 
> , xxx-base and xxx could be reordered as plugin names go through 
> series of hashmaps.



--
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] [Commented] (NETBEANS-5629) Gradle project Lookups ordering not defined well

2021-05-01 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17337808#comment-17337808
 ] 

Svatopluk Dedic commented on NETBEANS-5629:
---

It does :) experienced on my own in Maven projects, which work in a similar 
way, but for packaging only (sidenote:  packaging (distribution type) can be an 
interesting additional 'axis' in the gradle plugin system, too as it ultimately 
combines with technology plugins).

It does matter since individual plugin-folders are merged in ProxyLookup, which 
enumerates the contents (= list of ProjectServiceProviders) in the order of the 
ProxyLookup components, and only then (2nd level) ordered by position attribute 
of ProjectserviceProviders). I would like to take the opportunity that Gradle 
APIs do not define (at the moment) the order at all, to work out a system that 
works consistently for Ant, Maven, Gradle projects.

> Gradle project Lookups ordering not defined well
> 
>
> Key: NETBEANS-5629
> URL: https://issues.apache.org/jira/browse/NETBEANS-5629
> Project: NetBeans
>  Issue Type: Bug
>Reporter: Svatopluk Dedic
>Priority: Major
>
> Individual Plugins can contribute to project Lookup. In my testcase, which 
> uses java/java-base plugins, the Lookups loaded from 
> *Projects/org-netbeans-modules-gradle/*** were loaded in the following order:
> {code:java}
> [java, , root, java-base, base]
> {code}
> When Groovy was also present, the order was
> {code:java}
> [java, groovy, , root, groovy-base, java-base, base]
> {code}
> (note - groovy after java, groovy-base before java-base). But with scala, the 
> order is:
> {code:java}
> [java, scala, , root, java-base, scala-base, base]
> {code}
> (note - scala-base AFTER java-base).
> When opening a project with 
> {code:java}
> apply plugin: 'groovy'
> {code}
> the order is yet different:
> {code:java}
> [groovy, java, , root, groovy-base, java-base, base]{code}
> The order is unreliable and I guess under some circumstances even the 
> , xxx-base and xxx could be reordered as plugin names go through 
> series of hashmaps.



--
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] [Commented] (NETBEANS-5638) NbTestCase.assertGC fails with SecurityException

2021-04-29 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335388#comment-17335388
 ] 

Svatopluk Dedic commented on NETBEANS-5638:
---

// cc: [~jtulach]

> NbTestCase.assertGC fails with SecurityException
> 
>
> Key: NETBEANS-5638
> URL: https://issues.apache.org/jira/browse/NETBEANS-5638
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Harness
>Affects Versions: 12.4
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: Testing
> Fix For: 12.5
>
>
> During testing, I've found out that *assertGC* paths to root analysis fails 
> with *SecurityException* and does not provide any reasonable results:
> {code:java}
> java.lang.SecurityException: Prohibited package name: java.lang
>   at java.lang.ClassLoader.preDefineClass(ClassLoader.java:655)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:754)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
>   at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
>   at java.lang.Class.getDeclaredMethods0(Native Method)
>   at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
>   at java.lang.Class.getDeclaredMethods(Class.java:1975)
>   at 
> org.netbeans.insane.impl.InsaneEngine.recognizeClass(InsaneEngine.java:123)
> {code}
> The exception was thrown, because Insane library queries 
> *getDeclaredMethods()* on *org.netbeans.NbInstrumentation* - the whole heap 
> traversal then fails, since on JDK8 Module is not loaded from runtime, and an 
> attempt to load it from boot.jar fails.
>  



--
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-5638) NbTestCase.assertGC fails with SecurityException

2021-04-29 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5638:
--
Labels: Testing  (was: )

> NbTestCase.assertGC fails with SecurityException
> 
>
> Key: NETBEANS-5638
> URL: https://issues.apache.org/jira/browse/NETBEANS-5638
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Harness
>Affects Versions: 12.4
>Reporter: Svatopluk Dedic
>Priority: Major
>  Labels: Testing
> Fix For: 12.5
>
>
> During testing, I've found out that *assertGC* paths to root analysis fails 
> with *SecurityException* and does not provide any reasonable results:
> {code:java}
> java.lang.SecurityException: Prohibited package name: java.lang
>   at java.lang.ClassLoader.preDefineClass(ClassLoader.java:655)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:754)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
>   at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
>   at java.lang.Class.getDeclaredMethods0(Native Method)
>   at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
>   at java.lang.Class.getDeclaredMethods(Class.java:1975)
>   at 
> org.netbeans.insane.impl.InsaneEngine.recognizeClass(InsaneEngine.java:123)
> {code}
> The exception was thrown, because Insane library queries 
> *getDeclaredMethods()* on *org.netbeans.NbInstrumentation* - the whole heap 
> traversal then fails, since on JDK8 Module is not loaded from runtime, and an 
> attempt to load it from boot.jar fails.
>  



--
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] [Assigned] (NETBEANS-5638) NbTestCase.assertGC fails with SecurityException

2021-04-29 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic reassigned NETBEANS-5638:
-

Assignee: Svatopluk Dedic

> NbTestCase.assertGC fails with SecurityException
> 
>
> Key: NETBEANS-5638
> URL: https://issues.apache.org/jira/browse/NETBEANS-5638
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Harness
>Affects Versions: 12.4
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: Testing
> Fix For: 12.5
>
>
> During testing, I've found out that *assertGC* paths to root analysis fails 
> with *SecurityException* and does not provide any reasonable results:
> {code:java}
> java.lang.SecurityException: Prohibited package name: java.lang
>   at java.lang.ClassLoader.preDefineClass(ClassLoader.java:655)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:754)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
>   at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
>   at java.lang.Class.getDeclaredMethods0(Native Method)
>   at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
>   at java.lang.Class.getDeclaredMethods(Class.java:1975)
>   at 
> org.netbeans.insane.impl.InsaneEngine.recognizeClass(InsaneEngine.java:123)
> {code}
> The exception was thrown, because Insane library queries 
> *getDeclaredMethods()* on *org.netbeans.NbInstrumentation* - the whole heap 
> traversal then fails, since on JDK8 Module is not loaded from runtime, and an 
> attempt to load it from boot.jar fails.
>  



--
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-5638) NbTestCase.assertGC fails with SecurityException

2021-04-29 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5638:
--
Component/s: apisupport - Harness

> NbTestCase.assertGC fails with SecurityException
> 
>
> Key: NETBEANS-5638
> URL: https://issues.apache.org/jira/browse/NETBEANS-5638
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Harness
>Affects Versions: 12.4
>Reporter: Svatopluk Dedic
>Priority: Major
> Fix For: 12.5
>
>
> During testing, I've found out that *assertGC* paths to root analysis fails 
> with *SecurityException* and does not provide any reasonable results:
> {code:java}
> java.lang.SecurityException: Prohibited package name: java.lang
>   at java.lang.ClassLoader.preDefineClass(ClassLoader.java:655)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:754)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
>   at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
>   at java.lang.Class.getDeclaredMethods0(Native Method)
>   at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
>   at java.lang.Class.getDeclaredMethods(Class.java:1975)
>   at 
> org.netbeans.insane.impl.InsaneEngine.recognizeClass(InsaneEngine.java:123)
> {code}
> The exception was thrown, because Insane library queries 
> *getDeclaredMethods()* on *org.netbeans.NbInstrumentation* - the whole heap 
> traversal then fails, since on JDK8 Module is not loaded from runtime, and an 
> attempt to load it from boot.jar fails.
>  



--
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-5638) NbTestCase.assertGC fails with SecurityException

2021-04-29 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5638:
--
Priority: Major  (was: Critical)

> NbTestCase.assertGC fails with SecurityException
> 
>
> Key: NETBEANS-5638
> URL: https://issues.apache.org/jira/browse/NETBEANS-5638
> Project: NetBeans
>  Issue Type: Bug
>Reporter: Svatopluk Dedic
>Priority: Major
>
> During testing, I've found out that *assertGC* paths to root analysis fails 
> with *SecurityException* and does not provide any reasonable results:
> {code:java}
> java.lang.SecurityException: Prohibited package name: java.lang
>   at java.lang.ClassLoader.preDefineClass(ClassLoader.java:655)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:754)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
>   at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
>   at java.lang.Class.getDeclaredMethods0(Native Method)
>   at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
>   at java.lang.Class.getDeclaredMethods(Class.java:1975)
>   at 
> org.netbeans.insane.impl.InsaneEngine.recognizeClass(InsaneEngine.java:123)
> {code}
> The exception was thrown, because Insane library queries 
> *getDeclaredMethods()* on *org.netbeans.NbInstrumentation* - the whole heap 
> traversal then fails, since on JDK8 Module is not loaded from runtime, and an 
> attempt to load it from boot.jar fails.
>  



--
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-5638) NbTestCase.assertGC fails with SecurityException

2021-04-29 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5638:
--
Affects Version/s: 12.4

> NbTestCase.assertGC fails with SecurityException
> 
>
> Key: NETBEANS-5638
> URL: https://issues.apache.org/jira/browse/NETBEANS-5638
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 12.4
>Reporter: Svatopluk Dedic
>Priority: Major
>
> During testing, I've found out that *assertGC* paths to root analysis fails 
> with *SecurityException* and does not provide any reasonable results:
> {code:java}
> java.lang.SecurityException: Prohibited package name: java.lang
>   at java.lang.ClassLoader.preDefineClass(ClassLoader.java:655)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:754)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
>   at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
>   at java.lang.Class.getDeclaredMethods0(Native Method)
>   at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
>   at java.lang.Class.getDeclaredMethods(Class.java:1975)
>   at 
> org.netbeans.insane.impl.InsaneEngine.recognizeClass(InsaneEngine.java:123)
> {code}
> The exception was thrown, because Insane library queries 
> *getDeclaredMethods()* on *org.netbeans.NbInstrumentation* - the whole heap 
> traversal then fails, since on JDK8 Module is not loaded from runtime, and an 
> attempt to load it from boot.jar fails.
>  



--
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-5638) NbTestCase.assertGC fails with SecurityException

2021-04-29 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5638:
--
Fix Version/s: 12.5

> NbTestCase.assertGC fails with SecurityException
> 
>
> Key: NETBEANS-5638
> URL: https://issues.apache.org/jira/browse/NETBEANS-5638
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 12.4
>Reporter: Svatopluk Dedic
>Priority: Major
> Fix For: 12.5
>
>
> During testing, I've found out that *assertGC* paths to root analysis fails 
> with *SecurityException* and does not provide any reasonable results:
> {code:java}
> java.lang.SecurityException: Prohibited package name: java.lang
>   at java.lang.ClassLoader.preDefineClass(ClassLoader.java:655)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:754)
>   at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
>   at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
>   at java.lang.Class.getDeclaredMethods0(Native Method)
>   at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
>   at java.lang.Class.getDeclaredMethods(Class.java:1975)
>   at 
> org.netbeans.insane.impl.InsaneEngine.recognizeClass(InsaneEngine.java:123)
> {code}
> The exception was thrown, because Insane library queries 
> *getDeclaredMethods()* on *org.netbeans.NbInstrumentation* - the whole heap 
> traversal then fails, since on JDK8 Module is not loaded from runtime, and an 
> attempt to load it from boot.jar fails.
>  



--
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] [Created] (NETBEANS-5638) NbTestCase.assertGC fails with SecurityException

2021-04-29 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5638:
-

 Summary: NbTestCase.assertGC fails with SecurityException
 Key: NETBEANS-5638
 URL: https://issues.apache.org/jira/browse/NETBEANS-5638
 Project: NetBeans
  Issue Type: Bug
Reporter: Svatopluk Dedic


During testing, I've found out that *assertGC* paths to root analysis fails 
with *SecurityException* and does not provide any reasonable results:
{code:java}
java.lang.SecurityException: Prohibited package name: java.lang
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:655)
at java.lang.ClassLoader.defineClass(ClassLoader.java:754)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.getDeclaredMethods(Class.java:1975)
at 
org.netbeans.insane.impl.InsaneEngine.recognizeClass(InsaneEngine.java:123)
{code}
The exception was thrown, because Insane library queries *getDeclaredMethods()* 
on *org.netbeans.NbInstrumentation* - the whole heap traversal then fails, 
since on JDK8 Module is not loaded from runtime, and an attempt to load it from 
boot.jar fails.

 



--
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] [Comment Edited] (NETBEANS-5594) NBP12.3 application on JDK16/mac OS: Cannot load even default layout

2021-04-27 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333298#comment-17333298
 ] 

Svatopluk Dedic edited comment on NETBEANS-5594 at 4/27/21, 2:37 PM:
-

This was fixed in master:
 * upgraded Felix library, as 6.3 had a bug in JDK16 environment. Not sure 
where it was exactly broken, but its proxied URLStreamHandlerFactory threw 
MalformedURLs for http(s).
 * synced add-opens in harness with the ones in the NetBeans ide build

Fixes are in 12.4 RC1, will be part of 12.4 release. See NETBEANS-5499 for the 
Felix issue.


was (Author: sdedic):
This was fixed in master:
 * upgraded Felix library, as 6.3 had a bug in JDK16 environment. Not sure 
where it was exactly broken, but its proxied URLStreamHandlerFactory threw 
MalformedURLs for http(s).
 * synced add-opens in harness with the ones in the NetBeans ide build

Fixes are in 12.4 RC1, will be part of 12.4 release. See NETBEANS-5394 for the 
Felix issue.

> NBP12.3 application on JDK16/mac OS: Cannot load even default layout
> 
>
> Key: NETBEANS-5594
> URL: https://issues.apache.org/jira/browse/NETBEANS-5594
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Harness
>Affects Versions: 12.3
>Reporter: Sebastian Jaenicke
>Priority: Critical
> Attachments: jdk8-messages.log, messages.log2, messages3.log
>
>
> NBP application using 12.3, JDK 16, runs fine on Linux.
> On mac OS (Big Sur), I first got lots of relection-related exceptions from 
> NbInstaller, e.g.:
> java.lang.reflect.InaccessibleObjectException: Unable to make protected 
> java.util.Enumeration java.lang.ClassLoader.findResources(java.lang.String) 
> throws java.io.IOException accessible: module java.base does not "opens 
> java.lang" to unnamed module @4ccc0db7
>  at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
>  at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
>  at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
>  at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> [catch] at org.netbeans.Module.findResources(Module.java:567)
>  at org.netbeans.core.startup.NbInstaller.loadLayers(NbInstaller.java:605)
>  at org.netbeans.core.startup.NbInstaller.loadImpl(NbInstaller.java:332)
>  at org.netbeans.core.startup.NbInstaller.access$000(NbInstaller.java:77)
>  at org.netbeans.core.startup.NbInstaller$1.run(NbInstaller.java:322)
>  at org.openide.filesystems.FileUtil$2.run(FileUtil.java:413)
>  
> so I added '-J--illegal-access=permit' to default_options in etc/mgx_gui.conf.
> Now, after completely removing the user_dir, I get
>  * a popup warning: 'Cannot load even default layout, using internally 
> predefined configuration.'
>  * a NullPointerException related to FileObject.isValid()
> UI window itself is opened, but remains empty. I'm attaching the full 
> messages.log file,
> any ideas would be greatly appreciated.
>  



--
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] [Comment Edited] (NETBEANS-5594) NBP12.3 application on JDK16/mac OS: Cannot load even default layout

2021-04-27 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333298#comment-17333298
 ] 

Svatopluk Dedic edited comment on NETBEANS-5594 at 4/27/21, 2:37 PM:
-

This was fixed in master:
 * upgraded Felix library, as 6.3 had a bug in JDK16 environment. Not sure 
where it was exactly broken, but its proxied URLStreamHandlerFactory threw 
MalformedURLs for http(s).
 * synced add-opens in harness with the ones in the NetBeans ide build

Fixes are in 12.4 RC1, will be part of 12.4 release. See NETBEANS-5394 for the 
Felix issue.


was (Author: sdedic):
This was fixed in master:
 * upgraded Felix library, as 6.3 had a bug in JDK16 environment. Not sure 
where it was exactly broken, but its proxied URLStreamHandlerFactory threw 
MalformedURLs for http(s).
 * synced add-opens in harness with the ones in the NetBeans ide build

Fixes are in 12.4 RC1, will be part of 12.4 release.

> NBP12.3 application on JDK16/mac OS: Cannot load even default layout
> 
>
> Key: NETBEANS-5594
> URL: https://issues.apache.org/jira/browse/NETBEANS-5594
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Harness
>Affects Versions: 12.3
>Reporter: Sebastian Jaenicke
>Priority: Critical
> Attachments: jdk8-messages.log, messages.log2, messages3.log
>
>
> NBP application using 12.3, JDK 16, runs fine on Linux.
> On mac OS (Big Sur), I first got lots of relection-related exceptions from 
> NbInstaller, e.g.:
> java.lang.reflect.InaccessibleObjectException: Unable to make protected 
> java.util.Enumeration java.lang.ClassLoader.findResources(java.lang.String) 
> throws java.io.IOException accessible: module java.base does not "opens 
> java.lang" to unnamed module @4ccc0db7
>  at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
>  at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
>  at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
>  at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> [catch] at org.netbeans.Module.findResources(Module.java:567)
>  at org.netbeans.core.startup.NbInstaller.loadLayers(NbInstaller.java:605)
>  at org.netbeans.core.startup.NbInstaller.loadImpl(NbInstaller.java:332)
>  at org.netbeans.core.startup.NbInstaller.access$000(NbInstaller.java:77)
>  at org.netbeans.core.startup.NbInstaller$1.run(NbInstaller.java:322)
>  at org.openide.filesystems.FileUtil$2.run(FileUtil.java:413)
>  
> so I added '-J--illegal-access=permit' to default_options in etc/mgx_gui.conf.
> Now, after completely removing the user_dir, I get
>  * a popup warning: 'Cannot load even default layout, using internally 
> predefined configuration.'
>  * a NullPointerException related to FileObject.isValid()
> UI window itself is opened, but remains empty. I'm attaching the full 
> messages.log file,
> any ideas would be greatly appreciated.
>  



--
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] [Commented] (NETBEANS-5594) NBP12.3 application on JDK16/mac OS: Cannot load even default layout

2021-04-27 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333298#comment-17333298
 ] 

Svatopluk Dedic commented on NETBEANS-5594:
---

This was fixed in master:
 * upgraded Felix library, as 6.3 had a bug in JDK16 environment. Not sure 
where it was exactly broken, but its proxied URLStreamHandlerFactory threw 
MalformedURLs for http(s).
 * synced add-opens in harness with the ones in the NetBeans ide build

Fixes are in 12.4 RC1, will be part of 12.4 release.

> NBP12.3 application on JDK16/mac OS: Cannot load even default layout
> 
>
> Key: NETBEANS-5594
> URL: https://issues.apache.org/jira/browse/NETBEANS-5594
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Harness
>Affects Versions: 12.3
>Reporter: Sebastian Jaenicke
>Priority: Critical
> Attachments: jdk8-messages.log, messages.log2, messages3.log
>
>
> NBP application using 12.3, JDK 16, runs fine on Linux.
> On mac OS (Big Sur), I first got lots of relection-related exceptions from 
> NbInstaller, e.g.:
> java.lang.reflect.InaccessibleObjectException: Unable to make protected 
> java.util.Enumeration java.lang.ClassLoader.findResources(java.lang.String) 
> throws java.io.IOException accessible: module java.base does not "opens 
> java.lang" to unnamed module @4ccc0db7
>  at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
>  at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
>  at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
>  at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> [catch] at org.netbeans.Module.findResources(Module.java:567)
>  at org.netbeans.core.startup.NbInstaller.loadLayers(NbInstaller.java:605)
>  at org.netbeans.core.startup.NbInstaller.loadImpl(NbInstaller.java:332)
>  at org.netbeans.core.startup.NbInstaller.access$000(NbInstaller.java:77)
>  at org.netbeans.core.startup.NbInstaller$1.run(NbInstaller.java:322)
>  at org.openide.filesystems.FileUtil$2.run(FileUtil.java:413)
>  
> so I added '-J--illegal-access=permit' to default_options in etc/mgx_gui.conf.
> Now, after completely removing the user_dir, I get
>  * a popup warning: 'Cannot load even default layout, using internally 
> predefined configuration.'
>  * a NullPointerException related to FileObject.isValid()
> UI window itself is opened, but remains empty. I'm attaching the full 
> messages.log file,
> any ideas would be greatly appreciated.
>  



--
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] [Commented] (NETBEANS-5629) Gradle project Lookups ordering not defined well

2021-04-27 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333291#comment-17333291
 ] 

Svatopluk Dedic commented on NETBEANS-5629:
---

Note: given the order is *unspecified* (in fact), I would like to take an 
opportunity to somehow unify the behaviour with *Maven*, which now has 
*packaging*-dependent services, but lacks *plugin*-dependent ones (see 
NETBEANS-5394).

BTW there's one interesting difference between *ProxyLookup* composition and 
the composition that *MimeLookup* does:
 * ProxyLookup just orders the enumerated instance according to the delegate 
order. *position* attribute just orders within one delegate, so e.g. a *java* 
service can not go after/make a fallback to  *java-base* service (provided that 
java-base comes in earlier delegate)
 * MimeLookup applies the *position* attribute across branches. So one can 
position a "plug in" service before, or after the 'generic' one at will.

[~jtulach] - what do you think: shouldn't we use the MimeLookup-like 
composition for plugin-implied services ?

 

> Gradle project Lookups ordering not defined well
> 
>
> Key: NETBEANS-5629
> URL: https://issues.apache.org/jira/browse/NETBEANS-5629
> Project: NetBeans
>  Issue Type: Bug
>Reporter: Svatopluk Dedic
>Priority: Major
>
> Individual Plugins can contribute to project Lookup. In my testcase, which 
> uses java/java-base plugins, the Lookups loaded from 
> *Projects/org-netbeans-modules-gradle/*** were loaded in the following order:
> {code:java}
> [java, , root, java-base, base]
> {code}
> When Groovy was also present, the order was
> {code:java}
> [java, groovy, , root, groovy-base, java-base, base]
> {code}
> (note - groovy after java, groovy-base before java-base). But with scala, the 
> order is:
> {code:java}
> [java, scala, , root, java-base, scala-base, base]
> {code}
> (note - scala-base AFTER java-base).
> When opening a project with 
> {code:java}
> apply plugin: 'groovy'
> {code}
> the order is yet different:
> {code:java}
> [groovy, java, , root, groovy-base, java-base, base]{code}
> The order is unreliable and I guess under some circumstances even the 
> , xxx-base and xxx could be reordered as plugin names go through 
> series of hashmaps.



--
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] [Comment Edited] (NETBEANS-5627) Gradle project Lookup inconsistent until OpenProjects.open()

2021-04-27 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333286#comment-17333286
 ] 

Svatopluk Dedic edited comment on NETBEANS-5627 at 4/27/21, 2:18 PM:
-

Yes, that's it. I have already a half-working solution, but not ready yet: the 
goal is to load from caches (but no more) during project construction (or fail 
onto fallback quality if there's no cache + project not trusted). Someone 
should explicitly ask for better-than-cache in order to evaluate (trusted) 
Gradle script. But trying to solve along with NETBEANS- 5629


was (Author: sdedic):
Yes, that's it. I have already a half-working solution, but not ready yet: the 
goal is to load from caches (but no more) during project construction (or fail 
onto fallback quality if there's no cache + project not trusted). Someone 
should explicitly ask for better-than-cache in order to evaluate (trusted) 
Gradle script. But trying to solve along with NETBEANS- 5628

> Gradle project Lookup inconsistent until OpenProjects.open()
> 
>
> Key: NETBEANS-5627
> URL: https://issues.apache.org/jira/browse/NETBEANS-5627
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Reporter: Svatopluk Dedic
>Assignee: Laszlo Kishalmi
>Priority: Major
>
> Gradle fallback support recognizes several plugins from the directory 
> structure (without reading the {{build.gradle}} file): groovy, java,  scala, 
> war.
> However project Lookup does not contain services for those Plugins, until 
> OpenProjects.open() is called. The Project, however still untrusted, and 
> unevaluated, starts to serve java-related services.
> This is inconsistent with project API's philosophy: 
> [https://bits.netbeans.org/dev/javadoc/org-netbeans-modules-projectuiapi-base/org/netbeans/api/project/ui/OpenProjects.html]
> {quote}*Only certain operations should actually be aware of which projects 
> are "open"; by default, all project functionality should be available whether 
> it is open or not.*
> {quote}
> In this particular situation, ClassPath.getClassPath(sourceFile, SOURCE) does 
> not return ClassPath even though Gradle fallback support recognizes 'java' 
> and 'java-base' plugins until the project opens in the UI. For the rest of 
> the IDE, the project appears as not having any sources in it - the returned 
> ClassPath is not marked as incomplete, but simply does not exist.



--
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] [Commented] (NETBEANS-5627) Gradle project Lookup inconsistent until OpenProjects.open()

2021-04-27 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333286#comment-17333286
 ] 

Svatopluk Dedic commented on NETBEANS-5627:
---

Yes, that's it. I have already a half-working solution, but not ready yet: the 
goal is to load from caches (but no more) during project construction (or fail 
onto fallback quality if there's no cache + project not trusted). Someone 
should explicitly ask for better-than-cache in order to evaluate (trusted) 
Gradle script. But trying to solve along with NETBEANS- 5628

> Gradle project Lookup inconsistent until OpenProjects.open()
> 
>
> Key: NETBEANS-5627
> URL: https://issues.apache.org/jira/browse/NETBEANS-5627
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Reporter: Svatopluk Dedic
>Assignee: Laszlo Kishalmi
>Priority: Major
>
> Gradle fallback support recognizes several plugins from the directory 
> structure (without reading the {{build.gradle}} file): groovy, java,  scala, 
> war.
> However project Lookup does not contain services for those Plugins, until 
> OpenProjects.open() is called. The Project, however still untrusted, and 
> unevaluated, starts to serve java-related services.
> This is inconsistent with project API's philosophy: 
> [https://bits.netbeans.org/dev/javadoc/org-netbeans-modules-projectuiapi-base/org/netbeans/api/project/ui/OpenProjects.html]
> {quote}*Only certain operations should actually be aware of which projects 
> are "open"; by default, all project functionality should be available whether 
> it is open or not.*
> {quote}
> In this particular situation, ClassPath.getClassPath(sourceFile, SOURCE) does 
> not return ClassPath even though Gradle fallback support recognizes 'java' 
> and 'java-base' plugins until the project opens in the UI. For the rest of 
> the IDE, the project appears as not having any sources in it - the returned 
> ClassPath is not marked as incomplete, but simply does not exist.



--
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] [Created] (NETBEANS-5629) Gradle project Lookups ordering not defined well

2021-04-27 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5629:
-

 Summary: Gradle project Lookups ordering not defined well
 Key: NETBEANS-5629
 URL: https://issues.apache.org/jira/browse/NETBEANS-5629
 Project: NetBeans
  Issue Type: Bug
Reporter: Svatopluk Dedic


Individual Plugins can contribute to project Lookup. In my testcase, which uses 
java/java-base plugins, the Lookups loaded from 
*Projects/org-netbeans-modules-gradle/*** were loaded in the following order:
{code:java}
[java, , root, java-base, base]
{code}
When Groovy was also present, the order was
{code:java}
[java, groovy, , root, groovy-base, java-base, base]
{code}
(note - groovy after java, groovy-base before java-base). But with scala, the 
order is:
{code:java}
[java, scala, , root, java-base, scala-base, base]
{code}
(note - scala-base AFTER java-base).

When opening a project with 
{code:java}
apply plugin: 'groovy'
{code}
the order is yet different:
{code:java}
[groovy, java, , root, groovy-base, java-base, base]{code}
The order is unreliable and I guess under some circumstances even the 
, xxx-base and xxx could be reordered as plugin names go through 
series of hashmaps.



--
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-5628) Fallback project support should (heuristically) honour apply / plugin directives.

2021-04-27 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5628:
--
Summary: Fallback project support should (heuristically) honour apply / 
plugin directives.  (was: Fallback project support shoudl honour apply (plugin) 
directives.)

> Fallback project support should (heuristically) honour apply / plugin 
> directives.
> -
>
> Key: NETBEANS-5628
> URL: https://issues.apache.org/jira/browse/NETBEANS-5628
> Project: NetBeans
>  Issue Type: Improvement
>Reporter: Svatopluk Dedic
>Priority: Major
>
> The gradle cannot be executed to process/read the build.gradle until the 
> project is trusted. But at least basic technology plugins should be 
> recognized - and the process should be pluggable. Right now, the technologies 
> are hardcoded to: scala, java, groovy, war.
> The *ProjectInfoExtractor* should get an extension to actually *contribute* 
> to the GradleBaseProject (maybe others, too ?) - e.g. passing some Builder 
> around to the individual Extractors somehow.
> The base implementation should lookup / honour simple cases like
> {code:java}
> plugins { 
>    id("io.github.gradle-nexus.publish-plugin") version "1.0.0" 
> } 
> apply plugin: java{code}
> Individual gradle-aware project modules could extend the recognition to e.g.
>  
>  
> {code:java}
> // code placeholder
> application {
>mainClass.set("com.example1.Application")
> }
> micronaut { 
> ...
> } 
>  {code}
> Of course that would be *just a heuristic*, but could allow individual 
> implementations to be exposed early, so the query system in the IDE is not 
> broken that much.
> Maybe a contribution to *plugins* could be sufficient as a start, but the 
> interface should support extensions for the future.
>  



--
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] [Created] (NETBEANS-5628) Fallback project support shoudl honour apply (plugin) directives.

2021-04-27 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5628:
-

 Summary: Fallback project support shoudl honour apply (plugin) 
directives.
 Key: NETBEANS-5628
 URL: https://issues.apache.org/jira/browse/NETBEANS-5628
 Project: NetBeans
  Issue Type: Improvement
Reporter: Svatopluk Dedic


The gradle cannot be executed to process/read the build.gradle until the 
project is trusted. But at least basic technology plugins should be recognized 
- and the process should be pluggable. Right now, the technologies are 
hardcoded to: scala, java, groovy, war.

The *ProjectInfoExtractor* should get an extension to actually *contribute* to 
the GradleBaseProject (maybe others, too ?) - e.g. passing some Builder around 
to the individual Extractors somehow.

The base implementation should lookup / honour simple cases like
{code:java}
plugins { 
   id("io.github.gradle-nexus.publish-plugin") version "1.0.0" 
} 

apply plugin: java{code}
Individual gradle-aware project modules could extend the recognition to e.g.

 

 
{code:java}
// code placeholder
application {
   mainClass.set("com.example1.Application")
}

micronaut { 
...
}  
{code}
Of course that would be *just a heuristic*, but could allow individual 
implementations to be exposed early, so the query system in the IDE is not 
broken that much.

Maybe a contribution to *plugins* could be sufficient as a start, but the 
interface should support extensions for the future.

 



--
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] [Created] (NETBEANS-5627) Gradle project Lookup inconsistent until OpenProjects.open()

2021-04-27 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5627:
-

 Summary: Gradle project Lookup inconsistent until 
OpenProjects.open()
 Key: NETBEANS-5627
 URL: https://issues.apache.org/jira/browse/NETBEANS-5627
 Project: NetBeans
  Issue Type: Bug
  Components: projects - Gradle
Reporter: Svatopluk Dedic
Assignee: Laszlo Kishalmi


Gradle fallback support recognizes several plugins from the directory structure 
(without reading the {{build.gradle}} file): groovy, java,  scala, war.

However project Lookup does not contain services for those Plugins, until 
OpenProjects.open() is called. The Project, however still untrusted, and 
unevaluated, starts to serve java-related services.

This is inconsistent with project API's philosophy: 
[https://bits.netbeans.org/dev/javadoc/org-netbeans-modules-projectuiapi-base/org/netbeans/api/project/ui/OpenProjects.html]
{quote}*Only certain operations should actually be aware of which projects are 
"open"; by default, all project functionality should be available whether it is 
open or not.*
{quote}
In this particular situation, ClassPath.getClassPath(sourceFile, SOURCE) does 
not return ClassPath even though Gradle fallback support recognizes 'java' and 
'java-base' plugins until the project opens in the UI. For the rest of the IDE, 
the project appears as not having any sources in it - the returned ClassPath is 
not marked as incomplete, but simply does not exist.



--
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] [Commented] (NETBEANS-5623) 'fallback' project without trust can turn to 'evaluated'

2021-04-26 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17332924#comment-17332924
 ] 

Svatopluk Dedic commented on NETBEANS-5623:
---

No, this was a very simple testcase :) The complete test was:
{code:java}
public void testUntrustedProjectCannotGoUp() throws Exception {
Project prj = createProject();

NbGradleProjectImpl prjImpl = 
prj.getLookup().lookup(NbGradleProjectImpl.class);

assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));
// attempt to load everything
prjImpl.setAimedQuality(NbGradleProject.Quality.FULL);
// ... it loaded, but did not escalate the quality bcs not trusted

assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));
}
{code}
so when I attempted to setAimedQuality (the project was untrusted, so nothing 
was executed), the project transitioned "upwards" in quality: FALLBACK -> 
EVALUATED. This may be minor, but still according to what you say, technically 
incorrect as the project was never loaded "better" than fallback. 

> 'fallback' project without trust can turn to 'evaluated'
> 
>
> Key: NETBEANS-5623
> URL: https://issues.apache.org/jira/browse/NETBEANS-5623
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Reporter: Svatopluk Dedic
>Assignee: Laszlo Kishalmi
>Priority: Major
>
>  
> During prototyping, I've encountered a strange thing:
>  
> {code:java}
> NbGradleProjectImpl prjImpl = 
> prj.getLookup().lookup(NbGradleProjectImpl.class);
> 
> assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));
> // attempt to load everything
> prjImpl.setAimedQuality(NbGradleProject.Quality.FULL);
> // ... it loaded, but did not escalate the quality bcs not trusted
> 
> assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));
> {code}
> I expected (the assert at the end) that a fallback project won't change as 
> it's not permitted to execute gradle for it. But it turned to evaluated (no 
> gradle was executed, in fact).
> I consider that a bug - is it ? If so, pls. reassign to me, will fix it in my 
> implementation & make PR.



--
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-5623) 'fallback' project without trust can turn to 'evaluated'

2021-04-26 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5623:
--
Description: 
 

During prototyping, I've encountered a strange thing:

 
{code:java}
NbGradleProjectImpl prjImpl = 
prj.getLookup().lookup(NbGradleProjectImpl.class);

assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));
// attempt to load everything
prjImpl.setAimedQuality(NbGradleProject.Quality.FULL);
// ... it loaded, but did not escalate the quality bcs not trusted

assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));

{code}
I expected (the assert at the end) that a fallback project won't change as it's 
not permitted to execute gradle for it. But it turned to evaluated (no gradle 
was executed, in fact).

I consider that a bug - is it ? If so, pls. reassign to me, will fix it in my 
implementation & make PR.

  was:
 

During prototyping, I've encountered a strange thing:

 
{code:java}

NbGradleProjectImpl prjImpl = 
prj.getLookup().lookup(NbGradleProjectImpl.class);

assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));
// attempt to load everything
prjImpl.setAimedQuality(NbGradleProject.Quality.FULL);
// ... it loaded, but did not escalate the quality bcs not trusted

assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));

{code}
I expected (the assert at the end) that a fallback project won't change as it's 
not permitted to execute gradle for it. But it turned to evaluated (no gradle 
was executed, in fact).

I consider that a bug - is it ?


> 'fallback' project without trust can turn to 'evaluated'
> 
>
> Key: NETBEANS-5623
> URL: https://issues.apache.org/jira/browse/NETBEANS-5623
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Reporter: Svatopluk Dedic
>Assignee: Laszlo Kishalmi
>Priority: Major
>
>  
> During prototyping, I've encountered a strange thing:
>  
> {code:java}
> NbGradleProjectImpl prjImpl = 
> prj.getLookup().lookup(NbGradleProjectImpl.class);
> 
> assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));
> // attempt to load everything
> prjImpl.setAimedQuality(NbGradleProject.Quality.FULL);
> // ... it loaded, but did not escalate the quality bcs not trusted
> 
> assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));
> {code}
> I expected (the assert at the end) that a fallback project won't change as 
> it's not permitted to execute gradle for it. But it turned to evaluated (no 
> gradle was executed, in fact).
> I consider that a bug - is it ? If so, pls. reassign to me, will fix it in my 
> implementation & make PR.



--
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-5623) 'fallback' project without trust can turn to 'evaluated'

2021-04-26 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5623:
--
Issue Type: Bug  (was: Improvement)

> 'fallback' project without trust can turn to 'evaluated'
> 
>
> Key: NETBEANS-5623
> URL: https://issues.apache.org/jira/browse/NETBEANS-5623
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Reporter: Svatopluk Dedic
>Assignee: Laszlo Kishalmi
>Priority: Major
>
>  
> During prototyping, I've encountered a strange thing:
>  
> {code:java}
> NbGradleProjectImpl prjImpl = 
> prj.getLookup().lookup(NbGradleProjectImpl.class);
> 
> assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));
> // attempt to load everything
> prjImpl.setAimedQuality(NbGradleProject.Quality.FULL);
> // ... it loaded, but did not escalate the quality bcs not trusted
> 
> assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));
> {code}
> I expected (the assert at the end) that a fallback project won't change as 
> it's not permitted to execute gradle for it. But it turned to evaluated (no 
> gradle was executed, in fact).
> I consider that a bug - is it ?



--
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] [Created] (NETBEANS-5623) 'fallback' project without trust can turn to 'evaluated'

2021-04-26 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5623:
-

 Summary: 'fallback' project without trust can turn to 'evaluated'
 Key: NETBEANS-5623
 URL: https://issues.apache.org/jira/browse/NETBEANS-5623
 Project: NetBeans
  Issue Type: Improvement
  Components: projects - Gradle
Reporter: Svatopluk Dedic
Assignee: Laszlo Kishalmi


 

During prototyping, I've encountered a strange thing:

 
{code:java}

NbGradleProjectImpl prjImpl = 
prj.getLookup().lookup(NbGradleProjectImpl.class);

assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));
// attempt to load everything
prjImpl.setAimedQuality(NbGradleProject.Quality.FULL);
// ... it loaded, but did not escalate the quality bcs not trusted

assertTrue(prjImpl.getGradleProject().getQuality().worseThan(NbGradleProject.Quality.EVALUATED));

{code}
I expected (the assert at the end) that a fallback project won't change as it's 
not permitted to execute gradle for it. But it turned to evaluated (no gradle 
was executed, in fact).

I consider that a bug - is it ?



--
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] [Created] (NETBEANS-5616) Options API dependency on Core

2021-04-23 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5616:
-

 Summary: Options API dependency on Core
 Key: NETBEANS-5616
 URL: https://issues.apache.org/jira/browse/NETBEANS-5616
 Project: NetBeans
  Issue Type: Improvement
  Components: platform - OptionsSettings
Reporter: Svatopluk Dedic


Options API dependends on netbeans.core - just to reuse the code of 
*ListImagesEditor* beaninfo editor from the core package.

This means that every module that depends on Options API will, e.g. in unit 
test initialize full netbeans core (module system, ...). 
 * split options API (SPI) and options impl
 * reuse the code through delegation (?)

 



--
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] [Created] (NETBEANS-5615) Split Gradle module to reduce dependencies

2021-04-23 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5615:
-

 Summary: Split Gradle module to reduce dependencies
 Key: NETBEANS-5615
 URL: https://issues.apache.org/jira/browse/NETBEANS-5615
 Project: NetBeans
  Issue Type: Improvement
  Components: projects - Gradle
Reporter: Svatopluk Dedic
Assignee: Laszlo Kishalmi


Gradle module should be decomposed (at least) into UI and services layers.

Excess gradle module dependencies lead to worse reuse and worse testability. 
 * dependency on core.multiview -> openide.awt, ...
 * dependency on editor , just because of usage of NbEditorKit (can it be done 
better ?)
 ** editor.fold, editor.guards, ...
 * editor.completion -> org.netbeans.modules.sampler (!)
 * options.api -> quicksearch, core (!), ...
 * navigator
 * indirectly includes xml.ui through ant.module, java.project.ui

 



--
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] [Commented] (NETBEANS-5613) Support for OSGi modules on Classpath (tests primarily)

2021-04-23 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17330180#comment-17330180
 ] 

Svatopluk Dedic commented on NETBEANS-5613:
---

I put the work-in-progress changes here: 

[https://github.com/apache/netbeans/compare/master...sdedic:sdedic/osgi-classpath-wip]

 

> Support for OSGi modules on Classpath (tests primarily)
> ---
>
> Key: NETBEANS-5613
> URL: https://issues.apache.org/jira/browse/NETBEANS-5613
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Module System
>Reporter: Svatopluk Dedic
>Assignee: Jaroslav Tulach
>Priority: Major
>
> Tests compose their execution environment on the classpath; if module system 
> is triggered (i.e. by a Lookup for Module or ModuleInfo, core loads happily 
> NB modules from the classpath. But does not load OSGi modules.
> Subsequently, NB modules that depends on those won't be 'initialized' 
> although they are well part of  and their code can be 
> actually executed. 
> Modules tha are OSGi in the current distribution are:
>  
> {code:java}
> Bundle-SymbolicName: com.fasterxml.jackson.core.jackson-annotations
> Bundle-SymbolicName: com.fasterxml.jackson.core.jackson-core
> Bundle-SymbolicName: com.fasterxml.jackson.core.jackson-databind
> Bundle-SymbolicName: com.fasterxml.jackson.dataformat.jackson-dataformat
> Bundle-SymbolicName: com.googlecode.javaewah.JavaEWAH
> Bundle-SymbolicName: com.google.guava
> Bundle-SymbolicName: com.jcraft.jzlib
> Bundle-SymbolicName: com.sun.jersey.core
> Bundle-SymbolicName: com.sun.jna
> Bundle-SymbolicName: com.sun.jna.platform
> Bundle-SymbolicName: groovy
> Bundle-SymbolicName: groovy-ant
> Bundle-SymbolicName: javax.annotation-api
> Bundle-SymbolicName: javax.servlet-api
> Bundle-SymbolicName: javax.servlet.jsp.jstl-api
> Bundle-SymbolicName: javax.validation.api
> Bundle-SymbolicName: javax.ws.rs-api
> Bundle-SymbolicName: javax.xml
> Bundle-SymbolicName: javax.xml.soap-api
> Bundle-SymbolicName: jaxb-api
> Bundle-SymbolicName: jaxb-api
> Bundle-SymbolicName: joda-time
> Bundle-SymbolicName: junit-jupiter-api
> Bundle-SymbolicName: junit-jupiter-engine
> Bundle-SymbolicName: junit-jupiter-params
> Bundle-SymbolicName: net.java.html
> Bundle-SymbolicName: net.java.html.boot
> Bundle-SymbolicName: net.java.html.boot.fx
> Bundle-SymbolicName: net.java.html.boot.script
> Bundle-SymbolicName: net.java.html.geo
> Bundle-SymbolicName: net.java.html.json
> Bundle-SymbolicName: net.java.html.sound
> Bundle-SymbolicName: org.apache.commons.beanutils
> Bundle-SymbolicName: org.apache.commons.chain
> Bundle-SymbolicName: org.apache.commons.codec
> Bundle-SymbolicName: org.apache.commons.commons-fileupload
> Bundle-SymbolicName: org.apache.commons.io
> Bundle-SymbolicName: org.apache.commons.logging
> Bundle-SymbolicName: org.apache.felix.main
> Bundle-SymbolicName: org.apache.xmlrpc
> Bundle-SymbolicName: org.eclipse.core.jobs; singleton:=true
> Bundle-SymbolicName: org.eclipse.core.runtime.compatibility.auth
> Bundle-SymbolicName: org.eclipse.core.runtime; singleton:=true
> Bundle-SymbolicName: org.eclipse.equinox.common; singleton:=true
> Bundle-SymbolicName: org.eclipse.equinox.registry;singleton:=true
> Bundle-SymbolicName: org.eclipse.equinox.security;singleton:=true
> Bundle-SymbolicName: org.eclipse.mylyn.bugzilla.core;singleton:=true
> Bundle-SymbolicName: org.eclipse.mylyn.tasks.core;singleton:=true
> Bundle-SymbolicName: org.eclipse.mylyn.wikitext.confluence.core;single
> Bundle-SymbolicName: org.eclipse.mylyn.wikitext.markdown.core;singleto
> Bundle-SymbolicName: org.eclipse.osgi; singleton:=true
> Bundle-SymbolicName: org.glassfish.hk2.api
> Bundle-SymbolicName: org.glassfish.hk2.external.asm-all-repackaged
> Bundle-SymbolicName: org.glassfish.hk2.external.cglib
> Bundle-SymbolicName: org.glassfish.hk2.external.javax.inject
> Bundle-SymbolicName: org.glassfish.hk2.locator
> Bundle-SymbolicName: org.glassfish.hk2.osgi-resource-locator
> Bundle-SymbolicName: org.glassfish.hk2.utils
> Bundle-SymbolicName: org.glassfish.javax.el
> Bundle-SymbolicName: org.glassfish.javax.faces
> Bundle-SymbolicName: org.glassfish.jersey.containers.jersey-container-se
> Bundle-SymbolicName: org.glassfish.jersey.core.jersey-client
> Bundle-SymbolicName: org.glassfish.jersey.core.jersey-common
> Bundle-SymbolicName: org.glassfish.jersey.core.jersey-server
> Bundle-SymbolicName: org.glassfish.jersey.ext.jersey-entity-filtering
> Bundle-SymbolicName: org.glassfish.jersey.media.jersey-media-moxy
> Bundle-SymbolicName: org.glassfish.web.javax.servlet.jsp.jstl
> Bundle-SymbolicName: org.json
> Bundle-SymbolicName: org.netbeans.html.ko4j
> Bundle-SymbolicName: org.netbeans.html.xhr4j
> Bundle-SymbolicName: org.primefaces
> Bundle-SymbolicName: osgi.cmpn
> 

[jira] [Assigned] (NETBEANS-5613) Support for OSGi modules on Classpath (tests primarily)

2021-04-23 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic reassigned NETBEANS-5613:
-

Assignee: Jaroslav Tulach

> Support for OSGi modules on Classpath (tests primarily)
> ---
>
> Key: NETBEANS-5613
> URL: https://issues.apache.org/jira/browse/NETBEANS-5613
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - Module System
>Reporter: Svatopluk Dedic
>Assignee: Jaroslav Tulach
>Priority: Major
>
> Tests compose their execution environment on the classpath; if module system 
> is triggered (i.e. by a Lookup for Module or ModuleInfo, core loads happily 
> NB modules from the classpath. But does not load OSGi modules.
> Subsequently, NB modules that depends on those won't be 'initialized' 
> although they are well part of  and their code can be 
> actually executed. 
> Modules tha are OSGi in the current distribution are:
>  
> {code:java}
> Bundle-SymbolicName: com.fasterxml.jackson.core.jackson-annotations
> Bundle-SymbolicName: com.fasterxml.jackson.core.jackson-core
> Bundle-SymbolicName: com.fasterxml.jackson.core.jackson-databind
> Bundle-SymbolicName: com.fasterxml.jackson.dataformat.jackson-dataformat
> Bundle-SymbolicName: com.googlecode.javaewah.JavaEWAH
> Bundle-SymbolicName: com.google.guava
> Bundle-SymbolicName: com.jcraft.jzlib
> Bundle-SymbolicName: com.sun.jersey.core
> Bundle-SymbolicName: com.sun.jna
> Bundle-SymbolicName: com.sun.jna.platform
> Bundle-SymbolicName: groovy
> Bundle-SymbolicName: groovy-ant
> Bundle-SymbolicName: javax.annotation-api
> Bundle-SymbolicName: javax.servlet-api
> Bundle-SymbolicName: javax.servlet.jsp.jstl-api
> Bundle-SymbolicName: javax.validation.api
> Bundle-SymbolicName: javax.ws.rs-api
> Bundle-SymbolicName: javax.xml
> Bundle-SymbolicName: javax.xml.soap-api
> Bundle-SymbolicName: jaxb-api
> Bundle-SymbolicName: jaxb-api
> Bundle-SymbolicName: joda-time
> Bundle-SymbolicName: junit-jupiter-api
> Bundle-SymbolicName: junit-jupiter-engine
> Bundle-SymbolicName: junit-jupiter-params
> Bundle-SymbolicName: net.java.html
> Bundle-SymbolicName: net.java.html.boot
> Bundle-SymbolicName: net.java.html.boot.fx
> Bundle-SymbolicName: net.java.html.boot.script
> Bundle-SymbolicName: net.java.html.geo
> Bundle-SymbolicName: net.java.html.json
> Bundle-SymbolicName: net.java.html.sound
> Bundle-SymbolicName: org.apache.commons.beanutils
> Bundle-SymbolicName: org.apache.commons.chain
> Bundle-SymbolicName: org.apache.commons.codec
> Bundle-SymbolicName: org.apache.commons.commons-fileupload
> Bundle-SymbolicName: org.apache.commons.io
> Bundle-SymbolicName: org.apache.commons.logging
> Bundle-SymbolicName: org.apache.felix.main
> Bundle-SymbolicName: org.apache.xmlrpc
> Bundle-SymbolicName: org.eclipse.core.jobs; singleton:=true
> Bundle-SymbolicName: org.eclipse.core.runtime.compatibility.auth
> Bundle-SymbolicName: org.eclipse.core.runtime; singleton:=true
> Bundle-SymbolicName: org.eclipse.equinox.common; singleton:=true
> Bundle-SymbolicName: org.eclipse.equinox.registry;singleton:=true
> Bundle-SymbolicName: org.eclipse.equinox.security;singleton:=true
> Bundle-SymbolicName: org.eclipse.mylyn.bugzilla.core;singleton:=true
> Bundle-SymbolicName: org.eclipse.mylyn.tasks.core;singleton:=true
> Bundle-SymbolicName: org.eclipse.mylyn.wikitext.confluence.core;single
> Bundle-SymbolicName: org.eclipse.mylyn.wikitext.markdown.core;singleto
> Bundle-SymbolicName: org.eclipse.osgi; singleton:=true
> Bundle-SymbolicName: org.glassfish.hk2.api
> Bundle-SymbolicName: org.glassfish.hk2.external.asm-all-repackaged
> Bundle-SymbolicName: org.glassfish.hk2.external.cglib
> Bundle-SymbolicName: org.glassfish.hk2.external.javax.inject
> Bundle-SymbolicName: org.glassfish.hk2.locator
> Bundle-SymbolicName: org.glassfish.hk2.osgi-resource-locator
> Bundle-SymbolicName: org.glassfish.hk2.utils
> Bundle-SymbolicName: org.glassfish.javax.el
> Bundle-SymbolicName: org.glassfish.javax.faces
> Bundle-SymbolicName: org.glassfish.jersey.containers.jersey-container-se
> Bundle-SymbolicName: org.glassfish.jersey.core.jersey-client
> Bundle-SymbolicName: org.glassfish.jersey.core.jersey-common
> Bundle-SymbolicName: org.glassfish.jersey.core.jersey-server
> Bundle-SymbolicName: org.glassfish.jersey.ext.jersey-entity-filtering
> Bundle-SymbolicName: org.glassfish.jersey.media.jersey-media-moxy
> Bundle-SymbolicName: org.glassfish.web.javax.servlet.jsp.jstl
> Bundle-SymbolicName: org.json
> Bundle-SymbolicName: org.netbeans.html.ko4j
> Bundle-SymbolicName: org.netbeans.html.xhr4j
> Bundle-SymbolicName: org.primefaces
> Bundle-SymbolicName: osgi.cmpn
> Bundle-SymbolicName: osgi.core
> Bundle-SymbolicName: slf4j.jdk14
> Bundle-SymbolicName: software.amazon.ion.java
> Bundle-SymbolicName: testng
> 

[jira] [Created] (NETBEANS-5613) Support for OSGi modules on Classpath (tests primarily)

2021-04-23 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5613:
-

 Summary: Support for OSGi modules on Classpath (tests primarily)
 Key: NETBEANS-5613
 URL: https://issues.apache.org/jira/browse/NETBEANS-5613
 Project: NetBeans
  Issue Type: Improvement
  Components: platform - Module System
Reporter: Svatopluk Dedic


Tests compose their execution environment on the classpath; if module system is 
triggered (i.e. by a Lookup for Module or ModuleInfo, core loads happily NB 
modules from the classpath. But does not load OSGi modules.

Subsequently, NB modules that depends on those won't be 'initialized' although 
they are well part of  and their code can be actually 
executed. 

Modules tha are OSGi in the current distribution are:

 
{code:java}

Bundle-SymbolicName: com.fasterxml.jackson.core.jackson-annotations
Bundle-SymbolicName: com.fasterxml.jackson.core.jackson-core
Bundle-SymbolicName: com.fasterxml.jackson.core.jackson-databind
Bundle-SymbolicName: com.fasterxml.jackson.dataformat.jackson-dataformat
Bundle-SymbolicName: com.googlecode.javaewah.JavaEWAH
Bundle-SymbolicName: com.google.guava
Bundle-SymbolicName: com.jcraft.jzlib
Bundle-SymbolicName: com.sun.jersey.core
Bundle-SymbolicName: com.sun.jna
Bundle-SymbolicName: com.sun.jna.platform
Bundle-SymbolicName: groovy
Bundle-SymbolicName: groovy-ant
Bundle-SymbolicName: javax.annotation-api
Bundle-SymbolicName: javax.servlet-api
Bundle-SymbolicName: javax.servlet.jsp.jstl-api
Bundle-SymbolicName: javax.validation.api
Bundle-SymbolicName: javax.ws.rs-api
Bundle-SymbolicName: javax.xml
Bundle-SymbolicName: javax.xml.soap-api
Bundle-SymbolicName: jaxb-api
Bundle-SymbolicName: jaxb-api
Bundle-SymbolicName: joda-time
Bundle-SymbolicName: junit-jupiter-api
Bundle-SymbolicName: junit-jupiter-engine
Bundle-SymbolicName: junit-jupiter-params
Bundle-SymbolicName: net.java.html
Bundle-SymbolicName: net.java.html.boot
Bundle-SymbolicName: net.java.html.boot.fx
Bundle-SymbolicName: net.java.html.boot.script
Bundle-SymbolicName: net.java.html.geo
Bundle-SymbolicName: net.java.html.json
Bundle-SymbolicName: net.java.html.sound
Bundle-SymbolicName: org.apache.commons.beanutils
Bundle-SymbolicName: org.apache.commons.chain
Bundle-SymbolicName: org.apache.commons.codec
Bundle-SymbolicName: org.apache.commons.commons-fileupload
Bundle-SymbolicName: org.apache.commons.io
Bundle-SymbolicName: org.apache.commons.logging
Bundle-SymbolicName: org.apache.felix.main
Bundle-SymbolicName: org.apache.xmlrpc
Bundle-SymbolicName: org.eclipse.core.jobs; singleton:=true
Bundle-SymbolicName: org.eclipse.core.runtime.compatibility.auth
Bundle-SymbolicName: org.eclipse.core.runtime; singleton:=true
Bundle-SymbolicName: org.eclipse.equinox.common; singleton:=true
Bundle-SymbolicName: org.eclipse.equinox.registry;singleton:=true
Bundle-SymbolicName: org.eclipse.equinox.security;singleton:=true
Bundle-SymbolicName: org.eclipse.mylyn.bugzilla.core;singleton:=true
Bundle-SymbolicName: org.eclipse.mylyn.tasks.core;singleton:=true
Bundle-SymbolicName: org.eclipse.mylyn.wikitext.confluence.core;single
Bundle-SymbolicName: org.eclipse.mylyn.wikitext.markdown.core;singleto
Bundle-SymbolicName: org.eclipse.osgi; singleton:=true
Bundle-SymbolicName: org.glassfish.hk2.api
Bundle-SymbolicName: org.glassfish.hk2.external.asm-all-repackaged
Bundle-SymbolicName: org.glassfish.hk2.external.cglib
Bundle-SymbolicName: org.glassfish.hk2.external.javax.inject
Bundle-SymbolicName: org.glassfish.hk2.locator
Bundle-SymbolicName: org.glassfish.hk2.osgi-resource-locator
Bundle-SymbolicName: org.glassfish.hk2.utils
Bundle-SymbolicName: org.glassfish.javax.el
Bundle-SymbolicName: org.glassfish.javax.faces
Bundle-SymbolicName: org.glassfish.jersey.containers.jersey-container-se
Bundle-SymbolicName: org.glassfish.jersey.core.jersey-client
Bundle-SymbolicName: org.glassfish.jersey.core.jersey-common
Bundle-SymbolicName: org.glassfish.jersey.core.jersey-server
Bundle-SymbolicName: org.glassfish.jersey.ext.jersey-entity-filtering
Bundle-SymbolicName: org.glassfish.jersey.media.jersey-media-moxy
Bundle-SymbolicName: org.glassfish.web.javax.servlet.jsp.jstl
Bundle-SymbolicName: org.json
Bundle-SymbolicName: org.netbeans.html.ko4j
Bundle-SymbolicName: org.netbeans.html.xhr4j
Bundle-SymbolicName: org.primefaces
Bundle-SymbolicName: osgi.cmpn
Bundle-SymbolicName: osgi.core
Bundle-SymbolicName: slf4j.jdk14
Bundle-SymbolicName: software.amazon.ion.java
Bundle-SymbolicName: testng

{code}
And some others. 

Tests that eventually use those modules on classpath must either use 
NbModuleSuite, or will eventually fail to initialize the module system 
properly, even though the running code can actually use the module's classes.

Most notably, there're *asm-8.0*.jar*, which is used at boostrap and are 
included by *org.netbeans.lib.asm* NetBeans module wrapper, although the JARs 
themselves are OSGi modules. This complicates 

[jira] [Created] (NETBEANS-5612) Mocked module system in test runs

2021-04-23 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5612:
-

 Summary: Mocked module system in test runs
 Key: NETBEANS-5612
 URL: https://issues.apache.org/jira/browse/NETBEANS-5612
 Project: NetBeans
  Issue Type: Improvement
  Components: platform - Module System
Reporter: Svatopluk Dedic


I've noticed that in some tests (currently: gradle) Module system complains in 
test logs that this or that module is not enabled. While *some* tests aim to 
check dynamic behaviour, i.e. when a plugin module/provider is/is not present, 
or test behaviour of module system and the config infrastructure itself,  
*most* of tests work in "static" environment they build on Classpath.

But as a simple call as *NbPrefences.forModule* may initialize ModuleManager 
and its dependency checks. It greatly prolongs test time and makes the logs 
full of garbage.

But mocking just Preferences won't be probably sufficient.

I think that there should be some 'mock' ModuleManager for tests, that could 
eventually serve Module objects whose state would be (for example) all enabled, 
as they are all active on the Classpath (and therefore their registrations in 
META-INF are read by classloaders). Such a support should be strictly opt-in 
for older code, and ideally opt-out for code with newer dependencies (assuming 
that just a fraction of tests actually check module's state).

 



--
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] [Commented] (NETBEANS-5610) Gradle project loaded several times during project open

2021-04-21 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17326731#comment-17326731
 ] 

Svatopluk Dedic commented on NETBEANS-5610:
---

Question: can you think about a way how I could create unit tests for opening / 
working with gradle projects ? I am not sure if it is permitted/possible to 
actually launch gradle on the ASF build machines ... any guidance will be 
welcomed & turned into code.

> Gradle project loaded several times during project open
> ---
>
> Key: NETBEANS-5610
> URL: https://issues.apache.org/jira/browse/NETBEANS-5610
> Project: NetBeans
>  Issue Type: Bug
>  Components: lsp, projects - Gradle
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: performance, race-condition
> Attachments: gradleproject.log
>
>
> To reproduce: get a LSP client, e.g. VSCode. get *micronaut-test* project, 
> which is multi-project. In the LSP client, open a source from *test-junit5*.
> I noticed that Gradle projects are loaded several times during LSP "project 
> open" operation. The project first aims for FALLBACK and only then for 
> FULL_ONLINE; maybe an issue with the 'priming' action.
> But immediately after that the project again loads FALLBACK (from a RP, 
> presumably a scheduled task from project open ?) and the *again* aiming FULL 
> (from the projectOpened hook).
> Finally the *parent* (root) project is opened - surprising at level FALLBACK 
> - from *WorkspaceServiceImpl.getTestRootURLs*. Not sure if this quality level 
> is sufficient for further operation: [~lkishalmi]  – what are the 
> implications of getting the container project just to FALLBACK quality ?
> // cc: [~dbalek]



--
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] [Commented] (NETBEANS-5610) Gradle project loaded several times during project open

2021-04-21 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17326729#comment-17326729
 ] 

Svatopluk Dedic commented on NETBEANS-5610:
---

There are several issues.

First the "prime" action unnecessarily loads FALLBACK quality. In general, it's 
OK, but in this specific case (providing that the project is trusted), if 
someone asks for its enablement (explicitly), it's better to aim for better 
quality - not necessarily achievable, if the project is seen for 1st time, or 
was never compiled (artifacts missing, caches empty). But could be eventually 
populated from a cache, IMHO. At worst, the isActionEnabled() should load 
nothing (or do something very quick) and a full load should be done from 
invokeAction. I'll try to achieve that - that is without compromising speed of 
opening.

The other fallback from project.close() is simply unnecessary: the only purpose 
of that call is to get roots to be removed from the indexer; typically roots 
are known at the time of project close. Will try to fix this as well.

Still investigating some Classpath issues around.

> Gradle project loaded several times during project open
> ---
>
> Key: NETBEANS-5610
> URL: https://issues.apache.org/jira/browse/NETBEANS-5610
> Project: NetBeans
>  Issue Type: Bug
>  Components: lsp, projects - Gradle
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: performance, race-condition
> Attachments: gradleproject.log
>
>
> To reproduce: get a LSP client, e.g. VSCode. get *micronaut-test* project, 
> which is multi-project. In the LSP client, open a source from *test-junit5*.
> I noticed that Gradle projects are loaded several times during LSP "project 
> open" operation. The project first aims for FALLBACK and only then for 
> FULL_ONLINE; maybe an issue with the 'priming' action.
> But immediately after that the project again loads FALLBACK (from a RP, 
> presumably a scheduled task from project open ?) and the *again* aiming FULL 
> (from the projectOpened hook).
> Finally the *parent* (root) project is opened - surprising at level FALLBACK 
> - from *WorkspaceServiceImpl.getTestRootURLs*. Not sure if this quality level 
> is sufficient for further operation: [~lkishalmi]  – what are the 
> implications of getting the container project just to FALLBACK quality ?
> // cc: [~dbalek]



--
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-5610) Gradle project loaded several times during project open

2021-04-21 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5610:
--
Attachment: gradleproject.log

> Gradle project loaded several times during project open
> ---
>
> Key: NETBEANS-5610
> URL: https://issues.apache.org/jira/browse/NETBEANS-5610
> Project: NetBeans
>  Issue Type: Bug
>  Components: lsp, projects - Gradle
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: performance, race-condition
> Attachments: gradleproject.log
>
>
> To reproduce: get a LSP client, e.g. VSCode. get *micronaut-test* project, 
> which is multi-project. In the LSP client, open a source from *test-junit5*.
> I noticed that Gradle projects are loaded several times during LSP "project 
> open" operation. The project first aims for FALLBACK and only then for 
> FULL_ONLINE; maybe an issue with the 'priming' action.
> But immediately after that the project again loads FALLBACK (from a RP, 
> presumably a scheduled task from project open ?) and the *again* aiming FULL 
> (from the projectOpened hook).
> Finally the *parent* (root) project is opened - surprising at level FALLBACK 
> - from *WorkspaceServiceImpl.getTestRootURLs*. Not sure if this quality level 
> is sufficient for further operation: [~lkishalmi]  – what are the 
> implications of getting the container project just to FALLBACK quality ?
> // cc: [~dbalek]



--
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] [Created] (NETBEANS-5610) Gradle project loaded several times during project open

2021-04-21 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5610:
-

 Summary: Gradle project loaded several times during project open
 Key: NETBEANS-5610
 URL: https://issues.apache.org/jira/browse/NETBEANS-5610
 Project: NetBeans
  Issue Type: Bug
  Components: lsp, projects - Gradle
Reporter: Svatopluk Dedic
Assignee: Svatopluk Dedic


To reproduce: get a LSP client, e.g. VSCode. get *micronaut-test* project, 
which is multi-project. In the LSP client, open a source from *test-junit5*.

I noticed that Gradle projects are loaded several times during LSP "project 
open" operation. The project first aims for FALLBACK and only then for 
FULL_ONLINE; maybe an issue with the 'priming' action.

But immediately after that the project again loads FALLBACK (from a RP, 
presumably a scheduled task from project open ?) and the *again* aiming FULL 
(from the projectOpened hook).

Finally the *parent* (root) project is opened - surprising at level FALLBACK - 
from *WorkspaceServiceImpl.getTestRootURLs*. Not sure if this quality level is 
sufficient for further operation: [~lkishalmi]  – what are the implications of 
getting the container project just to FALLBACK quality ?

// cc: [~dbalek]



--
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-5609) Gradle project (re)loaded after close.

2021-04-21 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5609:
--
Labels: performance  (was: )

> Gradle project (re)loaded after close.
> --
>
> Key: NETBEANS-5609
> URL: https://issues.apache.org/jira/browse/NETBEANS-5609
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Reporter: Svatopluk Dedic
>Assignee: Laszlo Kishalmi
>Priority: Minor
>  Labels: performance
>
> When Gradle project is closed, its props are immediately reloaded back 
> because of calls from RepositoryUpdater. RepositoryUpdater is closing / 
> removing indexed roots and needs just URLs; but the now-closed project 
> performs a new {{loadProject}}. 
> {code:java}
> INFO [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load 
> aiming FALLBACK for Unloaded Gradle Project: 
> GradleFiles[projectDir=/space/src/micronaut/micronaut-test/test-junit5, 
> rootDir=/space/src/micronaut/micronaut-test]INFO 
> [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load aiming 
> FALLBACK for Unloaded Gradle Project: 
> GradleFiles[projectDir=/space/src/micronaut/micronaut-test/test-junit5, 
> rootDir=/space/src/micronaut/micronaut-test]java.lang.Throwable at 
> org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl.loadProject(GradleProjectLoaderImpl.java:50)
>  at 
> org.netbeans.modules.gradle.NbGradleProjectImpl.loadProject(NbGradleProjectImpl.java:259)
>  at 
> org.netbeans.modules.gradle.NbGradleProjectImpl.loadProject(NbGradleProjectImpl.java:254)
>  at 
> org.netbeans.modules.gradle.NbGradleProjectImpl.getGradleProject(NbGradleProjectImpl.java:184)
>  at 
> org.netbeans.modules.gradle.api.NbGradleProject.projectLookup(NbGradleProject.java:182)
>  at 
> org.netbeans.modules.gradle.java.api.GradleJavaProject.get(GradleJavaProject.java:125)
>  at 
> org.netbeans.modules.gradle.java.classpath.ClassPathProviderImpl.findClassPath(ClassPathProviderImpl.java:107)
>  at 
> org.netbeans.modules.csl.core.ProjectClassPathProvider.findClassPath(ProjectClassPathProvider.java:45)
>  at 
> org.netbeans.api.java.classpath.ClassPath.getClassPath(ClassPath.java:667) at 
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer.ensureSourcePath(JavaCustomIndexer.java:1338)
>  at 
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer.access$200(JavaCustomIndexer.java:132)
>  at 
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer$Factory.rootsRemoved(JavaCustomIndexer.java:1201)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.notifyRootsRemoved(RepositoryUpdater.java:5221)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.getDone(RepositoryUpdater.java:5125)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3420)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6183)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$4300(RepositoryUpdater.java:5834)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2$1.run(RepositoryUpdater.java:6099)
>  at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279){code}



--
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] [Assigned] (NETBEANS-5609) Gradle project (re)loaded after close.

2021-04-21 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic reassigned NETBEANS-5609:
-

Assignee: Laszlo Kishalmi

> Gradle project (re)loaded after close.
> --
>
> Key: NETBEANS-5609
> URL: https://issues.apache.org/jira/browse/NETBEANS-5609
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Reporter: Svatopluk Dedic
>Assignee: Laszlo Kishalmi
>Priority: Minor
>
> When Gradle project is closed, its props are immediately reloaded back 
> because of calls from RepositoryUpdater. RepositoryUpdater is closing / 
> removing indexed roots and needs just URLs; but the now-closed project 
> performs a new {{loadProject}}. 
> {code:java}
> INFO [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load 
> aiming FALLBACK for Unloaded Gradle Project: 
> GradleFiles[projectDir=/space/src/micronaut/micronaut-test/test-junit5, 
> rootDir=/space/src/micronaut/micronaut-test]INFO 
> [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load aiming 
> FALLBACK for Unloaded Gradle Project: 
> GradleFiles[projectDir=/space/src/micronaut/micronaut-test/test-junit5, 
> rootDir=/space/src/micronaut/micronaut-test]java.lang.Throwable at 
> org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl.loadProject(GradleProjectLoaderImpl.java:50)
>  at 
> org.netbeans.modules.gradle.NbGradleProjectImpl.loadProject(NbGradleProjectImpl.java:259)
>  at 
> org.netbeans.modules.gradle.NbGradleProjectImpl.loadProject(NbGradleProjectImpl.java:254)
>  at 
> org.netbeans.modules.gradle.NbGradleProjectImpl.getGradleProject(NbGradleProjectImpl.java:184)
>  at 
> org.netbeans.modules.gradle.api.NbGradleProject.projectLookup(NbGradleProject.java:182)
>  at 
> org.netbeans.modules.gradle.java.api.GradleJavaProject.get(GradleJavaProject.java:125)
>  at 
> org.netbeans.modules.gradle.java.classpath.ClassPathProviderImpl.findClassPath(ClassPathProviderImpl.java:107)
>  at 
> org.netbeans.modules.csl.core.ProjectClassPathProvider.findClassPath(ProjectClassPathProvider.java:45)
>  at 
> org.netbeans.api.java.classpath.ClassPath.getClassPath(ClassPath.java:667) at 
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer.ensureSourcePath(JavaCustomIndexer.java:1338)
>  at 
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer.access$200(JavaCustomIndexer.java:132)
>  at 
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer$Factory.rootsRemoved(JavaCustomIndexer.java:1201)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.notifyRootsRemoved(RepositoryUpdater.java:5221)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.getDone(RepositoryUpdater.java:5125)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3420)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6183)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$4300(RepositoryUpdater.java:5834)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2$1.run(RepositoryUpdater.java:6099)
>  at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279){code}



--
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-5609) Gradle project (re)loaded after close.

2021-04-21 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5609:
--
Component/s: projects - Gradle

> Gradle project (re)loaded after close.
> --
>
> Key: NETBEANS-5609
> URL: https://issues.apache.org/jira/browse/NETBEANS-5609
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Reporter: Svatopluk Dedic
>Priority: Minor
>
> When Gradle project is closed, its props are immediately reloaded back 
> because of calls from RepositoryUpdater. RepositoryUpdater is closing / 
> removing indexed roots and needs just URLs; but the now-closed project 
> performs a new {{loadProject}}. 
> {code:java}
> INFO [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load 
> aiming FALLBACK for Unloaded Gradle Project: 
> GradleFiles[projectDir=/space/src/micronaut/micronaut-test/test-junit5, 
> rootDir=/space/src/micronaut/micronaut-test]INFO 
> [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load aiming 
> FALLBACK for Unloaded Gradle Project: 
> GradleFiles[projectDir=/space/src/micronaut/micronaut-test/test-junit5, 
> rootDir=/space/src/micronaut/micronaut-test]java.lang.Throwable at 
> org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl.loadProject(GradleProjectLoaderImpl.java:50)
>  at 
> org.netbeans.modules.gradle.NbGradleProjectImpl.loadProject(NbGradleProjectImpl.java:259)
>  at 
> org.netbeans.modules.gradle.NbGradleProjectImpl.loadProject(NbGradleProjectImpl.java:254)
>  at 
> org.netbeans.modules.gradle.NbGradleProjectImpl.getGradleProject(NbGradleProjectImpl.java:184)
>  at 
> org.netbeans.modules.gradle.api.NbGradleProject.projectLookup(NbGradleProject.java:182)
>  at 
> org.netbeans.modules.gradle.java.api.GradleJavaProject.get(GradleJavaProject.java:125)
>  at 
> org.netbeans.modules.gradle.java.classpath.ClassPathProviderImpl.findClassPath(ClassPathProviderImpl.java:107)
>  at 
> org.netbeans.modules.csl.core.ProjectClassPathProvider.findClassPath(ProjectClassPathProvider.java:45)
>  at 
> org.netbeans.api.java.classpath.ClassPath.getClassPath(ClassPath.java:667) at 
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer.ensureSourcePath(JavaCustomIndexer.java:1338)
>  at 
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer.access$200(JavaCustomIndexer.java:132)
>  at 
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer$Factory.rootsRemoved(JavaCustomIndexer.java:1201)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.notifyRootsRemoved(RepositoryUpdater.java:5221)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.getDone(RepositoryUpdater.java:5125)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3420)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6183)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$4300(RepositoryUpdater.java:5834)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2$1.run(RepositoryUpdater.java:6099)
>  at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279){code}



--
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] [Created] (NETBEANS-5609) Gradle project (re)loaded after close.

2021-04-21 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5609:
-

 Summary: Gradle project (re)loaded after close.
 Key: NETBEANS-5609
 URL: https://issues.apache.org/jira/browse/NETBEANS-5609
 Project: NetBeans
  Issue Type: Bug
Reporter: Svatopluk Dedic


When Gradle project is closed, its props are immediately reloaded back because 
of calls from RepositoryUpdater. RepositoryUpdater is closing / removing 
indexed roots and needs just URLs; but the now-closed project performs a new 
{{loadProject}}. 
{code:java}


INFO [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load aiming 
FALLBACK for Unloaded Gradle Project: 
GradleFiles[projectDir=/space/src/micronaut/micronaut-test/test-junit5, 
rootDir=/space/src/micronaut/micronaut-test]INFO 
[org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load aiming 
FALLBACK for Unloaded Gradle Project: 
GradleFiles[projectDir=/space/src/micronaut/micronaut-test/test-junit5, 
rootDir=/space/src/micronaut/micronaut-test]java.lang.Throwable at 
org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl.loadProject(GradleProjectLoaderImpl.java:50)
 at 
org.netbeans.modules.gradle.NbGradleProjectImpl.loadProject(NbGradleProjectImpl.java:259)
 at 
org.netbeans.modules.gradle.NbGradleProjectImpl.loadProject(NbGradleProjectImpl.java:254)
 at 
org.netbeans.modules.gradle.NbGradleProjectImpl.getGradleProject(NbGradleProjectImpl.java:184)
 at 
org.netbeans.modules.gradle.api.NbGradleProject.projectLookup(NbGradleProject.java:182)
 at 
org.netbeans.modules.gradle.java.api.GradleJavaProject.get(GradleJavaProject.java:125)
 at 
org.netbeans.modules.gradle.java.classpath.ClassPathProviderImpl.findClassPath(ClassPathProviderImpl.java:107)
 at 
org.netbeans.modules.csl.core.ProjectClassPathProvider.findClassPath(ProjectClassPathProvider.java:45)
 at org.netbeans.api.java.classpath.ClassPath.getClassPath(ClassPath.java:667) 
at 
org.netbeans.modules.java.source.indexing.JavaCustomIndexer.ensureSourcePath(JavaCustomIndexer.java:1338)
 at 
org.netbeans.modules.java.source.indexing.JavaCustomIndexer.access$200(JavaCustomIndexer.java:132)
 at 
org.netbeans.modules.java.source.indexing.JavaCustomIndexer$Factory.rootsRemoved(JavaCustomIndexer.java:1201)
 at 
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.notifyRootsRemoved(RepositoryUpdater.java:5221)
 at 
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.getDone(RepositoryUpdater.java:5125)
 at 
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3420)
 at 
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6183)
 at 
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$4300(RepositoryUpdater.java:5834)
 at 
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2$1.run(RepositoryUpdater.java:6099)
 at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279){code}



--
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] [Resolved] (NETBEANS-5598) IllegalAccessException on running Netbeans Platform Application in JDK 16

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic resolved NETBEANS-5598.
---
Resolution: Duplicate

> IllegalAccessException on running Netbeans Platform Application in JDK 16
> -
>
> Key: NETBEANS-5598
> URL: https://issues.apache.org/jira/browse/NETBEANS-5598
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 12.3, 12.4
>Reporter: Sandeep Mishra
>Priority: Major
>
> Create or Open an existing Netbeans Platform Application.
> Run the application with Java Platform set to JDK 16.
> The following exception occurs:
> {code:java}
> java.lang.IllegalAccessException: class org.netbeans.Module cannot access a 
> member of class java.lang.ClassLoader (in module java.base) with modifiers 
> "protected"
> at 
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:385)
>  at 
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:687)
>  at java.base/java.lang.reflect.Method.invoke(Method.java:559) [catch] at 
> org.netbeans.Module.findResources(Module.java:571) at 
> org.netbeans.core.startup.NbInstaller.loadLayers(NbInstaller.java:605) at 
> org.netbeans.core.startup.NbInstaller.loadImpl(NbInstaller.java:332) at 
> org.netbeans.core.startup.NbInstaller.access$000(NbInstaller.java:77) at 
> org.netbeans.core.startup.NbInstaller$1.run(NbInstaller.java:322) at 
> org.openide.filesystems.FileUtil$2.run(FileUtil.java:413) at 
> org.openide.filesystems.EventControl.runAtomicAction(EventControl.java:102) 
> at org.openide.filesystems.FileSystem.runAtomicAction(FileSystem.java:494) at 
> org.openide.filesystems.FileUtil.runAtomicAction(FileUtil.java:397) at 
> org.openide.filesystems.FileUtil.runAtomicAction(FileUtil.java:417) at 
> org.netbeans.core.startup.NbInstaller.load(NbInstaller.java:319) at 
> org.netbeans.ModuleManager.enable(ModuleManager.java:1453) at 
> org.netbeans.ModuleManager.enable(ModuleManager.java:1254) at 
> org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:315) at 
> org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:251) at 
> org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:298) at 
> org.netbeans.core.startup.Main.getModuleSystem(Main.java:156) at 
> org.netbeans.core.startup.Main.getModuleSystem(Main.java:125) at 
> org.netbeans.core.startup.Main.start(Main.java:282) at 
> org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:98) at 
> java.base/java.lang.Thread.run(Thread.java:831) {code}
> This is happening because access to JDK Internals has been disallowed from 
> JDK 16 onwards.
> https://openjdk.java.net/jeps/396
> It used to show a warning in earlier JDK versions.
> There are few other places where the Netbeans Platform is hacking into JDK 
> internals:
>  
> {code:java}
> WARNING: Illegal reflective access by 
>  org.netbeans.modules.debugger.ui.views.debugging.DebugTreeView 
>  
> (jar:file:/Users/albatem/netbeans-12.3/ide/modules/org-netbeans-spi-debugger-ui.jar!/)
>  
>  to field javax.swing.tree.FixedHeightLayoutCache.info
>   at 
>  
> org.netbeans.modules.debugger.ui.views.debugging.DebugTreeView.clearSelectionCache(DebugTreeView.java:150)
>   at 
>  
> org.netbeans.modules.debugger.ui.views.debugging.DebugTreeView.resetSelection(DebugTreeView.java:140)
>   at 
>  
> org.netbeans.modules.debugger.ui.views.debugging.DebuggingViewComponent.releaseTreeView(DebuggingViewComponent.java:661)
>   at 
>  
> org.netbeans.modules.debugger.ui.views.debugging.DebuggingViewComponent.access$600(DebuggingViewComponent.java:104)
>   at 
>  
> org.netbeans.modules.debugger.ui.views.debugging.DebuggingViewComponent$4.run(DebuggingViewComponent.java:423)
>  
>  WARNING: Illegal reflective access by org.openide.text.QuietEditorPane$1 
>  
> (jar:file:/Users/albatem/netbeans-12.3/platform/modules/org-openide-text.jar!/)
>  
>  to field sun.awt.im.InputContext.inputMethodWindowContext
>   at org.openide.text.QuietEditorPane$1.run(QuietEditorPane.java:268)
>   at 
>  org.openide.text.QuietEditorPane.removeNotify(QuietEditorPane.java:308)
>  
>  
>  WARNING: Illegal reflective access by 
>  org.netbeans.modules.debugger.ui.views.debugging.DebugTreeView 
>  
> (jar:file:/Users/albatem/netbeans-12.3/ide/modules/org-netbeans-spi-debugger-ui.jar!/)
>  
>  to field javax.swing.tree.FixedHeightLayoutCache.info
>   at 
>  
> org.netbeans.modules.debugger.ui.views.debugging.DebugTreeView.clearSelectionCache(DebugTreeView.java:150)
>   at 
>  
> org.netbeans.modules.debugger.ui.views.debugging.DebugTreeView.resetSelection(DebugTreeView.java:140)
>   at 
>  
> 

[jira] [Updated] (NETBEANS-5596) No syntax coloring with the Java Editor Kit

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5596:
--
Priority: Minor  (was: Major)

> No syntax coloring with the Java Editor Kit
> ---
>
> Key: NETBEANS-5596
> URL: https://issues.apache.org/jira/browse/NETBEANS-5596
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Editor
>Affects Versions: 12.3
>Reporter: Nicolas Baumann
>Priority: Minor
>
> I think this is somewhere between a bug and an improvement request because I 
> have no doubt that syntax coloring works well inside the IDE but my issue 
> happens when I use the java editor as a dependency for a plain java 
> application rather than a netbeans platform application.
> I have to activate syntax coloring programatically with the line of code 
> below whereas it should be done automatically based on the mime type of the 
> editor which is text/x-java.
> {code:java}
> doc.putProperty(Language.class, JavaTokenId.language()){code}
> There are some cases where the editor is not accessible due to member 
> visibility, for example with the the DiffView from org-netbeans-modules-diff.
> Here is a mininal code sample to reproduce :
>  
> {code:java}
> final JFrame f = new JFrame("JAVA Syntax Coloring");
> final JEditorPane pane = new JEditorPane();
>  
> pane.setEditorKit(CloneableEditorSupport.getEditorKit(JavaKit.JAVA_MIME_TYPE));
>  //pane.getDocument().putProperty(Language.class, JavaTokenId.language()); // 
> activates syntax coloring
>  try {
>  SwingUtilities.invokeAndWait(() -> {
>  try {
>  pane.getDocument().insertString(0, "public class Hello {}", null);
>  } catch (final BadLocationException e) {
>  e.printStackTrace();
>  }
>  });
>  } catch (final Exception e) {
>  e.printStackTrace();
>  }
>  f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>  f.getContentPane().add(new JScrollPane(pane));
>  f.setSize(400, 300);
>  f.setVisible(true);
> {code}
>  
> From the javadoc :
> [https://bits.netbeans.org/dev/javadoc/org-netbeans-modules-lexer/org/netbeans/api/lexer/TokenHierarchy.html#get-D-]
> _Get or create mutable token hierarchy for the given swing document._
>  _The document may define a top language by doing 
> {{doc.putProperty("mimeType", mimeType)}} (a language defined for the given 
> mime type will be searched and used) or by doing 
> {{putProperty(Language.class, language)}}. Otherwise the returned hierarchy 
> will be inactive and 
> [{{TokenHierarchy.tokenSequence()}}|https://bits.netbeans.org/dev/javadoc/org-netbeans-modules-lexer/org/netbeans/api/lexer/TokenHierarchy.html#tokenSequence--]
>  will return null._
> In my case setting the mimeType property on the document was not enough to 
> activate the token hierarchy for syntax coloring. Only setting the 
> Language.class property resulted in activating it. But it's not possible with 
> an editor that I did not create myself and which I cannot have access to.
>  
> Suggestion :
> In the JavaKit class there is method createDefaultDocument() which creates a 
> default document. Is it possible for you to set the Langage.class property 
> here ?
>  
> Here is a workaround that I use to activate syntax coloring in the diff view.
> In the file org/netbeans/modules/java/editor/resources/layer.xml :
> {code:java}
> 
>  
>  {code}
>  
>  
> {code:java}
> public class SyntaxColoringJavaKit extends 
> org.netbeans.modules.editor.java.JavaKit {
> private static final long serialVersionUID = 1L;
>  @Override
>  public Document createDefaultDocument() {
>final Document document = super.createDefaultDocument();
>document.putProperty(Language.class, JavaTokenId.language());
>return document;
>  }
>  
> }
> {code}
>  
>  Below the maven dependencies that I use in this example :
> {code:java}
> 
>  
> org.netbeans.modules
> org-netbeans-modules-editor-mimelookup-impl 
> RELEASE123
>  
> 
> org.netbeans.modules
> org-netbeans-modules-editor-plain
> RELEASE123 
>  
> 
> org.netbeans.modules
> org-netbeans-modules-java-editor 
> RELEASE123  
>  
> org.frgaal
> compiler
> 14.0.0
> 
> {code}



--
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] [Commented] (NETBEANS-5598) IllegalAccessException on running Netbeans Platform Application in JDK 16

2021-04-20 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17325789#comment-17325789
 ] 

Svatopluk Dedic commented on NETBEANS-5598:
---

The application lacks appropriate *add-opens* etc in its etc/???.conf launcher 
config. See NETBEANS-5594, similar issue. Harness could eventually support some 
generation (?) of module system directive based on used classes  + 
synchronize with NB itself on the minimum required directives for the platform.

 

> IllegalAccessException on running Netbeans Platform Application in JDK 16
> -
>
> Key: NETBEANS-5598
> URL: https://issues.apache.org/jira/browse/NETBEANS-5598
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 12.3, 12.4
>Reporter: Sandeep Mishra
>Priority: Major
>
> Create or Open an existing Netbeans Platform Application.
> Run the application with Java Platform set to JDK 16.
> The following exception occurs:
> {code:java}
> java.lang.IllegalAccessException: class org.netbeans.Module cannot access a 
> member of class java.lang.ClassLoader (in module java.base) with modifiers 
> "protected"
> at 
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:385)
>  at 
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:687)
>  at java.base/java.lang.reflect.Method.invoke(Method.java:559) [catch] at 
> org.netbeans.Module.findResources(Module.java:571) at 
> org.netbeans.core.startup.NbInstaller.loadLayers(NbInstaller.java:605) at 
> org.netbeans.core.startup.NbInstaller.loadImpl(NbInstaller.java:332) at 
> org.netbeans.core.startup.NbInstaller.access$000(NbInstaller.java:77) at 
> org.netbeans.core.startup.NbInstaller$1.run(NbInstaller.java:322) at 
> org.openide.filesystems.FileUtil$2.run(FileUtil.java:413) at 
> org.openide.filesystems.EventControl.runAtomicAction(EventControl.java:102) 
> at org.openide.filesystems.FileSystem.runAtomicAction(FileSystem.java:494) at 
> org.openide.filesystems.FileUtil.runAtomicAction(FileUtil.java:397) at 
> org.openide.filesystems.FileUtil.runAtomicAction(FileUtil.java:417) at 
> org.netbeans.core.startup.NbInstaller.load(NbInstaller.java:319) at 
> org.netbeans.ModuleManager.enable(ModuleManager.java:1453) at 
> org.netbeans.ModuleManager.enable(ModuleManager.java:1254) at 
> org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:315) at 
> org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:251) at 
> org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:298) at 
> org.netbeans.core.startup.Main.getModuleSystem(Main.java:156) at 
> org.netbeans.core.startup.Main.getModuleSystem(Main.java:125) at 
> org.netbeans.core.startup.Main.start(Main.java:282) at 
> org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:98) at 
> java.base/java.lang.Thread.run(Thread.java:831) {code}
> This is happening because access to JDK Internals has been disallowed from 
> JDK 16 onwards.
> https://openjdk.java.net/jeps/396
> It used to show a warning in earlier JDK versions.
> There are few other places where the Netbeans Platform is hacking into JDK 
> internals:
>  
> {code:java}
> WARNING: Illegal reflective access by 
>  org.netbeans.modules.debugger.ui.views.debugging.DebugTreeView 
>  
> (jar:file:/Users/albatem/netbeans-12.3/ide/modules/org-netbeans-spi-debugger-ui.jar!/)
>  
>  to field javax.swing.tree.FixedHeightLayoutCache.info
>   at 
>  
> org.netbeans.modules.debugger.ui.views.debugging.DebugTreeView.clearSelectionCache(DebugTreeView.java:150)
>   at 
>  
> org.netbeans.modules.debugger.ui.views.debugging.DebugTreeView.resetSelection(DebugTreeView.java:140)
>   at 
>  
> org.netbeans.modules.debugger.ui.views.debugging.DebuggingViewComponent.releaseTreeView(DebuggingViewComponent.java:661)
>   at 
>  
> org.netbeans.modules.debugger.ui.views.debugging.DebuggingViewComponent.access$600(DebuggingViewComponent.java:104)
>   at 
>  
> org.netbeans.modules.debugger.ui.views.debugging.DebuggingViewComponent$4.run(DebuggingViewComponent.java:423)
>  
>  WARNING: Illegal reflective access by org.openide.text.QuietEditorPane$1 
>  
> (jar:file:/Users/albatem/netbeans-12.3/platform/modules/org-openide-text.jar!/)
>  
>  to field sun.awt.im.InputContext.inputMethodWindowContext
>   at org.openide.text.QuietEditorPane$1.run(QuietEditorPane.java:268)
>   at 
>  org.openide.text.QuietEditorPane.removeNotify(QuietEditorPane.java:308)
>  
>  
>  WARNING: Illegal reflective access by 
>  org.netbeans.modules.debugger.ui.views.debugging.DebugTreeView 
>  
> (jar:file:/Users/albatem/netbeans-12.3/ide/modules/org-netbeans-spi-debugger-ui.jar!/)
>  
>  to field javax.swing.tree.FixedHeightLayoutCache.info
>   at 
>  
> 

[jira] [Resolved] (NETBEANS-5602) Project opening failed

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic resolved NETBEANS-5602.
---
Fix Version/s: 12.4
   Resolution: Fixed

> Project opening failed
> --
>
> Key: NETBEANS-5602
> URL: https://issues.apache.org/jira/browse/NETBEANS-5602
> Project: NetBeans
>  Issue Type: Bug
>  Components: javaee - Web Project, serverplugins - Tomcat
>Affects Versions: 12.0
>Reporter: SHARON XAVIER
>Priority: Major
> Fix For: 12.4
>
>
> 12.java.lang.IllegalAccessError: superclass access check failed: class 
> org.netbeans.lib.nbjavac.services.CancelAbort (in unnamed module @0x7b049b4) 
> cannot access class com.sun.tools.javac.util.Abort (in module jdk.compiler) 
> because module jdk.compiler does not export com.sun.tools.javac.util to 
> unnamed module @0x7b049b4 at 
> java.base/java.lang.ClassLoader.defineClass1(Native Method) at 
> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1010) at 
> org.netbeans.JarClassLoader.doLoadClass(JarClassLoader.java:287) at 
> org.netbeans.ProxyClassLoader.selfLoadClass(ProxyClassLoader.java:246) at 
> org.netbeans.ProxyClassLoader.doFindClass(ProxyClassLoader.java:174) at 
> org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:125) at 
> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519) at 
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer$DefaultCompileWorkerProvider.getWorkers(JavaCustomIndexer.java:1542)
>  at 
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer.index(JavaCustomIndexer.java:359)
>  at 
> org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$2.run(Indexable.java:138)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runIndexer(RepositoryUpdater.java:275)
>  at 
> org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor.index(Indexable.java:136)
>  [catch] at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doIndex(RepositoryUpdater.java:2750)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.access$800(RepositoryUpdater.java:2154)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2636)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2634)
>  at 
> org.netbeans.modules.parsing.impl.indexing.errors.TaskCache.refreshTransaction(TaskCache.java:540)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.index(RepositoryUpdater.java:2634)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$AbstractRootsWork$4.call(RepositoryUpdater.java:5714)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$AbstractRootsWork$4.call(RepositoryUpdater.java:5622)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$4.run(RepositoryUpdater.java:2127)
>  at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279) at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runInContext(RepositoryUpdater.java:2123)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runInContext(RepositoryUpdater.java:2104)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.access$1500(RepositoryUpdater.java:136)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$AbstractRootsWork.scanSource(RepositoryUpdater.java:5749)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$AbstractRootsWork.scanSources(RepositoryUpdater.java:5419)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.getDone(RepositoryUpdater.java:5038)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$InitialRootsWork.getDone(RepositoryUpdater.java:5821)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3420)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6183)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$4300(RepositoryUpdater.java:5834)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2$1.run(RepositoryUpdater.java:6099)
>  at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279) at 
> org.netbeans.modules.parsing.impl.RunWhenScanFinishedSupport.performScan(RunWhenScanFinishedSupport.java:83)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:6095)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:6091)
>  at 
> org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
>  at 
> 

[jira] [Commented] (NETBEANS-5602) Project opening failed

2021-04-20 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17325787#comment-17325787
 ] 

Svatopluk Dedic commented on NETBEANS-5602:
---

This should be already fixed in NB 12.4 – *add-opens* instructions added to the 
launcher config.

> Project opening failed
> --
>
> Key: NETBEANS-5602
> URL: https://issues.apache.org/jira/browse/NETBEANS-5602
> Project: NetBeans
>  Issue Type: Bug
>  Components: javaee - Web Project, serverplugins - Tomcat
>Affects Versions: 12.0
>Reporter: SHARON XAVIER
>Priority: Major
>
> java.lang.IllegalAccessError: superclass access check failed: class 
> org.netbeans.lib.nbjavac.services.CancelAbort (in unnamed module @0x7b049b4) 
> cannot access class com.sun.tools.javac.util.Abort (in module jdk.compiler) 
> because module jdk.compiler does not export com.sun.tools.javac.util to 
> unnamed module @0x7b049b4 at 
> java.base/java.lang.ClassLoader.defineClass1(Native Method) at 
> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1010) at 
> org.netbeans.JarClassLoader.doLoadClass(JarClassLoader.java:287) at 
> org.netbeans.ProxyClassLoader.selfLoadClass(ProxyClassLoader.java:246) at 
> org.netbeans.ProxyClassLoader.doFindClass(ProxyClassLoader.java:174) at 
> org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:125) at 
> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519) at 
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer$DefaultCompileWorkerProvider.getWorkers(JavaCustomIndexer.java:1542)
>  at 
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer.index(JavaCustomIndexer.java:359)
>  at 
> org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$2.run(Indexable.java:138)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runIndexer(RepositoryUpdater.java:275)
>  at 
> org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor.index(Indexable.java:136)
>  [catch] at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doIndex(RepositoryUpdater.java:2750)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.access$800(RepositoryUpdater.java:2154)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2636)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2634)
>  at 
> org.netbeans.modules.parsing.impl.indexing.errors.TaskCache.refreshTransaction(TaskCache.java:540)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.index(RepositoryUpdater.java:2634)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$AbstractRootsWork$4.call(RepositoryUpdater.java:5714)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$AbstractRootsWork$4.call(RepositoryUpdater.java:5622)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$4.run(RepositoryUpdater.java:2127)
>  at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279) at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runInContext(RepositoryUpdater.java:2123)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runInContext(RepositoryUpdater.java:2104)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.access$1500(RepositoryUpdater.java:136)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$AbstractRootsWork.scanSource(RepositoryUpdater.java:5749)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$AbstractRootsWork.scanSources(RepositoryUpdater.java:5419)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.getDone(RepositoryUpdater.java:5038)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$InitialRootsWork.getDone(RepositoryUpdater.java:5821)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3420)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6183)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$4300(RepositoryUpdater.java:5834)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2$1.run(RepositoryUpdater.java:6099)
>  at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279) at 
> org.netbeans.modules.parsing.impl.RunWhenScanFinishedSupport.performScan(RunWhenScanFinishedSupport.java:83)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:6095)
>  at 
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:6091)
>  at 
> 

[jira] [Updated] (NETBEANS-5594) NBP12.3 application on JDK16/mac OS: Cannot load even default layout

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5594:
--
Component/s: apisupport - Harness

> NBP12.3 application on JDK16/mac OS: Cannot load even default layout
> 
>
> Key: NETBEANS-5594
> URL: https://issues.apache.org/jira/browse/NETBEANS-5594
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Harness
>Affects Versions: 12.3
>Reporter: Sebastian Jaenicke
>Priority: Critical
> Attachments: jdk8-messages.log, messages.log2
>
>
> NBP application using 12.3, JDK 16, runs fine on Linux.
> On mac OS (Big Sur), I first got lots of relection-related exceptions from 
> NbInstaller, e.g.:
> java.lang.reflect.InaccessibleObjectException: Unable to make protected 
> java.util.Enumeration java.lang.ClassLoader.findResources(java.lang.String) 
> throws java.io.IOException accessible: module java.base does not "opens 
> java.lang" to unnamed module @4ccc0db7
>  at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
>  at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
>  at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
>  at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> [catch] at org.netbeans.Module.findResources(Module.java:567)
>  at org.netbeans.core.startup.NbInstaller.loadLayers(NbInstaller.java:605)
>  at org.netbeans.core.startup.NbInstaller.loadImpl(NbInstaller.java:332)
>  at org.netbeans.core.startup.NbInstaller.access$000(NbInstaller.java:77)
>  at org.netbeans.core.startup.NbInstaller$1.run(NbInstaller.java:322)
>  at org.openide.filesystems.FileUtil$2.run(FileUtil.java:413)
>  
> so I added '-J--illegal-access=permit' to default_options in etc/mgx_gui.conf.
> Now, after completely removing the user_dir, I get
>  * a popup warning: 'Cannot load even default layout, using internally 
> predefined configuration.'
>  * a NullPointerException related to FileObject.isValid()
> UI window itself is opened, but remains empty. I'm attaching the full 
> messages.log file,
> any ideas would be greatly appreciated.
>  



--
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] [Commented] (NETBEANS-5594) NBP12.3 application on JDK16/mac OS: Cannot load even default layout

2021-04-20 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17325752#comment-17325752
 ] 

Svatopluk Dedic commented on NETBEANS-5594:
---

You must change your {{etc/.conf}} to add relevant 
*add-opens* for JDK11+. Refer to *etc/netbeans.conf* in NetBeans 12.4 
installation.

> NBP12.3 application on JDK16/mac OS: Cannot load even default layout
> 
>
> Key: NETBEANS-5594
> URL: https://issues.apache.org/jira/browse/NETBEANS-5594
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 12.3
>Reporter: Sebastian Jaenicke
>Priority: Critical
> Attachments: jdk8-messages.log, messages.log2
>
>
> NBP application using 12.3, JDK 16, runs fine on Linux.
> On mac OS (Big Sur), I first got lots of relection-related exceptions from 
> NbInstaller, e.g.:
> java.lang.reflect.InaccessibleObjectException: Unable to make protected 
> java.util.Enumeration java.lang.ClassLoader.findResources(java.lang.String) 
> throws java.io.IOException accessible: module java.base does not "opens 
> java.lang" to unnamed module @4ccc0db7
>  at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
>  at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
>  at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
>  at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> [catch] at org.netbeans.Module.findResources(Module.java:567)
>  at org.netbeans.core.startup.NbInstaller.loadLayers(NbInstaller.java:605)
>  at org.netbeans.core.startup.NbInstaller.loadImpl(NbInstaller.java:332)
>  at org.netbeans.core.startup.NbInstaller.access$000(NbInstaller.java:77)
>  at org.netbeans.core.startup.NbInstaller$1.run(NbInstaller.java:322)
>  at org.openide.filesystems.FileUtil$2.run(FileUtil.java:413)
>  
> so I added '-J--illegal-access=permit' to default_options in etc/mgx_gui.conf.
> Now, after completely removing the user_dir, I get
>  * a popup warning: 'Cannot load even default layout, using internally 
> predefined configuration.'
>  * a NullPointerException related to FileObject.isValid()
> UI window itself is opened, but remains empty. I'm attaching the full 
> messages.log file,
> any ideas would be greatly appreciated.
>  



--
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-5579) Exception Error from Netbeans

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5579:
--
Environment: 
Operating System   = Windows 7 version 6.1 running on amd64  
Java; VM; Vendor        = 1.8.0_221; Java HotSpot(TM) 64-Bit Server VM 
25.221-b11; Oracle Corporation  
Runtime                 = Java(TM) SE Runtime Environment 1.8.0_221-b11  Java 
Home 

> Exception Error from Netbeans
> -
>
> Key: NETBEANS-5579
> URL: https://issues.apache.org/jira/browse/NETBEANS-5579
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 11.1
> Environment: Operating System   = Windows 7 version 6.1 running on 
> amd64  
> Java; VM; Vendor        = 1.8.0_221; Java HotSpot(TM) 64-Bit Server VM 
> 25.221-b11; Oracle Corporation  
> Runtime                 = Java(TM) SE Runtime Environment 1.8.0_221-b11  Java 
> Home 
>Reporter: Suchitkumar B. Shah
>Priority: Major
>
> -->Log
>  Session: Wednesday, April 14, 2021 11:20:27 AM IST>System Info:   Product 
> Version         = Apache NetBeans IDE 11.1  Operating System        = Windows 
> 7 version 6.1 running on amd64  Java; VM; Vendor        = 1.8.0_221; Java 
> HotSpot(TM) 64-Bit Server VM 25.221-b11; Oracle Corporation  Runtime          
>        = Java(TM) SE Runtime Environment 1.8.0_221-b11  Java Home             
>   = C:\Program Files\Java\jdk1.8.0_221\jre  System Locale; Encoding = en_IN 
> (nb); Cp1252  Home Directory          = C:\Users\dell  Current Directory      
>  = D:\Program Files\NetBeans-11.1  User Directory          = 
> C:\Users\dell\AppData\Roaming\NetBeans\11.1  Cache Directory         = 
> C:\Users\dell\AppData\Local\NetBeans\Cache\11.1  Installation            = 
> D:\Program Files\NetBeans-11.1\netbeans\nb                            
> D:\Program Files\NetBeans-11.1\netbeans\ergonomics                            
> D:\Program Files\NetBeans-11.1\netbeans\ide                            
> D:\Program Files\NetBeans-11.1\netbeans\extide                            
> D:\Program Files\NetBeans-11.1\netbeans\java                            
> D:\Program Files\NetBeans-11.1\netbeans\apisupport                            
> D:\Program Files\NetBeans-11.1\netbeans\webcommon                            
> D:\Program Files\NetBeans-11.1\netbeans\websvccommon                          
>   D:\Program Files\NetBeans-11.1\netbeans\enterprise                          
>   D:\Program Files\NetBeans-11.1\netbeans\profiler                            
> D:\Program Files\NetBeans-11.1\netbeans\php                            
> D:\Program Files\NetBeans-11.1\netbeans\harness                            
> D:\Program Files\NetBeans-11.1\netbeans\groovy                            
> D:\Program Files\NetBeans-11.1\netbeans\javafx                            
> D:\Program Files\NetBeans-11.1\netbeans\platform  Boot & Ext. Classpath   = 
> C:\Program Files\Java\jdk1.8.0_221\jre\lib\resources.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\rt.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\sunrsasign.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\jsse.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\jce.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\charsets.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\jfr.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\classes;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\access-bridge-64.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\cldrdata.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\dnsns.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\jaccess.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\jfxrt.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\localedata.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\nashorn.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\sunec.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\sunjce_provider.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\sunmscapi.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\sunpkcs11.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\zipfs.jar  Application Classpath   = 
> D:\Program Files\NetBeans-11.1\netbeans\platform\lib\boot.jar;D:\Program 
> Files\NetBeans-11.1\netbeans\platform\lib\org-openide-modules.jar;D:\Program 
> Files\NetBeans-11.1\netbeans\platform\lib\org-openide-util-lookup.jar;D:\Program
>  Files\NetBeans-11.1\netbeans\platform\lib\org-openide-util-ui.jar;D:\Program 
> Files\NetBeans-11.1\netbeans\platform\lib\org-openide-util.jar;C:\Program 
> Files\Java\jdk1.8.0_221\lib\dt.jar;C:\Program 
> Files\Java\jdk1.8.0_221\lib\tools.jar  Startup Classpath       = D:\Program 
> 

[jira] [Updated] (NETBEANS-5579) Exception Error from Netbeans

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5579:
--
Affects Version/s: 11.1

> Exception Error from Netbeans
> -
>
> Key: NETBEANS-5579
> URL: https://issues.apache.org/jira/browse/NETBEANS-5579
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 11.1
>Reporter: Suchitkumar B. Shah
>Priority: Major
>
> -->Log
>  Session: Wednesday, April 14, 2021 11:20:27 AM IST>System Info:   Product 
> Version         = Apache NetBeans IDE 11.1  Operating System        = Windows 
> 7 version 6.1 running on amd64  Java; VM; Vendor        = 1.8.0_221; Java 
> HotSpot(TM) 64-Bit Server VM 25.221-b11; Oracle Corporation  Runtime          
>        = Java(TM) SE Runtime Environment 1.8.0_221-b11  Java Home             
>   = C:\Program Files\Java\jdk1.8.0_221\jre  System Locale; Encoding = en_IN 
> (nb); Cp1252  Home Directory          = C:\Users\dell  Current Directory      
>  = D:\Program Files\NetBeans-11.1  User Directory          = 
> C:\Users\dell\AppData\Roaming\NetBeans\11.1  Cache Directory         = 
> C:\Users\dell\AppData\Local\NetBeans\Cache\11.1  Installation            = 
> D:\Program Files\NetBeans-11.1\netbeans\nb                            
> D:\Program Files\NetBeans-11.1\netbeans\ergonomics                            
> D:\Program Files\NetBeans-11.1\netbeans\ide                            
> D:\Program Files\NetBeans-11.1\netbeans\extide                            
> D:\Program Files\NetBeans-11.1\netbeans\java                            
> D:\Program Files\NetBeans-11.1\netbeans\apisupport                            
> D:\Program Files\NetBeans-11.1\netbeans\webcommon                            
> D:\Program Files\NetBeans-11.1\netbeans\websvccommon                          
>   D:\Program Files\NetBeans-11.1\netbeans\enterprise                          
>   D:\Program Files\NetBeans-11.1\netbeans\profiler                            
> D:\Program Files\NetBeans-11.1\netbeans\php                            
> D:\Program Files\NetBeans-11.1\netbeans\harness                            
> D:\Program Files\NetBeans-11.1\netbeans\groovy                            
> D:\Program Files\NetBeans-11.1\netbeans\javafx                            
> D:\Program Files\NetBeans-11.1\netbeans\platform  Boot & Ext. Classpath   = 
> C:\Program Files\Java\jdk1.8.0_221\jre\lib\resources.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\rt.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\sunrsasign.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\jsse.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\jce.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\charsets.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\jfr.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\classes;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\access-bridge-64.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\cldrdata.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\dnsns.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\jaccess.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\jfxrt.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\localedata.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\nashorn.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\sunec.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\sunjce_provider.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\sunmscapi.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\sunpkcs11.jar;C:\Program 
> Files\Java\jdk1.8.0_221\jre\lib\ext\zipfs.jar  Application Classpath   = 
> D:\Program Files\NetBeans-11.1\netbeans\platform\lib\boot.jar;D:\Program 
> Files\NetBeans-11.1\netbeans\platform\lib\org-openide-modules.jar;D:\Program 
> Files\NetBeans-11.1\netbeans\platform\lib\org-openide-util-lookup.jar;D:\Program
>  Files\NetBeans-11.1\netbeans\platform\lib\org-openide-util-ui.jar;D:\Program 
> Files\NetBeans-11.1\netbeans\platform\lib\org-openide-util.jar;C:\Program 
> Files\Java\jdk1.8.0_221\lib\dt.jar;C:\Program 
> Files\Java\jdk1.8.0_221\lib\tools.jar  Startup Classpath       = D:\Program 
> Files\NetBeans-11.1\netbeans\platform\core\asm-all-5.0.1.jar;D:\Program 
> Files\NetBeans-11.1\netbeans\platform\core\core-base.jar;D:\Program 
> Files\NetBeans-11.1\netbeans\platform\core\core.jar;D:\Program 
> Files\NetBeans-11.1\netbeans\platform\core\org-netbeans-libs-asm.jar;D:\Program
>  
> Files\NetBeans-11.1\netbeans\platform\core\org-openide-filesystems-compat8.jar;D:\Program
>  
> Files\NetBeans-11.1\netbeans\platform\core\org-openide-filesystems.jar;D:\Program
>  

[jira] [Commented] (NETBEANS-5576) getCompilationUnit() error during startup

2021-04-20 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17325737#comment-17325737
 ] 

Svatopluk Dedic commented on NETBEANS-5576:
---

Missing info:
 * No reproduction steps given.
 * there's no UI log or messages.log attached that could serve to reconstruct 
the actions leading to the error (in absence of reproduction steps)

The stacktrace in the message.log is critical to identify the buggy code that 
works improperly with the parser result.

 

> getCompilationUnit() error during startup
> -
>
> Key: NETBEANS-5576
> URL: https://issues.apache.org/jira/browse/NETBEANS-5576
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Welcome
>Affects Versions: 12.0
>Reporter: Cation
>Priority: Major
>
> 
>  2021-04-13T19:24:35
>  1618334675354
>  1629
>  700
>  28
>  UI_USER_CONFIGURATION
>  UI_USER_CONFIGURATION
>  org.netbeans.modules.uihandler.Bundle
>  Windows 10, 10.0, amd64
>  Java HotSpot(TM) 64-Bit Server VM, 15+36-1562, Java(TM) SE Runtime 
> Environment, 15+36-1562
>  Apache NetBeans IDE 12.0
>  
>  IllegalStateException: Cannot call getCompilationUnit() if current 
> phase  JavaSource.Phase.PARSED. You must call toPhase(Phase.PARSED) 
> first.
>  Please provide a description of the problem or the steps to 
> reproduce
>  *
> 



--
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-5573) Split CSL into CSL-headless and CSL-UI

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5573:
--
Labels: VSNetBeans  (was: )

> Split CSL into CSL-headless and CSL-UI
> --
>
> Key: NETBEANS-5573
> URL: https://issues.apache.org/jira/browse/NETBEANS-5573
> Project: NetBeans
>  Issue Type: Bug
>Reporter: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans
>
> Just encountered a dependency:
> CSL > Diff (visual components)
> which may be harmful for headless applications. Since this is an autonomous 
> UI action, it could be separated to Eager module that would depend on 
> CSL+diff to enable.



--
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-5571) Consider Mutex.EVENT implementation for LSP

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5571:
--
Labels: VSNetBeans  (was: )

> Consider Mutex.EVENT implementation for LSP
> ---
>
> Key: NETBEANS-5571
> URL: https://issues.apache.org/jira/browse/NETBEANS-5571
> Project: NetBeans
>  Issue Type: Improvement
>  Components: lsp
>Affects Versions: 12.4
>Reporter: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans
> Fix For: Next
>
>
> In a sense, the thread which receives / sends LSP events is the "UI dispatch 
> thread" - similar to Swing EDT, it cannot be blocked (for long) and 
> definitely it cannot be blocked waiting for "user input", since there would 
> be noone who would deliver the user input.
> NetBeans already have safeguards against this, but they use either 
> *SwingUtilities* (which should be changed to Mutex.EVENT), or the 
> *Mutex.EVENT* - but that one lacks a special impl for LSP server environment.
> In addition, it might be desirable to extend the API with something similar 
> to *EventQueue.createSecondaryLoop*, that would allow any thread to wait for 
> the 'nested' interaction to finish. Unlike createSecondaryLoop, the API 
> should use *CompletionStage* so that if the LSP communication thread is the 
> one that shoudl wait, it would terminate the current action, and complete the 
> Stage after it receives an appropriate event.



--
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] [Created] (NETBEANS-5606) Unify RequestProcessor, ScheduledFuture and CompletableFuture

2021-04-20 Thread Svatopluk Dedic (Jira)
Svatopluk Dedic created NETBEANS-5606:
-

 Summary: Unify RequestProcessor, ScheduledFuture and 
CompletableFuture
 Key: NETBEANS-5606
 URL: https://issues.apache.org/jira/browse/NETBEANS-5606
 Project: NetBeans
  Issue Type: New Feature
  Components: platform - Other
Reporter: Svatopluk Dedic


Our RequestProcessor is a *ScheduledExecutionService* and returns Task which 
*could* implement *CompletableFuture* or *CompletionStage* interfaces. That 
would allow to eliminate *TaskListeners* and chain calls using full power of 
*CompletableFuture* JDK API.

With TaskListeners, the caller must perform exception handling 
(CompletableFuture can execute one following exec path on success, another on 
failure), can't get a result (must be passed in arrays or member vars). 

Code in many areas could be quite streamlined with this enhancement.



--
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] [Commented] (NETBEANS-2847) PHP feature is not activated after Oracle JS Parser Implementation is installed

2021-04-20 Thread Svatopluk Dedic (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17325728#comment-17325728
 ] 

Svatopluk Dedic commented on NETBEANS-2847:
---

Still relevant ?

> PHP feature is not activated after Oracle JS Parser Implementation is 
> installed
> ---
>
> Key: NETBEANS-2847
> URL: https://issues.apache.org/jira/browse/NETBEANS-2847
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - UI
>Affects Versions: 11.1
> Environment: NAME="Ubuntu"
> VERSION="18.04.2 LTS (Bionic Beaver)"
> ID=ubuntu
> ID_LIKE=debian
> PRETTY_NAME="Ubuntu 18.04.2 LTS"
> VERSION_ID="18.04"
> HOME_URL="https://www.ubuntu.com/;
> SUPPORT_URL="https://help.ubuntu.com/;
> BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
> PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
> VERSION_CODENAME=bionic
> UBUNTU_CODENAME=bionic
>Reporter: Jack J. Woehr
>Assignee: Svatopluk Dedic
>Priority: Major
> Attachments: NETBEANS-2847.zip, log.txt, 
> netbeans-2847-screenshot-1.png
>
>
> While re-opening a project that had been imported from previous version and 
> was marked "Broken". It re-opened and was no longer marked "broken", but then 
> this exception occurred.



--
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-1116) single ActionReference with id cannot be used on element

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-1116:
--
Labels: sd-candidate  (was: )

> single ActionReference with id cannot be used on element
> 
>
> Key: NETBEANS-1116
> URL: https://issues.apache.org/jira/browse/NETBEANS-1116
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Actions
>Affects Versions: 8.2, 9.0
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: sd-candidate
>
> I tried to link in a standard action, using
> {code:java}
> @ActionReference(
>  path = EditorTopComponent.TOOLBAR_ACTIONS,
>  id = @ActionID(category = "Edit", id = "org-openide-actions-UndoAction"),
>  position = 8000, separatorBefore = 7900
> )
> public final class EditorTopComponent extends TopComponent implements 
> PropertyChangeListener, ChangeListener {
> {code}
> But that failed, because ActionProcessor does not allow to specify 
> @ActionReference without a peer @ActionID. However when wrapped by
> {code:java}
> @ActionReferences({}){code}
> the registration became compilable. IMHO it's a bug in ActionProcessor.



--
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-1590) File version of Windows NB launchers should be updated

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-1590:
--
Labels: sd-candidate  (was: )

> File version of Windows NB launchers should be updated
> --
>
> Key: NETBEANS-1590
> URL: https://issues.apache.org/jira/browse/NETBEANS-1590
> Project: NetBeans
>  Issue Type: Improvement
>  Components: platform - LaunchersCLI
>Affects Versions: 10.0
>Reporter: Eirik Bakke
>Assignee: Svatopluk Dedic
>Priority: Minor
>  Labels: sd-candidate
> Fix For: Next
>
>
> For NetBeans 10vc2, Roy Henderson reports on the us...@netbeans.apache.org 
> mailing list: "[i]f you hover the mouse over the netbeans or netbeans64 files 
> in vc2/bin using Windows explorer then the file versions display as 9.0.0."
> This is easy to fix, but requires a launcher rebuild. Simply change 
> version="9.0.0.0" to version="10.0" in the "assemblyIdentity" element of the 
> following files:
> {noformat}
> harness/apisupport.harness/windows-launcher-src/app.exe.manifest
> nb/ide.launcher/windows/netbeans.exe.manifest
> nb/ide.launcher/windows/netbeans64.exe.manifest
> platform/o.n.bootstrap/launcher/windows/nbexec.exe.manifest
> {noformat}
> If there's a documented process for producing new NetBeans releases 
> somewhere, this should be added as a TODO that needs to be done for every new 
> 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



[jira] [Updated] (NETBEANS-5215) Progress API use-cases aren't valid

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5215:
--
Labels: sd-candidate  (was: )

> Progress API use-cases aren't valid
> ---
>
> Key: NETBEANS-5215
> URL: https://issues.apache.org/jira/browse/NETBEANS-5215
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Progress
>Affects Versions: 11.1
>Reporter: Jaroslav Tulach
>Assignee: Svatopluk Dedic
>Priority: Minor
>  Labels: sd-candidate
>
> Looking at
> [https://bits.netbeans.org/11.1/javadoc/org-netbeans-api-progress/overview-summary.html]
> I see that the documentation hasn't been properly updated to reflect the 
> split of Progress API and Progress Swing API. For example:
> {code:java}
> ProgressHandle handle = ProgressHandleFactory.creatHandle("My custom task"); 
> {code}
> there is a typo (consider using @codesnippet tag, at least in documentation 
> inside of classes). Moreover the {{ProgressHandleFactory}} isn't even in the 
> Progress API!
> Various other apichanges entries like showProgressDialogAndRun are 
> also out of scope and belong to Progress Swing API.



--
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-5389) Maven parent POM VM parameters ignored

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5389:
--
Labels: VSNetBeans  (was: )

> Maven parent POM VM parameters ignored
> --
>
> Key: NETBEANS-5389
> URL: https://issues.apache.org/jira/browse/NETBEANS-5389
> Project: NetBeans
>  Issue Type: Improvement
>  Components: projects - Maven
>Affects Versions: 12.2
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans
>
> During development of a Micronaut-based project, I have realized that launch 
> of the application gets *different parameters* when run from the IDE, and 
> from the commandline.
> In absence of an action mapping, the IDE attempts to parse out VM parametrs 
> and application parameters from the pom.xml, but does not use *effective POM* 
> model. 
> Micronaut incidentally generates their project's boilerplate so that it 
> references 
> {code:java}
>   
> io.micronaut
> micronaut-parent
> 2.3.3
>   
> {code}
>  
> as the parent POM. The micronaut parent, in turn, defines
>  
> {code:java}
> 
>   org.codehaus.mojo
>   exec-maven-plugin
>   ${exec-maven-plugin.version}
>   
> java
> 
>   -classpath
>   
>   -XX:TieredStopAtLevel=1
>   -Dcom.sun.management.jmxremote
>   ${exec.mainClass}
> 
>   
> 
> {code}
> But IDE will not pick the VM arguments from here to the Run action, the 
> Project Customizer, (and subsquently to the created action mappings).
>  
>  
>  



--
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-5318) Gradle priming build in VSCode is asking again and again.

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5318:
--
Labels: VSNetBeans pull-request-available  (was: pull-request-available)

> Gradle priming build in VSCode is asking again and again.
> -
>
> Key: NETBEANS-5318
> URL: https://issues.apache.org/jira/browse/NETBEANS-5318
> Project: NetBeans
>  Issue Type: Bug
>  Components: vscode
>Affects Versions: 12.3
> Environment: Ubuntu 20.04, GraalVM 21.0 Jdk 8.
>Reporter: Martin Balin
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans, pull-request-available
> Fix For: 12.4
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Running VSNetBeans 12.3.286 with GraalVM Micronaut ext. Create Gradle MN 
> project.
> VSNB asks for Gradle priming build many times, message:
> "NetBeans is about to invoke a Gradle build process of the project: demog.
>  Executing Gradle can be potentially un-safe as it allows arbitrary code 
> execution."
> I always answered OK, but it was appearing again and again.
> After that i invoked "Java: Compile workspace" and it built and also problem 
> with underlined "package" statement went away, this is great.
> Should to be fixed for 12.3 final.
>  



--
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-5587) Gradle project does not show -SNAPSHOT in Configurations

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5587:
--
Labels: VSNetBeans pull-request-available  (was: pull-request-available)

> Gradle project does not show -SNAPSHOT in Configurations
> 
>
> Key: NETBEANS-5587
> URL: https://issues.apache.org/jira/browse/NETBEANS-5587
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Affects Versions: 12.3
> Environment: Ubuntu Linux 19.04; Oracle JDK 8.
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans, pull-request-available
> Fix For: 12.4
>
> Attachments: nb-compile-classpath.jpg
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> I am working (for example) with project 
> 
> [g...@github.com:micronaut-projects/micronaut-starter.git|mailto:g...@github.com:micronaut-projects/micronaut-starter.git]
>  
>  
> I open the root one, and the 'starter-core' project. The explorer shows 
> something like this (see nb-compile-classpath.jpg). But the compileClasspath 
> from gradle dependencies seems a little richer: 
>  
> {code:java}
> +--- io.micronaut:micronaut-http -> 2.3.4-SNAPSHOT 
> +--- io.micronaut:micronaut-http-client -> 2.3.4-SNAPSHOT 
> |    |    +--- io.micronaut:micronaut-http:2.3.4-SNAPSHOT (*) 
> |    +--- io.micronaut:micronaut-http-client-core:2.3.4-SNAPSHOT 
> |    | +--- io.micronaut:micronaut-http:2.3.4-SNAPSHOT (*) 
> |    +--- io.micronaut:micronaut-http-netty:2.3.4-SNAPSHOT 
> |    |    +--- io.micronaut:micronaut-http:2.3.4-SNAPSHOT (*) 
> |    +--- io.micronaut:micronaut-http:2.3.4-SNAPSHOT (c) 
> |    +--- io.micronaut:micronaut-http-client:2.3.4-SNAPSHOT (c) 
> |    +--- io.micronaut:micronaut-http-client-core:2.3.4-SNAPSHOT (c) 
> |    +--- io.micronaut:micronaut-http-netty:2.3.4-SNAPSHOT (c) {code}
> None of the 'snapshot' dependencies are displayed in the explorer tree (but 
> they are repored in COMPILE ClassPath as roots).I tried to use 
> ModuleDependency from GradleConfiguration to map back JARs to 
> group:artifact:version coordinates, but in this case, the relevant 
> ModuleDependency lists no artifacts.
>  



--
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-5500) URLStreamFactory registration violates JDK9+ reflection restrictions

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5500:
--
Labels: VSNetBeans  (was: )

> URLStreamFactory registration violates JDK9+ reflection restrictions
> 
>
> Key: NETBEANS-5500
> URL: https://issues.apache.org/jira/browse/NETBEANS-5500
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Module System
>Affects Versions: 9.0
>Reporter: Jaroslav Tulach
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans
> Fix For: Next
>
>
> If you run NetBeans on JDK9+ you'll see:
> {code:java}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> org.netbeans.ProxyURLStreamHandlerFactory 
> (file:/netbeans/nbbuild/netbeans/platform/lib/boot.jar) to field 
> java.net.URL.handler
> WARNING: Please consider reporting this to the maintainers of 
> org.netbeans.ProxyURLStreamHandlerFactory
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release 
> {code}
> There is a new API that one can use to register (most of) the factories on 
> JDK9+: 
> [https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/spi/URLStreamHandlerProvider.html]
>  
> We should use it as once the JDK is going to ban the illegal access 
> operations and then it is better to be ready.



--
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-5167) Progress Controller skips lifecycle events for a ProgressHandle

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5167:
--
Labels: VSNetBeans  (was: sd-candidate)

> Progress Controller skips lifecycle events for a ProgressHandle
> ---
>
> Key: NETBEANS-5167
> URL: https://issues.apache.org/jira/browse/NETBEANS-5167
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - Progress
>Affects Versions: 12.2
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans
> Attachments: progress-patch.diff, progress1.log
>
>
> When progress is started, an event of type *PROGRESS_START* is generated. But 
> it may get merged with e.g. SILENT or SWITCH events, as the attached log 
> shows.
> The net result is that the *ProgressUIWorker* does not see the proper 
> lifecycle (start  processing ... finish) but just a part of the cycle.
> The fix is beyond my immediate capacity: while two 'progress' events can be 
> eventually merged, events that bring determinate / indeterminate switch or 
> silent / working state changes should not discard the other 'major' states.
> Skipping the important lifecycle points makes the implementation of UIWorker 
> much harder.



--
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-5226) Add true severities to StatusDisplayer.

2021-04-20 Thread Svatopluk Dedic (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svatopluk Dedic updated NETBEANS-5226:
--
Labels: VSNetBeans  (was: sd-candidate)

> Add true severities to StatusDisplayer.
> ---
>
> Key: NETBEANS-5226
> URL: https://issues.apache.org/jira/browse/NETBEANS-5226
> Project: NetBeans
>  Issue Type: New Feature
>  Components: platform - Notifications
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
>  Labels: VSNetBeans
>
> StatusDisplayer now uses "importance" which is only lightly compared to 
> sverity: the most important messages are *IMPORTANCE_ANNOTATION*, which are 
> essentially file-related texts.
> While it is OK to override error messages by temporaries, like file open 
> warnings or find / replace messages, a *newly reported error* should be 
> placed atop. In the current implementation, if the status message is not 
> GCed, a true error reported afterwards happily sits in the queue, and may 
> never be seen by the user.
> No idea at the moment how to solve, but the status message could be decorated 
> by a severity that helps to determine how to override/expire the visible 
> messages.
> // cc: [~jtulach]



--
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



  1   2   3   4   >