How to set up my development environment for Vassal 3.3.0?

Development
#1

I’m just getting started with the Vassal 3.3.0 code and trying to get an initial compile on my Ubuntu 18.04.4 LTS machine. I’ve cloned the code from the git repo.

One of the requirements mentioned in the Readme is launch4j. I’ve cloned its code from github, but it fails to compile due to java swing stuff. (I see that there’s a Maven repo for Launch4j, but it doesn’t seem like that will be much use for Vassal, since it isn’t using maven.)

I’ll also want to create Apple DMG installers, so I’m trying to compile the libdmg-hflplus library. Since I have run Vassal on my Mac, using the dmg installer, I assume that someone here has fixed the problems and gotten the library to compile. Can you tell me how you did that? Does it get installed somewhere in /usr/local?

So, bottom line… Is there someplace where the instructions for setting up a development environment are available? There are obviously folks out there that have done it.

Thanks,
Thom

#2

I am very new here myself, but I got it to compile and run on my Ubuntu with IntelliJ with these steps:

  • Open the project in IntelliJ, the general structure with the src, libs, libs-nondist and tests was found automagically by IntelliJ
  • In File->Settings->Java Compiler, deactivate “Use ‘–release’ option”, and at the bottom in “Override compiler parameters per-module” add this:
--add-exports java.desktop/sun.java2d.cmm=ALL-UNNAMED
  • this should be sufficient to build the project successfully, to run it I simply run the main() method in VASSAL.launch.ModuleManager

The Makefile has the above mentioned compiler option and several more of them in line 70, but these other options don’t seem to be necessary to run the application from inside the IDE.

This is obviously not the full development cycle, I don’t know how to produce release builds or these apple dmg files, but it seems to be a C project written in Java, the code looks like C and uses C-style idioms, and uses make as the build system.

#3

Thus spake Flint1b:

This is obviously not the full development cycle, I don’t know how to
produce release builds or these apple dmg files, but it seems to be a C
project written in Java, the code looks like C and uses C-style idioms,
and uses make as the build system.

‘make release’ is how I produce releases. You can’t realistically do that
without being on a Unix machine, due to the Makefile and all the tooling
it requires.

Specifically, making the DMGs requires genisoimage and the dmg tool
from libdmg-hfsplus (the latter of which you might have to compile
yourself).

I remember getting to the point where we could produce DMGs at all was a
long process of trial and error. There are not a lot of examples out there
of how to do it without using Apple’s tools on a Mac.

–
J.

#4

Things have improved in the recent years, it might make sense to look into:

#5

I’ve been trying to teach myself the Gradle build tools by trying to get VASSAL building with it.
I’m trying to recreate all functionality inside the MakeFile first… But I can post my results (once I have any), or create a PR against the github repo if it’s of any help.

#6

Note there is an only-slightly-out-of-date article here in the wiki about how to get Vassal to build on Eclipse:
vassalengine.org/wiki/Eclipse_setup

Obviously other IDE’s will vary, but if you’re already a java person you shouldn’t have too much trouble. You could also consider pulling down the stable 3.2.17 branch and getting that to build before worrying about Trunk and 3.3, although of course that means building for the earlier version of Java.

#7

Thus spake Flint1b:

Things have improved in the recent years, it might make sense to look
into:

From what I can see, javapackager was removed from Java 11, apparently
replaced by jpackage. The jpackage man page I have for Java 14 has
lots of Windows and Mac options, which it says can be used only on
Windows and Mac.

This one seems unable to cope with any of the JDKs I’ve supplied it.

This one looks like it has to be run on OS X.

–
J.

#8

Thus spake pixelpshr:

One of the requirements mentioned in the Readme is launch4j. I’ve cloned
its code from github, but it fails to compile due to java swing stuff.
(I see that there’s a Maven repo for Launch4j, but it doesn’t seem like
that will be much use for Vassal, since it isn’t using maven.)

I’ve used the precompiled launch4j for quite a long while now. You can
download that here:

launch4j.sourceforge.net/

I’ll also want to create Apple DMG installers, so I’m trying to compile
the libdmg-hflplus library. Since I have run Vassal on my Mac, using the
dmg installer, I assume that someone here has fixed the problems and
gotten the library to compile. Can you tell me how you did that? Does it
get installed somewhere in /usr/local?

What problems exactly did you encounter? I don’t recall having to modify
the source for dmg to get it to compile. I didn’t bother installing it
after compiling it; I’ve been running it from the source directory all
this time.

–
J.

#9

