[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346373#comment-346373
]
Tibor Digana commented on MNG-2205:
---
@Paul
We shouldn't introduce a new XML element like .
The worst and still possible we can do is to introduce new scope.
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345904#comment-345904
]
Jason van Zyl commented on MNG-2205:
I still think this would be confusing to have one behaviour with the 4.0.0
version of the POM and another behaviour with the 5.0.0 version of the model. I
honestly think this would be confusing and after several years with this
behaviour making a new scope name for the new behaviour is the way to go.
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346252#comment-346252
]
Paul Benedict commented on MNG-2205:
If this conversation is really about controlling the transitive nature of a
dependency, I think we should introduce a boolean tag. That won't
need a version update since it's a new tag (no one has used it before). Then
instead of inventing new scopes, we can just let programmers determine it for
themselves based on their own needs.
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346246#comment-346246
]
Tibor Digana commented on MNG-2205:
---
I agree with Jason that the model version should not change.
I agree with other commiters saying that XML schema should not be changed.
Therefore a new scope should be introduced and we can call it something like
"nonrunnable".
Thus the behavior of scope "provided" should not change in spec.
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345437#comment-345437
]
Michael Osipov commented on MNG-2205:
-
As a side note: if you introduce model version 5.0.0, we could easily fix the
provided scope and leave it in 4.0.0 as-is.
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342703#comment-342703
]
Jason van Zyl commented on MNG-2205:
I would love it if you concentrated fixing the hundreds of bugs in Maven. Our
attempt is in our integrations tests of which there are hundreds which do
exactly that: capture behaviour across Maven versions:
https://github.com/apache/maven-integration-testing
Feel free to augment. Also make sure that what you're asking for is actually
happening in the core and is not a function of a particular plugin which does
its own resolution. The WAR plugin for example.
Look forward to your patches.
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341795#comment-341795
]
Tibor Digana commented on MNG-2205:
---
@Jason
The problem is that the behavior has changed after Maven 2.2.1.
New keywords would not be acceptable by the community in my guess - this may
take quite long time to implement and finally the Maven users may get lost.
I prefer simplicity and correct behavior against huge number of keywords.
The right solution would be to concentrate on fixing hunderds of bugs in the
Maven project. First of all to write tests against Maven 2 behavior and then
run the same tests on Maven 3, let's see what will happen.
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341528#comment-341528
]
Jason van Zyl commented on MNG-2205:
It is unlikely we will change the behavior of the provided scope, but it would
be possible to create a new 'provided-transitive' if we really wanted this.
Changing the definition of existing scopes would be problematic.
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335883#comment-335883
]
Tibor Digana edited comment on MNG-2205 at 11/17/13 9:11 AM:
-
I do not know if the bug is definitely in Maven core or maven-war-plugin 2.2 or
2.4.
The efective-pom correctly resolves the modules DAO(jar) and Services(jar).
For sure I will rollback to Maven 2.2.1 because there the profiles in DAO-BOM
and Services-BOM work as expected.
{code
reactor's parent(pom)
^
+-+
| ^
| |
DAO(jar) -> DAO-BOM(pom)
^ ^
| |
Services(jar) -> Services-BOM(pom)
^
|
webapp(war)}
The development profile has dependencies in DAO(jar):
org.hibernate
hibernate-core
4.2.6.Final
Th production profile has dependencies in DAO(jar):
org.hibernate
hibernate-core
4.2.6.Final
org.jboss.spec.javax.transaction
jboss-transaction-api_1.1_spec
org.jboss.spec.javax.transaction
jboss-transaction-api_1.1_spec
1.0.1.Final
provided
was (Author: tibor17):
I do not know if the bug is definitely in Maven core or maven-war-plugin
2.2 or 2.4.
The efective-pom correctly resolves the modules DAO(jar) and Services(jar).
For sure I will rollback to Maven 2.2.1 because there the profiles in DAO-BOM
and Services-BOM work as expected.
reactor's parent(pom)
^
+-+
| ^
| |
DAO(jar) -> DAO-BOM(pom)
^ ^
| |
Services(jar) -> Services-BOM(pom)
^
|
webapp(war)
The development profile has dependencies in DAO(jar):
org.hibernate
hibernate-core
4.2.6.Final
Th production profile has dependencies in DAO(jar):
org.hibernate
hibernate-core
4.2.6.Final
org.jboss.spec.javax.transaction
jboss-transaction-api_1.1_spec
org.jboss.spec.javax.transaction
jboss-transaction-api_1.1_spec
1.0.1.Final
provided
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335883#comment-335883
]
Tibor Digana commented on MNG-2205:
---
I do not know if the bug is definitely in Maven core or maven-war-plugin 2.2 or
2.4.
The efective-pom correctly resolves the modules DAO(jar) and Services(jar).
For sure I will rollback to Maven 2.2.1 because there the profiles in DAO-BOM
and Services-BOM work as expected.
reactor's parent(pom)
^
+-+
| ^
| |
DAO(jar) -> DAO-BOM(pom)
^ ^
| |
Services(jar) -> Services-BOM(pom)
^
|
webapp(war)
The development profile has dependencies in DAO(jar):
org.hibernate
hibernate-core
4.2.6.Final
Th production profile has dependencies in DAO(jar):
org.hibernate
hibernate-core
4.2.6.Final
org.jboss.spec.javax.transaction
jboss-transaction-api_1.1_spec
org.jboss.spec.javax.transaction
jboss-transaction-api_1.1_spec
1.0.1.Final
provided
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-2205:
Description:
A provided scope dependency can also be thought of as "compile-only".
Project A requires Sybase JConnect on the runtime classpath. Project A declares
a "provided" dependency on Sybase JConnect.
Project B depends upon Project A. Project B declares a "compile" dependency on
Project A.
Project C depends upon Project B. Project C declares a "compile" dependency on
Project B.
{noformat}
C
| - compile dependency
B
| - compile dependency
A
| - provided dependency
Sybase JConnect
{noformat}
So, does Project C transitively depend on Sybase JConnect. Yes, of course! The
"provided" dependency needs to be transitive.
Ultimately, when Project C gets deployed, Sybase JConnect needs to be somewhere
on the runtime classpath in order for the application to function. It's valid
for Project C to assume that Sybase JConnect is available and use JDBC all over
the Project C code. Project C is safe to do this because it can happily deduce
that Sybase JConnect will be there in the runtime environment because Project A
NEEDS IT.
I've got Use Cases all over my aggregated build which make it absolutely
critical and common sense that provided scope dependencies are transitive. For
the (very rare) odd case where you don't want to inherit provided dependencies,
you can them.
was:
A provided scope dependency can also be thought of as "compile-only".
Project A requires Sybase JConnect on the runtime classpath. Project A declares
a "provided" dependency on Sybase JConnect.
Project B depends upon Project A. Project B declares a "compile" dependency on
Project A.
Project C depends upon Project B. Project C declares a "compile" dependency on
Project B.
C
| - compile dependency
B
| - compile dependency
A
| - provided dependency
Sybase JConnect
So, does Project C transitively depend on Sybase JConnect. Yes, of course! The
"provided" dependency needs to be transitive.
Ultimately, when Project C gets deployed, Sybase JConnect needs to be somewhere
on the runtime classpath in order for the application to function. It's valid
for Project C to assume that Sybase JConnect is available and use JDBC all over
the Project C code. Project C is safe to do this because it can happily deduce
that Sybase JConnect will be there in the runtime environment because Project A
NEEDS IT.
I've got Use Cases all over my aggregated build which make it absolutely
critical and common sense that provided scope dependencies are transitive. For
the (very rare) odd case where you don't want to inherit provided dependencies,
you can them.
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335779#comment-335779 ] Tibor Digana edited comment on MNG-2205 at 11/16/13 4:17 PM: - I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) -> services(jar) -> dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module "services". The class from provided artifact was not inherited by the module "services". The webapp module wouldn't inherit it either. So the people make a workaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround can be used to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM -> DAO-BOM -> reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. The Services-BOM and DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx was (Author: tibor17): I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) -> services(jar) -> dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module "services". The class from provided artifact was not inherited by the module "services". The webapp module wouldn't inherit it either. So the people make a workaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround can be used to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM -> DAO-BOM -> reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM -> DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: https://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 3.x / Backlog > > Attachments: transitivetest.zip > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect >
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335779#comment-335779 ] Tibor Digana edited comment on MNG-2205 at 11/16/13 4:16 PM: - I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) -> services(jar) -> dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module "services". The class from provided artifact was not inherited by the module "services". The webapp module wouldn't inherit it either. So the people make a workaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround can be used to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM -> DAO-BOM -> reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM -> DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx was (Author: tibor17): I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) -> services(jar) -> dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module "services". The class from provided artifact was not inherited by the module "services". The webapp module wouldn't inherit it either. So the people make a workaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround would be to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM -> DAO-BOM -> reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM -> DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: https://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 3.x / Backlog > > Attachments: transitivetest.zip > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, doe
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335779#comment-335779 ] Tibor Digana edited comment on MNG-2205 at 11/16/13 4:14 PM: - I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) -> services(jar) -> dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module "services". The class from provided artifact was not inherited by the module "services". The webapp module wouldn't inherit it either. So the people make a workaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround would be to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM -> DAO-BOM -> reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM -> DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx was (Author: tibor17): I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) -> services(jar) -> dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module "services". The class from provided artifact was not inherited by the module "services". The webapp module wouldn't inherit it either. So the people make a worakaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround would be to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM -> DAO-BOM -> reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM -> DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: https://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 3.x / Backlog > > Attachments: transitivetest.zip > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335779#comment-335779 ] Tibor Digana edited comment on MNG-2205 at 11/16/13 4:12 PM: - I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) -> services(jar) -> dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module "services". The class from provided artifact was not inherited by the module "services". The webapp module wouldn't inherit it either. So the people make a worakaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround would be to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM -> DAO-BOM -> reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM -> DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx was (Author: tibor17): I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) -> services(jar) -> dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. You can see this problem in the zip file in subdirectory "problem". If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module "services". The class from provided artifact was not inherited by the module "services". The webapp module wouldn't inherit it either. So the people make a worakaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround would be to create parents Services-BOM and DAO-BOM with packaging=pom. See the folder "without profiles and with parents". Inheritance: Services-BOM -> DAO-BOM -> reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM -> DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: https://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 3.x / Backlog > > Attachments: transitivetest.zip > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Projec
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335779#comment-335779 ] Tibor Digana commented on MNG-2205: --- I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) -> services(jar) -> dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. You can see this problem in the zip file in subdirectory "problem". If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module "services". The class from provided artifact was not inherited by the module "services". The webapp module wouldn't inherit it either. So the people make a worakaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround would be to create parents Services-BOM and DAO-BOM with packaging=pom. See the folder "without profiles and with parents". Inheritance: Services-BOM -> DAO-BOM -> reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM -> DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: https://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 3.x / Backlog > > Attachments: transitivetest.zip > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does Project C transitively depend on Sybase JConnect. Yes, of course! > The "provided" dependency needs to be transitive. > Ultimately, when Project C gets deployed, Sybase JConnect needs to be > somewhere on the runtime classpath in order for the application to function. > It's valid for Project C to assume that Sybase JConnect is available and use > JDBC all over the Project C code. Project C is safe to do this because it can > happily deduce that Sybase JConnect will be there in the runtime environment > because Project A NEEDS IT. > I've got Use Cases all over my aggregated build which make it absolutely > critical and common sense that provided scope dependencies are transitive. > For the (very rare) odd case where you don't want to inherit provided > dependencies, you can them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305822#comment-305822
]
David Boden commented on MNG-2205:
--
For what it's worth, I no longer agree with this issue that I started 6 years
ago! I have a best-practice document which I apply to my projects and have
pasted here in this comment. Under this strategy, I always declare compile-time
dependencies in any project that has an import; statement referring to the
class. I don't rely on transitive dependencies when I'm actually using a
dependency for compilation. I think this is what the Maven authors intended,
which is why "provided" has stayed like it is for such a long time.
1. in parent pom
Declare the versions for all dependencies in the project's parent pom using the
section. You're setting the versions that will be used
if the submodules decide to declare dependencies. Using dependency management
ensures that the version of all of your dependencies is entirely consistent
across all your sub-projects. This is especially important if you're creating a
single deployment consisting of many of these sub-modules and you are going to
deploy one set of dependency jars
Declare few or no dependencies in the section of the parent
pom. It's fair to assume that all your projects will depend on JUnit and a
logging framework so you may want to add those. Anything else results in
unnecessary dependencies making their way into your sub-projects.
It's not too useful to declare versions at an even higher level (e.g. the pom
that's the parent of all your projects) but in some cases it can make life
easier.
Failing to add a dependencyManagement section results in a classic problem of
scripts being generated in sub-projects which reference jar versions that don't
end up being packaged in the final assemby's lib folder.
2. Declare dependencies where you use them - don't rely on transitive
dependencies
Transitive dependencies are very useful. If you're using the public API of a
library in your code then you shouldn't have to care how its internals work.
Your sub-project should declare a dependency on the library that your code is
using; Maven will helpfully pull in the library's transitive dependencies. The
library is free to change how its internals work and what transitive
dependencies it declares for each version.
If you're using a library, you should declare it in the section
of your pom. Don't rely on transitive dependencies. If your Java code (or
Spring config; that's code too) uses commons-beanutils then you should declare
that dependency. If you don't, your build is brittle; internal changes to other
components can break your component's build.
Run:
mvn dependency:analyze
This tool will tell you about artifacts that you've failed to declare
dependencies for and will also tell you if you have extra dependencies declared
that you don't need. Be careful about dependencies that you don't use in your
.java files; the dependency plugin is only scanning those. If you use a class
in Spring config then you do really need it, even if the dependency plugin is
telling you that you don't. In these cases I find it useful to make sure that
the dependency is set to runtime. That way, when I get the
dependency:analyze report telling me that these are extra dependencies I know
that I probably set them to runtime because they're used by spring config. I
ignore the runtime dependencies and only weed out the compile scope ones.
3. Use sparingly (in the parent pom)
Declaring all dependency versions in properties and then using those properties
in the section is a little like the (bad) practice of
unnecessarily declaring all your Java variables right at the top of a method.
When there's a single artifact to configure, favour hardcoding the version into
the 1.0 tag.
Use properties when there are multiple artifacts to control. For example, set:
3.1.1.RELEASE
and then use:
${spring.version}
for artifacts like spring-core
Properties are public, not private. When you declare a property in the parent
pom, it's available anywhere in the build. Adding a property pollutes the
(build) environment.
4. Use the enforcer plugin to guard against old or unwanted dependencies
The enforcer plugin can fail your build based on duplicate classes found (the
same classes in more than one jar file on the build classpath) or can allow you
to ban old or unwanted dependencies. This is especially useful when the owner
of a library has changed the groupId or artifactId of their artifact. This
stops the Maven dependency mechanism from picking the latest version; you'll
end up with 2 similar artifacts on the classpath. For example, from Spring 2 to
Spring 3 they changed an artifactId from spring to spring-core. Without banning
the older spring dependency, it can easily transitively creep back onto your
classpath. Then when you
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305819#comment-305819 ] Sergey commented on MNG-2205: - Issue has been created: 06/Apr/06 5:37 AM 6 years old!!! Should be already fixed. > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: https://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 3.x / Backlog > > Attachments: transitivetest.zip > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does Project C transitively depend on Sybase JConnect. Yes, of course! > The "provided" dependency needs to be transitive. > Ultimately, when Project C gets deployed, Sybase JConnect needs to be > somewhere on the runtime classpath in order for the application to function. > It's valid for Project C to assume that Sybase JConnect is available and use > JDBC all over the Project C code. Project C is safe to do this because it can > happily deduce that Sybase JConnect will be there in the runtime environment > because Project A NEEDS IT. > I've got Use Cases all over my aggregated build which make it absolutely > critical and common sense that provided scope dependencies are transitive. > For the (very rare) odd case where you don't want to inherit provided > dependencies, you can them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305311#comment-305311 ] Ivan Bondarenko commented on MNG-2205: -- I have voted for this. Half-abstract and half-concrete example: A -> B(compile) -> servlet-api(provided), A must have an access to servlet-api classes (or at least have such possibility), because A must sit in web-container, so B has no other choice. In some cases A don't need classes from servlet-api, but this is not a problem, "compile" scope creates more problems in this case, because it pulls unnecessary dependencies along into package. I think the solution may be removing "optional" tag from dependency definition. Instead the tag "transitivity" can be introduced, which may be flexible and has different values: 1) 'transitive' - always transitive 2) 'optional' - as optional=true in current variant 3) 'detect' - transitive for cases when "The type cannot be resolved. It is indirectly referenced from required .class files" compile error appears 4) 'non-transitive' - always non-transitive 5) etc For backward compatibility 'transitive' can be default for "compile" scope and 'non-transitive' for "provided" > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: https://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 3.x / Backlog > > Attachments: transitivetest.zip > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does Project C transitively depend on Sybase JConnect. Yes, of course! > The "provided" dependency needs to be transitive. > Ultimately, when Project C gets deployed, Sybase JConnect needs to be > somewhere on the runtime classpath in order for the application to function. > It's valid for Project C to assume that Sybase JConnect is available and use > JDBC all over the Project C code. Project C is safe to do this because it can > happily deduce that Sybase JConnect will be there in the runtime environment > because Project A NEEDS IT. > I've got Use Cases all over my aggregated build which make it absolutely > critical and common sense that provided scope dependencies are transitive. > For the (very rare) odd case where you don't want to inherit provided > dependencies, you can them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=303579#comment-303579
]
Marco Speranza commented on MNG-2205:
-
Hi all...
I'm in a OSGi environment and I've the same problem.
I need to compile a project
*A* -> *B (provided)* -> *C (provided)*
B is an OSGi bunlde and A needs to use some C's packages/classes
I agree with
[Alexandre|http://jira.codehaus.org/browse/MNG-2205?focusedCommentId=141086&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-141086]
IMHO it's important to have a simple option to add a transitive 'provided'
dependency into the compile classpath.
Could be a simple solution to add a flag into the pom file (like system scope?
) that allows a provided dependency to be transitive?
i.e.
{code:xml}
foo.bar
project
1.0.0
provided
true
{code}
thanks and have a nice day :)
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=292547#comment-292547 ] Dale Wijnand commented on MNG-2205: --- I really like the 3rd solution given by Sei Syvalta (http://jira.codehaus.org/browse/MNG-2205?focusedCommentId=131081&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-131081). I'd like to vote that one in particular. I think it would make for more stable builds (or rather updating dependencies), such as: Dozer (net.sf.dozer:dozer:jar:5.3.2) currently depends on commons-lang:commons-lang:jar:2.5 If in my project I compile-time depend on dozer, I also have commons-lang on the compile classpath. If I Dozer's next version refactors everything to use Google's Guava instead (com.google.guava:guava:jar:11.0.2), then my code will break.. for something (basically) completely unrelated. > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: https://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 3.x / Backlog > > Attachments: transitivetest.zip > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does Project C transitively depend on Sybase JConnect. Yes, of course! > The "provided" dependency needs to be transitive. > Ultimately, when Project C gets deployed, Sybase JConnect needs to be > somewhere on the runtime classpath in order for the application to function. > It's valid for Project C to assume that Sybase JConnect is available and use > JDBC all over the Project C code. Project C is safe to do this because it can > happily deduce that Sybase JConnect will be there in the runtime environment > because Project A NEEDS IT. > I've got Use Cases all over my aggregated build which make it absolutely > critical and common sense that provided scope dependencies are transitive. > For the (very rare) odd case where you don't want to inherit provided > dependencies, you can them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
