Re: [all] auxillary components

2005-12-28 Thread Brett Porter
Sorry for the delay. robert burrell donkin wrote: > (this somewhat follows on tangentally from the discussions on > commons-collections-functor) > > i've been thinking over the last few weeks about the best approach for > non-core code in existing components which is distributed as separate > opti

Re: [all] auxillary components

2005-12-14 Thread Brian K. Wallace
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 robert burrell donkin wrote: > thanks: it's good to get different perspectives and we do appreciate > folk who take the time to join the debate. > > i think that there are two different dimensions to this discussion. the > first is flatter verses dee

Re: [all] auxillary components

2005-12-14 Thread robert burrell donkin
On Tue, 2005-12-13 at 09:19 -0600, Brian K. Wallace wrote: > I've been watching the functor/logging threads so I believe I > understand the reasoning behind your proposal, but I do not believe I > quite agree with the implementation you suggest. > > There are two distinctly different groups

Re: [all] auxillary components

2005-12-13 Thread Henri Yandell
+1. Flat is good. Auxilliary is good as optional is increasingly used with a legal policy slant (ie: some licences are okay for optional but not required). Hen On 12/13/05, robert burrell donkin <[EMAIL PROTECTED]> wrote: > (this somewhat follows on tangentally from the discussions on > commons-c

Re: [all] auxillary components

2005-12-13 Thread J.Pietschmann
robert burrell donkin wrote: it's easier to automate a flat structure +1 I also think more granularity in a flat structure will 1. Reduce the complexity of dependencies between components 2. Might foster reuse (less fears of unnecessary or cyclic dependencies between components) J.Pietschm

Re: [all] auxillary components

2005-12-13 Thread Brian K. Wallace
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 robert burrell donkin wrote: > (this somewhat follows on tangentally from the discussions on > commons-collections-functor) > > i've been thinking over the last few weeks about the best approach for > non-core code in existing components which is dist

[all] auxillary components

2005-12-13 Thread robert burrell donkin
(this somewhat follows on tangentally from the discussions on commons-collections-functor) i've been thinking over the last few weeks about the best approach for non-core code in existing components which is distributed as separate optional artifacts for reasons such as dependency management. i'd