Oh my, I didn’t realize that deployment is such a problem on desktops. I assume it’s not an option to just deliver a jar and a shell script or .bat file that runs it with the proper parameters, and tell the users to have a JRE installed, unzip the package and run the script? No installers, just like in the linux package? This is the only way I would want to run a Java application and I even had to mess with the shell script to get 3.2 to run on my linux, but I assume I am a very special kind of user in that respect. And doesn’t a jar file run when double-clicked, so the shell script or .bat file could be even dropped to not confuse the users?

And the jpackage, I see now that it needs to run on the target platform in order to package for that platform, I don’t have access to a Windows or Mac but surely some of the developers have a Windows and a Mac and could do the packaging? Or how is Vassal and its deployment on Win/Mac tested by the developers? Also there is some extra code for a Mac (ugh… in a platform-independent language), how is this tested if none of the developers have access to a Mac?

#10

Thus spake Flint1b:

Oh my, I didn’t realize that deployment is such a problem on desktops.

Server-side Java and deskop Java are quite far apart. It’s like being
in a building which is so large that you can be happily working at one
end while the other end is on fire.

I
assume it’s not an option to just deliver a jar and a shell script or
.bat file that runs it with the proper parameters, and tell the users to
have a JRE installed, unzip the package and run the script?

The reason we put together a Windows installer in the first place was to
head off all the problems users had with getting set up. The reason we
had the installer check if Java was installed and download and install it
if now was to head off all the problems users had with getting set up.
The reason we’re bundling Java with 3.3 is—wait for it—to head off
all the problems users had with getting set up.

It is hard to convey the diversity and quanitiy of installation issues
I’ve seen users have. I would never have beleived it had I not seen it
happen myself. Minimizing the ways that things can be screwed up will
always pay us back in time and reputation, so it’s worth it.

No
installers, just like in the linux package? This is the only way I would
want to run a Java application and I even had to mess with the shell
script to get 3.2 to run on my linux, but I assume I am a very special
kind of user in that respect. And doesn’t a jar file run when
double-clicked, so the shell script or .bat file could be even dropped
to not confuse the users?

A JAR won’t run when double-clicked if you don’t have Java installed,
or if you don’t have Java installed correctly. Of course, that would
not be our fault, but we nonetheless get blamed for it when it happens.

I would be interested to know how you had to modify the shell script,
as my intent was that no one would need to do that.

And the jpackage, I see now that it needs to run on the target platform
in order to package for that platform, I don’t have access to a Windows
or Mac but surely some of the developers have a Windows and a Mac and
could do the packaging? Or how is Vassal and its deployment on Win/Mac
tested by the developers? Also there is some extra code for a Mac
(ugh… in a platform-independent language), how is this tested if
none of the developers have access to a Mac?

I have both Windows and Mac VMs here. I test things in them. I have zero
interest in firing them up just to build a package. That’s a massive waste
of time. I sometimes build a package a dozen time in an evening. I must be
able to produce a package in the environment in which I’m developing.

I hate to tell you, but Java’s never been platform-independent on the
desktop, both because different JDKs have have different bugs and because
desktop envionments just differ in ways that are hard to paper over.

–
J.

#11

I understand. I am used to work with legacy code and “legacy developers” who have learned Java in a 2 week course 20 years ago and keep producing legacy code to this day. Guess I can be glad to not have to deal with legacy users professionally.

Nothing out of the ordinary, my default JVM was too modern to run 3.2 so I changed the call to java to point explicitly to a JVM 8:

$ diff VASSAL.sh VASSAL-oldjdk.sh 
11c11
< java -Duser.dir="$INSTALL_DIR" -classpath "$INSTALL_DIR"/lib/Vengine.jar VASSAL.launch.ModuleManager "$@"
---
> /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Duser.dir="$INSTALL_DIR" -classpath "$INSTALL_DIR"/lib/Vengine.jar VASSAL.launch.ModuleManager "$@"

I know, it’s terrible, I gave up the hope of all platform-independency after having worked with a JVM for IBM z/OS mainframes, with necessary calls to native C and even Cobol libs, and handling code for IBM DB2 deadlocks that is all over the codebase. “Let’s abstract away the DB layer so we can change the underlying DB any time we want”… yea, sure.

#12

Thus spake Flint1b:

Nothing out of the ordinary, my default JVM was too modern to run 3.2 so
I changed the call to java to point explicitly to a JVM 8:

Ah, I see. That’s ok. That’s not the sort of change I was worried about.

–
J.

#13

