How to configure Terasology for Netbeans?
- Thread starter Darkhog
- Start date
I imagine there is a gradle task for generating the netbeans project, however it is currently lacking the necessary extra build configuration to support the mod system. If you would like to update build.gradle with the necessary additions that would be grand. Basically you will need to edit the Mods subsection of the build so that the mods have the netbeans plugin applied, and add the necessary configuration so that netbeans compiles them into a 'classes' subdirectory of the mod - this is where Terasology looks for the code in exploded mods.
Darkhog
New Member
I used Netbeans most of the time before Terasology, the only thing that's really different is there's no built in GUI thing, other than that I would say Eclipse is a bit better. And you will get used to it.
Elijah C. Menifee
New Member
I do not believe that there is plugin task for generating a NetBeans project in Gradle. As far as I can tell the Gradle developers are holding off on adding support for NetBeans until more users request support.
I have forked/cloned https://github.com/kelemen/netbeans-gradle-project which appears to properly load a Terasology clone as a project, similar to how NetBeans natively handles a Maven pom as a NetBeans project. I can clean/build/run Terasology from within NetBeans so far.
I decided to try and get Terasology to work in NetBeans this evening, after learning that the IntelliJ IDEA ( which I was willing to learn to use ) does not include a code coverage utility in the free community edition. I was investigating why the org.terasology.logic.grammer.SetRuleTest was failing (BlockCollection does not implement equals/hash methods by the way...which also appears in need of a JUnit test....). I was going to set about contributing unit tests, and decided I wanted to find out what sections of code were not being covered by existing tests....
So far the downsides of the using the Gradle project NBM is that the Gradle unit tests do not integrate with NetBeans' JUnit framework, since it is essentially running Gradle as a background command line task. I also have not been able to figure out how to use the code coverage support in a NetBeans Gradle project, which I suspect is related to the JUnit tests not being integrated into the project at the NetBeans level. It may also be related to the code coverage plugin only working on native .nbprojects...I understand there is a separate plugin for code coverage under Maven...May require changes to the netbeans-gradle-project NBM, or an additional NBM for code coverage info from the Gradle tool.
Best option may be to create a custom Gradle task that generates either a .nbproject or a Maven POM similar to how the builtin plugin tasks for Gradle handle it for idea and eclipse...I may eventually try this, however at the moment I am not familiar enough with Gradle, or the black magic of a .nbproject directory, and my Maven skills are a bit rusty, to accomplish this in the immediate future.
Additional NetBeans/Gradle info I have found in my research tonight:
http://netbeans.dzone.com/nb72-gradle-plugin
Also an Oracle NetBeans engineer created a plugin, which was the basis for kelemen's, that I have not yet tried:
https://blogs.oracle.com/geertjan/entry/gradle_classpath_support_in_netbeans
https://blogs.oracle.com/geertjan/entry/gradle_in_netbeans_ide_71
http://plugins.netbeans.org/plugin/41776/gradle
I have forked/cloned https://github.com/kelemen/netbeans-gradle-project which appears to properly load a Terasology clone as a project, similar to how NetBeans natively handles a Maven pom as a NetBeans project. I can clean/build/run Terasology from within NetBeans so far.
I decided to try and get Terasology to work in NetBeans this evening, after learning that the IntelliJ IDEA ( which I was willing to learn to use ) does not include a code coverage utility in the free community edition. I was investigating why the org.terasology.logic.grammer.SetRuleTest was failing (BlockCollection does not implement equals/hash methods by the way...which also appears in need of a JUnit test....). I was going to set about contributing unit tests, and decided I wanted to find out what sections of code were not being covered by existing tests....
So far the downsides of the using the Gradle project NBM is that the Gradle unit tests do not integrate with NetBeans' JUnit framework, since it is essentially running Gradle as a background command line task. I also have not been able to figure out how to use the code coverage support in a NetBeans Gradle project, which I suspect is related to the JUnit tests not being integrated into the project at the NetBeans level. It may also be related to the code coverage plugin only working on native .nbprojects...I understand there is a separate plugin for code coverage under Maven...May require changes to the netbeans-gradle-project NBM, or an additional NBM for code coverage info from the Gradle tool.
Best option may be to create a custom Gradle task that generates either a .nbproject or a Maven POM similar to how the builtin plugin tasks for Gradle handle it for idea and eclipse...I may eventually try this, however at the moment I am not familiar enough with Gradle, or the black magic of a .nbproject directory, and my Maven skills are a bit rusty, to accomplish this in the immediate future.
Additional NetBeans/Gradle info I have found in my research tonight:
http://netbeans.dzone.com/nb72-gradle-plugin
Also an Oracle NetBeans engineer created a plugin, which was the basis for kelemen's, that I have not yet tried:
https://blogs.oracle.com/geertjan/entry/gradle_classpath_support_in_netbeans
https://blogs.oracle.com/geertjan/entry/gradle_in_netbeans_ide_71
http://plugins.netbeans.org/plugin/41776/gradle
Elijah C. Menifee - nice! Thanks for that research and effort, we'd be thrilled to see more, be it fancy Gradle/NB stuff or more useful unit tests 
Most of the code is lacking unit tests anyway. On that failing test, I believe one major issue with it is it tries to fetch CobbleStone out of the BlockManager, but never registers CobbleStone - so it will just return air. And yes, BlockCollection doesn't implement equals/hashCode.
Given what you've found out I think we should just not support Netbeans, unfortunately.
Given what you've found out I think we should just not support Netbeans, unfortunately.