To generally resolve cases like this, your IDE's build should be informed directly by your actual build files, rather than maintaining the IDE build separately. That ensures that the classpaths in the IDE directly match what the CI system or manual builds would produce, and keeps all developers on the same page, without the need for each to manually apply settings or check in build and IDE changes separately.
Build tools usually have their own features to hunt down transitive dependencies: mvn dependencies:tree, or gradle :dependencies would give you a hierarchical view of how transitive dependencies end up on your classpaths (though not, as you were initially suspicious of, how a class could be contributed from more than one jar). On Thursday, October 24, 2024 at 3:10:31 PM UTC-5 [email protected] wrote: > Okay, my bad. I looked for one class but not necessarily the right one. > There is another culprit, log4j2 core, that is using a commons IO class > (FileUtils), so that is likely the source of the problem. > > Sorry for wasting your time... but thanks very much for the quick > response, and if nothing else, giving me a wrist slap to make me look more > closely at what I'm doing. [I never made these kinds of mistakes when I > was younger.] > > On Thursday, October 24, 2024 at 4:05:20 PM UTC-4 Bob Lacatena wrote: > >> So, yeah, that's why it compiles fine on the build server and on my Mac >> from using javac / Java command line. I don't have gwt-dev.jar in my class >> paths there. And I don't have it explicitly in the Eclipse class path, but >> I am presuming it is implicitly there (and is the problem) because of >> course I have this: >> >> <classpathentry kind="con" >> path="com.gwtplugins.gwt.eclipse.core.GWT_CONTAINER"> >> <attributes> >> <attribute name="module" value="true"/> >> </attributes> >> </classpathentry> >> >> Or am I making a bad assumption here... does the problem/conflict lie >> elsewhere? >> >> Another data point... I did not have this problem last week. I haven't >> looked at that project for a week or so, and when I updated it (pull from >> GitHub) this compile issue cropped up, but I can find no change anyone else >> made remotely related to this, and everyone else (on Windows, I'm on a Mac) >> does not have the compile problem. >> >> Last data point... I let Eclipse apply updates this week, so it upgraded >> me to 2024-09 and who knows what else. >> >> I hate this black-box stuff. Worst problems in the world to try to >> fix... things where you can't entirely look under the hood (into what's >> actually going on in Eclipse) to see what is really going on. >> On Thursday, October 24, 2024 at 3:27:56 PM UTC-4 Colin Alworth wrote: >> >>> Vassilis is correct - definitely avoid placing either gwt-dev.jar or >>> gwt-user.jar on your server classpath. Ideally, one can do this by >>> splitting your server and client classpaths (into separate projects) - >>> eclipse should then keep jars for one out of the classpath for the other. >>> >>> GWT currently uses commons-io 2.4 in the compiler itself. There are a >>> number of out of date dependencies in the compiler, but as above, these >>> should never be deployed to your server, and should only present a risk if >>> you provide untrusted data to the compiler - that is, if your project's own >>> source and dependencies are themselves untrusted. >>> >>> On Thursday, October 24, 2024 at 2:21:02 PM UTC-5 [email protected] >>> wrote: >>> >>>> I think that you aren't supposed to include gwt-dev.jar in any >>>> classpath (frontend or backend). It is required for compilation and >>>> super-dev mode. >>>> >>>> I can understand the infighting with eclipse settings though and I >>>> sympathize... >>>> >>>> Vassilis >>>> >>>> On Thu, Oct 24, 2024 at 7:43 PM Bob Lacatena <[email protected]> wrote: >>>> >>>>> I've been working on a project for a while (posted a related problem >>>>> some time back) to convert our massively complex software from Java 8 to >>>>> Java 17. >>>>> >>>>> Almost everything is done, but a recurring problem, one that just >>>>> reared its head again this morning, as to do with jar conflicts. [I am >>>>> so >>>>> angry with the Java architects for "fixing" the version problem in such >>>>> an >>>>> intractable, unmanageable way...] >>>>> >>>>> The problem occurs when another jar (in this case gwt-dev.jar) embeds >>>>> other class files (in this case org.apache.commons.io) that are >>>>> otherwise used in our software. >>>>> >>>>> Some questions: >>>>> >>>>> 1) What version of commons-io is it within gwt-dev.jar? >>>>> 2) Is it all of the classes, or only the classes needed/referenced by >>>>> gwt-dev code? >>>>> 3) Has anyone else had this problem and found a good solution? >>>>> >>>>> Approaches I am going to try are: >>>>> >>>>> 1) Match our commons IO version to the one in gwt-dev (this bothers >>>>> me, because there may be a lot of recoding on my end) and remove the >>>>> commons-io jar from our classpath. >>>>> 2) If that doesn't work, then also rebuild the gwt-dev jar without the >>>>> commons-io (this won't work until I match our commons IO version to the >>>>> one >>>>> gwt-dev.jar embeds). >>>>> 3) Beg you to solve this problem for me somehow. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "GWT Users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/google-web-toolkit/b2259293-b34e-48bb-9ae7-22425ebb9d69n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/google-web-toolkit/b2259293-b34e-48bb-9ae7-22425ebb9d69n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> Vassilis Virvilis >>>> >>> -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/f4a30c32-ab5d-4ac3-a16e-eada196f0cean%40googlegroups.com.
