Thus spake “Brent Easton”:
Hmm. This is strange. It works fine for me, though it is necessary to have
a Vengine.jar build in order for me to run VASSAL.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Ok, probably just an Eclipse problem. I has had problems trying to create a new Branch which might be related also. I’ll try deleting the branch and everything and starting again.
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Brent Easton”:
The one thing I can say for sure (because I checked) is that nothing in the
repository refered to the JAR I renamed, xerces_2_5_0.jar, by name—except
the Vengine.jar manifest, which is rebuilt from the list of JARs in lib/
each time Vengine.jar is made anyway. (The reason I renamed that JAR is that
something referred to it by the name it was supposed to have, which, because
it didn’t have that name, prevented the jar tool from building the
INDEX.LIST.)
Does Eclipse keep an explicit list of JARs for your Classpath, or does it
keep a wildcard, like ‘lib/*’? If the former, then maybe your Classpath
is just stale.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Does anyone know what may be causing this when I try to run in Eclipse? I checked out the Beta4 tag.
-- OS Windows Vista
-- Java version 1.6.0_03
-- VASSAL version 3.1.0-beta4
[1925147184]
java.lang.ExceptionInInitializerError
at VASSAL.launch.Main.launch(Main.java:202)
at VASSAL.launch.Main.extractResourcesAndLaunch(Main.java:94)
at VASSAL.launch.Main$1$1.run(Main.java:80)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Thus spake “bsmith”:
You’re trying to use Main as the entry point. Main isn’t the entry point
anymore. ModuleManager is the entry point for general use. If you’re
trying to debug the Editor or Player, you can use Editor or Player as
the entry point, but that’s there for debugging purposes only.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
I fixed this by moving XercesImpl.jar to the start of the Order and Export section of the Build Path Properties.
Excellent! Thanks Ben, that has fixed it for me also.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Since the last few fixes w/ DP and part palettes most of everything has cleared out of my error log since 4376.
I am still getting one error upon startup which is not prompting the bug dialog and do not see any discernable effects - everything is running perfectly so do not feel it is critical but post for later reference should any one happen to come across or know why while fixing things:
1225822758703 1988471273 – Loading module file C:\Documents and Settings\Administrator\Desktop\Combat Commander 1-90beta.vmod
1225822758703 1988471273 – Loading module Combat Commander
1225822758703 1988471273 C:\Program Files\Java\jre1.6.0_06\bin\java -Xms512M -Xmx1024M -cp lib\Vengine.jar;Vengine.jar VASSAL.launch.Player
1225822758843 302725757 – Starting
1225822758859 302725757 – OS Windows 2003
1225822758859 302725757 – Java version 1.6.0_06
1225822758859 302725757 – VASSAL version 3.1.0-svn4376
1225822758859 302725757 – Player
1225822768046 302725757 – Combat Commander version 1.90
1225822768046 302725757
1225822768296 302725757 Extension 1. Combat Commander - Mediterranean v1.90 loaded
1225822768296 302725757
1225822768765 302725757 Extension 2. Battle Pack 0 - European Nations v1.90 loaded
1225822768765 302725757
1225822768859 302725757 Extension 3. Battle Pack 1 - Paratroopers v1.90 loaded
1225822768859 302725757
1225822769000 302725757 Extension 4. Combat Commander - Pacific v1.90 loaded
1225822769000 302725757
1225822777968 302725757java.io.IOException: closed
at javax.imageio.stream.ImageInputStreamImpl.checkClosed(Unknown Source)
at javax.imageio.stream.ImageInputStreamImpl.close(Unknown Source)
at javax.imageio.stream.FileCacheImageInputStream.close(Unknown Source)
at VASSAL.tools.IOUtils.closeQuietly(IOUtils.java:381)
at VASSAL.tools.memmap.MappedImageUtils.loadImage(MappedImageUtils.java:79)
at VASSAL.tools.memmap.MappedImageUtils.getImage(MappedImageUtils.java:28)
at VASSAL.tools.imageop.SourceOpMappedBitmapImpl.eval(SourceOpMappedBitmapImpl.java:50)
at VASSAL.tools.imageop.SourceOpMappedBitmapImpl.eval(SourceOpMappedBitmapImpl.java:32)
at VASSAL.tools.opcache.OpCache.getFuture(OpCache.java:307)
at VASSAL.tools.opcache.OpCache.get(OpCache.java:250)
at VASSAL.tools.opcache.AbstractOpImpl.get(AbstractOpImpl.java:79)
at VASSAL.tools.imageop.AbstractOpImpl.getImage(AbstractOpImpl.java:109)
at VASSAL.tools.imageop.ScaleOpBitmapImpl$TileOp.eval(ScaleOpBitmapImpl.java:167)
at VASSAL.tools.imageop.ScaleOpBitmapImpl$TileOp.eval(ScaleOpBitmapImpl.java:112)
at VASSAL.tools.opcache.OpCache$Request.doInBackground(OpCache.java:186)
at org.jdesktop.swingworker.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at org.jdesktop.swingworker.SwingWorker.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Thus spake “Tim M”:
This happens because FileCacheImageInputStream.close() throws an IOException
if the stream is already closed. This is rather addled, since there’s no
way provided to check if one has already been closed and it doesn’t follow
the convention for InputStreams, on which you can call close() as much as
you like.
I added a terribly ugly hack to IOUtils to get around this, in trunk@4377.
Check any build after svn4377 to see whether this still happens, and let
me know.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)