--- On Wed, 5/6/09, Torsten Curdt <tcu...@apache.org> wrote:
> From: Torsten Curdt <tcu...@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 <ja...@carmanconsulting.com>
> wrote:
> > On Tue, May 5, 2009 at 8:46 PM, Torsten Curdt <tcu...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
