-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there,
Joerg Hohwiller wrote: > 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 :) Actually I got totally lost in jarkarta-commons and othe projects before getting into maven. But now from the commons-logging point of view I want to raise this issue again: If JCL would have the API as top-level project and a sub-project for each bridge-implementation (log4j1.2, log4j1.3, jdk1.4-logger, logkit, avalon, etc.) this would cause: 1. ugly maintainence of the project 2. a jar for each bridge-implementation I think one could live with 1. Especially there is a general problem because of the dependency on log4j in two different version - this forces to splitt off in sub-projects if maven is used at all for the build. But for 2. there should be a way to build a jar in the top-level project that includes all code-output compiled in the sub-projects. Is that making sense for you or is this already targeted by m2? Do you see a better solution? BTW. I have seen this issue for aggregated javadocs in maven1 discussions a long time ago. Is that solved in m2? > [cut] Thanks Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTDDXmPuec2Dcv/8RAhvNAJ9rHaZuCa+pduDOfZ5eE9sgG/mMIgCghJ5u BWBIw970xrSMXMnetOQmJFg= =EFwJ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
