On Sat, Oct 18, 2014 at 2:44 PM, Phil Steitz <phil.ste...@gmail.com> wrote:

> On 10/18/14 2:03 PM, Paul Benedict wrote:
> > You are not including duplicate artifacts, they are totally distinct.
>
> I think Romain's point is that classes that are not changed in the
> different versions are duplicated.  It's interesting that from
> Romain's standpoint, the single jar, mass package rename strategy we
> have taken is "impractical," but what seems reasonable to him -
> split changed APIs into new jars - seems impractical to us.  So
> either he ends up repackaging (or distributing a larger
> distribution), or we do.  This is probably not a popular view here,
> but I think the moral of the story is we should try as much as
> possible to avoid backward-incompatible change in already released
> APIs - i.e., favor deprecate and replace.  That at least makes the
> splitting possible.  From painful experience in [math], however, I
> know this is sometimes not possible - i.e., there is such a thing as
> broken APIs - bugs that can't be resolved without incompatible API
> change.  And in other cases [pool], [dbcp], there really is no
> "duplication" as the v2's are completely different implementations.
>

But if Roman's use case is to ship the smallest amount of code as possible,
then he shouldn't be relying on dependencies being small. He should be
using build-time strategies to pull only the classes, or the functions,
that are needed.

Not that I'm not +1 to splitting off the lang3.time package into its own
jar, and then leaving it in maintenance only mode :)

Hen

Reply via email to