Refactoring JavaFX Builds & Sources

[Mario Torre]

2012/10/19 Danno Ferrin <danno.ferrin at shemnon.com>:
>
>
> On Fri, Oct 19, 2012 at 7:31 AM, Mario Torre
> <neugens.limasoftware at gmail.com> wrote:
>>
>> > Further more, you should be able to do "find usages" in your IDE and get
>> > EVERYTHING IN THE UNIVERSE, rather than right now where in NB it doesn't
>> > have enough information about the 160 other projects in our system to be
>> > able to do this. This is bad.
>> >
>> > Right now we build with ant. Many of you have suggested Maven. Some of
>> > you at JavaOne suggested Gradle. I am presently looking into Gradle. The key
>> > things I like about Gradle are:
>> >
>> >         1) It isn't XML
>> >         2) Like Ivy & Maven, it handles dependencies well
>> >
>> > We presently have a pile of XML files and nasty build logic for
>> > downloading dependencies (this is all in the closed repo, but you would be
>> > exposed to the horror if we just made it all public). I wanted instead to
>> > use Ivy at the very least, but rather if I can get better build happiness
>> > from another setup entirely (like Gradle) then I might as well give it a
>> > try.
>>
>> I kind of like Gradle, but let me put the cart before the horse here
>> (I don't know if this sounds as well in English as it is in Italian,
>> where we actually use the oxen, but well :)
>>
>> While Maven is a well understood tool, Gradle is fairly new. This
>> turns to be especially problematic when building and shipping on Linux
>> distributions because there are some constraints and limitation on
>> what can go or not in a given release (btw, I think this could be
>> considered a problem on Windows and OSX installations in some
>> environments where you can't simply install any tool you want).
>>
>> Maven, on the other end, is pretty likely sitting on your machine
>> already (as are Make, GCC and Configure most of the time on developers
>> machines), so I suspect it will be easier for the average folk as well
>> as heavily filled packager to take care of the build bits.
>
>
> Gradle has a "wrapper" script that can be checked in with the build (the
> gradlew script), it will download the specific version of gradle and build
> it in place, from the build. So having Gradle on your machine is not a
> requirement, the gradle script will build with it in place like it was an
> external library.

Yeah, but this is an issue for Linux distributions that want to
package and ship JavaFX, it also doesn't really solve the problem if
you can't install things on your machine that easily.

> Plus, Android has just shifted to building user projects with Gradle instead
> of Ant.  So there will be many Linux distros that will ship and approve
> Gradle just for that reason.

Maybe, but this is still far in the future, and it will remain so for
long enough to actually make a difference...

> The problem with Maven is when you get off the beaten path (like running
> your own annotation processor, shipping source code in the jar, custom build
> languages) the build script gets very verbose and hard to read.  All the XML
> creates more noise.  Yes, you can do it, but it becomes difficult to
> maintain.  Build scripts for Maven projects that follow the maven
> conventions are dead simple, but OpenJFX is not one of those run of the mill
> builds.

Yeah, I agree.

Just to be very clear what I mean, I don't think JavaFX should
necessarily embrace Maven, or any other specific tool; ultimately what
makes more sense for JavaFX is the way to go.

If something that is incompatible with the distributions will be used,
we will pretty much have some kind of wrapper projects, say IcedTeaFX
or such, to take care of that, exactlu the way it has been done for
OpenJDK and IcedTea, so this is less than issue than what it seems.

On the other end, upstream should be aware of downstream when doing
such critical decisions, that's the only reason why I bring this here
now, one way or the other it may turns more friendly (or get more work
on) the downstream side of things. Again, not enough alone to drive
the choice, but something to think of seriously.

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/