Allow package info classes to be resolved as a dependency by wakingrufus · Pull Request #1565 · TNG/ArchUnit

wakingrufus · 2025-12-10T21:07:14Z

Allow package info classes to be resolved as a dependency
exclude package-info classes from package metrics calculations

Resolves #1564

wakingrufus · 2025-12-12T15:42:48Z

I updated this PR to exclude the package-info classes when calculating package metrics. this fixes the failing tests

wakingrufus · 2026-01-05T16:14:47Z

Happy New Year @codecholeric and @hankem !
Just a gentle reminder that I would appreciate if this PR could be looked at.
Thanks again!

wakingrufus · 2026-02-17T21:19:05Z

Hi again @codecholeric and @hankem. I know I have a few PRs open at the moment, but this one is quite important. I would really appreciate of someone could take a look at this please.

… class dependency when scanning since TNG/ArchUnit#1565 has not been merged in a timely manner, we need a custom implementation on our end to fix this issue until it is finally merged.

hankem · 2026-04-22T06:19:36Z

I'm very sorry for the late response! I'll try to find more time. 🤞

wakingrufus · 2026-04-23T22:13:38Z

I'm very sorry for the late response! I'll try to find more time. 🤞

No problem, Thanks!

StefanGraeber

I dislike that the package-info is now included in JavaPackage.getClasses() (even as stub if it doesn't exist, which might be a breaking change for some use cases) and don't understand whether or how all classes in the package are retained when recreating the package in the JavaClass class.
IMO it also is the wrong location for the logic of resolving package info.

Can you explain in more detail which problem you want to solve?
To my understanding, the issue seems to be, that the package-info is not always resolved when you expect it to be loaded, but I'm not sure whether that's limited to loading single classes via new ClassFileImporter() or whether this also affects the "normal" execution with @AnalyzeClasses annotation

StefanGraeber · 2026-04-24T07:45:43Z

    }

+    @Test
+    public void function_getPackageInfo() {


looking at the previous tests in this class, I would expect that a test with this name would test
JavaClass.Functions.GET_PACKAGE_INFO, which doesn't exist.
This test doesn't fit the pattern of the other tests.
I'm not sure whether we would want to have that function, as I'm not sure what I should return apart from the package itself

thanks. this is fixed now.

StefanGraeber · 2026-04-24T07:56:30Z

@@ -0,0 +1,7 @@
+package com.tngtech.archunit.core.importer.testexamples.packageinforesolution;


I don't understand this new package name.
is it important that it is subpackage of the package in which OtherClass is defined or shall just be any other package?

It is important that this class is in a different package than OtherClass. other than that, this package could be anything

I already suspected that, but "package in for resolution" doesn't really tell me anything.
maybe sth like 'otherclassrefrencefromanotherpackage`?
damn is that long :D
and not really better than yours... maybe think a bit about a better name, but if you don't find one, it's also fine for me

StefanGraeber · 2026-04-24T08:32:54Z

+        JavaClass otherClass = new ClassFileImporter()
+                .importClass(OtherClass.class);
+
+        JavaPackage checkedClassPackageInfo = otherClass.getPackage();


The JavaPackage has the methods tryGetPackageInfo and getPackageInfo.
please include in the test they work as well.
as one calls the other, I would prefer to tests sth like assertThat(checkedClassPackageInfo.getPackageInfo()).isPresent(), even thought this is kind of redundant with the getAnnotations method which also relies on that field.

Looks like these exist in JavaPackageTest:

@Test public void test_getPackageInfo() { JavaPackage annotatedPackage = importPackage("packageexamples.annotated"); JavaPackage nonAnnotatedPackage = importPackage("packageexamples"); assertThat(annotatedPackage.getPackageInfo()).isNotNull(); assertThatThrownBy(nonAnnotatedPackage::getPackageInfo) .isInstanceOf(IllegalArgumentException.class) .hasMessageContaining(nonAnnotatedPackage.getDescription() + " does not contain a package-info.java"); } @Test public void test_tryGetPackageInfo() { JavaPackage annotatedPackage = importPackage("packageexamples.annotated"); JavaPackage nonAnnotatedPackage = importPackage("packageexamples"); assertThat(annotatedPackage.tryGetPackageInfo()).isPresent(); assertThat(nonAnnotatedPackage.tryGetPackageInfo()).isEmpty(); }

yes, but since you re-create the JavaPackage, it might be worth checking that the re-created package behaves as expected in these methods

still open, please add an assertion like assertThat(checkedClassPackageInfo.getPackageInfo()).isPresent() to make explicit that the package-info is loaded.
Asserting it before the annotations will likely give better error messages if it ever breaks

StefanGraeber · 2026-04-24T08:43:13Z

+        JavaPackage checkedClassPackageInfo = otherClass.getPackage();
+        assertThat(checkedClassPackageInfo.getAnnotations()).hasSize(1);
+        assertThat(checkedClassPackageInfo.isAnnotatedWith(SomeAnnotation.class)).isTrue();
+    }


