Hello, we use this for dependencies which should go the test scope by default as well. This prevents stuff like junit or mockito to be part of WARs, e.g. The only drawback here are our integration test suites where a lot of the code resides in src/main.
Same goes for logback-classic, which may be used in libraries in the scope test but should be explicitely declared as either provided (by our internal tomcat containers). As we use jcl-over-slf4j we define commons-logging as provided by jcl-over-slf4j as well, so we do not have to redeclare this in every application again. Regards Mirko On Fri, Jun 1, 2012 at 6:03 PM, Mark Struberg <[email protected]> wrote: > I sometimes use this for libraries (like e.g. openwebbeans-impl) which I > normally only have a runtime dependency for (generally defined via > dependencyManagement). > > > But in some cases you need to access some internal details. Usually I move > those parts to some 'utility' module which then has a compile time dependency > to the needed library. > > > LieGrue, > strub > > > > ----- Original Message ----- >> From: "Thiessen, Todd (Todd)" <[email protected]> >> To: Maven Users List <[email protected]> >> Cc: >> Sent: Friday, June 1, 2012 5:20 PM >> Subject: RE: Using scope in dependencyManagement: good idea or bad? >> >> +1 here. I find it valuable to changing scope to provided. >> >>> -----Original Message----- >>> From: Wayne Fay [mailto:[email protected]] >>> Sent: Friday, June 01, 2012 10:53 AM >>> To: Maven Users List >>> Subject: Re: Using scope in dependencyManagement: good idea or bad? >>> >>> > the subject say it all: Is declaring scopes in the >>> dependencyManagement >>> > section of your parent POM a good idea or a bad idea? >>> >>> Unless you are employing an approach wherein all of those deps will be >>> scope provided [because you are providing them in the application >>> server's shared libs folder], I think it is a bad idea. >>> >>> So I guess specifically for provided-scoped things, I support it, but >>> not for any others. >>> >>> Wayne >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
