Daniel Fagerstrom wrote: >> Would prefer puting API dependencies in the API module and let the >> impl depend on the api and the samples on the impl. Doesn't the >> tranistive dependencies work well enough or what is the reasons for >> having dependencies at parent level?
Well i figured it would buy us a "cleaner" way of defining dependencies, i now see I was wrong. Looking at Andreas' diagram, it's clear that we have to put API deps in the api pom and let the implementations care about their own dependencies - this way you wouldn't have to exclude unnecessary libs from impl1 in impl2 manually. What if there is no real need for an api block? Do we still add it and define for example the cocoon-core dependency there or do we leave it out alltogether ? Andreas Hochsteger wrote: > If you take everything into account, both API and implementation can > have their own dependencies, e.g.: > > * B (API) depends on A (API) wow, multiple APIs in one block ? > * C (impl of A) depends on A (API) > * D (impl of B) depends on B (API) > * D (impl of B) depends on C (impl of A) correct, albeit theoretically. I hope we won't need this level of inheritance for our blocks. > or better readable with a bit of ASCII art: > > API: [ A ] <--- [ B ] > ^ ^ > | | > Impl: [ C ] <--- [ D ] Nice ! Thanks for your feedback. Jorg
