MavenArtifactRepository getUrl() / getArtifactUrls() / artifactUrls() all expect URI's, not URLs


(Terence Kent) #1

While going through the 1.10 API, I noticed this typo in MavenArtifactRepository. All “Url” methods on the MavenArtifactRepository object actually work with java.net.URI objects, not java.net.URL objects.

It’s a pretty small thing, but I thought I would mention it since I assume the fix is easy.


(Peter Niederwieser) #2

These methods accept a ‘String’, ‘File’, ‘URI’, ‘URL’, etc. Those that have a return value intentionally return a ‘java.net.URI’.


(Terence Kent) #3

I was aware that the “set” methods would convert things into a URI, but I figured the naming was unintentional. Anyway, seems like the name/return value combination was not a mistake.


(Peter Niederwieser) #4

In general, ‘java.net.URI’ is a better representation for URLs than ‘java.net.URL’. The latter is mostly useful for accessing URLs.


(Terence Kent) #5

Please don’t get me wrong, I don’t disagree with that at all! I use URIs whenever possible as well, my comment is just about the names. Since it’s such a small thing, I probably shouldn’t have brought it up.


(Peter Niederwieser) #6

What’s wrong with the naming? These are URLs, it’s just that we prefer to represent them using ‘java.net.URI’. If you will, the confusion stems from the Java class library and its implementation of ‘URI’ and ‘URL’.


(Terence Kent) #7

What’s wrong the naming? Nothing, if it was named that way on purpose. When working with java (or a java-based language), I would expect a getUrl() method to return a URL. If it returns a URI, I would have expected it to be named getUri() instead. It’s not immediately clear to me what benefit there is in naming these methods with a Url suffix instead of Uri suffix, so I assumed it was just a mistake. It’s pretty clear from your responses that this was not an oversight, but intentional. So there is nothing wrong.


(Peter Niederwieser) #8

It was done in this way because logically, the methods accept/return an URL, not an URI (which is more general). It’s just that ‘java.net.URL’ is a poor general-purpose representation of an URL.