New developer

Hi,

I have contacted Joel via SourceForge to become a developer (as bobd91) but I thought that I would raise it here as well as I have some questions.

I have been doing Java since 1996, though not so much in the last few years, but I haven’t been involved in Open Source before or the sort of distributed development that involves.

What branch should I fix bugs against and is there a naming convention for branches that I should follow?
Is this forum the main place for developer discussion?
Is there a difference between the bug list on SourceForge and the Vassal tracker?
After I have addressed the bugs that affect me, is it best to work on 3.1 bugs or is there anything I can do to help get 3.2 ready?

Thanks,
Bob

There isn’t really any formal documents on branch naming conventions that I remember, but in general we have just been using our names, possibly hyphenated with what the branch purpose is, for example “bobd-bugfixes3.1”. When you look in the repository under VASSAL-src/branches you’ll see what I mean.

Most discussions take place here.

There should be no difference between the two trackers except for the assigned feature request/bug number. I think the preference is to work/update out of the Vassal tracker so all info/comments stays on vassal server instead of SF’s.

Joel will have to answer your last question. You may want to review the roadmap to see what the plan is (somewhat)

vassalengine.org/wiki/Roadmap

Thus spake bobd:

Hi,

I have contacted Joel via SourceForge to become a developer (as bobd91)
but I thought that I would raise it here as well as I have some
questions.

I sent this in reply, but it bounced:

Hi, Bob. I don’t have time to get you started this evening; I’ll
see what I can do later in the week.


J.

Sorry about that Joel, I had my sourceforge email prefs set incorrectly, it works now.

Thus spake Tim M:

There should be no difference between the two trackers except for the
assigned feature request/bug number. I think the preference is to
work/update out of the Vassal tracker so all info/comments stays on
vassal server instead of SF’s.

Please, please, please do not make changes in the SF bug tracker. The
only reason it’s there at this point is to serve as a backup of what
goes into our Bugzilla instance. If you do modify what’s in the SF
tracker, chances are nobody will ever see it.

Now that we’ve mostly settled in to using Bugzilla, I’m planning to turn
off the SF bug tracker, in order to avoid any confusion. (I just haven’t
made it that far yet.)


J.

Thus spake Tim M:

There isn’t really any formal documents on branch naming conventions
that I remember, but in general we have just been using our names,
possibly hyphenated with what the branch purpose is, for example
“bobd-bugfixes3.1”. When you look in the repository under
VASSAL-src/branches you’ll see what I mean.

Bob,

If you’re going to work on bug fixes (which I strongly encourage),
you should branch from the 3.1 branch.

The best thing you can do right now is help us squash bugs on the 3.1
branch. Getting into the 3.2 branch before I get it returned to a
functional state (which might happen this week, if I can get things
around here to settle down) will only be frustrating.

If you look here, you can see which bugs have been reported the most:

vassalengine.org/tracker/duplicates.cgi

The top two are both VASL bugs. If you have any interest in VASL, I’m
sure people would appreciate having those looked into. Bugs marked as
External are not ours—in most cases, these are bugs in Java that
we’re waiting on to be fixed—so there’s little or nothing we can do
about them. Otherwise, any bug you can fix (or even just determine the
cause of) is progress, but the more duplicates there are, the more
valuable it is to us to squash the bug. (Consider that we have to
spend time looking at bug reports, determining whether they’re dupes,
etc., so the faster we can eliminate commonly reported bugs, the more
time we can spend on other things.)


J.

I wonder which 3.1 branch should be taken. Should it be the one labeled as “3.1 7548”? I am a bit confused because I noticed that its parent folder is labeled as “branches 7656”. If so, where is this 7656 build?

Lance

Thus spake lancel:

I wonder which 3.1 branch should be taken. Should it be the one labeled
as “3.1 7548”? I am a bit confused because I noticed that its parent
folder is labeled as “branches 7656”. If so, where is this 7656 build?

