-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Brett,

Brett Porter wrote:
> We've so far opted not to do this (basically an optional dependency) as
> it can encourage poorly specified poms to stay that way. Basically by
> saying this you are saying to those depending on you "you may need tis
> jar at some point, but I can't tell you when". That's going to manifest
> in a class cast exception. It really is a dependency, and instead we
> allow the dependee to exclude the ones it knows it doesn't need.
> 
> This is more tedious though, and I'm not currently certain whether it is
> better to allow optinoal dependencies to aid in this.
Well if we make the example (commons-logging) more abstract we can think
 of a project providing a facade to some functionalitiy provided by
various exisiting implementations (e.g. could also be a facade for GUI
toolkits that allows Swing and SWT as backend).
In that case you would have a more abstract dependency where one can
choose. If that would be expressed in the POM as "dependency group"
there could also be a default choice if not explicitly choosen by the
aggregating project.
But actually the more I think about, it may be the best and simplest
approach to have a project just for the API and general code and a
subproject for each backend implementation defining the dependencies to
the real implementation. In the aggregating project you have a
dependency on the API and choose the implementation by another dependency.
So all I am saying is: you're right and maven(2) enforces structuring
your projects, which is good :)
> 
> - Brett
> 
> Joerg Hohwiller wrote:
> 
> 
>>Hi there,
>>
>>John Casey wrote:
>>
>>
>>>try adding <inherit>true</inherit> to the plugin definition at the top
>>>level...I can't remember whether the compiler plugin inherits by default
>>>or not (my suspicions are "not").
>>
>>
>>Not about POM inheritance but about dependency inheritance (transitive
>>dependencies):
>>
>>Can I also put <inherit>false</inherit> to a dependency definition so it
>>will not be inherited. E.g. if commons-logging does not want to carry
>>out all of their supported implementations?
>>
>>Regards
>>  Jörg
Thanks
  Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC97EbmPuec2Dcv/8RAloPAKCVq41//SAgOqGakWlJ40TWP1jsFQCeOM7y
bgYSYkwBXeGPr9Jfv2PkeoE=
=bkou
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to