When running checkedClassPackageInfo.getClasses(), this set now includes the package-info, which it didn't before.
I don't think that that class should be included in that Set as it is not a real class and shall instead be accessed via JavaPackage.getPackageInfo() which returns the JavaClass representing package-info as HasAnnotations. This change in type seems deliberate to me as this special class doesn't have all features of a JavaClass.

This is already the normal behavior in scanning a package. Ill add this assertion to JavaPackageTest.test_getPackageInfo() to show this:

assertThat(annotatedPackage.getClasses().stream().map(JavaClass::getFullName).collect(Collectors.toList())) .as("all classes and package-info are loaded as JavaClass") .containsExactlyInAnyOrder( "com.tngtech.archunit.core.domain.packageexamples.annotated.package-info", "com.tngtech.archunit.core.domain.packageexamples.annotated.PackageLevelAnnotation", "com.tngtech.archunit.core.domain.packageexamples.annotated.WithinAnnotatedPackage" );

how about packages without a package-info file?
IIRC you added somewhere a stub of it as JavaClass. If I don't have the package-info as explicit file in the package, I find it even weirder to have it returned as PackageInfo.
That is was like that before might not have been desired.
As you know, I'm new to the ArchUnit dev side (so far I only used it), but I find it surprising that this pseudo class is present at all in the result of getClasses() and even more surprising that it is now present even though I haven't even written that class.

I would prefer to never have package-info in this result

related to f0fca6f#r3332389020

StefanGraeber · 2026-04-24T12:33:33Z

I can't really localize the issue (and it might be a me-problem), but using windows 11 and IntelliJ, incremental builds fail with this error

