[MPMD-407] Upgrade to Doxia 2.0.0 GA Stack #175
Merged
+9
−51
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This closes #175
michael-o
force-pushed
the
doxia-2.0.0-ga
branch
from
8f78bc5 to
e99d2e4
Compare
adangel
changed the title
|
@michael-o Sorry for the ping.. I wasn't really sure where to post this, especially without a proper reproducer.. We noticed some interesting / weird behavior since this change in our internal builds - once maven-pmd-plugin 3.26.0 is in use (containing DOXIA 2.0 GA) we got problem building against an internal JFrog Artifactory where it does not return proper 404 "errors" for "missing" site.xml (instead 401) resulting in a complete build crash. Example: An error has occurred in PMD report generation. The site descriptor cannot be resolved from the repository:
Unable to locate site descriptor: The following artifacts could not be resolved: internal:parent-pom:xml:site:version (absent):
Could not transfer artifact internal:parent-pom:xml:site:version from/to repo (https://internal-jfrog-instance/artifactory/repos): status code: 401, reason phrase: (401) -> [Help 1] |
Did you update Maven Site Plugin as well? Did you purge your local repository? |
|
Thanks for the fast response! We don't have Maven Site Plugin in any of our projects directly configured. Our local repository is always purged / newly build inside Jenkins build pipeline using |
Then I need to see a verbose log output. |
|
I've got a "small" (but sadly) internal project to reproduce it.. the verbose output is 300mb.. This is hopfully the interesting part for you: What I found while trying to create a test project: Using <parent>
<groupId>internal</groupId>
<artifactId>internal</artifactId>
<version>2025.1</version>
<relativePath/>
</parent>creates a problem - but using a SNAPSHOT version does not create a problem / the build works - even tho none of our parent poms have site.xml published. Edit: I found why SNAPSHOT works differently.. our artifactory returns a proper 404.. not 401 for our SNAPSHOT repository |
|
I mean, have you set up authentication for that repo? Obviously, no auth has been configured. Can you fix this before we go further? Here is the code: https://github.com/apache/maven-doxia-sitetools/blob/b8f8ab4d1f5bdeaf40d944e9d7d93fc13ebed4a0/doxia-integration-tools/src/main/java/org/apache/maven/doxia/tools/DefaultSiteTool.java#L826-L932 |
|
I've reported this internally to our Artifactory Admin Team. I think it could be a bug within JFrog's Artifactory. All our repositories are public (no auth is required) Thanks for your really fast response and time! I'm gonna come back to you once I know more about this behaviour to inform you about (hopefully a fix on our side). A workaround for us (at the moment) is to downgrade maven-pmd-plugin to 3.24.0 where DOXIA 1.x is in use (which.. is more lenient in this case?) |
Thanks to hear, but honestly the older version was less lenient from my enterprise experience, but YMMV. See the comment in the work, the workaround I have implemented. Can you share logs with the old version as well? |
|
I tried to find the exact same place in the logs but that's kinda hard with 300mb.. What I found: the old version (3.24.0) never tried to access the -site.xml from our parent and therefore never failed.. That's interesting |
|
@michael-o Thanks for your time! We found the culprit.. within our Jfrog's virtual repositories.. one mirrored repository had authentication enabled.. which in turn broke our anonymous access to artefacts (-site.xml) that were not available in other mirrored repositories because Jfrog tried to search within the authentication required repo (without auth). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following this checklist to help us incorporate your
contribution quickly and easily:
for the change (usually before you start working on it). Trivial changes like typos do not
require a JIRA issue. Your pull request should address just this issue, without
pulling in other changes.
[MPMD-XXX] - Subject of the JIRA Ticket,where you replace
MPMD-XXXwith the appropriate JIRA issue. Best practiceis to use the JIRA issue title in the pull request title and in the first line of the
commit message.
mvn clean verifyto make sure basic checks pass. A more thorough check willbe performed on your pull request automatically.
mvn -Prun-its clean verify).If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.
I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
In any other case, please file an Apache Individual Contributor License Agreement.