commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gudnabr...@yahoo.com
Subject Re: [COLLECTIONS] 3.3 release
Date Wed, 06 May 2009 12:52:58 GMT


--- On Wed, 5/6/09, Torsten Curdt <tcurdt@apache.org> wrote:

> From: Torsten Curdt <tcurdt@apache.org>
> Subject: Re: [COLLECTIONS] 3.3 release
> To: "Commons Developers List" <dev@commons.apache.org>
> Date: Wednesday, May 6, 2009, 2:47 AM
> On Wed, May 6, 2009 at 03:04, James
> Carman <james@carmanconsulting.com>
> wrote:
> > On Tue, May 5, 2009 at 8:46 PM, Torsten Curdt <tcurdt@apache.org>
> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message