<classpathentry kind="con" path="com.gwtplugins.gwt.eclipse.core.GWT_CONTAINER">
<attributes>
<attribute name="module" value="true"/>
</attributes>
</classpathentry>
<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 vas...@gmail.com 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...VassilisOn Thu, Oct 24, 2024 at 7:43 PM Bob Lacatena <B...@lacatena.net> 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 google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/b2259293-b34e-48bb-9ae7-22425ebb9d69n%40googlegroups.com.
--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 google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/5857a12f-fb1e-40ee-a38f-a808f14c1cfen%40googlegroups.com.
No comments:
Post a Comment