You could have a second (dummy) module that depends on persistence, has all it's dependencies, and then just add that as either scope provided or test to the modules that you need
On Sat, May 24, 2008 at 4:11 PM, Fabien Coppens <[EMAIL PROTECTED]> wrote: > Yes, but doesn't that mean adding the list of build exclusions to each and > every > project that has a dependency on Persistence (because they are each being > tested and built > sperately by different teams) ? It's as cumbersome as adding the whole list > of dependencies > with "provided" scope in each of those modules; > > > Bryan Loofbourrow wrote: > > I have several modules that have a dependency on a PERSISTENCE >>>> >>>> >>> module. >> Said Persistence module has a bunch of dependencies on jars of scope >> "provided" because >> they will actually be available directly in the app server's >> out-of-the-box libraries. >> My modules that depend on Persistence need to see the libraries that >> Persistence declares >> in its Pom, both for compilation and for tests (UTs are run outside of the >> app server), BUT since >> those jars are declared with scope "provided" in the Persistence module's >> Pom, the command line >> build fails << >> >> I can see how "provided" is of limited usefulness in this situation, >> being non-transitive. So why not use "compile" scope and filter those >> jars out when you build your deployable war/ear? >> >> >> --------------------------------------------------------------------- >> 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] > >
