How to get a list of maven dependencies and the repositories they were fetched from
I'd like to, given a pom.xml file, expand the transitive dependencies, and for each direct and transitive dependency, list which repositories maven is fetching it from.
With the maven-dependency-plugin I can do
mvn dependency:tree to get the transitive dependency tree, but no repository info is included
mvn dependency:list-repositories to get a list of repositories used, but no dependency info is included
mvn dependency:get -Dartifact=<...> to fetch a single artifact and transitive dependencies, but it seems to fetch a lot more than needed and I can't tell which I actually care about.
java maven
asked Aug 18 '16 at 20:53
YunchiYunchi
5,12011116
add a comment |
I'd like to, given a pom.xml file, expand the transitive dependencies, and for each direct and transitive dependency, list which repositories maven is fetching it from.
With the maven-dependency-plugin I can do
mvn dependency:tree to get the transitive dependency tree, but no repository info is included
mvn dependency:list-repositories to get a list of repositories used, but no dependency info is included
mvn dependency:get -Dartifact=<...> to fetch a single artifact and transitive dependencies, but it seems to fetch a lot more than needed and I can't tell which I actually care about.
java maven
asked Aug 18 '16 at 20:53
YunchiYunchi
5,12011116
What kind of problem would you like to solve?
– khmarbaise
Aug 20 '16 at 15:24
I'm trying to migrate our codebase to use Bazel, which does not support transitive dependency resolution. I'd like to use maven to resolve the dependencies, use the output to generate Bazel rules for downloading and dependencies, and let Bazel do the work of downloading.
– Yunchi
Aug 25 '16 at 18:02
add a comment |
I'd like to, given a pom.xml file, expand the transitive dependencies, and for each direct and transitive dependency, list which repositories maven is fetching it from.
With the maven-dependency-plugin I can do
mvn dependency:tree to get the transitive dependency tree, but no repository info is included
mvn dependency:list-repositories to get a list of repositories used, but no dependency info is included
mvn dependency:get -Dartifact=<...> to fetch a single artifact and transitive dependencies, but it seems to fetch a lot more than needed and I can't tell which I actually care about.
java maven
asked Aug 18 '16 at 20:53
YunchiYunchi
5,12011116
I'd like to, given a pom.xml file, expand the transitive dependencies, and for each direct and transitive dependency, list which repositories maven is fetching it from.
With the maven-dependency-plugin I can do
mvn dependency:tree to get the transitive dependency tree, but no repository info is included
mvn dependency:list-repositories to get a list of repositories used, but no dependency info is included
mvn dependency:get -Dartifact=<...> to fetch a single artifact and transitive dependencies, but it seems to fetch a lot more than needed and I can't tell which I actually care about.
java maven
java maven
asked Aug 18 '16 at 20:53
YunchiYunchi
5,12011116
asked Aug 18 '16 at 20:53
YunchiYunchi
5,12011116
asked Aug 18 '16 at 20:53
YunchiYunchi
5,12011116
asked Aug 18 '16 at 20:53
YunchiYunchi
5,12011116
asked Aug 18 '16 at 20:53
YunchiYunchi
5,12011116
5,12011116
What kind of problem would you like to solve?
– khmarbaise
Aug 20 '16 at 15:24
I'm trying to migrate our codebase to use Bazel, which does not support transitive dependency resolution. I'd like to use maven to resolve the dependencies, use the output to generate Bazel rules for downloading and dependencies, and let Bazel do the work of downloading.
– Yunchi
Aug 25 '16 at 18:02
add a comment |
What kind of problem would you like to solve?
– khmarbaise
Aug 20 '16 at 15:24
I'm trying to migrate our codebase to use Bazel, which does not support transitive dependency resolution. I'd like to use maven to resolve the dependencies, use the output to generate Bazel rules for downloading and dependencies, and let Bazel do the work of downloading.
– Yunchi
Aug 25 '16 at 18:02
What kind of problem would you like to solve?
– khmarbaise
Aug 20 '16 at 15:24
What kind of problem would you like to solve?
– khmarbaise
Aug 20 '16 at 15:24
I'm trying to migrate our codebase to use Bazel, which does not support transitive dependency resolution. I'd like to use maven to resolve the dependencies, use the output to generate Bazel rules for downloading and dependencies, and let Bazel do the work of downloading.
– Yunchi
Aug 25 '16 at 18:02
I'm trying to migrate our codebase to use Bazel, which does not support transitive dependency resolution. I'd like to use maven to resolve the dependencies, use the output to generate Bazel rules for downloading and dependencies, and let Bazel do the work of downloading.
– Yunchi
Aug 25 '16 at 18:02
add a comment |
1 Answer
1
active
oldest
votes
I don't think that there is a plugin that does that. And I think the reason for that is that no one is really interested in that kind of information.
Consider having dependencies to released artifacts. Once they are downloaded to your local repo, Maven won't bother downloading them again (unless you delete them); all future resolutions to that artifact will be done through the local repo.
Sure, the file _remote.repositories in your local repo's artifact directory will contain the symbolical name of the repo it was downloaded from, whose actual URL might or might not be same over time.
The philosophy being this is that Maven coordinates are global. For example, a given release of (say) commons-codec:commons-codec:1.10 must be the same regardless of where it came from. Otherwise, if certain releases were to be different depending on where they came from, then everything would fall apart. Because of this, no one cares where dependency came from.
Snapshot dependencies are a different story, but you shouldn't rely on them for too long because you don't want to release your stuff based on dependencies that might change in the future. Usually, you are in control of where you want your snapshot dependencies to come from, so the whole point of finding out where your dependencies come from becomes futile.
Sometimes though, transitive dependencies will include POMs that specify additional repos for Maven to fetch sub-dependencies from. And sometimes these repositories are decommisioned or discontinued, breaking the dependency chain. In that case, you might want to block or reroute them in your settings.xml. A simple scan through all the POMs in your local repo is usually enough to sniff them out:
# Linux/Unix
%> find <your local repo> -name '*.pom' | xargs grep -c '<repositories>' | grep -v ':0'
This, together with mvn dependency:tree, should be enough to find out if a transitive dependency is dependent on a misbehaving repository.
answered Aug 19 '16 at 10:55
DanielDaniel
2,62121522
Thanks for the detailed answer. For my use case, I really do need at least the full dependency tree (see my comment on the question). It looks likemvn dependency:treedoes not report transitive dependencies if the dep is already a direct dependency in my pom.xml. Is there any way to force it to enumerate the full tree?
– Yunchi
Aug 25 '16 at 18:06
mvn dependency:tree -Dverbose=trueought to do the trick.
– Daniel
Aug 25 '16 at 20:04
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f39027312%2fhow-to-get-a-list-of-maven-dependencies-and-the-repositories-they-were-fetched-f%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I don't think that there is a plugin that does that. And I think the reason for that is that no one is really interested in that kind of information.
Consider having dependencies to released artifacts. Once they are downloaded to your local repo, Maven won't bother downloading them again (unless you delete them); all future resolutions to that artifact will be done through the local repo.
Sure, the file _remote.repositories in your local repo's artifact directory will contain the symbolical name of the repo it was downloaded from, whose actual URL might or might not be same over time.
The philosophy being this is that Maven coordinates are global. For example, a given release of (say) commons-codec:commons-codec:1.10 must be the same regardless of where it came from. Otherwise, if certain releases were to be different depending on where they came from, then everything would fall apart. Because of this, no one cares where dependency came from.
Snapshot dependencies are a different story, but you shouldn't rely on them for too long because you don't want to release your stuff based on dependencies that might change in the future. Usually, you are in control of where you want your snapshot dependencies to come from, so the whole point of finding out where your dependencies come from becomes futile.
Sometimes though, transitive dependencies will include POMs that specify additional repos for Maven to fetch sub-dependencies from. And sometimes these repositories are decommisioned or discontinued, breaking the dependency chain. In that case, you might want to block or reroute them in your settings.xml. A simple scan through all the POMs in your local repo is usually enough to sniff them out:
# Linux/Unix
%> find <your local repo> -name '*.pom' | xargs grep -c '<repositories>' | grep -v ':0'
This, together with mvn dependency:tree, should be enough to find out if a transitive dependency is dependent on a misbehaving repository.
answered Aug 19 '16 at 10:55
DanielDaniel
2,62121522
Thanks for the detailed answer. For my use case, I really do need at least the full dependency tree (see my comment on the question). It looks likemvn dependency:treedoes not report transitive dependencies if the dep is already a direct dependency in my pom.xml. Is there any way to force it to enumerate the full tree?
– Yunchi
Aug 25 '16 at 18:06
mvn dependency:tree -Dverbose=trueought to do the trick.
– Daniel
Aug 25 '16 at 20:04
add a comment |
I don't think that there is a plugin that does that. And I think the reason for that is that no one is really interested in that kind of information.
Consider having dependencies to released artifacts. Once they are downloaded to your local repo, Maven won't bother downloading them again (unless you delete them); all future resolutions to that artifact will be done through the local repo.
Sure, the file _remote.repositories in your local repo's artifact directory will contain the symbolical name of the repo it was downloaded from, whose actual URL might or might not be same over time.
The philosophy being this is that Maven coordinates are global. For example, a given release of (say) commons-codec:commons-codec:1.10 must be the same regardless of where it came from. Otherwise, if certain releases were to be different depending on where they came from, then everything would fall apart. Because of this, no one cares where dependency came from.
Snapshot dependencies are a different story, but you shouldn't rely on them for too long because you don't want to release your stuff based on dependencies that might change in the future. Usually, you are in control of where you want your snapshot dependencies to come from, so the whole point of finding out where your dependencies come from becomes futile.
Sometimes though, transitive dependencies will include POMs that specify additional repos for Maven to fetch sub-dependencies from. And sometimes these repositories are decommisioned or discontinued, breaking the dependency chain. In that case, you might want to block or reroute them in your settings.xml. A simple scan through all the POMs in your local repo is usually enough to sniff them out:
# Linux/Unix
%> find <your local repo> -name '*.pom' | xargs grep -c '<repositories>' | grep -v ':0'
This, together with mvn dependency:tree, should be enough to find out if a transitive dependency is dependent on a misbehaving repository.
answered Aug 19 '16 at 10:55
DanielDaniel
2,62121522
Thanks for the detailed answer. For my use case, I really do need at least the full dependency tree (see my comment on the question). It looks likemvn dependency:treedoes not report transitive dependencies if the dep is already a direct dependency in my pom.xml. Is there any way to force it to enumerate the full tree?
– Yunchi
Aug 25 '16 at 18:06
mvn dependency:tree -Dverbose=trueought to do the trick.
– Daniel
Aug 25 '16 at 20:04
add a comment |
I don't think that there is a plugin that does that. And I think the reason for that is that no one is really interested in that kind of information.
Consider having dependencies to released artifacts. Once they are downloaded to your local repo, Maven won't bother downloading them again (unless you delete them); all future resolutions to that artifact will be done through the local repo.
Sure, the file _remote.repositories in your local repo's artifact directory will contain the symbolical name of the repo it was downloaded from, whose actual URL might or might not be same over time.
The philosophy being this is that Maven coordinates are global. For example, a given release of (say) commons-codec:commons-codec:1.10 must be the same regardless of where it came from. Otherwise, if certain releases were to be different depending on where they came from, then everything would fall apart. Because of this, no one cares where dependency came from.
Snapshot dependencies are a different story, but you shouldn't rely on them for too long because you don't want to release your stuff based on dependencies that might change in the future. Usually, you are in control of where you want your snapshot dependencies to come from, so the whole point of finding out where your dependencies come from becomes futile.
Sometimes though, transitive dependencies will include POMs that specify additional repos for Maven to fetch sub-dependencies from. And sometimes these repositories are decommisioned or discontinued, breaking the dependency chain. In that case, you might want to block or reroute them in your settings.xml. A simple scan through all the POMs in your local repo is usually enough to sniff them out:
# Linux/Unix
%> find <your local repo> -name '*.pom' | xargs grep -c '<repositories>' | grep -v ':0'
This, together with mvn dependency:tree, should be enough to find out if a transitive dependency is dependent on a misbehaving repository.
answered Aug 19 '16 at 10:55
DanielDaniel
2,62121522
I don't think that there is a plugin that does that. And I think the reason for that is that no one is really interested in that kind of information.
Consider having dependencies to released artifacts. Once they are downloaded to your local repo, Maven won't bother downloading them again (unless you delete them); all future resolutions to that artifact will be done through the local repo.
Sure, the file _remote.repositories in your local repo's artifact directory will contain the symbolical name of the repo it was downloaded from, whose actual URL might or might not be same over time.
The philosophy being this is that Maven coordinates are global. For example, a given release of (say) commons-codec:commons-codec:1.10 must be the same regardless of where it came from. Otherwise, if certain releases were to be different depending on where they came from, then everything would fall apart. Because of this, no one cares where dependency came from.
Snapshot dependencies are a different story, but you shouldn't rely on them for too long because you don't want to release your stuff based on dependencies that might change in the future. Usually, you are in control of where you want your snapshot dependencies to come from, so the whole point of finding out where your dependencies come from becomes futile.
Sometimes though, transitive dependencies will include POMs that specify additional repos for Maven to fetch sub-dependencies from. And sometimes these repositories are decommisioned or discontinued, breaking the dependency chain. In that case, you might want to block or reroute them in your settings.xml. A simple scan through all the POMs in your local repo is usually enough to sniff them out:
# Linux/Unix
%> find <your local repo> -name '*.pom' | xargs grep -c '<repositories>' | grep -v ':0'
This, together with mvn dependency:tree, should be enough to find out if a transitive dependency is dependent on a misbehaving repository.
answered Aug 19 '16 at 10:55
DanielDaniel
2,62121522
answered Aug 19 '16 at 10:55
DanielDaniel
2,62121522
answered Aug 19 '16 at 10:55
DanielDaniel
2,62121522
answered Aug 19 '16 at 10:55
DanielDaniel
2,62121522
2,62121522
Thanks for the detailed answer. For my use case, I really do need at least the full dependency tree (see my comment on the question). It looks likemvn dependency:treedoes not report transitive dependencies if the dep is already a direct dependency in my pom.xml. Is there any way to force it to enumerate the full tree?
– Yunchi
Aug 25 '16 at 18:06
mvn dependency:tree -Dverbose=trueought to do the trick.
– Daniel
Aug 25 '16 at 20:04
add a comment |
Thanks for the detailed answer. For my use case, I really do need at least the full dependency tree (see my comment on the question). It looks likemvn dependency:treedoes not report transitive dependencies if the dep is already a direct dependency in my pom.xml. Is there any way to force it to enumerate the full tree?
– Yunchi
Aug 25 '16 at 18:06
mvn dependency:tree -Dverbose=trueought to do the trick.
– Daniel
Aug 25 '16 at 20:04
Thanks for the detailed answer. For my use case, I really do need at least the full dependency tree (see my comment on the question). It looks like
mvn dependency:tree does not report transitive dependencies if the dep is already a direct dependency in my pom.xml. Is there any way to force it to enumerate the full tree?– Yunchi
Aug 25 '16 at 18:06
Thanks for the detailed answer. For my use case, I really do need at least the full dependency tree (see my comment on the question). It looks like
mvn dependency:tree does not report transitive dependencies if the dep is already a direct dependency in my pom.xml. Is there any way to force it to enumerate the full tree?– Yunchi
Aug 25 '16 at 18:06
mvn dependency:tree -Dverbose=true ought to do the trick.– Daniel
Aug 25 '16 at 20:04
mvn dependency:tree -Dverbose=true ought to do the trick.– Daniel
Aug 25 '16 at 20:04
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f39027312%2fhow-to-get-a-list-of-maven-dependencies-and-the-repositories-they-were-fetched-f%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
What kind of problem would you like to solve?
– khmarbaise
Aug 20 '16 at 15:24
I'm trying to migrate our codebase to use Bazel, which does not support transitive dependency resolution. I'd like to use maven to resolve the dependencies, use the output to generate Bazel rules for downloading and dependencies, and let Bazel do the work of downloading.
– Yunchi
Aug 25 '16 at 18:02