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
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
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
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
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
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
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
