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.

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

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

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

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?

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?

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.

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.

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

Allow package info to be resolved as a dependency

3b8fda6

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 63c579b to 3b8fda6 Compare April 21, 2026 14:41

StefanGraeber suggested changes Apr 24, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow package info classes to be resolved as a dependency#1565

Allow package info classes to be resolved as a dependency#1565
wakingrufus wants to merge 1 commit intoTNG:mainfrom
wakingrufus:dependency-package-info

wakingrufus commented Dec 10, 2025 •

edited

Loading

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

Loading

Uh oh!

StefanGraeber Apr 24, 2026

Uh oh!

StefanGraeber Apr 24, 2026

Uh oh!

StefanGraeber Apr 24, 2026

Uh oh!

StefanGraeber Apr 24, 2026

Uh oh!

StefanGraeber Apr 24, 2026

Uh oh!

StefanGraeber commented Apr 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		@@ -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 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

StefanGraeber Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

StefanGraeber Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

StefanGraeber Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

StefanGraeber Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

StefanGraeber Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

StefanGraeber commented Apr 24, 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

Loading