> Task :archunit:compileJdk9mainJava FAILED
repopath\ArchUnit\archunit\src\jdk9main\java\com\tngtech\archunit\core\domain\Java9DomainPlugin.java:30: error: cannot access AnnotationPropertiesFormatter
                        .formatProperties(config -> config
                        ^
  class file for com.tngtech.archunit.core.domain.AnnotationFormatter$AnnotationPropertiesFormatter not found
1 error

as soon as I include your changes in JavaClass.
I can't reproduce the issue with adding some random new method in that class

wakingrufus · 2026-04-27T15:33:13Z

I dislike that the package-info is now included in JavaPackage.getClasses() (even as stub if it doesn't exist, which might be a breaking change for some use cases) and don't understand whether or how all classes in the package are retained when recreating the package in the JavaClass class. IMO it also is the wrong location for the logic of resolving package info.

Can you explain in more detail which problem you want to solve? To my understanding, the issue seems to be, that the package-infois not always resolved when you expect it to be loaded, but I'm not sure whether that's limited to loading single classes vianew ClassFileImporter()or whether this also affects the "normal" execution with@AnalyzeClasses` annotation

Thanks for taking a look at this. I will add a more detailed description of the use case in the PR description.

wakingrufus · 2026-04-27T15:40:50Z

I dislike that the package-info is now included in JavaPackage.getClasses() (even as stub if it doesn't exist, which might be a breaking change for some use cases) and don't understand whether or how all classes in the package are retained when recreating the package in the JavaClass class. IMO it also is the wrong location for the logic of resolving package info.
Can you explain in more detail which problem you want to solve? To my understanding, the issue seems to be, that the package-infois not always resolved when you expect it to be loaded, but I'm not sure whether that's limited to loading single classes vianew ClassFileImporter()or whether this also affects the "normal" execution with@AnalyzeClasses` annotation

Thanks for taking a look at this. I will add a more detailed description of the use case in the PR description.

@StefanGraeber Actually, I updated the associated issue, instead: #1564

wakingrufus · 2026-04-27T16:04:41Z

I can't really localize the issue (and it might be a me-problem), but using windows 11 and IntelliJ, incremental builds fail with this error
> Task :archunit:compileJdk9mainJava FAILED
repopath\ArchUnit\archunit\src\jdk9main\java\com\tngtech\archunit\core\domain\Java9DomainPlugin.java:30: error: cannot access AnnotationPropertiesFormatter
                        .formatProperties(config -> config
                        ^
  class file for com.tngtech.archunit.core.domain.AnnotationFormatter$AnnotationPropertiesFormatter not found
1 error
as soon as I include your changes in JavaClass. I can't reproduce the issue with adding some random new method in that class

I was able to run ./gradlew :archunit:compileJdk9mainJava on ubuntu with openjdk 17. Maybe try running the gradle command directly?

StefanGraeber · 2026-05-04T07:02:38Z

I was able to run ./gradlew :archunit:compileJdk9mainJava on ubuntu with openjdk 17. Maybe try running the gradle command directly?

whether I used the IntelliJ buttons or the gradle command via terminal made no difference.
The issue was related to something with the gradle logic of which packages need a rebuild. when cleaning the package before the build, everything is fine. It was really weird, I might try to reproduce it in more detail on another day

fix for TNG#1564 exclude package-info classes from package metrics calculations Signed-off-by: John Burns <wakingrufus@gmail.com>

wakingrufus · 2026-05-26T15:28:20Z

rebased on latest main

StefanGraeber · 2026-06-01T07:23:23Z

+            components.add(MetricsComponent.of(
+                    javaPackage.getName(),
+                    javaPackage.getClassesInPackageTree().stream()
+                            .filter(jc -> !jc.getSimpleName().equals("package-info"))


Sorry for opening a new frontier, but I needed a fresh review from the start after a month...

this is a behavior change in case of having a package-info file.

please look at MetricsComponentsTest.creates_components_from_Java_packages and make explicit that the package-info is not imported (you need to create one in the test scenario, probably best in case 1 for top-level and subpackage.

adding the package-info might also require changes to the the other test methods. it would be interesting to see whether creates_components_from_Java_classes stick with 3 components.

I hope this doesn't break too much for our users becasue the old behavior is unexpected for me and I haven't seen MetricsCompment before

StefanGraeber · 2026-06-01T07:37:49Z

+        assertThat(annotatedPackage.getClasses().stream().map(JavaClass::getFullName).collect(Collectors.toList()))
+                .as("all classes and package-info are loaded as JavaClass")
+                .containsExactlyInAnyOrder(
+                        "com.tngtech.archunit.core.domain.packageexamples.annotated.package-info",


should we really get the package-info in the classes?
I wouldn't expect that as user and don't really like having it as the package info is not really a class.

I just wanted to write that you can't get it via reflection as Class.forName("com.tngtech.archunit.core.domain.packageexamples.annotated.package-info") but you actually get it as an interface... there is always sth to learn about java...

What are your thoughts on including the package-info class in the classes of the package?
I have the feeling that it was like this before, but I don't like it.

What about a missing package-info file? I just checked that it is NOT included in that case. please extend the
test, I write a separate comment f0fca6f#r3332408963 for it

related/caused by to f0fca6f#r3136501904

I also just checked how the libraries Reflections and ClassGraph handle this:
Reflections includes it if you look for all subclasses of Object and disable the filterr preventing obejct sublcasses like this:

Reflections reflections = new Reflections( new ConfigurationBuilder() .forPackages("com.tngtech.archunit.core.domain.packageexamples.annotated") .setScanners(Scanners.SubTypes.filterResultsBy(c -> true)) // disable the Object filter ); Set<Class<?>> subTypesOfObject = reflections.getSubTypesOf(Object.class);

which is quite hacky.
ClassGraph doesn't include it at all but provides special methods for this

StefanGraeber · 2026-06-01T07:40:22Z

+                        "com.tngtech.archunit.core.domain.packageexamples.annotated.WithinAnnotatedPackage"
+                );

        assertThatThrownBy(nonAnnotatedPackage::getPackageInfo)


created by f0fca6f#r3332389020

I'd prefer to exchange the tested package by one with some classes in it (e.g. packageexamples.first) and asserting that those 2 classes but not the package-info are returned from getClasses()

StefanGraeber · 2026-06-01T07:44:50Z

+        JavaClass otherClass = new ClassFileImporter()
+                .importClass(OtherClass.class);
+
+        JavaPackage checkedClassPackageInfo = otherClass.getPackage();


still open, please add an assertion like assertThat(checkedClassPackageInfo.getPackageInfo()).isPresent() to make explicit that the package-info is loaded.
Asserting it before the annotations will likely give better error messages if it ever breaks

StefanGraeber · 2026-06-01T07:45:18Z

+        JavaPackage checkedClassPackageInfo = otherClass.getPackage();
+        assertThat(checkedClassPackageInfo.getAnnotations()).hasSize(1);
+        assertThat(checkedClassPackageInfo.isAnnotatedWith(SomeAnnotation.class)).isTrue();
+    }


related to f0fca6f#r3332389020

wakingrufus force-pushed the dependency-package-info branch 7 times, most recently from 6da5209 to 43288eb Compare December 11, 2025 23:23

wakingrufus marked this pull request as ready for review December 11, 2025 23:23

wakingrufus mentioned this pull request Dec 11, 2025

package-info should be resolvable through DependencyResolutionProcess #1564

Open

wakingrufus changed the title ~~failing tests to reproduce #1564~~ Allow package info classes to be resolved as a dependency Dec 11, 2025

wakingrufus force-pushed the dependency-package-info branch from 43288eb to 070d20f Compare December 12, 2025 15:41

wakingrufus force-pushed the dependency-package-info branch from 070d20f to 81cfe2d Compare December 12, 2025 15:57

wakingrufus mentioned this pull request Jan 20, 2026

add archrules-common to hold common archunit primatives nebula-plugins/nebula-archrules#32

Merged

wakingrufus force-pushed the dependency-package-info branch from 81cfe2d to 09eb2b1 Compare January 29, 2026 17:57

wakingrufus force-pushed the dependency-package-info branch from 09eb2b1 to ab61e25 Compare February 11, 2026 16:42

wakingrufus mentioned this pull request Feb 19, 2026

re-implement some ArchUnit code to support scanning package-info nebula-plugins/nebula-archrules-plugin#58

Merged

wakingrufus force-pushed the dependency-package-info branch from ab61e25 to 63c579b Compare February 19, 2026 17:33

wakingrufus force-pushed the dependency-package-info branch from 63c579b to 3b8fda6 Compare April 21, 2026 14:41

StefanGraeber requested changes Apr 24, 2026

View reviewed changes

wakingrufus force-pushed the dependency-package-info branch from 3b8fda6 to 7cd61cd Compare April 27, 2026 15:59

wakingrufus requested a review from StefanGraeber April 27, 2026 16:05

wakingrufus force-pushed the dependency-package-info branch from 7cd61cd to 7be3ecf Compare April 27, 2026 16:09

Allow package info to be resolved as a dependency

f0fca6f

fix for TNG#1564 exclude package-info classes from package metrics calculations Signed-off-by: John Burns <wakingrufus@gmail.com>

wakingrufus force-pushed the dependency-package-info branch from 7be3ecf to f0fca6f Compare May 26, 2026 15:27

StefanGraeber requested changes Jun 1, 2026

View reviewed changes

		@@ -0,0 +1,7 @@
		package com.tngtech.archunit.core.importer.testexamples.packageinforesolution;

Conversation

wakingrufus commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wakingrufus commented Dec 12, 2025

Uh oh!

wakingrufus commented Jan 5, 2026

Uh oh!

wakingrufus commented Feb 17, 2026

Uh oh!

hankem commented Apr 22, 2026

Uh oh!

wakingrufus commented Apr 23, 2026

Uh oh!

StefanGraeber left a comment • edited by hankem Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

StefanGraeber commented Apr 24, 2026

Uh oh!

wakingrufus commented Apr 27, 2026

Uh oh!

wakingrufus commented Apr 27, 2026

Uh oh!

wakingrufus commented Apr 27, 2026

Uh oh!

StefanGraeber commented May 4, 2026

Uh oh!

wakingrufus commented May 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

wakingrufus commented Dec 10, 2025 •

edited

Loading

StefanGraeber left a comment •

edited by hankem

Loading