one in
"rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java"
or the one in "jdk\modules\javafx.base\javaf
x\beans\InvalidationListener.class"?
Not sure I get what you mean. There isn't a jdk/modules/ directory
created by the build. Perhaps this is an Eclipse construct that it
uses to
indicate the modules that are in the JDK that you are using? The
FX build
puts the class files in:
rt/build/modular_sdk/modules/javafx.base/...
-- Kevin
Nir Lisker wrote:
Another question: do imports of javafx.* packages point to the javafx
source or to the jdk compilation?
For example, in the base module, the type
test.javafx.beans.InvalidationListenerMock
imports javafx.beans.InvalidationListener (twice, by the way, along
with Observable). Should the imported class be the one in
"rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java"
or the one in "jdk\modules\javafx.base\javaf
x\beans\InvalidationListener.class"?
Currently, the way it is in the Eclipse files is that the jdk .class
files are imported first[1], but it seemed odd to me - if I work
on 2 files
which depend on each other they should see the changes in each
other at
once.
[1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d12
7c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before
"src/main/java"),
- Nir
On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:
inline
Nir Lisker wrote:
Alright, cleaned that part. fxpackager build fails with an
internal NPE
in Eclipse, so I'm going to leave that alone and all of the
projects that
depends on it.
Now that projects can be built there are errors in deeper levels:
1. All org.junit imports cannot be resolved. This causes tons of
errors
in various test folders obviously. All the .classpath files use
<classpathentry kind="con" path="org.eclipse.jdt.junit.JU
NIT_CONTAINER/4"/>
which is a jar distributed with Eclipse (in the plugins folder) with
version 4.12.0. Is this really where the imports are supposed to
come from?
How does it work in Netbeans or IntelliJ?
For NetBeans we use their internal version of JUnit. I don't know
about
IntelliJ (maybe someone else on the list can answer that).
2. In the 'base' module, in
"/src/main/java-jfr/com/sun/javafx/logging"
there are imports of com.oracle.jrockit.jfr that can't be
resolved. Where
are these located?
These classes used to be part of the JFR commercial feature in the
Oracle JDK. The java-jfr sources are obsolete and no longer built
(and no
longer buildable), so you can safely remove it from your IDE
files. I also
still see references to it in the netbeans/base project. I will
file a bug
to remove this obsolete code and fix the NetBeans references at
the same
time.
-- Kevin
On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:
Ah, I see. Then yes, just removing the old ones is fine.
As for the larger question, unless there are dependencies on
apps, you
can assume that the only ones you care about are the ones
created by
"gradle sdk".
-- Kevin
Nir Lisker wrote:
So this is why I was asking about the optional stuff: 'graphics'
module has BOTH
build/resources/jsl-decora
build/resources/jsl-prism
and
build/gensrc/jsl-decora
build/gensrc/jsl-prism
That led me to think that when the new dependencies were added
the old
ones weren't removed. Those that weren't optional (like the
/resources
ones, which I removed) were easy to catch and we could have
finished here.
Those that are optional are not causing trouble even when
missing because
they are optional.
gradle sdk does not create the ones which are marked optional that
Iv'e surveyed, but I don't know if that's the only way they can
be created.
If I compare solely with gradle sdk then I can just remove
whatever is
missing on grounds that it's left over.
- Nir
On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:
One more thing about the specific path you mentioned as not being
there.
<classpathentry kind="src" exported="true"
path="build/resources/jsl-decora"/>
<classpathentry kind="src" exported="true"
path="build/resources/jsl-prism"/>
These are still being created by 'gradle sdk', but the path is
wrong
(the files moved in JDK 9) and should be:
build/gensrc/jsl-decora
build/gensrc/jsl-prism
You might want to take that into account.
-- Kevin
Kevin Rushforth wrote:
Nir Lisker wrote:
Iv'e removed all the classpath dependencies that were causing
errors. I don't mind sorting out the rest of the files while
at it, though
for that there are a few things I'm not sure about:
1. Some dependencies are marked as optional and as such they
don't
cause errors, but they are still missing. Is it safe to
remove them or is
it possible that they will be created as some point?
Some of them might be created...not sure without checking. I
recommend running "gradle sdk" and then seeing if the
dependencies are
there.
Examples are the 'base' module with "src/test/resources" and
"src/main/resources" optional dependencies, and 'controls'
module has the
optional dependency "src/main/resources" commented out.
I see. You might as well leave them, but it probably doesn't
matter.
2. Can I assume that all other dependencies are really needed?
(Eclipse won't complain about unused ones as far as I know.)
That seems best.
3. What are the formatting standards for XML (indentation, line
length...)? From a quick look I see different styles in
different files.
For IDE files, we don't worry about formatting. In many cases
they
are auto-generated anyway.
-- Kevin
- Nir
