Cannot invoke "org.apache.maven.model.RepositoryPolicy.isEnabled()" because "policy" is null

[whiskeysierra]

When upgrading io.repaint.maven:tiles-maven-plugin from 2.36 to 2.37 in all some projects I'm getting this error:

[ERROR] Internal error: java.lang.NullPointerException: Cannot invoke "org.apache.maven.model.RepositoryPolicy.isEnabled()" because "policy" is null -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: java.lang.NullPointerException: Cannot invoke "org.apache.maven.model.RepositoryPolicy.isEnabled()" because "policy" is null
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:121)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:963)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:199)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:568)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: java.lang.NullPointerException: Cannot invoke "org.apache.maven.model.RepositoryPolicy.isEnabled()" because "policy" is null
    at io.repaint.maven.tiles.TilesMavenLifecycleParticipant.getArtifactRepositoryPolicy (TilesMavenLifecycleParticipant.groovy:346)
    at io.repaint.maven.tiles.TilesMavenLifecycleParticipant.discoverAndSetDistributionManagementArtifactoryRepositoriesIfTheyExist (TilesMavenLifecycleParticipant.groovy:366)
    at io.repaint.maven.tiles.TilesMavenLifecycleParticipant.afterProjectsRead (TilesMavenLifecycleParticipant.groovy:338)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:254)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:193)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:106)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:963)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:199)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:568)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)

[talios]

Interesting - that should be a simple fix. However, do you possibly have a minimal test case you could provide I could add as an integration test? Does your project define <repository> elements?

[talios]

@whiskeysierra I've staged a 2.38 fix version in https://oss.sonatype.org/content/repositories/iorepaint-1046/ - are you able to add that repository to a build and test that?

I suspect you've got a <repository> that doesn't explicitly specify that it's enabled, or has any update policies defined (see https://maven.apache.org/pom.html#Repositories for details) which I didn't take into account when dropping the maven-compat changes.

Now, if there's no policy defined, we're defaulting to true and UPDATE_POLICY_ALWAYS, CHECKSUM_POLICY_WARN.

Let me know if this works and I'll promote it to maven central.

[whiskeysierra]

This is what my repositories section looks like:

<repositories>
    <repository>
        <id>foo</id>
        <url>https://pkgs.dev.azure.com/foo/_packaging/foo/maven/v1</url>
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
    </repository>
</repositories>

Setting policies explicitly doesn't change anything:

<repositories>
    <repository>
        <id>gropyus</id>
        <url>https://pkgs.dev.azure.com/gropyus/_packaging/gropyus/maven/v1</url>
        <releases>
            <enabled>true</enabled>
            <updatePolicy>always</updatePolicy>
            <checksumPolicy>warn</checksumPolicy>
        </releases>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>always</updatePolicy>
            <checksumPolicy>warn</checksumPolicy>
        </snapshots>
    </repository>
</repositories>

I tried to use the staging repo but for some reason Maven wouldn't bother downloading plugins from there. Not sure why.

I then tried to download the jar by hand and install it to my local repo using mvn install:install-file. That at least made the error go away, but now it didn't apply any tile 😞

[talios]

For plugins you need to use the element set to declare the repository.

Hope that help—

[whiskeysierra]

I don't get it. Did you mean to say pluginRepository?

[talios]

Doh - yes - I typed that on my phone as I'd just gone to bed, and it seemed to have removed the <pluginRepository> piece. Did you try that?

[whiskeysierra]

I tried it now and it doesn't throw any errors, but it doesn't work either. Same behavior as with the manually installed plugin jar: The tiles/parents aren't applied and the build runs with the default plugins only:

mvn clean verify
Running `/Users/willi/Projects/architecture/id/mvnw`...
[INFO] Scanning for projects...
[INFO]
[INFO] ---------------------------< com.gropyus:id >---------------------------
[INFO] Building ID 0.0.0
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ id ---
[INFO] Deleting /Users/willi/Projects/architecture/id/target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ id ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /Users/willi/Projects/architecture/id/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ id ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ id ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 9 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ id ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ id ---
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ id ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar: /Users/willi/Projects/architecture/id/target/id-0.0.0.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.654 s
[INFO] Finished at: 2023-10-17T09:39:33+02:00
[INFO] ------------------------------------------------------------------------

[talios]

Hrm, are you able to make a super simple sample project which reproduces this?

[talios]

@whiskeysierra if it's easier - you can maybe online chat might be easier - either on https://gitter.im in the repaint-io/maven-tiles room, or discord (taliosnz)...

[talios]

Running /Users/willi/Projects/architecture/id/mvnw...

mvnw? Are you running with the maven wrapper? Not that what should cause a problem as I've used that with tiles previously.

I wonder what running with -X produces.

[whiskeysierra]

