Re: Refactor renaming hardly works anymore

2020-02-24 Thread Laszlo Kishalmi 

That's fixed in 11.3

On 2/24/20 4:45 PM, Ty Young wrote:




If anyone's interested, here's another bug:


https://pastebin.com/g0eLXnFy


On 2/18/20 3:34 PM, Jan Lahoda wrote:

Thanks! I can reproduce, will take a look on how to fix this!

Jan

On Tue, Feb 18, 2020 at 10:21 AM Ty Young > wrote:




I know some things that changed (like adding the support for JDK
9, or the ability to use the JDK's javac instead of nb-javac).
But it is hard to say what is the issue without actually being
able to reproduce the issue. I am definitely willing to look at
problems with (Java) refactoring, but I need to be able to
reproduce them. I tried a simple testcase with renaming an
interface method, and it worked - so apparently I didn't trigger
the problematic part. Might be related to the JDK 9 module
support (although I tried both with and without module-info), or
to something else, but having a case where one can see what is
going on makes chances for a fix much higher.

Jan



It seems to work OK on newly created projects but once you start
actually getting into the thick of things it breaks. I suppose
the only way to track down any of the issues is by using an
existing project.


Sadly for my project(s) you'll need a Panama JDK compiled the
from the source code here(at least to compile):


https://github.com/openjdk/panama-foreign


My project can be found here:


https://github.com/BlueGoliath/Crosspoint


Oddly enough I can't, for whatever reason, get the interface
refractoring bug to happen again but I can get a NullPointer
Exception when moving MemoryObject interface to the enums package:


Module Java Refactoring threw java.lang.NullPointerException.
Please report a bug against Java Refactoring module and attach
your var/log/messages.log.


Detail stacktrace:


java.lang.NullPointerException
    at

org.netbeans.api.java.source.ElementUtilities.enclosingTypeElementImpl(ElementUtilities.java:140)
    at

org.netbeans.api.java.source.ElementUtilities.enclosingTypeElement(ElementUtilities.java:129)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitMemberSelect(MoveTransformer.java:126)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitMemberSelect(MoveTransformer.java:47)
    at
com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2231)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:76)
    at
com.sun.source.util.TreeScanner.visitRequires(TreeScanner.java:906)
    at
com.sun.tools.javac.tree.JCTree$JCRequires.accept(JCTree.java:2966)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:76)
    at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
    at
com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:114)
    at
com.sun.source.util.TreeScanner.visitModule(TreeScanner.java:879)
    at
com.sun.tools.javac.tree.JCTree$JCModuleDecl.accept(JCTree.java:2815)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:76)
    at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
    at
com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:114)
    at
com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:145)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitCompilationUnit(MoveTransformer.java:320)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitCompilationUnit(MoveTransformer.java:47)
    at
com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:603)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin$TransformTask.run(JavaRefactoringPlugin.java:443)
    at

org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin$TransformTask.run(JavaRefactoringPlugin.java:408)
    at

Re: Refactor renaming hardly works anymore

2020-02-24 Thread Ty Young 



If anyone's interested, here's another bug:


https://pastebin.com/g0eLXnFy


On 2/18/20 3:34 PM, Jan Lahoda wrote:

Thanks! I can reproduce, will take a look on how to fix this!

Jan

On Tue, Feb 18, 2020 at 10:21 AM Ty Young > wrote:




I know some things that changed (like adding the support for JDK
9, or the ability to use the JDK's javac instead of nb-javac).
But it is hard to say what is the issue without actually being
able to reproduce the issue. I am definitely willing to look at
problems with (Java) refactoring, but I need to be able to
reproduce them. I tried a simple testcase with renaming an
interface method, and it worked - so apparently I didn't trigger
the problematic part. Might be related to the JDK 9 module
support (although I tried both with and without module-info), or
to something else, but having a case where one can see what is
going on makes chances for a fix much higher.

Jan



It seems to work OK on newly created projects but once you start
actually getting into the thick of things it breaks. I suppose the
only way to track down any of the issues is by using an existing
project.


Sadly for my project(s) you'll need a Panama JDK compiled the from
the source code here(at least to compile):


https://github.com/openjdk/panama-foreign


My project can be found here:


https://github.com/BlueGoliath/Crosspoint


Oddly enough I can't, for whatever reason, get the interface
refractoring bug to happen again but I can get a NullPointer
Exception when moving MemoryObject interface to the enums package:


Module Java Refactoring threw java.lang.NullPointerException.
Please report a bug against Java Refactoring module and attach
your var/log/messages.log.


Detail stacktrace:


java.lang.NullPointerException
    at

org.netbeans.api.java.source.ElementUtilities.enclosingTypeElementImpl(ElementUtilities.java:140)
    at

org.netbeans.api.java.source.ElementUtilities.enclosingTypeElement(ElementUtilities.java:129)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitMemberSelect(MoveTransformer.java:126)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitMemberSelect(MoveTransformer.java:47)
    at
com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2231)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:76)
    at
