Cannot invoke "org.apache.maven.model.RepositoryPolicy.isEnabled()" because "policy" is null #144
Comments
|
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 |
|
@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 Now, if there's no policy defined, we're defaulting to Let me know if this works and I'll promote it to maven central. |
|
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. I then tried to download the jar by hand and install it to my local repo using |
|
For plugins you need to use the element set to declare the repository. Hope that help— |
|
I don't get it. Did you mean to say pluginRepository? |
|
Doh - yes - I typed that on my phone as I'd just gone to bed, and it seemed to have removed the |
|
I tried it now and it doesn't throw any errors, but it doesn't work either. |
|
Hrm, are you able to make a super simple sample project which reproduces this? |
|
@whiskeysierra if it's easier - you can maybe online chat might be easier - either on https://gitter.im in the |
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 |
Yes, we're using the wrapper in our company, exclusively actually. Never had an issue there. |
Probably yes, but most likely not within the next 2 weeks. |
|
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. |
You mean the tiles plugin config? |
|
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 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. |
|
In order to resolve the I'll try reproduce this tomorrow if I have some time. What version of Maven are you using as well? |
|
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. |
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>
Hard to tell. We don't use distributionManagement, afaik and neither do we use a mirror. |
|
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. |
|
Same result: |
|
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). |
|
@talios 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. |
|
Interesting, mentioning deploy, plus the area of code that was playing up points to do being in the I've added a simple IT test containing a tile with an 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: I can't remember the reason for switching to this off hand, tho there was a tiles related reason I believe. |
That's Nexus specific and since we don't use Nexus, I can't use that workaround.
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:
|
|
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 -UThe only differences from the above is the test one includes Does that pass/fail for you? PS: |
Ah, I finally understood that one now... I tried it again but this time without 2.38 interestingly fails now with this: But 2.39-SNAPSHOT works fine when I try to deploy. |
|
Interesting - one of the other changes in that branch was restoring/manually looking up the 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 |
|
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
<extensions>true</extensions> on your tile plugin declaration in the root.
—
Reply to this email directly, view it on GitHub
<#144 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADI7HLJEX23TECXTFLXQC3YCU7Z5AVCNFSM6AAAAAA6BXVZS6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJSHE3TONRXHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
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. |
|
I never had to do this before. Works in 2.36 and earlier without this. <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. |
|
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. |
|
To recap, this works for me:
|
|
That's good to know! I'd still be interested to know if that CI test for |
|
I checked out the repo and ran all integration tests (as you described above) - all successful. |
|
Assuming that was the |
|
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
<#144 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADI7HOV7PNAJTENGQY5DILYDFAJRAVCNFSM6AAAAAA6BXVZS6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJWGM2TAMBZGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Let me know if that other branch with the new test also passes for you. |
|
Looks like I managed to hit this issue (well, not the original The IT test seems to work without using the 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. |
|
When upgrading io.repaint.maven:tiles-maven-plugin from 2.36 to 2.37 in all some projects I'm getting this error:
The text was updated successfully, but these errors were encountered: