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