Perhaps it’s more like a dumpster fire at the other end… :unamused:

-Thom

#14

Ah, ok. I cloned the repo from github and tried to compile it myself. I’m sure that downloading the precompiled jar file will work better.

I cloned the repo from github.com/planetbeing/libdmg-hfsplus as this seems to the be master of all the forks that I’ve found. The most recent change was in Feb of 2018.

The Readme says the are 3 CLI components to build.

HFS+:
It says to cd into hfs and run make. It skipped over the part about cmaking the Makefile. After doing that, I ran make:

$ make [ 14%] Built target common [ 21%] Building C object hfs/CMakeFiles/hfs.dir/btree.c.o [ 28%] Building C object hfs/CMakeFiles/hfs.dir/catalog.c.o [ 35%] Building C object hfs/CMakeFiles/hfs.dir/extents.c.o [ 42%] Building C object hfs/CMakeFiles/hfs.dir/fastunicodecompare.c.o [ 50%] Building C object hfs/CMakeFiles/hfs.dir/flatfile.c.o [ 57%] Building C object hfs/CMakeFiles/hfs.dir/hfslib.c.o [ 64%] Building C object hfs/CMakeFiles/hfs.dir/rawfile.c.o [ 71%] Building C object hfs/CMakeFiles/hfs.dir/utility.c.o [ 78%] Building C object hfs/CMakeFiles/hfs.dir/volume.c.o [ 85%] Linking C static library libhfs.a [ 85%] Built target hfs [ 92%] Building C object hfs/CMakeFiles/hfsplus.dir/hfs.c.o /home/tdecarlo/git/libdmg-hfsplus/hfs/hfs.c: In function ‘cmd_attr’: /home/tdecarlo/git/libdmg-hfsplus/hfs/hfs.c:138:17: warning: implicit declaration of function ‘attrFile’; did you mean ‘newFile’? [-Wimplicit-function-declaration] attrFile(argv[1], argv[2], volume); ^~~~~~~~ newFile [100%] Linking C executable hfsplus [100%] Built target hfsplus

It looks like there were build errors, but it also looks like it built the hflplus executable.

DMG:
The Readme says he bundled a version of zlib (v1.2.3) in the dmg directory, but there is no such thing in the repo. However, Unbuntu 18.04.4 has zlib1g v1.2.11 available, so I installed that.

Skipping the part about compiling zlib, I cded into dmg and ran make:

$ make [ 8%] Built target common [ 48%] Built target hfs [ 52%] Building C object dmg/CMakeFiles/dmg.dir/adc.c.o [ 56%] Building C object dmg/CMakeFiles/dmg.dir/base64.c.o [ 60%] Building C object dmg/CMakeFiles/dmg.dir/checksum.c.o [ 64%] Building C object dmg/CMakeFiles/dmg.dir/dmgfile.c.o [ 68%] Building C object dmg/CMakeFiles/dmg.dir/dmglib.c.o [ 72%] Building C object dmg/CMakeFiles/dmg.dir/filevault.c.o In file included from /home/tdecarlo/git/libdmg-hfsplus/dmg/filevault.c:6:0: /home/tdecarlo/git/libdmg-hfsplus/includes/dmg/filevault.h:82:11: error: field ‘hmacCTX’ has incomplete type HMAC_CTX hmacCTX; ^~~~~~~ /home/tdecarlo/git/libdmg-hfsplus/dmg/filevault.c: In function ‘fvClose’: /home/tdecarlo/git/libdmg-hfsplus/dmg/filevault.c:180:2: warning: implicit declaration of function ‘HMAC_CTX_cleanup’; did you mean ‘HMAC_CTX_get_md’? [-Wimplicit-function-declaration] HMAC_CTX_cleanup(&(info->hmacCTX)); ^~~~~~~~~~~~~~~~ HMAC_CTX_get_md /home/tdecarlo/git/libdmg-hfsplus/dmg/filevault.c: In function ‘createAbstractFileFromFileVault’: /home/tdecarlo/git/libdmg-hfsplus/dmg/filevault.c:237:2: warning: implicit declaration of function ‘HMAC_CTX_init’; did you mean ‘HMAC_CTX_new’? [-Wimplicit-function-declaration] HMAC_CTX_init(&(info->hmacCTX)); ^~~~~~~~~~~~~ HMAC_CTX_new dmg/CMakeFiles/dmg.dir/build.make:182: recipe for target 'dmg/CMakeFiles/dmg.dir/filevault.c.o' failed make[2]: *** [dmg/CMakeFiles/dmg.dir/filevault.c.o] Error 1 CMakeFiles/Makefile2:182: recipe for target 'dmg/CMakeFiles/dmg.dir/all' failed make[1]: *** [dmg/CMakeFiles/dmg.dir/all] Error 2 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2