mvnw? Are you running with the maven wrapper? Not that what should cause a problem as I've used that with tiles previously.

Yes, we're using the wrapper in our company, exclusively actually. Never had an issue there.

[whiskeysierra]

Hrm, are you able to make a super simple sample project which reproduces this?

Probably yes, but most likely not within the next 2 weeks.

[talios]

I'll see if I can create something to reproduce - I added a the same repository block above to one of my projects, but tiles worked fine. What do you have in your plugin config?

You could send it direct to mark @ talios.com if you don't want anything showing up in a GH ticket.

[whiskeysierra]

What do you have in your plugin config?

You mean the tiles plugin config?

[whiskeysierra]

Pretty straightforward on that end:

<build>
    <plugins>
        <plugin>
            <groupId>io.repaint.maven</groupId>
            <artifactId>tiles-maven-plugin</artifactId>
            <version>2.36</version>
            <extensions>true</extensions>
            <configuration>
                <tiles>
                    <tile>com.gropyus.tiles:lib:${tiles.version}</tile>
                </tiles>
            </configuration>
        </plugin>
    </plugins>
</build>

The lib tile is a composite of other tiles:

<?xml version="1.0" encoding="UTF-8"?>
<project>
    <tiles>
        <tile>com.gropyus.tiles:compile-java:@project.version@</tile>
        <tile>com.gropyus.tiles:compile-kotlin:@project.version@</tile>
        <tile>com.gropyus.tiles:coverage:@project.version@</tile>
        <tile>com.gropyus.tiles:cve:@project.version@</tile>
        <tile>com.gropyus.tiles:duplicate-finder:@project.version@</tile>
        <tile>com.gropyus.tiles:format-kotlin:@project.version@</tile>
        <tile>com.gropyus.tiles:package:@project.version@</tile>
        <tile>com.gropyus.tiles:private-repo:@project.version@</tile>
        <tile>com.gropyus.tiles:release:@project.version@</tile>
        <tile>com.gropyus.tiles:test:@project.version@</tile>
    </tiles>
</project>

In conjunction, they contain a variety of plugins, maven-compiler-plugin, maven-kotlin-plugin, duplicate-finder-plugin, maven-ktlint-plugin, just to name a few.

[talios]

In order to resolve the @project.version@ you'd need the <filtering> element set true in the lib tile, but I assume you have that already since this worked under 2.36 for you.

I'll try reproduce this tomorrow if I have some time.

What version of Maven are you using as well?

[talios]

I wonder if you're being hit by the issue I introduced which is fixed by https://github.com/repaint-io/maven-tiles/pull/146/commits/25c938e40a7a6ca73853b49e5a4481078ad8b194

I tend to only use a maven mirror to our Nexus install rather than repository definitions so missed this.

[whiskeysierra]

What version of Maven are you using as well?

mvn -version
Running `/Users/willi/Projects/architecture/id/mvnw`...
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /Users/willi/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3
Java version: 17.0.5, vendor: Oracle Corporation, runtime: /Users/willi/.sdkman/candidates/java/17.0.5-oracle
Default locale: en_DE, platform encoding: UTF-8
OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"

In order to resolve the @project.version@ you'd need the <filtering> element set true in the lib tile, but I assume you have that already since this worked under 2.36 for you.

Yes, that worked before and we have it enabled:

<plugin>
    <groupId>io.repaint.maven</groupId>
    <artifactId>tiles-maven-plugin</artifactId>
    <version>2.36</version>
    <extensions>true</extensions>
    <configuration>
        <filtering>true</filtering>
        <tiles>
            <tile>com.gropyus.tiles:private-repo:${project.version}</tile>
            <tile>com.gropyus.tiles:release:${project.version}</tile>
        </tiles>
    </configuration>
</plugin>

I wonder if you're being hit by the issue I introduced which is fixed by 25c938e

I tend to only use a maven mirror to our Nexus install rather than repository definitions so missed this.

Hard to tell. We don't use distributionManagement, afaik and neither do we use a mirror. We do have a custom/internal repository, but just for fetching dependencies.

[talios]

Ahh - when I removed maven-compat I think i may have set the requirements to 3.9.5 (along with some dependencies) which is the current version of Maven.

I wonder if this is a case of such an older version of Maven tripping things up.

Are you able to try your project with Maven 3.9.5?

