• upgraded to JUnit 4.7 and reorganized unit tests and increased code coverage
• added help goal
• added documentation to cover the supported javafxdoc tags
• Issue #2974182 added jar goal
• added profile plugin parameter (“desktop”, “mobile”, and “tv” for 1.3)
• tested compatability against JavaFX 1.3 and JavaFX 1.2.3

Give it a whirl, and please let me know if you find any issues. Comments are welcome.

• new tv value for the -profile option
• @treatasprivate is checked in more places in the standard xsl files
• a new link at the top of the generated documentation to expand/collapse multi-line comments
• the -version option no longer stops javafxdoc when packages or files are command line arguments, though it still doesn’t generate information in the @version annotation

Unfortunately, the tool documentation page is still woefully out of sync with the usage information in the tool. Some items documented don’t even work (-link, -linkoffline).

I am adding a profile parameter to the maven-javafxdoc plugin to allow specifying “desktop”, “mobile” or “tv” (if the JavaFX version is 1.3 or higher). Assuming everything goes well with testing, I will release a new version of the plugin at the end of the week.

So, compiled for you below, is a list of all tags that are specifically mentioned in the chain of components that make up the javafxdoc tool (as of SDK 1.2.3):

Documentation for these tags are part of the site documentation for the maven-javafxdoc-plugin 1.0 release.

Testing this plugin has reinforced my belief that unit testing is not enough. You have to do integration testing. I found this out the hard way when I went to use the 0.7 plugin in a Maven project to generate the site documentation. It didn’t work. I had forgotten to implement the MavenReport interface in the mojo! Perhaps my unit testing needs revised…

Give it a whirl and log any issues to the tracking system.

Using the maven-javadoc-plugin as a template, I have created the maven-javafxdoc-plugin. At this time, version 0.7 has been released, and is available from the project site.

The following table lists the standard options mapped to the plugin configuration:

The following standard doclet options are also supported:

I found these options by running the tool at the command line and looking at the source in the JavaFX SDK. The documentation page for javafxdoc in the JavaFX 1.2.3 distribution is quite out of date. It lists options that do not work (yet?) while omitting some options that do.

The upcoming 0.9 release will focus on finishing support for the standard doclet options and covering as much code as possible in the unit tests. Once 1.0 has been released, I will add new goals such as javafxdoc:jar.

Feel free to download the jar and try it out. Feedback is welcome and you can log issues at the project tracker page.

• @profile – use this tag in the class comment to document the profile your class falls under (common, desktop, mobile)
• @defaultvalue – use this tag in property documentation to fill in the Default Value column in the generated documentation

For example, the following markup

produces this in the generated docs

Any more hidden gems out there waiting for discovery?

So, just how easy is it to create custom controls in JavaFX? <pun>It’s as easy as 1.2.3!</pun> Seriously, though, the first step was checking out a blog entry from Jonathan Giles describing how to create custom controls.

Just like everything else, writing the code is fairly simple. The hard part is testing it and fixing the problems. To help with that, I decided to write some examples of using the SplitNode. I plan to use FEST to unit test it once JavaFX support becomes available.

When I got to the point of implementing a horizontal split, I thought I would use an enum to represent the divider orientation, instead of using static integers. Unfortunately, you have to use a Java enum, as there is no such beast in JavaFX. This is where I ran into issues with Maven, as described in an earlier post.

The project resides at splitnode.sourceforge.net. The bug and enhancement trackers have all current known issues and planned additions.

Here are a few screen shots of it in action:

I will write about the details of the main classes in the near future. Feedback is always appreciated as this is as much a learning exercise as it is a teaching one.

1. Place all JavaFX source files in src\main\javafx. Otherwise, NetBeans complains about not being able to find com.sun.javafx.runtime.FXBase.
2. Place all Java source files in src\main\java, just like a normal Java project.



3. Ignore the error message in JavaFX files about being in a non-JavaFX project. If the standard project definition lets you mix Java and JavaFX source files, why not in a Maven project?



4. Fix Imports will not fix imports for your own classes. You must manually type in the import statement, and resist the urge to use the command later as it will remove your own imported classes.



5. Even if you do manage to keep your imports, you still have to contend with complaints about variable types.

And yet, this project will still compile, despite the warnings.

At first, I thought there was an issue when I tried it out on an empty project. It was choking when creating a URL that contained my local Maven repository. I had just used the default settings, which on a Windows XP machine has spaces in it (C:\Documents and Settings\{user}\.m2\…). Until this point, it worked perfectly. This was easy enough to fix; edit the settings.xml file to point to a new directory, and move the .m2 directory to that spot.

The real problem is how NetBeans recognizes the project. If you start mixing Java and JavaFX files in the same project, NetBeans becomes confused about what type of project it is. Maybe rightfully so. It will still compile the project and create the jar file, so you just have to carefully edit your code. The Fix Imports command my decide to remove some of your needed imports, or new classes may lack package declarations.

Aside from this, I feel that we have a usable enough plugin now that I will start using Maven for all of my JavaFX projects. Good job Alex!