Create account / Log in

Moving on with deployment and build handling

Discussion area for the development team.

Moderators: uckelman, Tim M

Re: Moving on with deployment and build handling

Postby uckelman » July 22nd, 2020, 11:54 pm

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.
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Moving on with deployment and build handling

Postby Flint1b » July 22nd, 2020, 11:57 pm

All right, I'll proceed with putting the ComparableVersion into our code then.
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby Flint1b » July 23rd, 2020, 12:46 am

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?
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby Flint1b » July 24th, 2020, 11:59 am

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?
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby uckelman » July 25th, 2020, 10:41 pm

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.
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Moving on with deployment and build handling

Postby uckelman » July 26th, 2020, 3:21 pm

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.
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Moving on with deployment and build handling

Postby Flint1b » July 26th, 2020, 4:55 pm

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.
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby Flint1b » July 26th, 2020, 5:21 pm

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.
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby Flint1b » August 4th, 2020, 1:14 pm

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 :D), 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.
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby uckelman » August 4th, 2020, 9:28 pm

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.
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Previous

Return to Developers

Who is online

Users browsing this forum: No registered users and 1 guest