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\javafx\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/305d127c6ed5/modules/javafx.base/.classpath
<http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d127c6ed5/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
<mailto: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.JUNIT_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
<mailto: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
<mailto: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
