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:
> > ...
> > <dependencyManagement><dependencies>
> >  <dependency>
> >    <groupId>org.codehaus.groovy</groupId>
> >    <artifactId>groovy-all</artifactId>
> >    <version>${groovy-all.version}</version>
> >    <scope>test</scope>
> >  </dependency>
> > </dependencies></dependencyManagement>
> > ...
> > <dependencies>
> >  <dependency>
> >    <groupId>org.codehaus.groovy</groupId>
> >    <artifactId>groovy-all</artifactId>
> >  </dependency>
> > </dependencies>
> >
> >
> > Intermediate POM:
> > ...
> > <parent>[my parent POM]</parent>
> > ...
> > <dependencyManagement><dependencies>
> >  <dependency>
> >    <groupId>org.codehaus.groovy</groupId>
> >    <artifactId>groovy-all</artifactId>
> >    <version>${groovy-all.version}</version>
> >    <scope>compile</scope>
> >  </dependency>
> > </dependencies></dependencyManagement>
> >
> >
> > Child POM for module which needs groovy-all during runtime:
> > ...
> > <parent>[my intermediate POM]</parent>
> > ...
> > <dependencies>
> >  <dependency>
> >    <groupId>org.codehaus.groovy</groupId>
> >    <artifactId>groovy-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
>
>

Reply via email to