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

StefanGraeber · 2026-04-24T08:06:57Z

    }

+    void completePackageInfoFrom(ImportContext context) {
+        this.javaPackage = JavaPackage.from(Arrays.asList(


I'm not familiar with the class resolution yet, but this looks to me as if the package is re-created with just the current class and the package-info class.
If you look e.g. at the package testexamples, you have these classes (and more):

SomeClass

OtherClass

package-info

assuming we are now in the JavaClass representing SomeClass, I expect that getPackage().getClasses() contains all three of these classes, but I don't see how it could return anything else then Set.of(SomeClass, package-info), as this statement replaces the package and just passes these 2 classes into the new factory.
I don't see any call in JavaPackage.from checking the package of the class, which could contain the information.

It is also not clear to me how the dependencies and subpackages are build if all the other classes in teh package are missing.

Wouldn't it be much cleaner if we could resolve the package-info class when initially building the JavaPackage?
Why should each JavaClass in that package be responsible for resolving the package-info?

because initially building JavaPackage is only something that happens if the package-info class is in the initial list of files passed to ClassfileImporter. when class dependencies are resolved, if the other class lives in another (non-imported) package, only the package name is known. this method that is added allows us to resolve the rest of the package info for this package, even if the entire package was not included in the import.

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(); }

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" );

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?

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 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

Allow package info to be resolved as a dependency

7be3ecf

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 7cd61cd to 7be3ecf Compare April 27, 2026 16:09

		@@ -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!

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!

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