Eclipse cannot handle 11.3.0 for some reason

[crowlogic]

Import maven project... it bizarrely says there is no constructor for AbstractDataSet

[RalphSteinhagen]

@crowlogic, we need more information on this. Your description is inconclusive. Could you check that the effect you see is reproducible using the maven command line tool on a freshly checked out source tree?

[crowlogic]

Hi @RalphSteinhagen ,

The issue persists, from the commandline maven has no problem compiling it, which seems weird .. if i compile from maven, then delete the errors and dont touch the files that extend AbstractDataSet its ok, but otherwise its broken. You should be able to reproduce this pretty easily just by checking out the arb4j project in eclipse, see https://github.com/crowlogic/arb4j/commit/9a9a25c9d9ee914106b6ede1bbb9c2971eafc1a1

[RalphSteinhagen]

@crowlogic it seems that this is not reproducible with the command-line maven, other IDEs (N.B. we are using idea), or unit-test.

I suggest following up on this with the Eclipse IDE community that seems to reimplemented their own non-conformant version of maven.

I am closing this issue as this is not related to this specific library. Hope that the Eclipse community can fix your problem in their IDE.

[crowlogic]

The whole f** point was eclipse specific so I don't know why you would even want to test it on another IDE in the first place but whatever you want dude. And has nothing to do with something not conforming with whatever rigid standards you think need to be conformed to it's called a f** bug. Thanks for f** nothing Hope you all can find a little diversity in your development environment for other environments besides crap beans or whatever that thing is

[wirew0rm]

@crowlogic please take a look at our Code of Conduct if you plan to continue interacting with this project. We should treat each other with respect and your previous comment fails to reflect that.

The point of testing with different maven implementations is an indicator whether we are doing something invalid in our pom structure or whether the problem is in the specific IDE's implementation. Closing this bug means that we believe that the problem should probably be fixed/investigated in eclipse or at least by other eclipse users. If that turns out new results or problems on our side you can still comment or reopen the issue.

In general we are trying to not break chart-fx for anyone independent of their preferred IDE or OS, but as we do not have infinite resources we cannot actively investigate issues on systems we are not actively using ourselves. I think that is reasonable.

[yezhengli-Mr9]

Hi @RalphSteinhagen ,

The issue persists, from the commandline maven has no problem compiling it, which seems weird .. if i compile from maven, then delete the errors and dont touch the files that extend AbstractDataSet its ok, but otherwise its broken.

Dear @crowlogic, recommend Intellij (Community) if better for debug while command lines in terminal are enough for exec:java.

[crowlogic]

Hi @RalphSteinhagen ,

The issue persists, from the commandline maven has no problem compiling it, which seems weird .. if i compile from maven, then delete the errors and dont touch the files that extend AbstractDataSet its ok, but otherwise its broken.

Dear @crowlogic, recommend Intellij (Community) if better for debug while command lines in terminal are enough for exec:java.

Jet brain sucks I will check out the project in eclipse and then fix the bug in eclipse I would rather stab myself in the eye with a hot poker than use intelliJ. As it is to work around of just deleting the errors and eclipse works just fine for now. It's just maddening because this guy asked me for information and then I did a fair amount of work based on that request under the assumption that he was going to actually be helpful or useful instead of just redirect or say not my problem

[crowlogic]

If you want something done right you got to do it yourself, The Golden rule

[ennerf]

Eclipse has a tiny market share and none of the maintainers use it themselves. If there were a clear error message it'd be one thing, but the error is not particularly useful either. This issue also doesn't affect regular users, and I'm unclear why you need to build from an IDE in the first place.

[crowlogic]

I've fixed this error, it was indeed a problem with chartfx. The issue is that AbstractDataSet depends on Measurable which is in the bench project. If the bench project is not imported, this class is not available. Perhaps there is a module dependency not declared properly somewhere

[crowlogic]

@ennerf it boggles the mind how you could NOT build from the IDE. Nonetheless, your comments about "regular users" not withstanding, the issue is indeed one where your subpar IDEs are not exact enough to expose this error that was swept under the rug by this inferior IDEs. There are only two industries who call people users, drug pushers, and software developers.

[ennerf]

