How to become a Vassal developper

It should be in the /lib-src path already

-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of zov66
Sent: Saturday, July 30, 2011 10:25 AM
To: messages@vassalengine.org
Subject: [messages] [Developers] Re: How to become a Vassal developper

Eclipse is likely not finding lib-nondist/AppleJavaExtensions.jar.

Okay, so how can I tell Eclipse to find this jar?

I did a search on my system and could not find it either.

Do I need to SVN down this?

code.google.com/p/jalbum-jtextpa … ppleJavaEx
tensions.jar?r=5


Read this topic online here:
https://forum.vassalengine.org/t/how-to-become-a-vassal-developper/4103/20

Thus spake zov66:

Eclipse is likely not finding lib-nondist/AppleJavaExtensions.jar.

Okay, so how can I tell Eclipse to find this jar?

I did a search on my system and could not find it either.

Do I need to SVN down this?

code.google.com/p/jalbum-jtextpa … pleJavaExt
ensions.jar?r=5

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.


J.

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.

How does this compare with what you have?

Here is my screen shot:

Here is another screen shot:

Thus spake zov66:

Here is another screen shot:

[1]

[1] i286.photobucket.com/albums/ll11 … lipse2.jpg

Have you verified that AppleJavaExtensions.jar is listed in the
Libraries tab of the Java Build Path pane of the Properties dialog
for the project?


J.

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

Here is two screen shots:

at line error

hover over error

close but not quite their yet…

Thus spake zov66:

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.


J.

Joel,

Fair point.

Any ideas on my last 4 errors in ASL-src per the screen shots above?

Thus spake zov66:

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

The immediate cause is that all of the memory-mapped images code,
including MappedBufferedImage, no longer exists in the trunk.

The correct way to get a map image is to get an ImageOp using
Op.loadLarge(), and then to call getImage() on that ImageOp to get
a BufferedImage.

However, if you’re planning to do anything with that BufferedImage
other than immediately display it, you should encapsulate whatever
further processing your going to do in another ImageOp, as otherwise
you’re bypassing the image cache. E.g., it looks like after line 377
that the BufferedImage is cropped and scaled, which should be done
using CropOp and ScaleOp.


J.

Joel,

Oh, okay that sounds fine and all but all I am trying to do is to get VASSAL to complie in Eclipse. So I am not even coding anything yet.

So my basic question is since that this is old code or whatever, can I just delete it, comment it out or what?

Again, just trying to get the SVN down (which I did) and for it to work (compile) in Eclipse (which is wont).

Basically following directions that are old and not working correctly.

Thus spake zov66:

Joel,

Oh, okay that sounds fine and all but all I am trying to do is to get
VASSAL to complie in Eclipse. So I am not even coding anything yet.

So my basic question is since that this is old code or whatever, can I
just delete it, comment it out or what?

Again, just trying to get the SVN down (which I did) and for it to work
(compile) in Eclipse (which is wont).

Basically following directions that are old and not working correctly.

If you’re tring to compile VASL against the trunk as-is, that can’t
possibly work, because the trunk no longer contains some things which
VASL uses. If all you want is for VASL to compile, then you could do
that by commenting out the offending code—but presumably that code is
not intended to be a no-op, so you won’t produce a program which works
properly this way, just one that compiles.

Alternatively, I believe that VASL will compile against the 3.1 branch
of VASSAL without modification. However, this is only a short-term
solution. Someone will eventually need to update the VASL code to work
with the trunk.


J.

Okay, so basically one can’t download each one of the trunks and expect them to work as is. So that means then that the project is broke. So I need to SVN down only the branches and they should all work?

Kind of confusing, seems like one could download (SVN) down the trunk and it should compile with out all these issues and then add in the branches.

Still new to all this, the documentation is slim at best and so it’s confusing to say the least.

So I need to delete all that I have SVN down and only SVN down the branches correct? And that will cure everything?

Thus spake zov66:

Okay, so basically one can’t download each one of the trunks and expect
them to work as is.

Not together, no. They’re not synchronized. The VASSAL trunk is ahead
of the VASL trunk.

So that means then that the project is broke. So I
need to SVN down only the branches and they should all work?

No. There are likely to be many branches which don’t work.

Kind of confusing, seems like one could download (SVN) down the trunk
and it should compile with out all these issues and then add in the
branches.

I think you’re misunderstanding what the branches are. For VASSAL, each
branch started as a copy of the trunk at some point in the past. They’re
not meant to work together—each one is a complete copy of VASSAL.

So I need to delete all that I have SVN down and only SVN down the
branches correct? And that will cure everything?

The VASL trunk should compile aginst the VASSAL 3.1 branch.


J.

Okay, so still no go for some reason. I downloaded (SVN) VASSAL trunk (not sure which branch it is it was the default one so whatever version that is) and then the VASL trunk. This fails. So now I need to figure out somehow which VASSAL 3.1 branch to SVN and then get the VASL trunk again or something like that?

man this is confusing, the getting started does not work, NetBeans does not like SVN with VASSAL and Eclipse fails with the docs so far.

By the time I figure this all out it will be outdated and everyone will be using C++ … lol oh well…

Thus spake zov66:

Okay, so still no go for some reason. I downloaded (SVN) VASSAL trunk
(not sure which branch it is it was the default one so whatever version
that is) and then the VASL trunk. This fails. So now I need to figure
out somehow which VASSAL 3.1 branch to SVN and then get the VASL trunk
again or something like that?

There is only one 3.1 branch. It’s located at VASSAL-src/branches/3.1.


J.

Okay VASSAL full (the whole trunk) and VASSAL 3.1 branch are all okay it’s the VASL (ASL) piece I am having issues with.

So no problems with VASSAL full (trunk) nor the VASSAL 3.1 branch. But ASL is hosed.

Any ideas?

Now the errors are :

Description Resource Path Location Type
AndFilter cannot be resolved to a type JabberClient.java /dlazov - VASSAL 3.1 Branch/src/VASSAL/chat/jabber line 576 Java Problem

100 errors…

There just has to be an easier way then all this mess, even at work which is thousands of programs, web aps, junit it’s not as crazy nor unorganized as trying to get this to work.

There should be an easier way for someone to SVN down the code and for it to compile without a fellow writing one line of code…

Have you set the Build Path correctly and set your Project references correctly?

The 3.1 Vassal branch project must be referenced in the Projects section of the VASL project.

Have you included all of the libray jars in the lib folder of the 3.1 branch in your build path for the project?

That error you are referring to in JabberClient.java is an error in VASSAL, not VASL. AndFilter is found in Smack.jar in the lib folder.

Thus spake zov66:

There should be an easier way for someone to SVN down the code and for
it to compile without a fellow writing one line of code…

The instructions are in the wiki. You could update them once you get
things working.


J.