v0.8.1-alpha

🥳 some minor fixes and polish.

• Thank you to @lukeMains for fixing issue #3 Validation of Group and Artifact ID during grind new
• Fix for issue #1 we now safely backup the .bashrc file before any mutation to it.

v0.8.0-alpha

🚀 Java Version Manager Implemented!

In this release the major new feature that was on the "Long Term roadmap" has been implemented, I think this is important because it allows grind to be able to be dropped into any Linux/Mac system and be able to get building a Java project without worrying about dealing with which Java is installed OR not installed.

The main command is java and is used as follows:

List available JDK versions available

grind java list

Display the current Java in use

grind java current

Automatically download OR switch to a specific JDK version

grind java use 11

Remove the Grind managed Java JDK

grind java remove

v0.7.5-alpha

In this release two newer features:

• Automatic vscode settings when scaffolding a new project, this fully sets up the official Microsoft Java extension plugin
• CLI arguments pass through when using the run command

v0.7.4-alpha

🧪 Experimental Fat Jar (uberjar) feature

In this release v0.7.4-alpha we now have a working bundle feature, this should now fully generate a "fat jar" aka uberjar.

Of course here be dragons! as I'm not entirely sure the merging logic is 100% correct, but it does seem to work for the non-trivial Pet Clinic spring boot project.

example output when bundling the Pet Clinic project:

anhar@workstation:~/Desktop/sandbox/PetClinicApplication$ grind bundle prod
==> 🔨 compiling project [PetClinicApplication]...
🧩 Starting fat jar build...
 → Output: build/PetClinicApplication.jar
 → Classes: target
 → Libs: libs
 → Main-Class: org.springframework.samples.petclinic.PetClinicApplication
+ manifest: META-INF/MANIFEST.MF
+ resource: application-postgres.properties
# <SNIPPED>
+ resource: templates/error.html
📦 Merging 99 dependency jar(s)...
   [99/99 | 100%] org.springframework.boot_spring-boot-data-jpa_4.0.0-RC1.jarr1.jar.jarjar
+ merged: META-INF/spring/org.springframework.boot.webmvc.test.autoconfigure.AutoConfigureWebMvc.imports
# <SNIPPED>
+ merged: META-INF/spring/configuration-metadata/org.springframework.boot.jdbc.init.DatabaseInitializationProperties.json
✅ Fat jar created: build/PetClinicApplication.jar
📊 Summary:
   → 82 class/resource files
   → 99 dependency jars merged
⏱ Total build time: 2.325 seconds

v0.7.3-alpha

🚀

In this release some excellent progress!

• The effectivePom resolution has been fixed so we're not downloading an excessive amount of dependencies, previously when using against the Pet Clinic Demo, we were downloading 856 dependencies but now we're downloading 100. We filter out for only compile and also remove ones that have optional=true.
• We now support profiles these are defined in the grind.yml and each profile can now define custom compiler flags as well as environment variables
• When running a project we now use streaming I/O to show the console output in real time

Here is a screen shot of the latest grind successfully compiling and running the "Pet Clinic" demo:

v0.7.2-alpha

🥳

A lot of changes and fixes!

• ripped out the semver crate, turns out Maven versions and certainly the ones in the wild have their own semantics around how versions are represented, including legacy quirks.
• ripped out the solr search as this wasn't providing the latest stable versions, instead we now use the maven-metadata.xml
• removed range specifiers and only allow properly resolved versions
• tweaked the collisions

With all those changes, FINALLY we're able to actually compile and run the Pet Clinic spring demo, which is a massive achievement! (it does crash at runtime on boot, but at least it's compiling without any errors, that took a lot of debugging)

We now also have a way to directly compare Maven resolution behaviour (wonderful edge cases included) against grinds resolution,

At the moment, grind is pulling down too many dependencies e.g around 856 vs 156. Some are multiple versions (but I suspect that's some clean up we're not doing to match the grind.lock vs what is actually on disk) so that figure should reduce down. Will need to investigate why we're including more dependencies over Maven.

v0.7.0-alpha

New v0.7.0-alpha release.

In this release the new plugin based test runner has been completed. This uses the TestTube in order to run and report on tests.

grind will automatically download and install (after confirming the integrity) the TestTube test plugin, then it will compile all the test classes and run them.

NOTE: The TestTube is compiled using Java 17, if you're using a lower version this will not work, however you can manually compile the plugin and regenerate the integrity.json using the grind integrity generate command.

One of our longer term goal for grind is to add Java JDK version management, at which point this JDK version mismatch will not be a problem. The other option maybe to automatically compile from sources.

v0.6.1-alpha

Minor update:

• Added the integrity feature, mainly for when creating plugin bundles, we generate the correct checksums as well as validate when unpacking bundles.

v0.6.0-alpha

🥳

In this release, a huge amount of work and refactor and minor fixes, the highlight:

• We're now fully computing the EffectivePOM meaning we now properly walk the parents, imports and then apply the inheritance order when merging as well as handling the properties interpolation.
• This ends up being a DAG (Directed Acyclic Graph), so we also detect cycles to stop ending up in an endless loop.

For the first time, we're able to use real libraries, this has been tested using the Javalin framework and confirmed to fully compile, build and run as well as work when packaged into a jar!

There are only two features not implemented yet:

• Exclusions
• Version options/ranges/specifiers e.g >=, < etc

Exclusions should be do-able, as we're already doing merging down and so we can just pass that filter down. However the version options is much harder as that requires building an entire SAT solver... (a significant amount of work!)

v0.4.0-alpha

This release includes some minor bug fixes, but the main focus is two new features:

• Collision detection and resolution using the "newest" wins strategy
• grind.lock file to freeze the fully resolved artefacts

With both these features grind should be able to be much more reproducible as we essentially take a snapshot of the resolved dependencies which is then source controlled. grind will use the grind.lock if one exists as the source of truth.