Phil summarized it right! But we can stop this thread since maybe tomee will just need to take more 《ownership》 on its deps to tackle it... Le 19 oct. 2014 06:19, "Henri Yandell" <flame...@gmail.com> a écrit :
> 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 >