>> mvn dependency:tree --pl chartfx-dataset
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------< io.fair-acc:dataset >-------------------------
[INFO] Building chartfx-dataset master-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ dataset ---
[INFO] io.fair-acc:dataset:jar:master-SNAPSHOT
[INFO] +- io.fair-acc:bench:jar:master-SNAPSHOT:compile
[INFO] ... others ...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.063 s
[INFO] Finished at: 2023-12-18T11:42:39+01:00
[INFO] ------------------------------------------------------------------------

From the maven docs on the compile scope:

This is the default scope, used if none is specified. 
Compile dependencies are available in all classpaths of a project. 
Furthermore, those dependencies are propagated to dependent projects.

The dependency definition is valid according to the Maven spec, so there is no error here. That being said, we can specify the dependency explicitly to work around this apparent bug in Eclipse. Thanks for finding it.

There are only two industries who call people users, drug pushers, and software developers.

That's just nonsense 🤷‍♂️ Any tooling company refers to customers as users, and at the end of the day Software is just another tool.

[crowlogic]

Strangely, mvn:dependencies sees it, but eclipse doesnt pick it up unless its explicitly specified as required in the module-info. It could be a bug in m2e or perhaps related to a DTD parsing error being strict in one implementation and not the other, I've seen this as a cause of related problems before. I guess you aren't wrong there, you gotta call it something i guess. Thanks for humoring me, im grumpy as hell my eyes hurt my neck hurts half the time

when i add requires transitive io.fair_acc.bench;

the dependency:tree command remains the same but it makes eclipse happy.

The benefit of building from within the IDE is that changes are recompiled immediately when the file is saved and one doesn't have to waste time building and installing

