Note: gradlew (gradle Wrapper) is a native Windows Batch File so you dont have to install gradle, it works on every os
1 Like
In gradle, if you run a task from the root project then it will automatically try to run them in the child projects. I guess the NetBeans plugin doesnât take this into account but Iâm very surprised then that it doesnât let you enter a task directly for running.
Itâs a super common thing to do in multiproject development⌠of course, I now remember the NetBeans doesnât know much about multiproject development in general because itâs always sucked pretty hard there. I feel bad ragging on Netbeans but their mutiproject support has been pretty abysmal which can be an indication that their dev team doesnât develop things that way⌠or at least it influences whoever wrote the gradle plugin.
I think I have this almost figured out enough where I can get new people at least up and running in NetBeans cloning and using their own fork on GitHub if thatâs their vice. I have to verify some stuff that can only be done when you guys make commits though before I am sure.
I ran into a small situation caused by NetBeans that I am not sure how to handle with the jme3-bullet-native.
When you do the first build after cloning it generates these .h files over again with no changes other than time stamping them as near I can tell. Because of that you have a new commit to push to master.
I donât know if the .h files should be ignored or excluded from the commit.
Ignore or exclude the CPP folder.
Do something else.
Well there is only one way to do it and thatâs exclude each file.
That in turn fills your commit dialog full of worthless excluded items and I saw no way to get them out of the list. Cant ignore them, not an option.
What a POS.
Thank you.