Moving on with deployment and build handling

[uckelman]

Thus spake Flint1b:
>
> But for other, arbitary strings it is the other way round:
> * 2.0.1-xyz > 2.0.1
> * 2.0.1-xyz-80 > 2.0.1
>
> Why do we need to order these like that, shouldn't the alpha/beta/rc
> identifiers be enough?

Those "other things" are test builds, generally, and we've historically
treated them as being in the run-up to the next version rather than
something tailing after the previous version. We could just name them
as "SNAPSHOT", I suppose. As I said, it makes little difference how
inter-release versions sort against one another.

--
J.

[Flint1b]

All right, I'll proceed with putting the ComparableVersion into our code then.

[Flint1b]

Pushed a new commit into PR #114, removed some bits of code.. This whole version number code is Vassal's internals and modules don't depend on it, don't they?

[Flint1b]

The maven repository thing is in master, can we make a first "alpha1" release, "maven-only jar/src-jar/javadoc-jar" release, for internal use only, no one but us needs to know? Put a first working version into our own maven repository and allow us to test how modules would pull the maven dependency, and create a first working template module project?

[uckelman]

Thus spake Flint1b:
> Pushed a new commit into PR #114, removed some bits of code.. This whole
> version number code is Vassal's internals and modules don't depend on
> it, don't they?

No modules that I can see.

--
J.

[uckelman]

I've started a Maven repo for us on our site: http://www.vassalengine.org/maven/

It has 3.3.3-alpha1 in it, which I've tagged so we have something to put there.

[Flint1b]

The "release" of vassal-parent needs to be there as well, vassal-app depends on it. Maven must be able to find all the parents of any pom.xml because their content is inherited by the children. It's like with class inheritance, the subclasses don't work without the superclass.

[Flint1b]

Looks good now.

I have created a module template project under https://github.com/yanlyub/vassal-module-template, it's probably best to copy that into a new GitHub repo under github.com/vassalengine.

[Flint1b]

With many checkstyle checks already in place and protecting the code formatting from further degradation, I think the time has come to tackle the more serious issues.

I have added "SpotBugs" as a Maven plugin, this is a static code analyzer tool and the successor of the widely used "FindBugs". In the initial configuration it will run in Maven's "test" phase after the unit tests, report violations of the most severe kind, and not break the build. A local run shows 122 violations of this kind, they look reasonably dangerous and fairly easy to fix.

Examples are static fields which should be final but are not, assignment to static fields from instance methods (bad singleton pattern implemented in a bad way for a double-bad result ), dereference of null pointers, unreachable code, self assignment of variables, fields masking fields with the same name in a superclass, non-thread-safe static fields like DateFormat, tests for floating-point equality.

Assignment to static fields from instance methods is particularly fun, have a look at this little gem, SpotBug's category name "scary" is very appropriate for potential bugs like these:

Code: Select all

new GlobalOptions().addTo(null);

The change is in PR #153.

[uckelman]

Thus spake Flint1b:
>
> I have added "SpotBugs" as a Maven plugin, this is a static code
> analyzer tool and the successor of the widely used "FindBugs". In the
> initial configuration it will run in Maven's "test" phase after the unit
> tests, report violations of the most severe kind, and not break the
> build. A local run shows 122 violations of this kind, they look
> reasonably dangerous and fairly easy to fix.

It's merged.

--
J.