Wannabe VASSAL developer has setup question

I am trying to check-out the VASSAL code to Eclipse with subversion, according to the tutorial here
http://www.vassalengine.org/wiki/Eclipse_setup
but am not getting the expected results. I attempted to checkout src-VASSAL/trunk as suggested in the tutorial, but I get a Package Explorer that looks much different from that shown in the tutorial: I have many times more children of VASSAL,Pieter that expected, and the ones with similar names have the prefix “src.”. I get thousands of errors even after making recommanded setup changes to the Java Build Path. Can someone help me out by pointing out my stupid mistake?

I am an experienced developer, but new to JAVA, Eclipse, and subversion, as my experience tends towards SQL/VB/C with RCS or VSS.

Thank you in advance.

Oh yes - I am running Windows Vista Home Premium SP2 with 3GB RAM, and Eclipse Helios (build 20100617-1415). I have the 1.6JDK for Java downloaded. I have attempted to checkout both VASSAL-src/trunk and VASSAL-src/tags/v3_1_14 - though the latter downloads faster, I see no significant difference in the top level structure between them, and the error count is nearly identical.

Thus spake pgeerkens:

Oh yes - I am running Windows Vista Home Premium SP2 with 3GB RAM, and
Eclipse Helios (build 20100617-1415). I have the 1.6JDK for Java
downloaded. I have attempted to checkout both VASSAL-src/trunk and
VASSAL-src/tags/v3_1_14 - though the latter downloads faster, I see no
significant difference in the top level structure between them, and the
error count is nearly identical.

What errors are you seeing? It’s hard to help you without knowing that.


J.

AboutScreen cannot be resolved to a type Documentation.java /VASSAL-v3_1_14/src/VASSAL/build/module 6 times
AboutWindow cannot be resolved to a type AboutScreen.java /VASSAL-v3_1_14/src/VASSAL/build/module/documentation *4
AbstractBuildable cannot be resolved to a type BrowserHelpFile.java /VASSAL-v3_1_14/src/VASSAL/chat/ui

on for 16, 018 errors

Thus spake pgeerkens:

AboutScreen cannot be resolved to a type Documentation.java
/VASSAL-v3_1_14/src/VASSAL/build/module 6 times
AboutWindow cannot be resolved to a type AboutScreen.java
/VASSAL-v3_1_14/src/VASSAL/build/module/documentation *4
AbstractBuildable cannot be resolved to a type BrowserHelpFile.java
/VASSAL-v3_1_14/src/VASSAL/chat/ui

on for 16, 018 errors

Eclipse is clearly not finding the class files. I don’t know what to
tell you beyond that. One of the developers who uses Eclipse might be
able to help you more.


J.

OK. I got the errors down to 226 (+ 187 warnings) by right-clicking src.VASSAL:
Refactoring → Rename to VASSAL
with
Update References =Y
and
Rename Packages=Y

My errors now look like:
ActivePeer cannot be resolved to a type P2PClient.java /VASSAL-v3_1_14/VASSSL/chat/peer2peer * 1
ActivePeerManager cannot be resolved to a type P2PClient.java /VASSAL-v3_1_14/VASSSL/chat/peer2peer * about 12
BuildException cannot be resolved to a type WriteProperties.java /VASSAL-v3_1_14/dist/ant * 4
etc

By continuing the refactoring sensibly *, I am now down to 4 errors, but they look like real ones to me:

VASSAL.PieceMover cannot be resolved in PieceSLot.java * 2
VASSAL.Properties cannot be resolved to a variable in SavedGameUpdater.java * 2

If anyone can help with these last 2*2 errors I would greatly appreciate it.

Pieter

  • And I added ant.jar as an external library.

Thus spake pgeerkens:

By continuing the refactoring sensibly, I am now down to 4 errors, but
they look like real ones to me:

VASSAL.PieceMover cannot be resolved in PieceSLot.java * 2
VASSAL.Properties cannot be resolved to a variable in
SavedGameUpdater.java * 2

If anyone can help with these last 2*2 errors I would greatly appreciate
it.

If those are the full class names you have now, what you’ve done has
completely demolished the package structure we’re using. This is not
the right way to get Eclipse set up to work on VASSAL.


