Well, actually there is also some issues…
It is an actually implementation of Plexus Compiler API for JavaFX. This is very easy to get it working (will just require to have some more params specific to JavaFX). I just “forked” from JavacCompiler of Plexus.
But what about license? Plexus code is under MIT and Apache licenses, while OpenJFX is under GNU. Could it actually survive?
It would be good to have artifact repository with all versions of compiler, runtime and Scenegraph. Where? Again how licenses should be managed?
Minor: what version, artifactId and groupId should OpenJFX *.jar get? It is slightly more than just a naming convention…
the request
Date: Wed, 06 Feb 2008 15:32:33 +0200
From: Alexander Zynevich <zynevich@mail.ru>
Content-Type: text/plain; char set=ISO-8859-1; format=flowed
Subject: Java FX with Maven and Ant
Tom,
playing with Maven a bit I have found that it is quite easy to add one
more "JavaC"-like compiler component to Maven, and I wrote one. It is
very draft, but working. I could contribute. Is it acceptable to have it
somewhere within openjfx.dev.java.net site? Say, as a subproject of
openjfx, sibling of openjfx-compiler? I mean if I submit
request-for-proj, d'you approve? 
PS: for those who are interesting in Maven-javafxc:
POM will looks like:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>net.java.dev.openjfx</groupId>
<artifactId>testjfx</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>testjfx</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>net.java.dev.openjfx</groupId>
<artifactId>javafxrt</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerId>javafxc</compilerId>
<include>**/*.fx</include>
</configuration>
<dependencies>
<dependency>
<groupId>net.java.dev.openjfx</groupId>
<artifactId>openjfx-compiler-javafxc</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</project>
output when building from NB6.0:
WARNING: You are running Maven builds externally, some UI functionality
will not be available.
Executing:/usr/share/apache-maven-2.0.8/bin/mvn --errors clean install
+ Error stacktraces are turned on.
Scanning for projects...
------------------------------------------------------------------------
Building testjfx
task-segment: [clean, install]
------------------------------------------------------------------------
Deleting directory /home/alex/NetBeansProjects/testjfx/target
Using default encoding to copy filtered resources.
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/net/java/dev/openjfx/javafxc/1.0-SNAPSHOT/javafxc-1.0-SNAPSHOT.pom
Compiling 2 source files to
/home/alex/NetBeansProjects/testjfx/target/classes
Using default encoding to copy filtered resources.
Nothing to compile - all classes are up to date
No tests to run.
Building jar:
/home/alex/NetBeansProjects/testjfx/target/testjfx-1.0-SNAPSHOT.jar
Installing
/home/alex/NetBeansProjects/testjfx/target/testjfx-1.0-SNAPSHOT.jar to
/home/alex/.m2/repository/net/java/dev/openjfx/testjfx/1.0-SNAPSHOT/testjfx-1.0-SNAPSHOT.jar
------------------------------------------------------------------------
BUILD SUCCESSFUL
------------------------------------------------------------------------
Total time: 7 seconds
Finished at: Wed Feb 06 15:23:57 EET 2008
Final Memory: 23M/41M
------------------------------------------------------------------------
Tom Ball wrote:
> Peter Pilgrim wrote:
>>> The task is as much like the javac Ant task as practical. When using in
>>> your own projects, be sure to specify the bootclasspath argument
>>> (especially on Macs) as we are using new versions of javac than what's
>>> released.
>>
>> Therefore it should be runnable from Maven as a `maven-antrun-plugin'
>> with some pushing.
>
> Good to know -- this answer probably belongs in an FAQ somewhere.
>
>>> Any improvements and other suggestions are appreciated, as none of us
>>> claim to be Ant experts -- we're just Ant users like most other Java
>>> developers.
>>
>> Neither am I an Ant or Maven expert. Thanks for your input.
>> Do you have an opinion on separate source code and classes folders?
>> The maven standard is to use (at least for Java is):
>>
>> <YOUR-PROJECT>/src/main/java
>>
>> which appears in <YOUR-PROJECT>/target/classes
>>
>> For Unit testing it follows a similar pattern
>>
>> <YOUR-PROJECT>/src/test/java
>>
>> which appears in <YOUR-PROJECT>/target/test-classes
>>
>> Would you mix JavaFX and Java code together or would you encourage
>> separate source folder for each language.
>>
>> <YOUR-PROJECT>/src/main/javafx
>> which appears in <YOUR-PROJECT>/target/classes
>
> Personally, I prefer keeping all build artifacts separate from the
> project source, so that full cleanup involves just deleting one or more
> generated directories such as build, dist, etc. The compiler is
> currently following the naming conventions of the javac team so we can
> more easily work together, but other projects should be free to follow
> Maven, Eclipse, NetBeans, or any other naming convention that makes
> sense for that project.
>
> I think JavaFX Script, Java, Jython, JRuby, and any other JVM compiled
> language should be grouped by functionality rather than language, so
> everything that belongs in one package shouDate: Wed, 06 Feb 2008 15:32:33 +0200
From: Alexander Zynevich <zynevich@mail.ru>
Content-Type: text/plain; char set=ISO-8859-1; format=flowed
Subject: Java FX with Maven and Ant
Tom,
playing with Maven a bit I have found that it is quite easy to add one
more "JavaC"-like compiler component to Maven, and I wrote one. It is
very draft, but working. I could contribute. Is it acceptable to have it
somewhere within openjfx.dev.java.net site? Say, as a subproject of
openjfx, sibling of openjfx-compiler? I mean if I submit
request-for-proj, d'you approve?
PS: for those who are interesting in Maven-javafxc:
POM will looks like:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>net.java.dev.openjfx</groupId>
<artifactId>testjfx</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>testjfx</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>net.java.dev.openjfx</groupId>
<artifactId>javafxrt</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerId>javafxc</compilerId>
<include>**/*.fx</include>
</configuration>
<dependencies>
<dependency>
<groupId>net.java.dev.openjfx</groupId>
<artifactId>openjfx-compiler-javafxc</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</project>
output when building from NB6.0:
WARNING: You are running Maven builds externally, some UI functionality
will not be available.
Executing:/usr/share/apache-maven-2.0.8/bin/mvn --errors clean install
+ Error stacktraces are turned on.
Scanning for projects...
------------------------------------------------------------------------
Building testjfx
task-segment: [clean, install]
------------------------------------------------------------------------
Deleting directory /home/alex/NetBeansProjects/testjfx/target
Using default encoding to copy filtered resources.
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/net/java/dev/openjfx/javafxc/1.0-SNAPSHOT/javafxc-1.0-SNAPSHOT.pom
Compiling 2 source files to
/home/alex/NetBeansProjects/testjfx/target/classes
Using default encoding to copy filtered resources.
Nothing to compile - all classes are up to date
No tests to run.
Building jar:
/home/alex/NetBeansProjects/testjfx/target/testjfx-1.0-SNAPSHOT.jar
Installing
/home/alex/NetBeansProjects/testjfx/target/testjfx-1.0-SNAPSHOT.jar to
/home/alex/.m2/repository/net/java/dev/openjfx/testjfx/1.0-SNAPSHOT/testjfx-1.0-SNAPSHOT.jar
------------------------------------------------------------------------
BUILD SUCCESSFUL
------------------------------------------------------------------------
Total time: 7 seconds
Finished at: Wed Feb 06 15:23:57 EET 2008
Final Memory: 23M/41M
------------------------------------------------------------------------
Tom Ball wrote:
> Peter Pilgrim wrote:
>>> The task is as much like the javac Ant task as practical. When using in
>>> your own projects, be sure to specify the bootclasspath argument
>>> (especially on Macs) as we are using new versions of javac than what's
>>> released.
>>
>> Therefore it should be runnable from Maven as a `maven-antrun-plugin'
>> with some pushing.
>
> Good to know -- this answer probably belongs in an FAQ somewhere.
>
>>> Any improvements and other suggestions are appreciated, as none of us
>>> claim to be Ant experts -- we're just Ant users like most other Java
>>> developers.
>>
>> Neither am I an Ant or Maven expert. Thanks for your input.
>> Do you have an opinion on separate source code and classes folders?
>> The maven standard is to use (at least for Java is):
>>
>> <YOUR-PROJECT>/src/main/java
>>
>> which appears in <YOUR-PROJECT>/target/classes
>>
>> For Unit testing it follows a similar pattern
>>
>> <YOUR-PROJECT>/src/test/java
>>
>> which appears in <YOUR-PROJECT>/target/test-classes
>>
>> Would you mix JavaFX and Java code together or would you encourage
>> separate source folder for each language.
>>
>> <YOUR-PROJECT>/src/main/javafx
>> which appears in <YOUR-PROJECT>/target/classes
>
> Personally, I prefer keeping all build artifacts separate from the
> project source, so that full cleanup involves just deleting one or more
> generated directories such as build, dist, etc. The compiler is
> currently following the naming conventions of the javac team so we can
> more easily work together, but other projects should be free to follow
> Maven, Eclipse, NetBeans, or any other naming convention that makes
> sense for that project.
>
> I think JavaFX Script, Java, Jython, JRuby, and any other JVM compiled
> language should be grouped by functionality rather than language, so
> everything that belongs in one package should reside in one directory.
> If the tools can't figure out the difference between those file types,
> then the tools need to be improved, but happily all I've tried seem to
> work fine. Again, that's just my personal opinion, as teams should
> define the conventions that make sense in their context.
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@openjfx.dev.java.net
> For additional commands, e-mail: users-help@openjfx.dev.java.net
>
>
ld reside in one directory.
> If the tools can't figure out the difference between those file types,
> then the tools need to be improved, but happily all I've tried seem to
> work fine. Again, that's just my personal opinion, as teams should
> define the conventions that make sense in their context.
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@openjfx.dev.java.net
> For additional commands, e-mail: users-help@openjfx.dev.java.net
>
>
Дальше интереснее! Нажимаем кнопку 3-й раз, и… ничего не происходит но в динамике гарнитуры раздаётся мелодия входящего звонка. Ну конечно же надо нажать кнопку в 4-й раз, что бы принять этот эффемерный звонок, тут-то и случается то самое чудо — телефон начинает набирать номер за что ему и спасибо! Неправда-ли, весьма своеобразная трактовка сигнала “повторить звонок” инженерами Gigaset? Дальше интереснее хотите вы просто поднять трубку перевести гудок на гарнитуру и набрать номер, давайте попробуем: держим зеленую кнопку на телефоне пока не раздасться гудок, нажимаем кнопку гарнитуры… Да-да-да и тут в гарнитуре раздаётся знакомая мелодия вызова — нажимает кнопку еще раз и получаем гудок в гарнитуре, уф… можно набирать номер. 
— просто красивая штучка.