Re: dependecy management, shared libraries should not be in a war/ear

[Kris Bravo <kr...@corridor-software.us>]

I prefer 4) with the logged warnings. With 2) you potentially create more
significant runtime problems.

If, however, you decide to go with 2), a file included in an obvious
location (i.e., WEB-INF/lib/runtime.txt) listing the dropped dependencies
would help with the troubleshooting sessions.

Kris

> Jason van Zyl wrote:
>
>>>2) scope in end POM always wins
>>>
>>>
>>To me this would seem to be the most obvious the user.
>>
>>
> I agree, given the current use of dependencies.
>
>>
>>
>>>4) keep it as is (where you can use <dependencyManagement /> to force
>>>the appropriate scope)
>>>
>>>
>>Wouldn't that be a little inconvenient and unintuitive to have to create
>>the <depMan/> element to control the scope of a single dependency.
>>
>>
> Yes, it is inconvenient.
>
> A couple of problems with (2):
> - it changes the behaviour of a dependency contextually when it is
> acting in transitive mode vs. final POM. This may not be a big deal.
> - it could hide changes that cause breakages.
>
> Consider this scenario:
> A (a webapp) depends on B (which currently has no dependencies).
> A depends on commons-collections as a test dependency.
> B later adds commons-collections as a compile time dependency.
>
> Under (4), commons-collections becomes a compile time dependency for A
> and gets included in the webapp, allowing B to function.
> Under (2), C-C remains a test dependency for A and gets omitted from the
> webapp, causing B to fail at runtime with a ClassNotFoundException.
>
> Of course, we'd be warning something to the effect of "Dependency scope
> test commons-collections hides a definition of compile on B", but if
> that is actually what you wanted to do, doesn't that get annoying? I
> guess we recommend using depMgmt there to avoid the warning.
>
> I guess another option is to use (4) and instead of requiring a depMgmt
> entry, have a <force>true</force> flag on a dependency?
>
> What do others prefer? I guess of all this, I think (2) with the warning
> might be the best solution.
>
> - Brett
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org