[INFO] --------------------------< org.arblib:arb4j >-------------------------- [INFO] Building arb4j 0.8 [INFO] --------------------------------[ jar ]--------------------------------- [INFO] [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ arb4j --- [INFO] org.arblib:arb4j:jar:0.8 [INFO] +- org.ow2.asm:asm:jar:9.5:compile [INFO] +- org.ow2.asm:asm-util:jar:9.5:compile [INFO] | +- org.ow2.asm:asm-tree:jar:9.5:compile [INFO] | - org.ow2.asm:asm-analysis:jar:9.5:compile [INFO] +- org.slf4j:slf4j-jdk14:jar:2.0.7:compile [INFO] | - org.slf4j:slf4j-api:jar:2.0.7:compile [INFO] +- org.openjfx:javafx-base:jar:20.0.2:compile [INFO] | - org.openjfx:javafx-base:jar:linux:20.0.2:compile [INFO] +- org.openjfx:javafx-swing:jar:20.0.2:compile [INFO] | +- org.openjfx:javafx-swing:jar:linux:20.0.2:compile [INFO] | - org.openjfx:javafx-graphics:jar:20.0.2:compile [INFO] | - org.openjfx:javafx-graphics:jar:linux:20.0.2:compile [INFO] +- org.openjfx:javafx-fxml:jar:20.0.2:compile [INFO] | +- org.openjfx:javafx-fxml:jar:linux:20.0.2:compile [INFO] | - org.openjfx:javafx-controls:jar:20.0.2:compile [INFO] | - org.openjfx:javafx-controls:jar:linux:20.0.2:compile [INFO] +- com.massisframework:j-text-utils:jar:0.3.4:compile [INFO] | +- com.google.guava:guava:jar:21.0:compile [INFO] | +- commons-lang:commons-lang:jar:2.6:compile [INFO] | - au.com.bytecode:opencsv:jar:2.4:compile [INFO] +- org.scilab.forge:jlatexmath:jar:1.0.7:compile [INFO] | +- org.scilab.forge:jlatexmath-font-greek:jar:1.0.7:compile [INFO] | - org.scilab.forge:jlatexmath-font-cyrillic:jar:1.0.7:compile [INFO] +- io.fair-acc:chartfx:jar:11.3.0:compile [INFO] | +- org.kordamp.ikonli:ikonli-javafx:jar:12.3.1:compile [INFO] | | - org.kordamp.ikonli:ikonli-core:jar:12.3.1:compile [INFO] | +- org.kordamp.ikonli:ikonli-fontawesome-pack:jar:12.3.1:compile [INFO] | +- org.kordamp.ikonli:ikonli-fontawesome5-pack:jar:12.3.1:compile [INFO] | +- io.fair-acc:dataset:jar:11.3.0:compile [INFO] | +- io.fair-acc:math:jar:11.3.0:compile [INFO] | | +- com.github.wendykierp:JTransforms:jar:3.1:compile [INFO] | | | - pl.edu.icm:JLargeArrays:jar:1.5:compile [INFO] | | - org.apache.commons:commons-math3:jar:3.6.1:compile [INFO] | +- ar.com.hjg:pngj:jar:2.1.0:compile [INFO] | +- org.hdrhistogram:HdrHistogram:jar:2.1.12:compile [INFO] | +- org.apache.commons:commons-lang3:jar:3.13.0:compile [INFO] | - org.jetbrains:annotations:jar:24.0.1:compile [INFO] +- io.fair-acc:bench:jar:11.3.0:compile [INFO] +- ch.qos.logback:logback-classic:jar:1.2.3:compile [INFO] | - ch.qos.logback:logback-core:jar:1.2.3:compile [INFO] +- org.controlsfx:controlsfx:jar:11.1.2:compile [INFO] - junit:junit:jar:4.13.2:compile [INFO] - org.hamcrest:hamcrest-core:jar:1.3:compile

[RalphSteinhagen]

@crowlogic, it's good that you seem to have isolated the root cause and workaround for your problem.

The Eclipse IDE implemented its own maven integration, which is known for having some non-conformities. Maybe you could let the good folks at Eclipse know that there is a non-conformity or even provide a patch to fix it there: https://github.com/eclipse-m2e/m2e-core/issues.

[wirew0rm]

when i add requires transitive io.fair_acc.bench;

Oh, I guess we are talking about different modules, maven modules have nothing to do with JPMS/jigsaw modules. The later unfortunately was still a big mess when I last tried to add proper support for it to chart-fx. The only way to really do that is to only use dependencies that are also fully modularized (or complicated maven plugins that essentially shard them and patch them to be modularized in the process). Do you need to use jigsaw for anything specific (e.g. jlink)? Otherwise you could probably just put chart-fx on the classpath instead of the module path and be good...

[crowlogic]

yes, it works great now why would I do that? There are other modules too, like the kind that are vector spaces without the requirement that the elements by fields but can be any ring which is a bit more general.

i'll see if i can incoporate these upstream because I do forsee using graalvm to make native versions for both javafx apps and headless operations

if I had a dime for every time said someone said the term "at the end of the day" as if they are some arbiter of the flow of time or something... @RalphSteinhagen

[ennerf]

There are other modules too, like the kind that are vector spaces without the requirement that the elements by fields but can be any ring which is a bit more general.

Sorry, but I'm lost as to what that means 🤷‍♂️

I do forsee using graalvm to make native versions for both javafx apps and headless operations

GraalVM does not care about jigsaw modules. It already works. See JavaFX w/ GraalVM native image.

[crowlogic]

In your message, you mention two concepts: mathematical modules and GraalVM's compatibility with JavaFX. Let's address these separately for clarity.

Modules (in mathematics): The statement about modules being "vector spaces without the requirement that the elements be fields but can be any ring" refers to a concept in abstract algebra. In mathematics, a vector space requires its operations to be over a field (like real or complex numbers), where every non-zero element has a multiplicative inverse. A module relaxes this requirement. Instead of a field, it operates over a ring, where such inverses are not guaranteed. This makes modules a more general concept than vector spaces.

GraalVM and JavaFX: Regarding GraalVM, your statement is correct. GraalVM is designed to be compatible with various Java modules, including those used in JavaFX. This compatibility means that GraalVM can efficiently compile JavaFX applications into native code, improving performance. The fact that it "does not care about jigsaw modules" implies that GraalVM can handle these without specific adjustments or configurations, streamlining the process of creating native applications.

p.s. i see noticed you referred me to a video rather than documentation about the topic.. why? videos are a terrible format for anything except porn thats why the internet was invented :-)

[ennerf]

In your message, you mention two concepts: mathematical modules

No. You responded to a comment about Jigsaw Modules with unrelated stuff about mathematical modules. How am I supposed to guess that you switched to a completely unrelated topic? The next line read like you expect issues with GraalVM and Jigsaw modules.

i see noticed you referred me to a video rather than documentation about the topic.. why? videos are a terrible format for anything except porn thats why the internet was invented :-)

I linked to a video on my personal YouTube channel that shows a complex application built with JavaFX and ChartFX that was compiled to a GraalVM native image. That is proof that it works, and that I likely have the ability to help you in case anyone runs into problems with native compilation. There is no documentation because nobody has ever asked me about it.

I'm done talking to you.