J.

Thus spake pgeerkens:

By continuing the refactoring sensibly, I am now down to 4 errors, but
they look like real ones to me:

VASSAL.PieceMover cannot be resolved in PieceSLot.java * 2
VASSAL.Properties cannot be resolved to a variable in
SavedGameUpdater.java * 2

If anyone can help with these last 2*2 errors I would greatly appreciate
it.

I think I know what your problem is: You have the wrong build path set.
Go to the Properties dialog for your project. Select “Java Build Path”,
and look under the Source tab. If the directory where your working
copy from SVN is is called VASSAL-v3_1_14 (as it appears to be from the
error messagese you posted), then you should have “VASSAL-v3_1_14/src”
listed in that tab. If you don’t, that could be preventing Eclipse from
getting the right build root.


J.

Aha! That got it. Thank you very much.

I just read this, and something is quite odd. Could you post a screenshot
of what your IDE looks like, especially the package browser with VASSAL
expanded.

  • M.

On 24 September 2010 16:38, pgeerkens pgeerkens@hotmail.com wrote:

Aha! That got it. Thank you very much.

I just read this, and something is quite odd.� Could you post a screenshot of what your IDE looks like, especially the package browser with VASSAL expanded.

- M.

On 24 September 2010 16:38, pgeerkens <pgeerkens@hotmail.com> wrote:

Aha! �That got it. Thank you very much.

Here it is, after applying J.'s thoughts

[attachment=1]Eclipse.PNG[/attachment]

I checked out tag 3.1.14 for this one, as I figured it would be easiest to debug compilation errors on a known clean build.
Here is the amended Jave Build Path as well:

[attachment=0]Eclispse2.PNG[/attachment]

You don’t need to add ant.jar as a library.

After you set the src directory as the source folder, all you need to do is
ensure that the libraries in lib are in the libraries tab of the Java Build
Path dialog.

That should be it. That should compile fine.

  • M.

On 24 September 2010 19:56, pgeerkens pgeerkens@hotmail.com wrote:

[This message has been edited.]

Here it is, after applying J.'s thoughts

Eclipse.PNG

I checked out tag 3.1.14 for this one, as I figured it would be easiest
to debug compilation errors on a known clean build.
Here is the amended Jave Build Path as well:

Eclispse2.PNG

Read this topic online here:
https://forum.vassalengine.org/t/wannabe-vassal-developer-has-setup-question/3301/12


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

You don’t need to add ant.jar as a library.

After you set the src directory as the source folder, all you need to do is ensure that the libraries in lib are in the libraries tab of the Java Build Path dialog.


That should be it.� That should compile fine.

- M.

On 24 September 2010 19:56, pgeerkens <pgeerkens@hotmail.com> wrote:

[This message has been edited.]

Here it is, after applying J.'s thoughts

Eclipse.PNG

I checked out tag 3.1.14 for this one, as I figured it would be easiest
to debug compilation errors on a known clean build.
Here is the amended Jave Build Path as well:

Eclispse2.PNG

