Hi Griffon Users!
I have some problems with NetBeans opening a new project that has been built using lazybones.
First, I create a javafx-java project with: lazybones create griffon-javafx-java myapp NetBeans opens the project as a Maven one, not as Gradle. Does anyone knows how to do this? I feel the solution
Second, if I open the file myapp.fxml, NetBeans shows an error saying that org.example.MyappController does not exist, and of course it is generated by lazybones. Related to my previous point, I was wondering if forcing NetBeans to open the project as a Gradle one would help getting rid of this dependency error.
Lastly, in a different post Andres was discussing different approaches to build a modular application using Griffon. One of the things he mentioned was to build subprojects, and I believe this could be achieved with a Gradle build. Does anyone know of a real-world example of how to achieve this?
Ps: One thing that I just found out is that if I open the sample projects that are in Griffon's source code (sample-javafx-java and editor-javafx-java), NetBeans handle them with no problem as Gradle projects.
It appears NetBeans is too eager to open a project as a Maven project as long as there's a `pom.xml` file in the sources. Simply remove the file and the `maven` directory and reopen again. This time NetBeans should treat it as a Gradle project.
The lazybones template supplies both choices (Gradle and Maven) because some developers prefer one tool over the other. The template is just a starting point; almost every single aspect of the build is optional or can be changed to your liking.
The second problem could be related to NetBeans' default handling of the source directories when opening the project as a Maven project. Please give it a try again once the Maven files have been removed.
The Griffon source tree includes a multi-project example
It's worth noting that some files had to be relocated and changes had to be made in order to wire up all subprojects into a single multi-project build. Again, the templates are just a suggestion, you can modify the files as much as needed.
Something weird is going on with the project in NetBeans. You were right about removing maven and pom.xml. I had tried that path before and didn't work. I did those modifications after closing the project and I reopened it: NetBeans saw the project as a Gradle one, it could not be built and it complaint about the missing pom.xml file!
Anyway, this morning I started from scratch and did the modification before opening NetBeans and this time the app could be built and run, but another weird thing just happened: even though the project was created with the griffon-javafx-java lazybone's template, the project view now shows both Groovy and Java directories (see attached pictures). Do you have any idea of why this is happening and how to solve it?
Great to know you're making progress in NB :-)
The second problem is related to https://github.com/griffon/griffon/issues/152 Basically NB is doing more stuff that's needed as neither IntelliJ nor Eclipse display the symptoms NB does. You could try removing the `groovy` plugin and applying just `java`. If you do then make sure you also remove the line `compileGroovy.enabled = false` form the build script.
The `groovy` plugin is enabled by default so that you may use Spock for testing, but it's not a hard requirement for using Griffon.
Thanks for the message. I didn't believe NetBeans was going to be so difficult with the projects!
I followed the link you sent for the issue 152 and also tracked the bug report Richard-Cranium opened in the Gradle plugin support for NetBeans: Bug #268 Report Link. I think that bug report would benefit from your expertise because neither Richard nor I could provide valuable information to it.
In the mean time, one of the suggestions posted says that griffon could add the following to remove the source directories:
groovy.srcDirs = 
Do you think that will work? If so, where should I add it? I am looking for a solution that will remove as little functionality as possible.
Ok, I think I got it working. I'm going to document it in case someone else is emotionally attached to NetBeans and can't let it go! Beware of the new sport NetBeans enrolled you into: hitting a wall every now an then...
The trick is to edit the build.gradle file before opening the project in NetBeans. At the end of the file add the following:
srcDirs = 
Hopefully Andres can confirm that they won't be any side effects with this solution.
Well, it turns out that NetBeans does not allow me to add a new FXML file in the Resources folder because it lays outside the source folder... ugh... The solution would be to create the file in one of the source folders (view) and move it to the Resources folder.
Too bad I can't use the grifon command line to create the views and have the new files generated in the right place...
Is there a way to tell grifon where the FXML files are located? Can this be done in config.java where the mvcGroups are defined?
Disabling the groovy source directory is not the way to go IMHO. Removing the `groovy` plugin altogether is more like it. You'll have to make the following changes:
1. change from `apply plugin: 'groovy'` to `apply plugin: 'java'`.
2. comment out the `groovy-all` and `spock-core` dependencies found in the `testCompile` configuration inside the `dependencies` block.
3. comment out or remove the line `compileGroovy.enabled = false`.
4. comment out or remove the lines that configure the `GroovyCompile` task.
1. comment out or remove the `groovydoc` block.
Is there a way to customize via properties or configuration files where Grifon looks for a particular type of file? For example, let's say that I would want the FXML files in the same folder as the View classes, can I achieve that in any way other that editing Config.Java for every single case?
There's no need to edit `Config.java` to achieve this. You can place resource files anywhere in your project as long as the containing directories are identified as such. In the case of Gradle you'd have to redefine the resources directory so that it skips all *.java sources, otherwise you'll end up with *.class, *.fxml, and *.java in the binaries directory.