(I think i did see the IT tests fail on github with an older version actually.

I'll try an older version locally as well in the morning.

[whiskeysierra]

Same result:

❯ mvn -version
Running `/Users/willi/Projects/architecture/id/mvnw`...
Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
Maven home: /Users/willi/.m2/wrapper/dists/apache-maven-3.9.5-bin/32db9c34/apache-maven-3.9.5
Java version: 17.0.5, vendor: Oracle Corporation, runtime: /Users/willi/.sdkman/candidates/java/17.0.5-oracle
Default locale: en_DE, platform encoding: UTF-8
OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"

❯ mvn clean verify
Running `/Users/willi/Projects/architecture/id/mvnw`...
[INFO] Scanning for projects...
[INFO]
[INFO] ---------------------------< com.gropyus:id >---------------------------
[INFO] Building ID 0.0.0
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- clean:3.2.0:clean (default-clean) @ id ---
[INFO] Deleting /Users/willi/Projects/architecture/id/target
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ id ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /Users/willi/Projects/architecture/id/src/main/resources
[INFO]
[INFO] --- compiler:3.11.0:compile (default-compile) @ id ---
[INFO] No sources to compile
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @ id ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 9 resources from src/test/resources to target/test-classes
[INFO]
[INFO] --- compiler:3.11.0:testCompile (default-testCompile) @ id ---
[INFO] No sources to compile
[INFO]
[INFO] --- surefire:3.1.2:test (default-test) @ id ---
[INFO]
[INFO] --- jar:3.3.0:jar (default-jar) @ id ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar: /Users/willi/Projects/architecture/id/target/id-0.0.0.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.707 s
[INFO] Finished at: 2023-10-17T15:30:56+02:00
[INFO] ------------------------------------------------------------------------

[talios]

I just released 2.38 with the NPE for I had originally added for this, along with the distribution SNAPSHOT repository - this may not resolve this issue yet, but I suspect this issue might be slightly different (unless the combination of changes resolves things).

[whiskeysierra]

@talios 2.38 did indeed fix the original issue in the repos where I saw it first. But in my company we're now seeing another issue that only appears with 2.38 and I'm not sure whether it's related or not:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project digital-factory-grpc-api: Execution default-deploy of goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy failed: Cannot invoke "org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout.getId()" because the return value of "org.apache.maven.artifact.repository.ArtifactRepository.getLayout()" is null -> [Help 1]

[whiskeysierra]

2.38 did indeed fix the original issue in the repos where I saw it first.

Correction: While it did fix the original issue, this deploy using we see in every project now that runs with 2.38.

[talios]

Interesting, mentioning deploy, plus the area of code that was playing up points to do being in the distributionManagement configuration not normal repositories (not sure why I was asking about them, since the code is clearly about distribution repos).

I've added a simple IT test containing a tile with an distributionManagement section and that works fine, I can only seem to get it to break when using a totally broken config.

I did find a bit of code that was commented out during which is related, and I've readded that and pushed a snapshot to 2.39-SNAPSHOT release to:

https://oss.sonatype.org/content/repositories/snapshots

you could try?

For what it's worth - in my release tile I use the alternate property syntax to define my distribution repositories:

<properties>

 <altSnapshotDeploymentRepository>snapshots::default::https://YOUR_NEXUS_URL/snapshots</altSnapshotDeploymentRepository>

 <altReleaseDeploymentRepository>releases::default::https://YOUR_NEXUS_URL/releases</altReleaseDeploymentRepository>
/properties>

I can't remember the reason for switching to this off hand, tho there was a tiles related reason I believe.

[whiskeysierra]

For what it's worth - in my release tile I use the alternate property syntax to define my distribution repositories

That's Nexus specific and since we don't use Nexus, I can't use that workaround.

a tile with an distributionManagement section

For reference, ours looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<project>
    <distributionManagement>
        <repository>
            <id>xxx</id>
            <url>https://pkgs.dev.azure.com/xxx/_packaging/xxx/maven/v1</url>
        </repository>
    </distributionManagement>
</project>

This tile interacts with the different versions of the tiles plugin like this:

• 2.36: ✅ works
• 2.37: :x: before deploy already, see the original comment of this issue
• 2.38: :x: see https://github.com/repaint-io/maven-tiles/issues/144#issuecomment-1772209728
• 2.39-SNAPSHOT: :x: doesn't seem to actually inject the distributionManagement section from the tile. If I manually copy over the distributionManagement it works.

[talios]

Interesting - there should AFAIK be nothing different between 2.39-SNAPSHOT and 2.38 as there's no commits.

I've pushed a new IT test checking the distributionManagement (https://github.com/repaint-io/maven-tiles/tree/feature/distributionManagement) which seems to pass for me when running:

mvn clean install -Prun-its -U

The only differences from the above is the test one includes <modelVersion>4.0.0</modelVersion> and <name> ( https://github.com/repaint-io/maven-tiles/blob/feature/distributionManagement/src/it/distributionManagemetTile/tileA/tile.xml specifically ).

Does that pass/fail for you?

PS: altReleaseDeploymentRepository isn't (or shouldn't be AFAIK) nexus specific: https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#altReleaseDeploymentRepository

[whiskeysierra]

PS: altReleaseDeploymentRepository isn't (or shouldn't be AFAIK) nexus specific