_______________________________________________
Read this topic online here:
https://forum.vassalengine.org/t/wannabe-vassal-developer-has-setup-question/3301/12
_______________________________________________
messages mailing list
[messages@vassalengine.org](mailto:messages@vassalengine.org)
[vassalengine.org/mailman/listinfo/messages](http://www.vassalengine.org/mailman/listinfo/messages)



I should also point out that the trunk is not really guaranteed to compile.
Try checking out branches/3.1 and see if you can get that to compile first.

  • M.

On 24 September 2010 20:45, Michael Kiefte mkiefte@dal.ca wrote:

You don’t need to add ant.jar as a library.

After you set the src directory as the source folder, all you need to do is
ensure that the libraries in lib are in the libraries tab of the Java Build
Path dialog.

That should be it. That should compile fine.

  • M.

On 24 September 2010 19:56, pgeerkens pgeerkens@hotmail.com wrote:

[This message has been edited.]

Here it is, after applying J.'s thoughts

Eclipse.PNG

I checked out tag 3.1.14 for this one, as I figured it would be easiest
to debug compilation errors on a known clean build.
Here is the amended Jave Build Path as well:

Eclispse2.PNG

I should also point out that the trunk is not really guaranteed to compile.� Try checking out branches/3.1 and see if you can get that to compile first.

- M.

On 24 September 2010 20:45, Michael Kiefte <mkiefte@dal.ca> wrote:

You don't need to add ant.jar as a library.

After you set the src directory as the source folder, all you need to do is ensure that the libraries in lib are in the libraries tab of the Java Build Path dialog.


That should be it.� That should compile fine.

- M.

On 24 September 2010 19:56, pgeerkens <pgeerkens@hotmail.com> wrote:

[This message has been edited.]

Here it is, after applying J.'s thoughts

Eclipse.PNG

I checked out tag 3.1.14 for this one, as I figured it would be easiest
to debug compilation errors on a known clean build.
Here is the amended Jave Build Path as well:

Eclispse2.PNG

Thank you Michael - I have removed ant.jar again.

Yes I have switched to tags/3_1_14 to be sue of a clean snapshot, and will migrate from there as my comfort level improves.

PG

Thus spake Michael Kiefte:

I should also point out that the trunk is not really guaranteed to compile.
Try checking out branches/3.1 and see if you can get that to compile first.

Ken complains at me rather quickly when it doesn’t compile, so it’s almost
always in a state where it compiles. There’s no guarantee that it works.


J.

This comment got me thininking about a complex reporting and analysis application that I was lead developer on back in the '90’s. Using the macro facility we built the means to automatically run every test case which had been submitted as a previous bug. This was launched every night upon completion of a complete build of FDA (the reporting/analysis product), with it’s output going to individually named files for each test case. The UNIX diff facility ran comparison of each test case against the preserved standard output for each test case, and all non-zero comparisons were emailed to me at 8:00 in the morning, waiting for me when I arrived at 8:30.

This process allowed us to catch every regression of a previously reported defect in TEST. For over three years the team continued to enhance this product without ever regressing a previously reported defect into PRODUCTION.

By adhering to a discipline where we built everything from the bottom up, almost always in small steps which could be checked-in each evening, any regressions found in TEST were invariably simple to cure because of always being the result of the previous days work.

So my thought of the day is - Are there any portions of VASSAL that would be amenable to this treatment? The key features of the process are:

  • a means to automate the performance of user tasks with the software; and
  • a means (XML?) to output the results of that in a text format which can be diff’'ed against a previously captured correct output.

Thus spake pgeerkens:

This comment got me thininking about a complex reporting and analysis
application that I was lead developer on back in the '90’s. Using the
macro facility we built the means to automatically run every test case
which had been submitted as a previous bug. This was launched every
night upon completion of a complete build of FDA (the reporting/analysis
product), with it’s output going to individually named files for each
test case. The UNIX diff[i] facility ran comparison of each test case
against the preserved [i]standard
output for each test case, and all
non-zero comparisons were emailed to me at 8:00 in the morning, waiting
for me when I arrived at 8:30.

This process allowed us to catch every regression of a previously
reported defect in TEST. For over three years the team continued to
enhance this product without ever regressing a previously reported
defect into PRODUCTION.

By adhering to a discipline where we built everything from the
bottom up, almost always in small steps which could be checked-in each
evening, any regressions found in TEST were invariably simple to cure
because of always being the result of the previous days work.

So my thought of the day is - Are there any portions of VASSAL that
would be amenable to this treatment? The key features of the process
are:

  • a means to automate the performance of user tasks with the software;
    and
  • a means (XML?) to output the results of that in a text format which
    can be diff’'ed against a previously captured correct output.

Basically what you’re talking about is a unit testing and continuous
integration framework. VASSAL is using JUnit for unit testing, but we’re
right at the beginning of writing tests. We’re writing tests for all new
code, but we have heaps of old code which is in desperate need of tests.
If you’d like to help us write tests, that would be quite welcome.

If you look at the trunk, our tests are under the test/ directory. Right
now, Ken Stevens is heading up writing tests for old code. Hopefully this
will get his attention, and he’ll comment on where you might start.

(BTW, have you registered at SF yet? I can’t add you as a developer until
you do that.)


J.

I have now registered at SourceForge, as “pgeerkens”.

P.