The second number is the last revision which affected that directory
tree. In this case, it means that the last commit to the 3.1 branch was
revision 7548, while the last commit to any branch was 7656. (The branch
where that commit was happens to be uckelman-working2, which is where
I’m working on 3.2.)


J.

Hi,
I just checked out the source from “3.1 7663” branch and noticed that I got 8 Access restriction errors on DataArchive.java and MemoryUtils.java on opening the Package Explorer within Eclipse. Has anyone else seen them?

The errors are something like this:

Access restriction: The constructor AppletAudioClip(byte[]) is not accessible due to restriction on required library C:\Program Files\Java\jre6\rt.jar.

All other errors have the same rt.jar error. I wonder if I missed downloading something. (I can post a screenshot if necessary.)

Lance

Thus spake lancel:

Hi,
I just checked out the source from “3.1 7663” branch and noticed that I
got 8 Access restriction errors on DataArchive.java and MemoryUtils.java
on opening the Package Explorer within Eclipse. Has anyone else seen
them?

The errors are something like this:

Access restriction: The constructor AppletAudioClip(byte[]) is not
accessible due to restriction on required library C:\Program
Files\Java\jre6\rt.jar.

AppletAudioClip is a Sun-private thing, which will be disappearing
at some point in the future. When I build from the command line, I
only get a warning about this, not an error.

What are the other classes it tells you are problematic?


J.

Joel,
The other errors from the MemoryUtils.java file are similar to the one below:
Access restriction: The method getTotalPhysicalMemorySize() from the type OperatingSystemMXBean is not accessible due to restriction on required library C:\Program Files\Java\jre6\rt.jar.
Lance

Thus spake lancel:

Joel,
The other errors from the same MemoryUtils.java are similar to the one
below:
Access restriction: The method getTotalPhysicalMemorySize() from the
type OperatingSystemMXBean is not accessible due to restriction on
required library C:\Program Files\Java\jre6\rt.jar.
Lance

I think this page has your answer:

lkamal.blogspot.com/2008/09/ecli … brary.html

In the long run, we need to stop using both of those classes.

For the latter one, if you know of a library which will tell us the
amount of installed RAM on the system—one which works on all platforms
we support—I’d be happy to start using it.


J.

Thanks. That took out the error message. I then moved on according to vassalengine.org/wiki/Eclipse_setup. I got into the following classNotfoundException error for “java.lang.NoClassDefFoundError: add” when I ran the ModuleManager. Something missing in my classpath setup?

Lance

Thus spake lancel:

Thanks. That took out the error message. I then moved on according to
vassalengine.org/wiki/Eclipse_setup[1]. I got into the
following classNotfoundException error for
“java.lang.NoClassDefFoundError: add” when I ran the ModuleManager.
Something missing in my classpath setup?

Is that the complete error message?


J.

The stacktrace is below:

Vassal[Java Application] C:\Program Files\Java\jre6\bin\javaw.exe (Mar 18, 2011 11:12:10 AM)

java.lang.NoClassDefFoundError: add
Caused by: java.lang.ClassNotFoundException: add
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Exception in thread “main”

Lance

Please ignore. I got a different error in the beginning. After addressing that, I did not refresh the project before rebuilding. I just did that and I have no problem building the ModuleManager.

Thanks.

Lance

Thus spake lancel:

The stacktrace is below:

Vassal[Java Application] C:\Program
Files\Java\jre6\bin\javaw.exe (Mar 18, 2011 11:12:10 AM)

java.lang.NoClassDefFoundError: add
Caused by: java.lang.ClassNotFoundException: add
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Exception in thread “main”

What are you trying to run when that happens? That stack trace never
makes it into our code. I’m guessing you have a typo in your Eclipse
settings somewhere, as “add” isn’t the name of any class we have.


J.

I was just trying to run the ModuleManager. Everything being the same, the error was gone after I refreshed the project. I think this weird error came up because of the corrupted state of my workspace after I manually deleted the output folder. It is now fine without any problems.

Lance