Why is there the option to exclude a dependency of a dependency in pom.xml / maven?
I have been reading the Introduction to POM and don't understand the following. In the pom.xml you can configure dependencies, let's say we configure dependency maven-embedder. Then you can exclude a dependencies of your dependency, let's say we want to exclude maven-core from the maven-embedder dependency. In what cases would you like to do that? Wouldn’t that cause your dependency to stop working if it does not have all it dependencies? I’m obviously missing a puzzle piece here :)
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-embedder</artifactId>
<version>2.0</version>
<exclusions>
<exclusion>
<groupId>org.apache.maven</groupId>
<artifactId>maven-core</artifactId>
</exclusion>
</exclusions>
</dependency>
...
</dependencies>
Example: https://maven.apache.org/pom.html#Exclusions
java apache maven build pom.xml
asked Nov 13 '18 at 10:09
DominikDominik
1128
add a comment |
I have been reading the Introduction to POM and don't understand the following. In the pom.xml you can configure dependencies, let's say we configure dependency maven-embedder. Then you can exclude a dependencies of your dependency, let's say we want to exclude maven-core from the maven-embedder dependency. In what cases would you like to do that? Wouldn’t that cause your dependency to stop working if it does not have all it dependencies? I’m obviously missing a puzzle piece here :)
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-embedder</artifactId>
<version>2.0</version>
<exclusions>
<exclusion>
<groupId>org.apache.maven</groupId>
<artifactId>maven-core</artifactId>
</exclusion>
</exclusions>
</dependency>
...
</dependencies>
Example: https://maven.apache.org/pom.html#Exclusions
java apache maven build pom.xml
asked Nov 13 '18 at 10:09
DominikDominik
1128
add a comment |
I have been reading the Introduction to POM and don't understand the following. In the pom.xml you can configure dependencies, let's say we configure dependency maven-embedder. Then you can exclude a dependencies of your dependency, let's say we want to exclude maven-core from the maven-embedder dependency. In what cases would you like to do that? Wouldn’t that cause your dependency to stop working if it does not have all it dependencies? I’m obviously missing a puzzle piece here :)
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-embedder</artifactId>
<version>2.0</version>
<exclusions>
<exclusion>
<groupId>org.apache.maven</groupId>
<artifactId>maven-core</artifactId>
</exclusion>
</exclusions>
</dependency>
...
</dependencies>
Example: https://maven.apache.org/pom.html#Exclusions
java apache maven build pom.xml
asked Nov 13 '18 at 10:09
DominikDominik
1128
I have been reading the Introduction to POM and don't understand the following. In the pom.xml you can configure dependencies, let's say we configure dependency maven-embedder. Then you can exclude a dependencies of your dependency, let's say we want to exclude maven-core from the maven-embedder dependency. In what cases would you like to do that? Wouldn’t that cause your dependency to stop working if it does not have all it dependencies? I’m obviously missing a puzzle piece here :)
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-embedder</artifactId>
<version>2.0</version>
<exclusions>
<exclusion>
<groupId>org.apache.maven</groupId>
<artifactId>maven-core</artifactId>
</exclusion>
</exclusions>
</dependency>
...
</dependencies>
Example: https://maven.apache.org/pom.html#Exclusions
java apache maven build pom.xml
java apache maven build pom.xml
asked Nov 13 '18 at 10:09
DominikDominik
1128
asked Nov 13 '18 at 10:09
DominikDominik
1128
asked Nov 13 '18 at 10:09
DominikDominik
1128
asked Nov 13 '18 at 10:09
DominikDominik
1128
asked Nov 13 '18 at 10:09
DominikDominik
1128
1128
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Perhaps an example will help. We had a use-case for this recently.
A dependency of ours (which was quite big, but of which we needed just a couple of isolated methods) had a dependency on Rhino, but we wouldn't go anywhere near the Rhino-touching parts of the code.
In our module we were including YUI Compressor. For whatever reason, both libraries feature exactly the same fully qualified class name, but with slightly different method signatures.
The result was that including the transitive dependency of Rhino broke functionality that was previously working. YUI Compressor threw a runtime exception because the method had a different signature than it expected.
The solution was to exclude Rhino explicitly.
In general, you should not have to exclude dependencies. It usually comes as a result of modules which are poorly designed.
For example, if a module becomes too big then most users may only need a fraction of their classes or methods, so not all of their dependencies will strictly be required. In this case, the library designers should probably break the module down into a set of smaller modules.
Having the same fully qualified class name in two different libraries seems like a poor design decision as well.
answered Nov 13 '18 at 10:22
MichaelMichael
19.7k83471
add a comment |
The trick here is that you might want to use another version of the transitive dependency, not the default one. In another word, you might replace or even disable some default part of behavior.
answered Nov 13 '18 at 10:22
Volodymyr StrontsitskyiVolodymyr Strontsitskyi
212
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%2f53278552%2fwhy-is-there-the-option-to-exclude-a-dependency-of-a-dependency-in-pom-xml-mav%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Perhaps an example will help. We had a use-case for this recently.
A dependency of ours (which was quite big, but of which we needed just a couple of isolated methods) had a dependency on Rhino, but we wouldn't go anywhere near the Rhino-touching parts of the code.
In our module we were including YUI Compressor. For whatever reason, both libraries feature exactly the same fully qualified class name, but with slightly different method signatures.
The result was that including the transitive dependency of Rhino broke functionality that was previously working. YUI Compressor threw a runtime exception because the method had a different signature than it expected.
The solution was to exclude Rhino explicitly.
In general, you should not have to exclude dependencies. It usually comes as a result of modules which are poorly designed.
For example, if a module becomes too big then most users may only need a fraction of their classes or methods, so not all of their dependencies will strictly be required. In this case, the library designers should probably break the module down into a set of smaller modules.
Having the same fully qualified class name in two different libraries seems like a poor design decision as well.
answered Nov 13 '18 at 10:22
MichaelMichael
19.7k83471
add a comment |
Perhaps an example will help. We had a use-case for this recently.
A dependency of ours (which was quite big, but of which we needed just a couple of isolated methods) had a dependency on Rhino, but we wouldn't go anywhere near the Rhino-touching parts of the code.
In our module we were including YUI Compressor. For whatever reason, both libraries feature exactly the same fully qualified class name, but with slightly different method signatures.
The result was that including the transitive dependency of Rhino broke functionality that was previously working. YUI Compressor threw a runtime exception because the method had a different signature than it expected.
The solution was to exclude Rhino explicitly.
In general, you should not have to exclude dependencies. It usually comes as a result of modules which are poorly designed.
For example, if a module becomes too big then most users may only need a fraction of their classes or methods, so not all of their dependencies will strictly be required. In this case, the library designers should probably break the module down into a set of smaller modules.
Having the same fully qualified class name in two different libraries seems like a poor design decision as well.
answered Nov 13 '18 at 10:22
MichaelMichael
19.7k83471
add a comment |
Perhaps an example will help. We had a use-case for this recently.
A dependency of ours (which was quite big, but of which we needed just a couple of isolated methods) had a dependency on Rhino, but we wouldn't go anywhere near the Rhino-touching parts of the code.
In our module we were including YUI Compressor. For whatever reason, both libraries feature exactly the same fully qualified class name, but with slightly different method signatures.
The result was that including the transitive dependency of Rhino broke functionality that was previously working. YUI Compressor threw a runtime exception because the method had a different signature than it expected.
The solution was to exclude Rhino explicitly.
In general, you should not have to exclude dependencies. It usually comes as a result of modules which are poorly designed.
For example, if a module becomes too big then most users may only need a fraction of their classes or methods, so not all of their dependencies will strictly be required. In this case, the library designers should probably break the module down into a set of smaller modules.
Having the same fully qualified class name in two different libraries seems like a poor design decision as well.
answered Nov 13 '18 at 10:22
MichaelMichael
19.7k83471
Perhaps an example will help. We had a use-case for this recently.
A dependency of ours (which was quite big, but of which we needed just a couple of isolated methods) had a dependency on Rhino, but we wouldn't go anywhere near the Rhino-touching parts of the code.
In our module we were including YUI Compressor. For whatever reason, both libraries feature exactly the same fully qualified class name, but with slightly different method signatures.
The result was that including the transitive dependency of Rhino broke functionality that was previously working. YUI Compressor threw a runtime exception because the method had a different signature than it expected.
The solution was to exclude Rhino explicitly.
In general, you should not have to exclude dependencies. It usually comes as a result of modules which are poorly designed.
For example, if a module becomes too big then most users may only need a fraction of their classes or methods, so not all of their dependencies will strictly be required. In this case, the library designers should probably break the module down into a set of smaller modules.
Having the same fully qualified class name in two different libraries seems like a poor design decision as well.
answered Nov 13 '18 at 10:22
MichaelMichael
19.7k83471
answered Nov 13 '18 at 10:22
MichaelMichael
19.7k83471
answered Nov 13 '18 at 10:22
MichaelMichael
19.7k83471
answered Nov 13 '18 at 10:22
MichaelMichael
19.7k83471
19.7k83471
add a comment |
add a comment |
The trick here is that you might want to use another version of the transitive dependency, not the default one. In another word, you might replace or even disable some default part of behavior.
answered Nov 13 '18 at 10:22
Volodymyr StrontsitskyiVolodymyr Strontsitskyi
212
add a comment |
The trick here is that you might want to use another version of the transitive dependency, not the default one. In another word, you might replace or even disable some default part of behavior.
answered Nov 13 '18 at 10:22
Volodymyr StrontsitskyiVolodymyr Strontsitskyi
212
add a comment |
The trick here is that you might want to use another version of the transitive dependency, not the default one. In another word, you might replace or even disable some default part of behavior.
answered Nov 13 '18 at 10:22
Volodymyr StrontsitskyiVolodymyr Strontsitskyi
212
The trick here is that you might want to use another version of the transitive dependency, not the default one. In another word, you might replace or even disable some default part of behavior.
answered Nov 13 '18 at 10:22
Volodymyr StrontsitskyiVolodymyr Strontsitskyi
212
answered Nov 13 '18 at 10:22
Volodymyr StrontsitskyiVolodymyr Strontsitskyi
212
answered Nov 13 '18 at 10:22
Volodymyr StrontsitskyiVolodymyr Strontsitskyi
212
answered Nov 13 '18 at 10:22
Volodymyr StrontsitskyiVolodymyr Strontsitskyi
212
212
add a comment |
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%2f53278552%2fwhy-is-there-the-option-to-exclude-a-dependency-of-a-dependency-in-pom-xml-mav%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
