Skip to content
New issue

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

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

Already on GitHub? # 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!

# for free to join this conversation on GitHub. Already have an account? # 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