JavaFX Maven Plugin

How about instead of 1. requiring a system-level environment variable, it could, instead, or alternatively, be a pom property?

I like your idea!

I'm not a very advanced Maven user. By POM property you mean a property passed to a POM from the settings.xml?

We could extend your suggestion to fall back to the environment variable if the POM property is not set (not sure how doable this is though.)

Thanks!

I'm not very advanced with Maven either but i saw in some other poms how to use them.

There is a <properties> section in the pom (which i suppose extends the settings.xml). The properties defined there can be referenced elsewhere in the pom.

For example, given:

Then

can be placed elsewhere in the pom and it expands to its given value.

I suspect you just need to determine how to reference the properties from the plugin.

I think it is a bad idea to put something like the location of JAVAFX_HOME to the pom.xml since that file should be the same for all platforms and all developers...

I found an issue: mvn clean compile results in:

INFO Failed to execute: Executing Ant script: /compile.build.xml compile.desktop.target: Failed to execute.

destination directory "{my_project_dir}/target/classes" does not exist or is not a directory

Having an environment variable was the only solution I had at that time. Do you have an alternative?

Thanks for reporting this issue. I'll look into this. Can you please file a bug, so we can have a record in the bug tracker?

Cheers,

Alex,

The general Maven practice is to provide the libraries in a repository and then just reference the version of the dependency. So, one way to approach the issue is to simply require the Maven user to install:install all the required libraries. Personally, i hate that approach because it means if i move to another system, i have to install all the libraries again. I disagree with Johanees that it is a bad idea to include paths in the pom. It's a far more common and understandable approach to most developers to set environment variables (or similarly, Maven properties) than it is to have to install libraries into local repositories to manage dependencies. And unless the pom is going to be public, it makes no difference since it'll remain a local developer pom. I think there is a compromise. Provide a goal (or plugin) that will install the required libraries into the user's local repository based on the JAVAFX_HOME (or, better, a Maven property for the JAVAFX_HOME). The plugin could then look in some common, default locations per platform to perform the install and not require a reference to JAVAFX_HOME most of the time.

And to go off-topic a little, i think that capability should be built into Maven itself. Managing dependencies for fast moving products that don't automatically produce poms is a major pain in the ass to have to constantly install new libraries locally. I should be able to tell Maven to install from local paths when no valid versions are found in the local and central repositories. /rant

Alex,

(Random feedback) –

I had an issue with yours with a loader constraint violation for org/codehaus/classworlds/RealmClassLoader

Also a bit of a Google, the JFrog plug-in (which I've had to switch to because of the above error) doesn't actually require you to install the JavaFX jars in a repository after all – as you can list them with <scope>system</scope> and a local system path (although it is quite verbose). See this example I came across on Project Kenai
http://projectkenai.com/projects/jezzballfx/sources/knackfx/content/trunk/KnackFX/pom.xml?rev=99

Thanks William for the feedback

What version of Maven are you using? It seems that it may be a problem of Maven's Ant plugin, or any of its dependencies (I did a little Googling.)

I saw the sample using JFrog's. That verbosity is exactly what I want to avoid, and one of the main reasons I created this plugin.

Cheers,
-Alex

Alex,

I too have an issue with a loader constraint violoation:

Regards,
/Viktor

Thanks so much Viktor for the feedback. I'd like to ask you a big favor. Can you please file a bug at http://jira.codehaus.org/browse/FEST , adding the whole stack trace? I suspect this is an issue with Maven and I'd like to track which version has a fix for this problem.

Many thanks!

(Sorry for the slow reply)

I was using 2.0.10 when I hit the error. 2.2.1 didn't error in that way.

However, with 2.2.1 I did have another two issues –
1. Dependencies on other Maven projects (particularly other Maven JavaFX projects) didn't seem to work.
2. The build would fail after a "mvn clean" because the target directory does not exist.

All the reported issues have been entered in our JIRA instance. I expect to release version 0.2 the first week of February. Many thanks for the feedback.

Nicerobot,

I apologize for the late reply. JavaFX is a special case, given its license. The reasons I don't think we should specify the paths for each jar, and have an environment variable instead, are:

• I don’t see the point of having JavaFX jars in a Maven repository, since those jars cannot be distributed (per JavaFX’s license)
• Installing those jars in a local repository is easy but time-consuming: it needs to be done one by one
• So far, with each release, the number and some of the names of JavaFX jars change; I wouldn’t want to go through the process of installing them in a local repository every time there is a JavaFX release

Cheers!

Alex,

Maybe my point was too winded :) I agreed with your approach. I like referencing an environment variable (but would still prefer a Maven property) instead of the standard Maven approach of installing libraries into the local repo. I was just trying to suggest a compromise for Johannes issue.

Thanks

Nicerobot,

The good news is that I'm rewriting the plugin in Java. Originally the plugin was wrapping an Ant build. This approach is too limited, and does not allow me (or at least I couldn't figure out how) to fall back to the environment variable if the Maven property for "JavaFX Home" is not available, and to pass the dependency classpath to the Ant build.

In addition, it seems that creating Maven Ant plugins is discouraged (that section was removed from the official Maven book.)

Cheers!