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]
