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
