Oh, I see. You are pointing to the exploded modules for the JDK in
build/XXXXX/jdk rather than the JDK image in build/XXXXX/images/jdk.
Yes, I think it would be preferable to both reverse the order and also
add in the location of the built class files. So the following order
seems best:
rt/modules/javafx.base/build/classes/main/javafx.base/
rt/modules/javafx.base/src/main/java/
jdk/modules/javafx.base
-- Kevin
Nir Lisker wrote:
This is what I mean: In the
type /base/src/test/java/test/com/sun/javafx/collections/ListListenerHelperTest.java
there are these imports:
import test.javafx.collections.MockListObserver;
import java.util.BitSet;
import javafx.beans.Observable;
The first one is the one in
FX: rt\modules\javafx.base\src\test\java\test\javafx\collections\MockListObserver.java
The second one is in the referenced JDK which was built with
FX: jdk\modules\java.base\java\util\BitSet.class
The third one exists in both:
- in JFX it's in:
rt\modules\javafx.base\src\main\java\javafx\beans\Observable.java
- in the JDK it's
in: jdk\modules\javafx.base\javafx\beans\Observable.class
Does the question make sense now?
On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth
<kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>> wrote:
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"?
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\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
