Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken dependency in 7.3.x branch (javamoney) #346

Closed
svenkarol opened this issue May 16, 2021 · 6 comments
Closed

Broken dependency in 7.3.x branch (javamoney) #346

svenkarol opened this issue May 16, 2021 · 6 comments
Assignees
Labels
in: infrastructure Build related tasks etc. prio: 1 - high High priority issues type: bug Bugs
Milestone

Comments

@svenkarol
Copy link

Hi folks,

we discovered that there's a problem on the 7.3.x branch with a dependency to the moneta-core 1.4-tud. Fresh building of any project that I tried relying on that version of Salespoint and the st-lab-parent 2.3.0 fails with an HTTP-401 Error on that dependency.

The specific message I get is:
BUILD-SNAPSHOT: Failed to collect dependencies at de.tudresden.inf.st:salespoint-framework:jar:7.3.0 -> org.javamoney.moneta:moneta-core:jar:1.4-tud: Failed to read artifact descriptor for org.javamoney.moneta:moneta-core:jar:1.4-tud: Could not transfer artifact org.javamoney:moneta-parent:pom:1.4-tud from/to spring-libs-milestone (https://repo.spring.io/libs-milestone): Access denied to https://repo.spring.io/libs-milestone/org/javamoney/moneta-parent/1.4-tud/moneta-parent-1.4-tud.pom. Error code 401, -> [Help 1]

Steps to reproduce:

  • clear cache in user/.m2
  • trigger a new build, e.g., in Videoshop ./mvnw clean package

Workaround: create a local repository for that dependency (works from command-line but not so much on Eclipse Spring Tools)

@martinmo
Copy link
Contributor

Hi, that's interesting, until today I didn't know that Salespoint used a custom moneta build ;-) (my guess is that version 1.4-tud of moneta is/was a custom moneta build which works around a behavior change as described in e99e67b).

Your maven error message says it tried to load it from repo.spring.io – that's odd, I am sure that such a custom build should be found on our maven repo (under https://st.inf.tu-dresden.de/SalesPoint/repository/). However, the URL https://st.inf.tu-dresden.de/SalesPoint/repository/org/javamoney/moneta-parent/1.4-tud/moneta-parent-1.4-tud.pom gives a 404.

@odrotbohm do you have an idea what could be wrong?

@svenkarol
Copy link
Author

svenkarol commented May 26, 2021

Hi! Is there any chance to create a new release with a cherry-pick of e99e67b ? I did that on my fork, and it seems to fix the issue. However, two test cases fail on my local build, but they those fail on the 7.3.0 tag too.

@martinmo
Copy link
Contributor

Hi, yes I'm going to try it ASAP. Because I am usually not doing the releases, there is a little chance that I mess things up 😬 I'll give my best. Btw, sorry for the delayed answer, last week I was on vacation.

@martinmo martinmo self-assigned this Jun 1, 2021
@martinmo martinmo added in: infrastructure Build related tasks etc. prio: 1 - high High priority issues type: bug Bugs labels Jun 1, 2021
@martinmo martinmo added this to the 7.3.1 milestone Jun 1, 2021
@martinmo
Copy link
Contributor

martinmo commented Jun 1, 2021

Interestingly, when I try to build the current clean 7.3.x branch with mvn clean test, Maven prints this line when downloading moneta:

Downloading from maven-default-http-blocker: http://0.0.0.0/org/javamoney/moneta-parent/1.4-SNAPSHOT/maven-metadata.xml

This seems to be a new feature in Maven 3.8.1 to block externel non-https repositories by default.

martinmo pushed a commit that referenced this issue Jun 1, 2021
Tweaked the implementation of MonetaryAmountAttributeConverter to workaround JavaMoney/jsr354-ri#357, as in 1.4 the toString() method returns a formatted value. We now extract currency code and numeric value explicitly ourselves.

[This is a cherry-pick of e99e67b in main, see issue #345.]
@martinmo martinmo closed this as completed Jun 1, 2021
martinmo pushed a commit that referenced this issue Jun 1, 2021
Tweaked the implementation of MonetaryAmountAttributeConverter to workaround JavaMoney/jsr354-ri#357, as in 1.4 the toString() method returns a formatted value. We now extract currency code and numeric value explicitly ourselves.

[This is a cherry-pick of e99e67b in main, see issue #345.]
@martinmo
Copy link
Contributor

martinmo commented Jun 1, 2021

I have created the 7.3.1 release, but it didn't go as flawless as described in the readme 😁 The jars should be available in our repository. However, somehow the documentation on the website is still for 7.3.0, I am now trying to sort this out.

@svenkarol
Copy link
Author

Great! Thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: infrastructure Build related tasks etc. prio: 1 - high High priority issues type: bug Bugs
Projects
None yet
Development

No branches or pull requests

2 participants