Re: Heads up... changing the rt/build/*sdk/ directory
Last time I have tried, the NB plugin worked fine (though you will need
Gradle 1.9 or later) as far as I could determine it. The only thing needed
to be changed is to have a build.gradle for each project because NB needs a
way to quickly determine if a folder is a project folder or not. I will try
to do something about it but it will never be as convenient as if the
subprojects had a build.gradle of their own.
2014-02-18 1:54 GMT+01:00 Kevin Rushforth kevin.rushfo...@oracle.com:
Right.
For the apps (e.g., Ensemble8), we use call ant from gradle to build
anyway, so pointing NB at them seems best.
For the runtime itself, we tried using an earlier version of the NetBeans
Gradle plugin, but were not successful, so we ended up producing netbeans
files that are used only by the IDE. If a newer version of the NB gradle
plugin works well enough, then it would be great if we could retire these
files.
-- Kevin
Stephen F Northover wrote:
We are not currently using the gradle plugins for any of the IDE's.
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
Steve
On 2014-02-14 7:26 PM, Scott Palmer wrote:
Are you guys using the NetBeans Gradle plugin?
Scott
On Fri, Feb 14, 2014 at 2:17 PM, Kevin Rushforth
kevin.rushfo...@oracle.com
wrote:
Thanks David.
For NB 7.4 (or 8) users, you should be able to just open up the apps
projects in NB and have it work without needing to do anything extra.
-- Kevin
David Hill wrote:
As part of this Jira https://javafx-jira.kenai.com/browse/RT-35809,
we
are trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be
able
to provide a common path to host build jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with,
explained here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A
developer may
// have multiple SDK's on their system at any one time, depending
on
which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into
'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like
this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
Re: Heads up... changing the rt/build/*sdk/ directory
On 2/15/14, Feb 15, 7:55 PM, Stefan Fuchs wrote:
Hi,
hm, is there now a way to crossbuild the apps like Ensemble8?
Seems to me that the apps are now always build against the default sdk.
I ask this, because for the dalvik port, we currently use a stripped down
version of the sdk, which only contains the classes, we got working.
Stefan,
When performing 'gradle apps', we pass several properties into the the ant
based apps/build.xml.
(Actually gradle sucks in the apps/build.xml tree and runs internally, but that
is an implementation detail).
def appsJar = project.task(appsJar${t.capital}) {
doLast() {
ant.properties['targetBld'] = $t.name
if (!rootProject.ext[t.upper].compileSwing) {
ant.properties['JFX_CORE_ONLY'] = 'true'
}
ant.properties['jfxbuild.jfxrt.jar'] = jfxrtJar
ant.properties['platforms.JDK_1.8.home'] =
${rootProject.ext.JDK_HOME}
ant.project.executeTarget(sampleAppsJar)
}
}
in this case jfxrtJar now evaluates on a 'host' build to:
build/sdk/rt/lib/ext/jfxrt.jar
and on a cross build to:
build/${t.name}-sdk/rt/lib/ext/jfxrt.jar
Note in the above the conditional setting of JFX_CORE_ONLY. This is because we are
currently not building Swing SWT classes in the ARM cross builds, and we use
the JFX_CORE_ONLY property to avoid trying to build some of the examples.
Our nightly build does quite a bit (but not all) of the apps tree for both
'host' and cross.
I am looking forward to hooking up most of the rest. I think there are a couple
that we will not ever build nightly (I think Kevin said Scenebuilder was one).
Dave
- Stefan
David Hill wrote:
As part of this Jira https://javafx-jira.kenai.com/browse/RT-35809, we are
trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be able to provide a
common path to host build jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with, explained
here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A developer may
// have multiple SDK's on their system at any one time, depending on which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into 'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
--
David Hill david.h...@oracle.com
Java Embedded Development
The most likely way for the world to be destroyed, most experts agree, is by
accident. That's where we come in; we're computer professionals. We cause accidents.
-- Nathaniel Borenstein (1957 - )
Re: Heads up... changing the rt/build/*sdk/ directory
Right.
For the apps (e.g., Ensemble8), we use call ant from gradle to build
anyway, so pointing NB at them seems best.
For the runtime itself, we tried using an earlier version of the
NetBeans Gradle plugin, but were not successful, so we ended up
producing netbeans files that are used only by the IDE. If a newer
version of the NB gradle plugin works well enough, then it would be
great if we could retire these files.
-- Kevin
Stephen F Northover wrote:
We are not currently using the gradle plugins for any of the IDE's.
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
Steve
On 2014-02-14 7:26 PM, Scott Palmer wrote:
Are you guys using the NetBeans Gradle plugin?
Scott
On Fri, Feb 14, 2014 at 2:17 PM, Kevin Rushforth
kevin.rushfo...@oracle.com
wrote:
Thanks David.
For NB 7.4 (or 8) users, you should be able to just open up the apps
projects in NB and have it work without needing to do anything extra.
-- Kevin
David Hill wrote:
As part of this Jira
https://javafx-jira.kenai.com/browse/RT-35809, we
are trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be
able
to provide a common path to host build jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with,
explained here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A
developer may
// have multiple SDK's on their system at any one time,
depending on
which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install
into 'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like
this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
Re: Heads up... changing the rt/build/*sdk/ directory
We are not currently using the gradle plugins for any of the IDE's.
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE
Steve
On 2014-02-14 7:26 PM, Scott Palmer wrote:
Are you guys using the NetBeans Gradle plugin?
Scott
On Fri, Feb 14, 2014 at 2:17 PM, Kevin Rushforth kevin.rushfo...@oracle.com
wrote:
Thanks David.
For NB 7.4 (or 8) users, you should be able to just open up the apps
projects in NB and have it work without needing to do anything extra.
-- Kevin
David Hill wrote:
As part of this Jira https://javafx-jira.kenai.com/browse/RT-35809, we
are trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be able
to provide a common path to host build jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with,
explained here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A
developer may
// have multiple SDK's on their system at any one time, depending on
which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into 'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like
this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
Re: Heads up... changing the rt/build/*sdk/ directory
Hi,
hm, is there now a way to crossbuild the apps like Ensemble8?
Seems to me that the apps are now always build against the default sdk.
I ask this, because for the dalvik port, we currently use a stripped
down version of the sdk, which only contains the classes, we got working.
- Stefan
David Hill wrote:
As part of this Jira https://javafx-jira.kenai.com/browse/RT-35809,
we are trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be
able to provide a common path to host build jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with,
explained here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A
developer may
// have multiple SDK's on their system at any one time, depending
on which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into
'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like
this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
Heads up... changing the rt/build/*sdk/ directory
As part of this Jira https://javafx-jira.kenai.com/browse/RT-35809, we are
trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be able to provide a
common path to host build jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with, explained
here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A developer may
// have multiple SDK's on their system at any one time, depending on which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into 'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
--
David Hill david.h...@oracle.com
Java Embedded Development
On a clear disk, you can seek forever.
Re: Heads up... changing the rt/build/*sdk/ directory
Thanks David.
For NB 7.4 (or 8) users, you should be able to just open up the apps
projects in NB and have it work without needing to do anything extra.
-- Kevin
David Hill wrote:
As part of this Jira https://javafx-jira.kenai.com/browse/RT-35809,
we are trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be
able to provide a common path to host build jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with,
explained here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A
developer may
// have multiple SDK's on their system at any one time, depending
on which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into
'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like
this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
Re: Heads up... changing the rt/build/*sdk/ directory
Are you guys using the NetBeans Gradle plugin?
Scott
On Fri, Feb 14, 2014 at 2:17 PM, Kevin Rushforth kevin.rushfo...@oracle.com
wrote:
Thanks David.
For NB 7.4 (or 8) users, you should be able to just open up the apps
projects in NB and have it work without needing to do anything extra.
-- Kevin
David Hill wrote:
As part of this Jira https://javafx-jira.kenai.com/browse/RT-35809, we
are trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be able
to provide a common path to host build jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with,
explained here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A
developer may
// have multiple SDK's on their system at any one time, depending on
which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into 'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like
this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