com.sun.source.util.TreeScanner.visitRequires(TreeScanner.java:906)
    at
com.sun.tools.javac.tree.JCTree$JCRequires.accept(JCTree.java:2966)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:76)
    at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
    at
com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:114)
    at
com.sun.source.util.TreeScanner.visitModule(TreeScanner.java:879)
    at
com.sun.tools.javac.tree.JCTree$JCModuleDecl.accept(JCTree.java:2815)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:76)
    at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
    at
com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:114)
    at
com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:145)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitCompilationUnit(MoveTransformer.java:320)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitCompilationUnit(MoveTransformer.java:47)
    at
com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:603)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin$TransformTask.run(JavaRefactoringPlugin.java:443)
    at

org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin$TransformTask.run(JavaRefactoringPlugin.java:408)
    at
org.netbeans.api.java.source.JavaSource$1.run(JavaSource.java:673)
    at

Disabling doclint on a mavens Netbeans module

2020-02-24 Thread Alejandro Murillo 
This blog explains how to turn off doclint on regular maven projects:

https://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html

But I can't figure out how to do that for a Netbeans RCP mavens based
project. As the javadoc dependency seems to be hidden behind the netbeans
API dependencies. I don't have much experience  creating maven based
Netbeans projects, so I might be missing something

Has anyone done that?

Thanks

-- 
Alejandro

Problem with tomcat #2

2020-02-24 Thread Blake McBride 
Greetings,

This is a shorter version of my previous email containing only the piece I
can't get past.  I am really stuck and would appreciate help if possible.

2.  If I manually deploy the app (copy the war file to the tomcat/webapps
directory) the app runs.  But I can't get NetBeans to deploy for me.

Under Project / Properties / Build / Packaging / WAR Content I have
build/web set but it doesn't get deployed.

I have CATALINA_BASE and CATALINA_HOME set to the same path.

Thank you!

Blake McBride

Re: NB 11.2 change default project path

2020-02-24 Thread Ernie Rael 

On 2/21/2020 12:06 AM, Neil C Smith wrote:



On Fri, 21 Feb 2020, 01:42 Laszlo Kishalmi, > wrote:


I haven't known this one either. Just spent  one minute to dig it
up from the source code.

Always good advice! I didn't either until just before you posted, 
although found it via Google .. on the old mailing lists .. in an 
email from 6 years ago .. that I sent. :-)
And to close the loop. The latest directory used is saved/used. It's 
stashed as a preference at /org/netbeans/modules/projectui keyed with 
projectsFolder.


Those lists are a goldmine of useful info that we used to know - 
hopefully they're archived and spidered enough not to disappear!


Best wishes,

Neil




-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Problems with tomcat

2020-02-24 Thread Blake McBride 
Greetings,

I am using NetBeans 11.2 on a 64 bot Linux system with Java 8.

I have a working web app and my own instance of tomcat.

I am having the following problems:

1.  Once tomcat is launched, if things go wrong, I have no way of killing
tomcat other than killing the process from the command prompt.  There needs
to be a button in NetBeans to kill the process by shutting it down normally
but if that doesn't work - kill the process.

2.  If I manually deploy the app (copy the war file to the tomcat/webapps
directory) the app runs.  But I can't get NetBeans to deploy for me.

Under Project / Properties / Build / Packaging / WAR Content I have
build/web set but it doesn't get deployed.

I have CATALINA_BASE and CATALINA_HOME set to the same path.

I even have the "force stop" option enabled.

3.  In terms of setting up tomcat instances under Tools / Servers:

a. It would be nice to be able to rename the instance

b.  Setting of the base should be related to the project and not global.

Thanks!

Blake McBride