Re: Overriding dependency scope
FYI, this idea did not work. I still need help.
Maybe defining a BOM is the way to go, but I would prefer to keep everything in
one repo and one project.
--
Alexander Kriegisch
Am 29.03.2014 um 11:35 schrieb Alexander Kriegisch
alexan...@kriegisch.name:
Baptiste, Mirko,
thanks for your answers. I was unable to override the scope in a depending
POM, I tried several approaches, e.g. redefining dependencyManagement in
the child POM - to no avail. I have heard about the rule/idiom dependency
mgmt overrides dependency scope before, but I have not found a comprehensive
(i.e. understandable) explanation with concrete examples anywhere.
Baptiste, how and why would an intermediate POM help me solve this problem? I
think it is rather funny to define an intermediate POM for just one module
needing it. If you could give me an example that would be great, maybe then I
understand better. My guess is you mean something like this:
Parent POM:
...
dependencyManagementdependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
version${groovy-all.version}/version
scopetest/scope
/dependency
/dependencies/dependencyManagement
...
dependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
/dependency
/dependencies
Intermediate POM:
...
parent[my parent POM]/parent
...
dependencyManagementdependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
version${groovy-all.version}/version
scopecompile/scope
/dependency
/dependencies/dependencyManagement
Child POM for module which needs groovy-all during runtime:
...
parent[my intermediate POM]/parent
...
dependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
/dependency
/dependencies
Is that what you mean? Have you tested it? Does it really work? Please
correct my (untested, I am on the road) sketch if it is wrong.
Baptiste Mathus schrieb am 28.03.2014 17:45:
IIUC, you have a unique parent pom (likely a corporate pom), let's can
him P. P says scope is test for groovy-all.
You have modules m1, m2... who all inherits P.
In some module mN, you need groovy-all with scope compile.
But m1 actually depends on mN and will crash since the dependency onto
groovy-all isn't retrieved?
If so, then this is expected. Dependency mgmt overrides the dependencies
scope. One possible solution to centralize many redefinitions is to create
an intermediate parent for those modules where you need groovy-all with
scope compile.
I think that's what Mirko was proposing.
Does that help?
Le 28 mars 2014 15:08, Mirko Friedenhagen mfriedenha...@gmail.com a
écrit :
AFAIK you may override the scope in the inheriting poms. If I remember
correctly I did this with junit as I needed it for an selenium test
project, where I had put base tests beneath src/main (to recite Brecht: oh,
don't ask why).
On Mar 28, 2014 2:59 PM, Alexander Kriegisch alexan...@kriegisch.name
wrote:
I have a situation as follows:
- Multi-module project (~30 modules)
- Certain test dependencies (e.g. groovy-all) needed by nearly all
sub-modules are declared directly with test scope in the parent POM
(not just dependencyManagement, but also dependency). I know this is
considered to be bad practice but it saves a lot of redundant
dependency duplication.
- One new sub-module now actually also needs groovy-all, but with a
compile scope. So my wish (although seemingly unsupported by Maven)
is to override the default scope for this sub-module so as for the
dependency to be actually available during runtime.
How can I do this or work around the need to duplicate my test
dependencies in 30 modules just so as to be able to define the scope for
the new module? AFAIK a POM can only inherit from one POM. But can I
somehow use an included POM in my 30 modules in order to be able to
centrally manage the test dependencies? Sorry if I am explaining this
wrong or using incorrect erms, but I am by no means a Maven pro.
Hopefully I was at least able to make my intent clear. I am looking for
good advice beyond lecturing about how I should really, really declare
everything 30 times in order to do it the Maven way. I am looking for
alternatives, am willing to learn and hoping to get constructive answers.
Thanks you all in advance
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Overriding dependency scope
Hi Alexander,
One new sub-module now actually also needs groovy-all, but with a
compile scope.
There are a few different ways to solve this. Personally I have not had
good luck trying to alter the scope of a dependency downstream (as Mirko
suggested might be possible). But of course, one simple and hacky way is to
change the groovy-all dependency to compile at the root, and then it will
be available to everything.
Another less hacky possibility would be, as Baptiste suggests, to introduce
another layer of inheritance, although I would do it as follows:
toplevel
|-- intermediate-with-test-deps-declared
|-- x1
|-- x2
...
|- xM
|-- intermediate-with-groovy-all-at-compile-scope
|- y1
|- y2
...
|- yN
Where x modules need the groovy-all etc. deps at test scope, and y
modules need groovy-all etc. at compile scope.
In this way, you do not ever need to override a dependency scope from one
level to another level.
Alternately, if you only have a single module that needs groovy-all at
compile scope, it could just extend the toplevel parent directly instead of
introducing the intermediate-with-groovy-all-at-compile-scope layer. But
you might find that layer handy later as soon as a second such module comes
into existence.
A third possibility which might be more elegant in your situation, and
closer to the infamous Maven way, is called import scope; see:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
Regards,
Curtis
On Sun, Mar 30, 2014 at 1:19 AM, Alexander Kriegisch
alexan...@kriegisch.name wrote:
FYI, this idea did not work. I still need help.
Maybe defining a BOM is the way to go, but I would prefer to keep
everything in one repo and one project.
--
Alexander Kriegisch
Am 29.03.2014 um 11:35 schrieb Alexander Kriegisch
alexan...@kriegisch.name:
Baptiste, Mirko,
thanks for your answers. I was unable to override the scope in a
depending POM, I tried several approaches, e.g. redefining
dependencyManagement in the child POM - to no avail. I have heard about
the rule/idiom dependency mgmt overrides dependency scope before, but I
have not found a comprehensive (i.e. understandable) explanation with
concrete examples anywhere.
Baptiste, how and why would an intermediate POM help me solve this
problem? I think it is rather funny to define an intermediate POM for just
one module needing it. If you could give me an example that would be great,
maybe then I understand better. My guess is you mean something like this:
Parent POM:
...
dependencyManagementdependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
version${groovy-all.version}/version
scopetest/scope
/dependency
/dependencies/dependencyManagement
...
dependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
/dependency
/dependencies
Intermediate POM:
...
parent[my parent POM]/parent
...
dependencyManagementdependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
version${groovy-all.version}/version
scopecompile/scope
/dependency
/dependencies/dependencyManagement
Child POM for module which needs groovy-all during runtime:
...
parent[my intermediate POM]/parent
...
dependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
/dependency
/dependencies
Is that what you mean? Have you tested it? Does it really work? Please
correct my (untested, I am on the road) sketch if it is wrong.
Baptiste Mathus schrieb am 28.03.2014 17:45:
IIUC, you have a unique parent pom (likely a corporate pom), let's can
him P. P says scope is test for groovy-all.
You have modules m1, m2... who all inherits P.
In some module mN, you need groovy-all with scope compile.
But m1 actually depends on mN and will crash since the dependency onto
groovy-all isn't retrieved?
If so, then this is expected. Dependency mgmt overrides the dependencies
scope. One possible solution to centralize many redefinitions is to
create
an intermediate parent for those modules where you need groovy-all with
scope compile.
I think that's what Mirko was proposing.
Does that help?
Le 28 mars 2014 15:08, Mirko Friedenhagen mfriedenha...@gmail.com a
écrit :
AFAIK you may override the scope in the inheriting poms. If I remember
correctly I did this with junit as I needed it for an selenium test
project, where I had put base tests beneath src/main (to recite
Brecht: oh,
don't ask why).
On Mar 28, 2014 2:59 PM, Alexander Kriegisch
alexan...@kriegisch.name
wrote:
I have a situation as follows:
- Multi-module project (~30 modules)
- Certain test dependencies (e.g. groovy-all) needed by nearly all
sub-modules are declared directly with test
Re: Overriding dependency scope
Hi Curtis.
I had also considered your approach before, but dislike the idea of structuring
my project based on the dependency scope of a single library. Moreover, what if
I have several such libraries? Should I have n! different intermediate modules?
Actually I found out that scope override works without any intermediate
modules. This is why compilation works, I guess. But my runtime tests do not
work because the application is packed into an uber JAR via Maven Shade, and I
suspect Maven Shade not to recognise the overridden scope. BTW, running the
application from IntelliJ IDEA with Maven auto import also does not work. I got
it working by specifying the groovy-all dependency redundantly in the module
responsible for packing the uber JAR. Another way of tricking Maven would be to
use Maven Shade in the Groovy module and shade the dependency right into the
module's artifact. That way the other module (packing the big JAR with all
modules and external dependencies) would also see the Groovy runtime without
specifying a redundant dependency there.
I hope that was not too much information.
Is there any expert for Maven Shade out there who can tell me why Shade does
not notice my overridden dependency scope and automatically pack the Groovy
runtime into the uber JAR?
--
Alexander Kriegisch
Am 30.03.2014 um 16:04 schrieb Curtis Rueden ctrue...@wisc.edu:
Hi Alexander,
One new sub-module now actually also needs groovy-all, but with a
compile scope.
There are a few different ways to solve this. Personally I have not had
good luck trying to alter the scope of a dependency downstream (as Mirko
suggested might be possible). But of course, one simple and hacky way is to
change the groovy-all dependency to compile at the root, and then it will
be available to everything.
Another less hacky possibility would be, as Baptiste suggests, to introduce
another layer of inheritance, although I would do it as follows:
toplevel
|-- intermediate-with-test-deps-declared
|-- x1
|-- x2
...
|- xM
|-- intermediate-with-groovy-all-at-compile-scope
|- y1
|- y2
...
|- yN
Where x modules need the groovy-all etc. deps at test scope, and y
modules need groovy-all etc. at compile scope.
In this way, you do not ever need to override a dependency scope from one
level to another level.
Alternately, if you only have a single module that needs groovy-all at
compile scope, it could just extend the toplevel parent directly instead of
introducing the intermediate-with-groovy-all-at-compile-scope layer. But
you might find that layer handy later as soon as a second such module comes
into existence.
A third possibility which might be more elegant in your situation, and
closer to the infamous Maven way, is called import scope; see:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
Regards,
Curtis
On Sun, Mar 30, 2014 at 1:19 AM, Alexander Kriegisch
alexan...@kriegisch.name wrote:
FYI, this idea did not work. I still need help.
Maybe defining a BOM is the way to go, but I would prefer to keep
everything in one repo and one project.
--
Alexander Kriegisch
Am 29.03.2014 um 11:35 schrieb Alexander Kriegisch
alexan...@kriegisch.name:
Baptiste, Mirko,
thanks for your answers. I was unable to override the scope in a
depending POM, I tried several approaches, e.g. redefining
dependencyManagement in the child POM - to no avail. I have heard about
the rule/idiom dependency mgmt overrides dependency scope before, but I
have not found a comprehensive (i.e. understandable) explanation with
concrete examples anywhere.
Baptiste, how and why would an intermediate POM help me solve this
problem? I think it is rather funny to define an intermediate POM for just
one module needing it. If you could give me an example that would be great,
maybe then I understand better. My guess is you mean something like this:
Parent POM:
...
dependencyManagementdependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
version${groovy-all.version}/version
scopetest/scope
/dependency
/dependencies/dependencyManagement
...
dependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
/dependency
/dependencies
Intermediate POM:
...
parent[my parent POM]/parent
...
dependencyManagementdependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
version${groovy-all.version}/version
scopecompile/scope
/dependency
/dependencies/dependencyManagement
Child POM for module which needs groovy-all during runtime:
...
parent[my intermediate POM]/parent
...
dependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
/dependency
/dependencies
Is that what you mean? Have you tested it? Does it really work? Please
Re: Overriding dependency scope
Baptiste, Mirko,
thanks for your answers. I was unable to override the scope in a depending POM,
I tried several approaches, e.g. redefining dependencyManagement in the child
POM - to no avail. I have heard about the rule/idiom dependency mgmt overrides
dependency scope before, but I have not found a comprehensive (i.e.
understandable) explanation with concrete examples anywhere.
Baptiste, how and why would an intermediate POM help me solve this problem? I
think it is rather funny to define an intermediate POM for just one module
needing it. If you could give me an example that would be great, maybe then I
understand better. My guess is you mean something like this:
Parent POM:
...
dependencyManagementdependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
version${groovy-all.version}/version
scopetest/scope
/dependency
/dependencies/dependencyManagement
...
dependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
/dependency
/dependencies
Intermediate POM:
...
parent[my parent POM]/parent
...
dependencyManagementdependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
version${groovy-all.version}/version
scopecompile/scope
/dependency
/dependencies/dependencyManagement
Child POM for module which needs groovy-all during runtime:
...
parent[my intermediate POM]/parent
...
dependencies
dependency
groupIdorg.codehaus.groovy/groupId
artifactIdgroovy-all/artifactId
/dependency
/dependencies
Is that what you mean? Have you tested it? Does it really work? Please correct
my (untested, I am on the road) sketch if it is wrong.
Regards
--
Alexander Kriegisch
Baptiste Mathus schrieb am 28.03.2014 17:45:
IIUC, you have a unique parent pom (likely a corporate pom), let's can
him P. P says scope is test for groovy-all.
You have modules m1, m2... who all inherits P.
In some module mN, you need groovy-all with scope compile.
But m1 actually depends on mN and will crash since the dependency onto
groovy-all isn't retrieved?
If so, then this is expected. Dependency mgmt overrides the dependencies
scope. One possible solution to centralize many redefinitions is to create
an intermediate parent for those modules where you need groovy-all with
scope compile.
I think that's what Mirko was proposing.
Does that help?
Le 28 mars 2014 15:08, Mirko Friedenhagen mfriedenha...@gmail.com a
écrit :
AFAIK you may override the scope in the inheriting poms. If I remember
correctly I did this with junit as I needed it for an selenium test
project, where I had put base tests beneath src/main (to recite Brecht: oh,
don't ask why).
On Mar 28, 2014 2:59 PM, Alexander Kriegisch alexan...@kriegisch.name
wrote:
I have a situation as follows:
- Multi-module project (~30 modules)
- Certain test dependencies (e.g. groovy-all) needed by nearly all
sub-modules are declared directly with test scope in the parent POM
(not just dependencyManagement, but also dependency). I know this is
considered to be bad practice but it saves a lot of redundant
dependency duplication.
- One new sub-module now actually also needs groovy-all, but with a
compile scope. So my wish (although seemingly unsupported by Maven)
is to override the default scope for this sub-module so as for the
dependency to be actually available during runtime.
How can I do this or work around the need to duplicate my test
dependencies in 30 modules just so as to be able to define the scope for
the new module? AFAIK a POM can only inherit from one POM. But can I
somehow use an included POM in my 30 modules in order to be able to
centrally manage the test dependencies? Sorry if I am explaining this
wrong or using incorrect erms, but I am by no means a Maven pro.
Hopefully I was at least able to make my intent clear. I am looking for
good advice beyond lecturing about how I should really, really declare
everything 30 times in order to do it the Maven way. I am looking for
alternatives, am willing to learn and hoping to get constructive answers.
Thanks you all in advance
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Overriding dependency scope
I have a situation as follows: - Multi-module project (~30 modules) - Certain test dependencies (e.g. groovy-all) needed by nearly all sub-modules are declared directly with test scope in the parent POM (not just dependencyManagement, but also dependency). I know this is considered to be bad practice but it saves a lot of redundant dependency duplication. - One new sub-module now actually also needs groovy-all, but with a compile scope. So my wish (although seemingly unsupported by Maven) is to override the default scope for this sub-module so as for the dependency to be actually available during runtime. How can I do this or work around the need to duplicate my test dependencies in 30 modules just so as to be able to define the scope for the new module? AFAIK a POM can only inherit from one POM. But can I somehow use an included POM in my 30 modules in order to be able to centrally manage the test dependencies? Sorry if I am explaining this wrong or using incorrect erms, but I am by no means a Maven pro. Hopefully I was at least able to make my intent clear. I am looking for good advice beyond lecturing about how I should really, really declare everything 30 times in order to do it the Maven way. I am looking for alternatives, am willing to learn and hoping to get constructive answers. Thanks you all in advance -- Alexander Kriegisch smime.p7s Description: S/MIME Cryptographic Signature
Re: Overriding dependency scope
Alexander, AFAIK you may override the scope in the inheriting poms. If I remember correctly I did this with junit as I needed it for an selenium test project, where I had put base tests beneath src/main (to recite Brecht: oh, don't ask why). Regards Mirko -- Sent from my mobile On Mar 28, 2014 2:59 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: I have a situation as follows: - Multi-module project (~30 modules) - Certain test dependencies (e.g. groovy-all) needed by nearly all sub-modules are declared directly with test scope in the parent POM (not just dependencyManagement, but also dependency). I know this is considered to be bad practice but it saves a lot of redundant dependency duplication. - One new sub-module now actually also needs groovy-all, but with a compile scope. So my wish (although seemingly unsupported by Maven) is to override the default scope for this sub-module so as for the dependency to be actually available during runtime. How can I do this or work around the need to duplicate my test dependencies in 30 modules just so as to be able to define the scope for the new module? AFAIK a POM can only inherit from one POM. But can I somehow use an included POM in my 30 modules in order to be able to centrally manage the test dependencies? Sorry if I am explaining this wrong or using incorrect erms, but I am by no means a Maven pro. Hopefully I was at least able to make my intent clear. I am looking for good advice beyond lecturing about how I should really, really declare everything 30 times in order to do it the Maven way. I am looking for alternatives, am willing to learn and hoping to get constructive answers. Thanks you all in advance -- Alexander Kriegisch
Re: Overriding dependency scope
IIUC, you have a unique parent pom (likely a corporate pom), let's can him P. P says scope is test for groovy-all. You have modules m1, m2... who all inherits P. In some module mN, you need groovy-all with scope compile. But m1 actually depends on mN and will crash since the dependency onto groovy-all isn't retrieved? If so, then this is expected. Dependency mgmt overrides the dependencies scope. One possible solution to centralize many redefinitions is to create an intermediate parent for those modules where you need groovy-all with scope compile. I think that's what Mirko was proposing. Does that help? Le 28 mars 2014 15:08, Mirko Friedenhagen mfriedenha...@gmail.com a écrit : Alexander, AFAIK you may override the scope in the inheriting poms. If I remember correctly I did this with junit as I needed it for an selenium test project, where I had put base tests beneath src/main (to recite Brecht: oh, don't ask why). Regards Mirko -- Sent from my mobile On Mar 28, 2014 2:59 PM, Alexander Kriegisch alexan...@kriegisch.name wrote: I have a situation as follows: - Multi-module project (~30 modules) - Certain test dependencies (e.g. groovy-all) needed by nearly all sub-modules are declared directly with test scope in the parent POM (not just dependencyManagement, but also dependency). I know this is considered to be bad practice but it saves a lot of redundant dependency duplication. - One new sub-module now actually also needs groovy-all, but with a compile scope. So my wish (although seemingly unsupported by Maven) is to override the default scope for this sub-module so as for the dependency to be actually available during runtime. How can I do this or work around the need to duplicate my test dependencies in 30 modules just so as to be able to define the scope for the new module? AFAIK a POM can only inherit from one POM. But can I somehow use an included POM in my 30 modules in order to be able to centrally manage the test dependencies? Sorry if I am explaining this wrong or using incorrect erms, but I am by no means a Maven pro. Hopefully I was at least able to make my intent clear. I am looking for good advice beyond lecturing about how I should really, really declare everything 30 times in order to do it the Maven way. I am looking for alternatives, am willing to learn and hoping to get constructive answers. Thanks you all in advance -- Alexander Kriegisch
