Errors in parser project, Campaign type can't be determined

[Rumble]

Couple of things with the latest MapTool from the repository:

First, I can't get parser to build - I have a raft of errors (24 of them; things like "ASSIGNEE cannot be resolved" and so forth). I don't know what I'm missing; I checked out the trunk folder under "parser" in the RPTools SVN.

Second, and perhaps related to the first, if I run the dev version anyway (in spite of the warning about parser errors), I can't load any campaigns - it says "Campaign format cannot be determined."

[Azhrei]

Couple of things with the latest MapTool from the repository:

First, I can't get parser to build - I have a raft of errors (24 of them; things like "ASSIGNEE cannot be resolved" and so forth). I don't know what I'm missing; I checked out the trunk folder under "parser" in the RPTools SVN.

Oh, crud. That's not good.

I just closed everything except the parser project (also have trunk checked out) and I get 54 warnings but no errors. I remember something about the ASSIGNEE stuff, though. Some issue with a library...

Which project/source directory is being reported on the errors? It would be the Resource & Path columns in the Problems view.

The problem could be the build path for MapTool not including the parser project. What I had to do was remove the parser-1.1.b20.jar from the build path of MT, then specify that the parser project was a dependent. Ditto for the rplib library and project.

If anyone here knows a better way to do this I'd love to hear about it. I think there should be some way to specify an environment variable that contains a classpath location. It would either point to the project build dir if the project is open, or to the library in maptool/lib if the project is closed. That would be ideal, IMO.

Second, and perhaps related to the first, if I run the dev version anyway (in spite of the warning about parser errors), I can't load any campaigns - it says "Campaign format cannot be determined."

I searched all of my projects and cannot find that string anywhere. Could it be different from that quote? I did find this string, "Cannot determine campaign file format; not loaded" -- was that it?

Please check your log.txt. There should be a message of "Could not load campaign in the current format, trying old format". That means what you think it means. It's probably because of the use of some older code from the parser project.

We need to figure out why your parser project won't build. I'm sure it's a classpath issue with a missing JAR file or something.

If you want, we can get on Vent or something and go through it. PM me with a time that's good for you and we can go through and compare screens and such to see what might be different.

[Rumble]

Once again, I'm at work now and can't give it a shot, but I'll check that stuff out at home (if I remember ). I'm sure it's a classpath issue; I'm only vaguely sure how all the build intricacies work so I may have changed, deleted, or otherwise altered something (or perhaps something didn't update properly).

As for the campaign format thing, it is the string you found - I misremembered the exact error message, but that was it. I'll sort out a couple things this evening and then report back anything unusual.

[Rumble]

Okay, after the most recent update, I get build path errors on a synchronization, but if I reorder the libraries and force it to rebuild, it works fine. Go figure.

[Azhrei]

Okay, after the most recent update, I get build path errors on a synchronization, but if I reorder the libraries and force it to rebuild, it works fine. Go figure.

I'd like to hear more about this, if possible. Can you Team > Update again and see if it changes anything?

I had to build the parser library again (1.1.b22) so that required that I turn off my project dependencies and add the JARs to my build path in order to test with those JARs. Maybe I had done the Team > Commit with the various projects in an inconsistent configuration? Maybe JARs were in the build path along with the projects? Or something else funky?

Perhaps you still have the projects in your build path along with the JARs?

I do want this to be as painless as possible for someone else to just check out the source code and start playing with it...

[Rumble]

Just ran a new update and this time, after a couple update cycles (to make sure I got everything) it built without any errors. I think (now that you mention it) I had both the jars and the projects in the build path previously - could that have been the issue?

[jfrazierjr]

I do want this to be as painless as possible for someone else to just check out the source code and start playing with it...

If you have enough Ant knowledge, I would highly suggest making the default target(and a second target that does the "official RPTools release build") one that does not invoke the pack200 stuff and build the jnlp file. Some people may have just enough knowledge to attempt to build with Ant, but not enough knowledge to fix the issues that come up(and I don't want to modify the Ant project file locally and keep having it overwritten.

[Azhrei]

I'd be happy to review any patches to the build file if you'd like to submit them.

I'm very familiar with makefiles and ANT is basically an MXL-based version of the same, but with a lot of built-in "tasks". It's the details on the tasks that I'm not familiar with.

That might be a good solution for the last phase of testing. It's more convenient when debugging to have the project dependency so that changes in a library are immediately picked up and I don't have to generate a JAR. But for initial stages of testing, the JAR would be better.

I also thought of creating another project using the same workspace location, but I don't think I'd be able to have two separate Eclipse projects in the same directory since I don't get to choose the name of the project configuration file (the .project file). After all, if it could be selected how would Eclipse know where to find it when the project was opened? Another possibility might be a separate project, but with the source and build directories specified to be the directory of the original project... Just no time to test all the possibilities and (possibly) screw something up.