JDK-8196130: Eclipse configuration files need to be updated
Nir Lisker
nlisker at gmail.com
Thu Jan 25 17:51:06 UTC 2018
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?
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?
On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth <kevin.rushforth at 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.rushforth at 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-deco
>> ra"/>
>> <classpathentry kind="src" exported="true" path="build/resources/jsl-pris
>> m"/>
>>
>> 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
>>>>
>>>
>
More information about the openjfx-dev
mailing list