Ah, I finally understood that one now...

I tried it again but this time without distributionManagement but instead with those two properties:

2.38 interestingly fails now with this:

Running `/Users/willi/Projects/architecture/tiles/mvnw`...
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Unknown packaging: tile @ com.gropyus.tiles:private-repo:${revision}, /Users/willi/Projects/architecture/tiles/private-repo/pom.xml, line 7, column 16
[ERROR] Unknown packaging: tile @ com.gropyus.tiles:release:${revision}, /Users/willi/Projects/architecture/tiles/release/pom.xml, line 8, column 16
...

But 2.39-SNAPSHOT works fine when I try to deploy.

[talios]

Interesting - one of the other changes in that branch was restoring/manually looking up the ArtifcateRepositoryLayout rather than taking the factory version.

I should reword that commit, or split it to separate out the IT test from that lookup. That was my bad last night.

That new issue about the unknown packaging sounds like you may be missing <extensions>true</extensions> on your tile plugin declaration in the root.

[whiskeysierra]

You mean the parent module of my multi module build?

On Fri, Nov 3, 2023, 20:21 Mark Derricutt @.***> wrote:

Interesting - one of the other changes in that branch was restoring/manually looking up the ArtifcateRepositoryLayout rather than taking the factory version.

I should reword that commit, or split it to separate out the IT test from that lookup. That was my bad last night.

That new issue about the unknown packaging sounds like you may be missing

true on your tile plugin declaration in the root. — Reply to this email directly, view it on GitHub , or unsubscribe . You are receiving this because you were mentioned.Message ID: ***@***.***>

[talios]

Yup - since the modules include the “tile” packaging type you'll need to have the plugin declare the extensions which add the lifecycle/packaging type.

Extensions are loaded once at the start of the maven process so it needs to be declared such at the root.

[whiskeysierra]

I never had to do this before. Works in 2.36 and earlier without this. But I tried it anyway now and added this block to my parent/root module:

<build>
    <plugins>
        <plugin>
            <groupId>io.repaint.maven</groupId>
            <artifactId>tiles-maven-plugin</artifactId>
            <version>2.38</version>
            <extensions>true</extensions>
        </plugin>
    </plugins>
</build>

Same result though. Something is fishy with 2.38. At least for me.

[whiskeysierra]

Huh! I just deleted 2.38 from my local maven repo to force a clean download and now it works...

Not sure what that was.

[whiskeysierra]

To recap, this works for me:

• 2.38
• alternative distribution syntax (see https://github.com/repaint-io/maven-tiles/issues/144#issuecomment-1773721526) instead of distributionManagement
• no tiles plugin definition in my root module

[talios]

That's good to know! I'd still be interested to know if that CI test for distributionManagement passes for you tho - as that seems to pass for me, and in the GH actions (if you can reproduce that breaking, that points to an issue elsewhere.

[whiskeysierra]

I checked out the repo and ran all integration tests (as you described above) - all successful.

[talios]

Assuming that was the feature/distributionManagement branch with the new distribution management CI test, and that your original issue is resolved - I'll merge that branch and start preparing to release 2.39.

[whiskeysierra]

No, the default branch. Didn't catch that it's on a different branch.

On Mon, Nov 6, 2023, 21:14 Mark Derricutt @.***> wrote:

Assuming that was the feature/distributionManagement branch with the new distribution management CI test, I'll merge that branch and start preparing to release 2.39.

— Reply to this email directly, view it on GitHub https://github.com/repaint-io/maven-tiles/issues/144#issuecomment-1796350094, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADI7HOV7PNAJTENGQY5DILYDFAJRAVCNFSM6AAAAAA6BXVZS6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJWGM2TAMBZGQ . You are receiving this because you were mentioned.Message ID: @.***>

[talios]

Let me know if that other branch with the new test also passes for you.

[talios]

Looks like I managed to hit this issue (well, not the original isEnabled() one, but a subsequent issue with distributionManagement) in one of our own projects so once I could reproduce it, I could dive further in.

The IT test seems to work without using the altReleaseDeploymentRepository property so it would be great if you could confirm this branch works for you in your setup before I merge and release.

There are still benefits to using the property approach, which now that I have docs working again in a different branch I'll look at adding an example based on this IT test.

[whiskeysierra]

[INFO] -------------------------------------------------
[INFO] Build Summary:
[INFO]   Passed: 7, Failed: 0, Errors: 0, Skipped: 0
[INFO] -------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:04 min
[INFO] Finished at: 2023-11-09T09:13:13+01:00
[INFO] ------------------------------------------------------------------------

~/Projects/oss/maven-tiles on feature/distributionManagement
>