The Readme had warned about failures in the filevault stuff, but it implied that the build could get past it. That’s not what I found.

Since the hdutil depends on the dmg, I did not try to go any farther.

#15

Thus spake pixelpshr:

I cloned the repo from github.com/planetbeing/libdmg-hfsplus[2]
as this seems to the be master of all the forks that I’ve found. The
most recent change was in Feb of 2018.

The Readme says the are 3 CLI components to build.

This worked for me:

git clone github.com/planetbeing/libdmg-hfsplus.git
cd libdmg-hfsplus
mkdir build
cd build
cmake …
make

Trying to build the the three components separately is not how it’s
intended to work, from what I can see.

It looks like there were build errors, but it also looks like it built
the hflplus executable.

That’s just a warning. The build was successful.

DMG:
The Readme says he bundled a version of zlib (v1.2.3) in the dmg
directory, but there is no such thing in the repo. However, Unbuntu
18.04.4 has zlib1g v1.2.11 available, so I installed that.

That looks like outdated documentation. It ought to be possible to link
with the zlib you have installed. I linked against 1.2.11 on my system.

Skipping the part about compiling zlib, I cded into dmg and ran make:

See above; I think you should build from the root of the repo.

Code:
$ make
[ 8%] Built target common
[ 48%] Built target hfs
[ 52%] Building C object dmg/CMakeFiles/dmg.dir/adc.c.o
[ 56%] Building C object dmg/CMakeFiles/dmg.dir/base64.c.o
[ 60%] Building C object dmg/CMakeFiles/dmg.dir/checksum.c.o
[ 64%] Building C object dmg/CMakeFiles/dmg.dir/dmgfile.c.o
[ 68%] Building C object dmg/CMakeFiles/dmg.dir/dmglib.c.o
[ 72%] Building C object dmg/CMakeFiles/dmg.dir/filevault.c.o
In file included from
/home/tdecarlo/git/libdmg-hfsplus/dmg/filevault.c:6:0:
/home/tdecarlo/git/libdmg-hfsplus/includes/dmg/filevault.h:82:11: error:
field ‘hmacCTX’ has incomplete type
HMAC_CTX hmacCTX;

That’s a struct which is part of openssl. I’ll bet you don’t have the
development files for openssl installed. (There’s probably an
openssl-devel package or something like that on Ubuntu.)

–
J.

messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages

#16

Ah, there seems to be a problem with OpenSSL versions. My Ubuntu 18.04.4 had openssl 1.1.0 installed. There were some breaking changes introduced when they moved from v0.9.x to v1.1.x. I had to make some changes to the filevault.[c|h] files in dmg to account for them. There may be pull requests in some of the other libdmg-hfsplus forks that fix the problem, but I wouldn’t know which to choose and which might eventually get incorporated into the main project (if any ever gets included).

But at any rate, the libdmg-hfsplus stuff has compiled now. It’s time to try the rest of the vassal code again!

#17

I’ve gotten a little further, but there seems to be an issue in the module-info.java file. In particular, the compiler is reporting an error in the “requires jl1.0.1” line. It’s having heartburn with the dots in that module name. I cannot find anything in the javazoom.net/jlayer documentation to show what the module should be called.

Also, I’m getting 100 errors (I think that’s just where it stopped counting) saying that it found certain packages in more than one module. I’ve commented out several of the “requires” lines and got it to stop complaining about that.

So now I’m just down to smack and jl1.0.1 modules not found.

#18

Thus spake pixelpshr:

I’ve gotten a little further, but there seems to be an issue in the
module-info.java file. In particular, the compiler is reporting an error
in the “requires jl1.0.1” line. It’s having heartburn with the dots in
that module name. I cannot find anything in the javazoom.net/jlayer
documentation to show what the module should be called.

I don’t know what file module-info.java is. That’s not one of ours.

jl1.0.1.jar, smack.jar, and smackx.jar are in lib/.

–
J.

#19

Well, that’s kind of scary… :open_mouth:

#20

Thus spake pixelpshr:

“uckelman” wrote:

I don’t know what file module-info.java is. That’s not one of ours.

Well, that’s kind of scary… :open_mouth:

No, seriously. Where are you finding this file? What’s in it?

–
J.