SimMath - Vec3i contribution

I’m planning to improve @pspeed’s SimMath’s Vec3i class. However, to do so, I need to do “refresh” a few things.

  1. Add a .gitignore
    I’ll simply use this website : - Create Useful .gitignore Files For Your Project

  2. Update the Gradle wrapper’s version
    Currently, the Gradle wrapper version used is 2.10. I’d like to use the latest version, which is Gradle 7.1.1. It is necessary, as my IDE does not support Gradle versions that old. Also, newer versions allow the use of newer JDKs. See the the following GitHub issue : Does not Build with Java 14 and Gradle 2.10 · Issue #2 · Simsilica/SimMath · GitHub

  3. Update the Gradle configuration

  4. [Unsure] Switch TestNG with Ant for jUnit 5 with Gradle

What do you think, fellow monkeys? :monkey:


Contributions are always cool… however…

I have like 20 projects so I’ve been delaying upgrading to newer gradle because there are like a dozen breaking changes and it will be a pretty massive undertaking. It’s also completely unnecessary for contributions from others who are welcome to use whatever build system they like in the interim as long as the code still compiles. (Surgical updates are always better than complete rewrites after all.)

I don’t even know what (4) is about. SimMath uses groovy for testing and I will 100000% never change that because Java-based tests are a huge waste of time.

It might be more productive to discuss the actual code contributions you would like to make.

I thought SimMath was used as an external library by using the artifact on GitHub (or Maven artifact)? If so, then my understanding is that it would not change anything. Am I missing a piece of information?

I understand the parentheses part but I am not sure I understand the preceding sentence as I am a non-native English speaker. Do you mean that I can use whatever build system I want as long as it’s not merged in the repository?

I agree completely. What I meant is that there are a few complicated configuration files related to TestNG which uses Ant.

By the way, the intention of this post and the proposed changes is not to change everything nor to redo everything. I’d like to keep it as simple , follow your conventions and make the changes as transparent as possible for the users.

I wanted to make Vec3i follow more closely Vector3f conventions. I forgot the details because I diverged, as I always do :hear_no_evil:

1 Like

That directory can be removed. It has nothing to do with testing. SimMath was created long enough ago that I still used the JME SDK for some development and so it got the netbeans poop in its directory structure.

Yes, but I develop and maintain many open source projects all of which are still using older gradle. If I upgrade my gradle then I need to convert ALL of them over… which at this point may be a two-whole-weekend project… for no real benefit.

Yes, if for some reason you find the current perfectly functional build setup distasteful and want to go through the trouble of having an uncommitted parallel build then that’s up to you. I think some folks already do similar things with IDEs.

Ok, I would need to take it case by case. I purposely did things differently in some cases because Vector3f has some bad stuff it inherited from 15 years ago that can’t be changed for ‘legacy reasons’.

Vec3d and Vec3i should follow similar conventions and that’s the standard I use.

Personally, I almost always do the math in Vec3d/Vec3i and then toVector3f() right before I need to hand it to JME for some reason. But my situation is a bit different because I don’t use bullet, etc… My interaction with JME is usually limited to a few places.

1 Like

Thanks for that input. I’ll reassess my needs for changes and probably just discard them if possible.

Ouch ahah. Originally, I just wanted to update the Gradle wrapper to 3.x in order to code a few functions using my IDE as the editor but then again I got overboard.

Thanks for that comment by the way. I looked on the interwebs for a simple Groovy testing framework and found Spock!

1 Like

Spock is ok. I have never needed anything other than the testing facilities already available by default. Groovy is pretty powerful testing on its own.

At some point, I need to update all of my projects to the latest gradle as part of moving things to maven central from jcenter. I’m just not particularly looking forward to it.


Note: it’s always good to “check my math” so to speak. If there are differences that feel wrong then feel free to point them out. There may be a reason or I may have made a mistake.