Raise the project version to 2.1.3

[MarkusPaulsen]

Summary

Raises the project version from 2.1.2 to 2.1.3 so that the 95 commits merged into main since the v2.1.2 tag can be cut as a release.

Linked issues

None.

1. Problem

pom.xml still declares 2.1.2, a version that has already been tagged and published to reposilite.aet.cit.tum.de/releases and to Maven Central. Since that tag, 95 commits have landed on main, among them the supervised-package detection work of #174, the generated-test scope changes, the pull request template checks and several Renovate dependency updates.

The consequence is that anything built from main today produces an artefact stamped 2.1.2 which is not the published 2.1.2. Two identical coordinates then denote two different jars, one in a developer's local ~/.m2 and one on reposilite, and Maven has no way to tell them apart. An instructor who builds main locally and an instructor who resolves 2.1.2 from reposilite silently get different enforcement behaviour.

This is neither a false negative nor a false positive in the enforcement layers. It sits in the build integration: the version coordinate no longer identifies the code it is attached to. It also blocks the downstream work, because an exercise cannot be moved onto the newer code while that code has no version of its own to depend on.

2. Improvement from the user's perspective

Instructors gain a coordinate they can actually pin. Once 2.1.3 is tagged and published, an exercise test repository can depend on the current code by version rather than by a locally installed snapshot, and two instructors resolving the same coordinate are guaranteed the same jar.

Note that this pull request only raises the version. Publication to reposilite is a separate manual step, and until it happens de.tum.cit.ase:ares:2.1.3 remains unresolvable for the Artemis build agents.

3. Improvement from the maintainer's perspective

Removes the ambiguity between "2.1.2 as released" and "2.1.2 as currently on main", which is the state that makes a bug report impossible to attribute to a build. It is also the first of the ordinary release steps, so the remaining ones (tag, GitHub release, publish) become mechanical.

4. Testing manual

Prerequisites

1. JDK 17 (Temurin 17 was used here) and Maven 3.9.
2. This branch checked out.
3. A Gradle exercise whose test repository already depends on Ares 2, for example examples/ares-exercise-gradle, or any exercise using the JAVA_USING_GRADLE_ARCHUNIT_AND_ASPECTJ policy configuration.

Steps

1. From the repository root, run mvn install -DskipTests.
2. Inspect ~/.m2/repository/de/tum/cit/ase/ares/2.1.3/.
3. In the exercise test repository's build.gradle, change every de.tum.cit.ase:ares:2.1.0 coordinate (the aresAgent, testImplementation and aspect entries) to 2.1.3, and confirm mavenLocal() is among the declared repositories.
4. Run ./gradlew clean test against the exercise's solution sources.
5. Run ./gradlew clean test against the exercise's template sources.
6. Add a forbidden operation to the solution sources, for example a static { } initialiser calling java.nio.file.Files.readString(java.nio.file.Path.of("secret.txt")) in a class the tests instantiate, and run ./gradlew clean test again.

Expected result

1. BUILD SUCCESS, with the Checkstyle and SpotBugs quality gates passing.
2. The directory contains ares-2.1.3.jar, ares-2.1.3-agent.jar, ares-2.1.3-sources.jar, ares-2.1.3-javadoc.jar and ares-2.1.3.pom. The version in the directory name is the only thing this pull request changes.
3. No expected output; this is a configuration step.
4. All tests pass. The Gradle log names ares-2.1.3.jar and ares-2.1.3-agent.jar on the -javaagent and -Xbootclasspath/a arguments, which is where a reviewer confirms that 2.1.3 and not a cached 2.1.0 was resolved.
5. All tests fail with org.opentest4j.AssertionFailedError from the structural test providers, and no SecurityException appears in build/test-results/test/*.xml. An unsolved template must fail on missing implementation, not on security.
6. Every test fails with java.lang.SecurityException, and the stack trace in build/test-results/test/*.xml names de.tum.cit.ase.ares.api.architecture.java.archunit.JavaArchunitTestCase.runRuleAndCapture.

This was carried out against all eight Ares 2 exercises of the ITP Ares 2 test course. Every solution scored 100% and every template 0%, with test counts of 18, 30, 20, 11, 10, 21, 14 and 17 matching the counts recorded before the bump, so 2.1.3 changes no observable behaviour relative to 2.1.0 for these exercises.

Negative case (what must still be rejected)

Step 6 is the negative case: with the version raised, forbidden file system access, network access, command execution, thread creation and reflection must all still be rejected. All five were injected into separate exercises and all five were rejected, each as a java.lang.SecurityException raised before the test body ran. A run in which step 6 passes would mean the bump had made Ares more permissive.

Modes exercised

• ArchUnit + AspectJ
• ArchUnit + instrumentation
• WALA + AspectJ
• WALA + instrumentation

A single mode is sufficient here because the diff is one version string in pom.xml and contains no code that any mode selects between. The mode that was exercised is the one Artemis Java exercises actually run.

5. Test case coverage regarding this PR

No production Java code changed.

Breaking changes and migration

None.

Checklist

• The title of this pull request describes the change, not the implementation.
• I followed the guidelines for inclusive, diversity-sensitive and appreciative language.
• I have self-reviewed the diff of this pull request.

• CI is green, or every remaining failure is explained above.
• No secrets, tokens or absolute local paths are contained in the diff.

Review progress

• Code review

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 0cb55607-234a-4f76-99a3-6b20ce2b1ba2

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}