Open aplatypus opened 6 years ago
kelemen
commented
6 years ago Only 2.X versions of the plugin (e.g.: 2.0.0.2) is expected to be used in NB 9. Though, I would have expected older versions to work too. Can you try 2.0.02?
Non-existent folders should be normal on the classpath. It appears because you have applied the Groovy plugin and so - in principle - there is such an output directory. I don't think NB should be bothered about it.
Anyway, I will investigate this further.
kelemen
commented
6 years ago I have looked at NB's sources and it seems that it expects those URL's to end with a slash. I'm not sure if it is really alright NB to expect that but it doesn't seem to be needed at the point where it checks it. So - for now -, the easiest workaround is to remove the "-J-ea " from netbeans.conf. This issue was probably there in older versions of NB as well but assertation were not enabled in the past.
kelemen
commented
6 years ago I have pushed same changes to the nb9 branch which should fix your problem (even with enabled assertion). You can try if it works for you.
aplatypus
commented
6 years ago Will I see this on the Plugin update?
build/class/groovy/main -- This path should not be in the project build, except for any internal artifacts.
I have checked the Netbeans 9 IDE log on my Linux PC and there is not reference to that folder in that log. So calls upon groovy main src and class files is both plain mysterious and may relate to Windows or Gradle on Windows.
If you look into the JIRA report; purging ALL and EVERY gradle cache resolved the problem temporarily.
kelemen
commented
6 years ago For now, it is only on the "nb9" branch which you could build manually (the plugin should buil out of the box but you can also set up as described on the development page if you want to build it the same way as I do).
You shouldn't be bothered about build/class/groovy/main, why it is there is not relevant from your perspective. The plugin builds your project via Gradle and the output is whatever Gradle produces. But if you really want to know, it is there because it is one of the build output directory of your "main" source set. It is also not a Windows issue, I'm fairly certain that this issue is there even in earlier versions the only reason you don't see it because assertation are not enabled on a release build of NB. (if you disabled assertion here, you wouldn't see a problem).
aplatypus
commented
6 years ago Hi and thanks for that.
I am unlikely to have time to build with Java 6 though.
I need to clarify the situation regarding this erroneous folder. The: build/class/groovy/main does not exist under the build/ tree for all 40 of the projects I just checked. And that is the correct answer, there should be NO such directory in these projects.
The flaw as I see it, is that something expects that path to exist. It is an assumption.
And there are errors popping up because some assumption some place is incorrect. That might be one or a combination
When software fails looking for something that should not be and is not there ... You have bugs that are merely symptoms. And as I have been experiencing with Netbeans 9 very, very slow and unresponsive.
Yes, I believe it is relevant.
geertjanw
commented
6 years ago No one is asking to build anything with Java 6, I think. NetBeans doesn't run on Java 6, though it is needed for building the plugin: https://github.com/kelemen/netbeans-gradle-project/wiki/Development
For now, the fix is only on the "nb9" branch which you could build manually (the plugin should build out of the box but you can also set up as described on the development page if you want to build it the same way as Attila does).
Here is the "nb9" branch: https://github.com/kelemen/netbeans-gradle-project/tree/nb9
Note that indeed build/class/groovy/main is not in your project structure, it is a 'build' folder, i.e., that is output from the Gradle process, via the Gradle plugin, when it succeeds in doing your build.
Maybe @kelemen can make an NBM available that @aplatypus can use to try it out without needing to build anything? Happy to try it too and provide feedback.
kelemen
commented
6 years ago As Geertjan said, there is no need to set up Jave 6 to build one of the subproject. The only reason I have to is because if I didn't people would need the version of Java used for building to evaluate Gradle scripts (i.e. you could only develop project conveniently targeting that Java version or higher). This is irrelevant if you are building it for yourself.
Anyway, I have built the plugin and uploaded to here https://www.justbeamit.com/x8v3k (I have never used this file sharing site, so I don't know how long will they keep it).
kelemen
commented
6 years ago Anyway, your assumptions are wrong. Given that I know the code, I hope you can trust me that I know what the problem is if I claim so :). NB doesn't "crashes" because it tries to access a non-existent folder (the only reason you see the path is because it logically exists) and having non-existent folders on the classpath is completely normal in NB (because the output folder might be on the classpath of other source sets and obviously you can't expect the build output folder to exist).
kelemen
commented
6 years ago I have found another place from where URLs without trailing slashes can creep in, so I have created another build: https://www.justbeamit.com/7m47h
aplatypus
commented
6 years ago Hi,
I built with Java 8 u162 and gradle 4.6. I set the Netbeans exe to point at my Netbeans 8.2. It doesn't fix the problem. I have attached the log files.
There's one query on the Gradle plugin. The version from the Plugin Portal shows-up as v1.4.3. The build project is building on a v2.0.x.x lineage.
plug in portal
Version: 1.4.3 Source: Plugin Portal
Plugin Description
Allows opening directories containing a "build.gradle" file as a project in NetBeans. The opened project then can be used as a usual Java project.built version:
Version: 2.0.0.2 Source: org-netbeans-gradle-project.nbm
Plugin Description
Allows opening directories containing a "build.gradle" file as a project in NetBeans. The opened project then can be used as a usual Java project.I configured the project with the attached root gradle.properties file. gitHub can't cope with properties, hence the odd name.
One thing that caused me trouble is that a grep of the whole project did not find the netBeansExecutable symbol in the project. Eventually I had to start netbeans 9 from a command line to ensure the correct JDK, user and cache folders were supplied; then load the plugin via downloads.
Anyway no cigar as yet.
This doesn't look like a plug-in error. Sure the plugin is just the victim of bad data, or bad input. Of course if I remove the Gradle plugin from a Gradle project, there will be no gradle-plugin errors. That actually demonstrates nothing.
What I suggest you do is capture such BAD data and add logging to identify the source.
Gradle info:
------------------------------------------------------------
Gradle 4.6
------------------------------------------------------------
Build time: 2018-02-28 13:36:36 UTC
Revision: 8fa6ce7945b640e6168488e4417f9bb96e4ab46c
Groovy: 2.4.12
Ant: Apache Ant(TM) version 1.9.9 compiled on February 2 2017
JVM: 1.8.0_162 (Oracle Corporation 25.162-b12)
OS: Windows 10 10.0 amd64@geertjanw ... Concerning the mooted Groovy path. I am afraid you are not listening to me.
Out of 40 project build folder AFTER a complete gradle clean and gradle build -- NONE of those build folders have any main/groovy folders. This is absolutely the correct condition.
Also there are no custom components involved. The error occurs with ANY GUI screen but it is not limited to Pallette-s, that just happens to be the second example when I decided to report it.
Netbeans 9 / Gradle builds on Windows passes several path names to directories that Do Not exist. And ought Not to exist. Of course when given a non-existent directory to process we have errors. Netbeans 9 on Linux, Netbeans 8.2 on both Windows and Linux don't look for that folder tree.
But as before, the problem appears to stem from something in a cache some place. If I ran the Linux project enough times I might see it.
------------------------------------------------------------
Gradle 4.6
------------------------------------------------------------
Build time: 2018-02-28 13:36:36 UTC
Revision: 8fa6ce7945b640e6168488e4417f9bb96e4ab46c
Groovy: 2.4.12
Ant: Apache Ant(TM) version 1.9.9 compiled on February 2 2017
JVM: 1.8.0_162 (Oracle Corporation 25.162-b12)
OS: Windows 10 10.0 amd64There is no Groovy at all in NetBeans 9. Groovy modules have not been donated yet to Apache, so it is completely impossible for any referenced at all to anything related to Groovy to be in NetBeans 9. It is physically impossible since nothing at all related to Groovy is in NetBeans 9.
aplatypus
commented
6 years ago unfortunately ...
sorry, this download link no longer exists :(kelemen
commented
6 years ago @aplatypus
Since, you could build the plugin, I assume the download link is no longer relevant. The netBeansExecutable property is used by Radim's nbm-gradle plugin, so you won't find it here.
I believe you that it doesn't exist but it doesn't matter if it exists or not. As you can see in NB's sources, the exception has nothing to do with the folder existing or not. The reason it is there because the 'groovy' plugin were applied to (some) of your projects but since you have no groovy sources, then Gradle won't create the empty folder for nothing. This is all fine and normal.
The issue is that NB checks if the URL it got from somewhere (obviously provided by this plugin) doesn't end with a '/' character. If the issue still persists for you (I have uploaded some changes which you might want to try), I'll have to look harder in NB's code to find from where it gets these URLs.
kelemen
commented
6 years ago Also, after building the plugin from sources and installing it in the target IDE, please exit NB, remove the Gradle cache (.nb-gradle/private/cache) and start NB again to avoid those bad URLs to creep in from the cache.
aplatypus
commented
6 years ago I demonstrated that cleaning the cache is a workaround for this but in the JIRA bug thread. However I believe that's part of the bigger picture. Netbeans and individual plugins Must deal effectively with incorrect Cache contents. It is impractical to have to clean-out everything before starting your IDE.
The other huge problem is the performance hit that comes with all the Exceptions. If as asserted these file paths are optional then they ought to be coded that way and not cause exceptions. There is a cost in the JVM on exceptions.
After the cache-s have been blown away, you need to rebuild the GUI project in order for any screens to load. To test the fix, you must then exit Netbeans.
Upon restart with a built GUI, Netbeans should show the GUI panels in design.
In my book, we need to be confident that GUI screens will load in Netbeans every time Netbeans is started.
The gradle plugin v 2.0.0.2 does not workaround to the problem.
v1.4.3.v 2.0.0.2 pluginv1.4.3 Gradle Pluginjava.lang.AssertionError: file:/D:/work/products/FourAbs/FourAbsClientCommon/build/classes/groovy/main
at org.netbeans.modules.form.project.ClassSource.getClasspath(ClassSource.java:81)
at org.netbeans.modules.form.project.ClassPathUtils.loadClass(ClassPathUtils.java:164)
at org.netbeans.modules.form.palette.PaletteItem.loadComponentClass(PaletteItem.java:318)
at org.netbeans.modules.form.palette.PaletteItem.getComponentClass(PaletteItem.java:146)
at org.netbeans.modules.form.palette.PaletteItem.getBeanDescriptor(PaletteItem.java:346)
at org.netbeans.modules.form.palette.PaletteItem.getDisplayName(PaletteItem.java:259)
at org.netbeans.modules.form.palette.PaletteItemDataObject$ItemNode.getDisplayName(PaletteItemDataObject.java:307)
at org.openide.nodes.FilterNode.getDisplayName(FilterNode.java:503)
at org.openide.nodes.FilterNode.getDisplayName(FilterNode.java:503)
at org.netbeans.modules.form.palette.PaletteUtils$1.run(PaletteUtils.java:224)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
Caused: org.openide.util.RequestProcessor$SlowItem: task failed due to
at org.openide.util.RequestProcessor.post(RequestProcessor.java:395)
at org.netbeans.modules.form.palette.PaletteUtils.preparePalette(PaletteUtils.java:211)
at org.netbeans.modules.form.palette.PaletteUtils.getPaletteLookup(PaletteUtils.java:161)
at org.netbeans.modules.form.FormDesigner.initLookup(FormDesigner.java:346)
at org.netbeans.modules.form.FormDesigner.<init>(FormDesigner.java:164)
at org.netbeans.modules.nbform.FormDesignerTC.createDesigner(FormDesignerTC.java:97)
at org.netbeans.modules.nbform.FormDesignerTC.<init>(FormDesignerTC.java:89)
at org.netbeans.modules.nbform.FormDesignerTC.<init>(FormDesignerTC.java:83)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:488)
at org.netbeans.core.spi.multiview.MultiViewFactory$MapMVD.createElement(MultiViewFactory.java:422)
at org.netbeans.core.multiview.MultiViewModel.getElementForDescription(MultiViewModel.java:197)
at org.netbeans.core.multiview.MultiViewModel.getActiveElement(MultiViewModel.java:107)
at org.netbeans.core.multiview.MultiViewModel.getActiveElement(MultiViewModel.java:103)
at org.netbeans.core.multiview.MultiViewPeer.showCurrentElement(MultiViewPeer.java:445)
at org.netbeans.core.multiview.MultiViewPeer.showCurrentElement(MultiViewPeer.java:437)
at org.netbeans.core.multiview.MultiViewPeer$SelectionListener.selectionChanged(MultiViewPeer.java:904)
at org.netbeans.core.multiview.MultiViewModel.fireSelectionChanged(MultiViewModel.java:234)
at org.netbeans.core.multiview.MultiViewModel.setActiveDescription(MultiViewModel.java:95)
at org.netbeans.core.multiview.MultiViewModel$BtnGroup.setSelected(MultiViewModel.java:297)
at java.desktop/javax.swing.JToggleButton$ToggleButtonModel.setSelected(JToggleButton.java:346)
at java.desktop/javax.swing.ButtonGroup.setSelected(ButtonGroup.java:168)
at org.netbeans.core.multiview.MultiViewModel$BtnGroup.setSelected(MultiViewModel.java:293)
at java.desktop/javax.swing.JToggleButton$ToggleButtonModel.setSelected(JToggleButton.java:346)
at java.desktop/javax.swing.AbstractButton.setSelected(AbstractButton.java:341)
at org.netbeans.core.multiview.TabsComponent.changeActiveManually(TabsComponent.java:541)
at org.netbeans.core.multiview.MultiViewPeer$MVTCHandler.requestActive(MultiViewPeer.java:931)
at org.netbeans.core.api.multiview.MultiViewHandler.requestActive(MultiViewHandler.java:74)
at org.netbeans.modules.nbform.FormEditorSupport.openFormEditor(FormEditorSupport.java:224)
at org.netbeans.modules.nbform.FormDataNode$1.actionPerformed(FormDataNode.java:66)
at org.openide.explorer.view.TreeView$PopupSupport.mouseClicked(TreeView.java:1584)
at java.desktop/java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:278)
at java.desktop/java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:277)
at java.desktop/java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:277)
at java.desktop/java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:277)
at java.desktop/java.awt.Component.processMouseEvent(Component.java:6592)
at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342)
at java.desktop/java.awt.Component.processEvent(Component.java:6354)
at java.desktop/java.awt.Container.processEvent(Container.java:2260)
at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4966)
at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2318)
at java.desktop/java.awt.Component.dispatchEvent(Component.java:4798)
at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4906)
at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4544)
at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4476)
at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2304)
at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772)
at java.desktop/java.awt.Component.dispatchEvent(Component.java:4798)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
at java.desktop/java.awt.EventQueue.access$600(EventQueue.java:97)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:97)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
[catch] at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)Thanks for looking into it. It seems that Apache Netbeans is NOT supporting Gradle. For the time being our people will have to with 8.2. Which works. That's probably good enough for 3 - 5 years.
For this bug, I may get time to make a small project and try to reproduce it. I can't do much on my boss' clock since we are not going to be able to use NB9 in the next year or so.
geertjanw
commented
6 years ago Many people will not be able to use NB9 since it is only focused on Java SE, not EE, not JavaScript, not Groovy, not PHP. A lot has not been donated to Apache yet. NB9 is definitely not equivalent to 8.2 and no one has said it is. NB is undergoing transition to Apache and a lot has not been donated yet.
aplatypus
commented
6 years ago Hi ...
Thanks very much for clarifying that situation. This was NOT at all clear. It makes more sense too.
I suggest the features page:
Needs to announce/state these constrictions. Most people I have connection with seem to consider Netbeans 9 to be Netbeans 8 with new stuff. Such as Netbeans 8 was built on Netbeans 7.
In the open source parlance, it sounds like Netbeans 9 is a fork with "core" functionality. This makes some sense if the world was a Java world. Sadly it is no longer.
A very LARGE part of my employer's on-going technical development is due to the Oracle refusal to build a replacement secure container for Java applets. We have several mobile applications. These are Gradle, Javascript/Typescript and Groovy intensive technologies. The gentleman who sits next to me has IceTea which works with modern browsers. It is irrelevant now, so we have shifted back to the age of VisualBasic for enterprise applications. That legacy rewrite is not user/customer driver, it is just because there is no more Java in the browser.
To be brutally honest VisualBasic was a lot safer and less error prone than Typescript/Javascript. (I digress)
Developer people need to Understand that the next Netbeans (9) will be branch or diversion from the known Netbeans 8 <-7<-6 evolution, as we know it.
One thing is for sure, since I can't use Netbeans 9 in my Day Job along with my fellow team members, I need to evaluate the alternatives. I feel it is a shame in a way. Alas, I've witnessed the death,perversion and neutering of many an operating system and development environment. For example Netbeans is still the only IDE that really bought into and Implemented the DevOps idea. Wow
One other point. We have quite a few Solaris systams. Will there be something Netbeans (legacy) 8.3 or something?
On 2 May 2018 at 13:04, Geertjan Wielenga notifications@github.com wrote:
Many people will not be able to use NB9 since it is only focused on Java SE, not EE, not JavaScript, not Groovy, not PHP. A lot has not been donated to Apache yet. NB9 is definitely not equivalent to 8.2 and no one has said it is. NB is undergoing transition to Apache and a lot has not been donated yet.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kelemen/netbeans-gradle-project/issues/382#issuecomment-385851939, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEF1AfckiyJP9L-N9ySJ4NJJMNmgubNks5tuSI5gaJpZM4TfE34 .
-- aloha, _w_/
º http://www.facebook.com/will.2016So many misunderstandings here, not really sure where to begin. Maybe it’s best to sign up to the mailing lists via netbeans.apache.org and follow ongoing discussions. Everything that is currently in 8.2 will eventually be part of Apache NetBeans, it’s just taking a while to get everything from Oracle to Apache and we’re doing it in stages. Again, best to join the mailing lists to follow the ongoing developments.
kelemen
commented
6 years ago @aplatypus
This issue is most likely present with all versions of NB, the only reason you don't see it because assertations are disabled in the NB releases (and as I have heard it will be so in NB9 release), so you won't notice this issue in the released version of NB 9. If you want to workaround the issue you can still remove the "-J-ea" from the NetBeans config (though if you are just testing, then of course you don't want to do that).
This is - probably - not a cache issue, I just wanted to make sure. Of course, noone wants you to follow a workflow to delete the cache all the time, it is just for testing (to eliminate one source of uncertainty). However, since the issue still exists for you, it means there is still some place where non-existent paths are converted to URLs without a trailing slash, so I will keep looking.
problem ## There is a problem with the Gradle 1.4.3 and Netbeans 9-beta1 and Java 10. an
AssertionErroris raised when attempting to load a palette for the Netbeans Designer (see stacktrace below). By comparison the plugin works correctly with Netbeans 8.2 with NoAssertionError.Please refer to the attachments and logs on the Netbeans JIRA issue, here.
The
AssertionErrorconcerns loading of the Swing Designer pallette. This error also occurs if you switch to a GUI designer page -- Palette loading just hangs. TheAssertionErrorexhibits as a "slowness problem" much of the time. Sometimes theAssertionErrorwill be reported directly by the Netbeans GUI.The stacktrack shows an error on a non-existant foler.
build/classes/groovy/mainWhich is not an expected folder path for this project. The project folder tree is shown below. There are NO file under
src/test/groovy/at this point. There is nosrc/main/groovytree and none is required -- the project code is pure Java.The test source would give:
build/classes/groovy/testin any case.---[ Netbeans stacktrace ]---
environment