Server configuration httpHeaders ignored

[eroznik-sr]

Hello,
I am using version 2.7 to manage dependencies(properties + parent) using the following commands:

• mvn versions:display-parent-updates
• mvn versions:display-property-updates
• mvn versions:update-parent
• mvn versions:update-properties

The project I am using this on has configured a custom repository(Gitlab) which requires a custom header for authorization.

The project pom.xml has a repository(lets say its id is "custom-repo"), than i have a custom server entry in my .m2/settings.xml configured to add a custom HTTP header:
<server> <id>custom-repo</id> <configuration> <httpHeaders> <property> <name>Private-Token</name> <value>super-secret-token</value> </property> </httpHeaders> </configuration> </server>

I can confirm this setup works when pulling new dependencies, I am encountering only issues when using the versions plugin.

The behavior of the underlying HTTP client was confirmed when i enabled Maven HTTP logging. When Maven pulls new dependencies(not available locally) it adds the custom authorization token to the outgoing requests, when versions plugin checks for new versions - the header isn't added to the request so Gitlab won't accept the request.

Best regards
Etien

[eroznik-sr]

Hey all, just a quick update:

After several hours of debugging what might be the issues I found out that Maven 3.x uses another system for dependency resolution - Aether.
I prepared a working fix for Versions plugin, its working locally, I have to fix some tests and prepare a MR for review.

The implementation replaces ArtifactMetadataSource with RepositorySystem, hopefully this wont be an issue(e.g. compatibility with older Maven versions)

[waschmittel]

Any news on this? I also stumbled upon this, which cost me about an hour of debugging (because even with -X there is no indication as to why the metadata cannot be found)

Are there reasons not to apply @eroznik's fix?

[kayoza]

I hope this will come in a release soon because we have the same metadata problem, and insufficient debug logging makes it hard to find the reason why updating fails.

[armhart]

We have the same issue.

As a work-around we use this script in our GitLab yml:

.build_function: &update_to_latest_framework |
echo "----- Start updating framework version for "$APPLICATION_NAME" in $PROJECT_BRANCH -----"
currentFramework=$(grep version pom.xml | grep -v -e '<?xml|~'| head -n 1 | sed 's/[[:space:]]//g' | sed -E 's/<.{0,1}version>//g' | awk '{printf "%s ",$0} END {print ""}') || true
currentFramework=echo ${currentFramework} | sed 's/ *$//g' || true
echo "Current Frameworkversion is: ${currentFramework}"
frameworkLatestVersionXml=$(curl --fail -k -H "Authorization: Bearer ${REPOSITORY_TOKEN}" https://artifactory.bla/artifactory/releases/nl/blueriq/parent/maven-metadata.xml )
frameworkLatestVersion=$(echo $frameworkLatestVersionXml | grep "." | sed -n 's:.(.).:\1:p')
selectedFramework=$frameworkLatestVersion
echo "Selected Frameworkversion is: $selectedFramework"
if [[ ${selectedFramework} == ${currentFramework} ]]
then
echo "Your framework is already the same as the requested version."
else
echo "-- Update Framework version to $selectedFramework"
# Broken: mvn $MAVEN_CLI_OPTS versions:update-parent -DparentVersion=[$selectedFramework]
sed -i -e "s|$currentFramework|$selectedFramework|" pom.xml
fi

[jkroepke]

See: https://gitlab.com/gitlab-org/gitlab/-/issues/277385 for supporting auth basic for gitlab.

[waschmittel]

I see this project is still active, but this issue has been auto-closed apparently. Does this mean that there is no hope of the fix being merged?

[eroznik]

Hopefully we get a response from one of the maintainers, at least a suggestion on what to change within the PR so this gets merged. It seems that Gitlab won't be fixing this anytime soon..