Okay at work I was able to install svn, cvs, eclipse and get the vassal
to download the trunk. Here at home not quite so lucky.
You don’t need CVS installed. That’s a completely different version
control system, one which were not using.
I am getting this error when in eclipse and trying to access the svn:
Failed to load JavaHL Library.
These are the errors that were encountered:
C:\csvn\bin\libapr-1.dll: Can’t load IA 32-bit .dll on a AMD 64-bit
platform
This tells me that you’re trying to run 32-bit libraries on a 64-bit
machine.
Okay have two versions of eclipse setup (EE & Java SE). Currently using Java SE and have svn setup correctly now and was able to svn down the src. I followed the instructions on the setting up eclipse page but something is still wrong.
My setup looks like:
dlazov - VASSAL
dlazov - ASL
CASL
VSQL
VASSAL is showing 38 errors with the first showing:
Access restrictions: The constructor AppletAudioClip(by…required library C:\Program Files\Java\jre6\lib\rt.jar
So that both the VASSAL & ASL are red X and the CASL & VSQL are red !
When I look in the Libraries folder for CASL ad VSQL it shows:
So not I get 30 errors like:
Description Resource Path Location Type
Application cannot be resolved MacOSXMenuManager.java /dlazov - VASSAL/src/VASSAL/tools/menu line 65 Java Problem
When I go into that src file (MacOSXMenuManager.java it basically says:
Multiple markers at this line
- Application cannot be resolved
- Application cannot be resolved to a type
I am still a newbie java developer so any help here?
The instructions in the vassal wiki are really out of date
I cant comment on CASL setup but VSQL being red should be ok or at least
don’t worry about that directory - (VASSAL directory should be the main
thing to get fixed). The VSQL directory is no longer used for just Squad
Leader - it also holds all of the custom classes for different modules.
Okay have two versions of eclipse setup (EE & Java SE). Currently using
Java SE and have svn setup correctly now and was able to svn down the
src. I followed the instructions on the setting up eclipse page but
something is still wrong.
My setup looks like:
dlazov - VASSAL
dlazov - ASL
CASL
VSQL
VASSAL is showing 38 errors with the first showing:
Access restrictions: The constructor AppletAudioClip(by…required
library C:\Program Files\Java\jre6\lib\rt.jar
So that both the VASSAL & ASL are red X and the CASL & VSQL are red !
When I look in the Libraries folder for CASL ad VSQL it shows:
So not I get 30 errors like:
__
Description Resource Path Location Type
Application cannot be resolved MacOSXMenuManager.java /dlazov -
VASSAL/src/VASSAL/tools/menu line 65 Java Problem__
When I go into that src file (MacOSXMenuManager.java it basically says:
__Multiple markers at this line
Application cannot be resolved
Application cannot be resolved to a type__
I am still a newbie java developer so any help here?
Eclipse is likely not finding lib-nondist/AppleJavaExtensions.jar.
No, it’s in the lib-nondist directory of VASSAL-src/trunk and any
branch which is less than three years old. If you don’t have it, then
your working copy is hosed.
I should first note that I am not an Eclipse user. The sole reason why
I’ve set up Eclipse myself is so I can see what other people see when
they use it. That said:
I’m going to take some screenshots for you so you can see what I have
and compare that with what you have.
I have checked out two subtrees of the svn repo, uckelman-3.2 and uckelman-working, which you can see in the first screenshot.
[attachment=2]eclipse-1.png[/attachment]
This is what I see when I bring up the Properties dialog on the uckelman-3.2 branch, with the “Subversion” pane selected:
[attachment=1]eclipse-2.png[/attachment]
You can see there that I’ve not checked out the whole repository, but a particular branch from VASSAL-src/branches/.
The next screenshot shows the “Java Build Path” pane in the same dialog. In order for the compiler to find all of the libraries we use, they need to be listed in the “Libraries” tab.
[attachment=0]eclipse-3.png[/attachment]
The one that you’re missing, AppleJavaExtensions.jar, happens to be the first one displayed here.
Has anyone had success with Netbeans? I am not that familar with NetBeans, but I am attempting to SVN down the VASSAL engine code now.
I know that the ‘new’ direction for VASSAL 4 is C++ (which is kind of ironic, I used to be a C/C++ programmer and in 2004 I could not find any jobs doing that, so just this year I switched to java, did some C# from 2006 to 2009 or so off and on). Java obviously is platform independent so not sure why you would want to screw with that by going to C++ which in general is platform dependent, at least to most of my past knowledge.
At any rate I do like Eclipse it is what we use at work and now that I downloaded NB7 and Java7 NB7 is pretty neat as well.
Interesting, that lib was not listed, the instructions only indicated setting the lib jars, after I added the lib-nondist that removed all but 4 errors.
Okay, I then added that to the out put and did a clean and VASSAL is okay now. But CASL was complainign about a 1.5 JRE which I don’t have (only have 1.6 and 1.7) so I just removed that and then CASL has a black thing in it but it looks okay. Now ASL is complaining with 4 errors.
MappedBufferedImage cannot be resolved to a type
ASLBoard.java
/dlazov - ASL/src/VASL/build/module/map/boardPicker
line 377
Java Problem
I know that the ‘new’ direction for VASSAL 4 is C++ (which is kind of
ironic, I used to be a C/C++ programmer and in 2004 I could not find any
jobs doing that, so just this year I switched to java, did some C# from
2006 to 2009 or so off and on). Java obviously is platform independent
so not sure why you would want to screw with that by going to C++ which
in general is platform dependent, at least to most of my past knowledge.
Sun claimed, and now Oracle claims, that Java is platform-independent.
The only interpretation I can see under which this could be true is that
they mean that classes compiled by their Java compiler will run in any of
their JVMs. This is such a weak claim as to be useless, as we care about
the classes’ behavior, not just that they’ll run. If they’re claiming that
you can expect classes to have the same behavior on different platforms,
then that’s simply false—some don’t. I’d point to our ImageIOImageLoader
class as evidence for this—it’s 350 lines of workarounds for the various
ways in which Java’s ImageIO image loaders are broken, some of which
affect only certain platforms. We also have 30+ locations in our trunk
where we do OS checks in order to get correct behavior. No C++ project
I’ve worked on has had so much platform-specific code (or code for
working around broken libraries) as VASSAL does.