3

I have a fork artifact from one who stored in repo.maven.apache.org, it has the same group, artifact id and version. My fork is stored in my.repo.hostname.

How can I force Maven to use artifact from my repository, not from Maven Central?

  • 3
    Is it the same artifact, or did you make changes to it and then repackage it with the same group/artifact/version? It seems that if you "forked" it, you should at least change the group name, otherwise this is misleading at best. – Todd Jan 08 '16 at 13:54
  • Easy change: change the version to a more appropriate one; a fork with the same version should be nothing more than the same thing the you forked, huh?! – x80486 Jan 08 '16 at 13:54
  • @Todd Yes, I made changes to it and then repackage it with the same group/artifact/version. My artifact is used as replacement for official artifact from Maven central, so I don't want to change artifact group/artifact id/version. – Dmitry Sergeev Jan 08 '16 at 13:57
  • A smart guy will come in (the new guy), and figure he can fix a whole bunch of issues by changing the artifact to the latest version. Gone your changes. To avoid this, but the artifiact under your own group-id. Even with all already said, I cannot see a benefit of trying to keep the original group/artifact-id if you are not going to commit back your changes to the community. – YoYo Jan 08 '16 at 21:40

1 Answers1

3

When forking an original artifact, you should use classifiers to make a distinction.

So, if the original artifact was:

<dependency>
    <groupId>com.sample</groupId>
    <artifactId>library</artifactId>
    <version>1.0</version>
</dependency>

You can have your fork as:

<dependency>
    <groupId>com.sample</groupId>
    <artifactId>library</artifactId>
    <version>1.0</version>
    <classifier>myfork</classifier>
</dependency>

Advantages of this approach:

  • You keep traceability with original Maven coordinates, so it is clear from where the fork was made
  • You make it clear it is a different version (or a fork) of that specific version of that specific artifact
  • You don't create confusion if someone else is looking at your POM and, say, tries to build it in another machine with no access to your repository (providing the fork) and then having different behavior or even errors because using the original one: maintainability is a big gain.
  • You use Maven standards (see below)

For the classifier name (it's a free string) I often found useful to provide additional information:

  • if you are working in a company, add the company name to the classifier, so if a contract/external needs to work with it, it is immediately clear that it was a fork made by the concerned company
  • if it's a patch or an additional feature (or for a specific OS or Java version), try to make it clear as well
  • Use your common sense, like if it was a tag and you would use it later on for search

Using classifier in this case it is also a Maven recommended approach, from official documentation:

The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number.

As such, no repository order or any other type of issue would be present and your build will gain clarity, reproducibility and maintainability. Hope it might help.

A_Di-Matteo
  • 26,902
  • 7
  • 94
  • 128
  • The intent of the classifier is to have the same binary built different ways. A good example would be a version with added debug information, additional localization, or added instrumentation/logging. I would advise against using it otherwise. – YoYo Jan 08 '16 at 21:33
  • @JoD. it's a point of debate I would say, by experience I've seen in several companies the same use case (forked/patched libraries) and classifiers were a good solution, much better than reusing same GAV at least, which once really leaded to confusion and not-easy troubleshooting, because you just lose information, while with classifier you make it clear: same GAV, patched/forked version, which is similar to many use case out there (same GAV, jdk4 version or same GAV, Linux version, 64bit version and so on). – A_Di-Matteo Jan 08 '16 at 21:37
  • @ADiMatteo see my comment to the OP about 'the smart/new guy' coming in. If they are your changes, and not the communities changes, then dont put it in the same group/artifact-id space. But still add classifiers for your different use cases too, that remains. – YoYo Jan 08 '16 at 21:44
  • 1
    @JoD. I still think changing GAV is a loss of traceability. ArtifactId may be not enough, looking at dependencies I want to see from exactly (which group, artifact AND version) where your patch came from, so that if I want I can also test against a newer version later on and see if I still need your patch (given good non regressions test, of course), but I know it's a patch for that official GAV. Again, it's a point of debate. By experience, I prefer this approach. Also, keep in mind using classifier it will not be the same GAV, it will be a new GAVC (that is, unique). – A_Di-Matteo Jan 08 '16 at 21:52
  • 1
    @ADiMatteo. Well, still not a fan, but for the Same G/A id, it is at least much better with the classifier. The different/added classifier will be a good visual cue for the 'new' guy. I concede. – YoYo Jan 08 '16 at 22:49