--- On Wed, 5/6/09, Torsten Curdt <[email protected]> wrote:
> From: Torsten Curdt <[email protected]> > Subject: Re: [COLLECTIONS] 3.3 release > To: "Commons Developers List" <[email protected]> > Date: Wednesday, May 6, 2009, 2:47 AM > On Wed, May 6, 2009 at 03:04, James > Carman <[email protected]> > wrote: > > On Tue, May 5, 2009 at 8:46 PM, Torsten Curdt <[email protected]> > wrote: > >>> Using what strategy, Torsten? > >> > >> Not sure I understand the question. But let's > try: > > > > I think the question was "using what existing > > technology/framework/tool/etc"? Something like > uberjar, perhaps? > [SNIP] In my apparent ignorance, I was under the impression that "dependency inlining" might encompass other approaches (e.g. svn externals) as well. Anyway, this approach works for encapsulated code, but would it work in the case of [collections] and [functor], where we're talking about the API itself? Maybe what we're looking for here is a multi-pronged approach. Inline private/implementation dependencies AND create finer-grained artifacts per Jorge's suggestion in the same thread. In the case of [collections] and [functor] I could even see withdrawing all [functor] code from [collections] and having [functor] publish a functor-collections artifact (because [functor]'s API is quite richer than the comparable part of [collections]. -Matt --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
