commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)
Date Tue, 21 Oct 2014 06:44:38 GMT
2014-10-19 6:18 GMT+02:00 Henri Yandell <flamefew@gmail.com>:

> On Sat, Oct 18, 2014 at 2:44 PM, Phil Steitz <phil.steitz@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.
> >
>

I think Commons is very conservative when it comes to redesigning new APIs.
API styles change over time, so pushing out a complete redesign after some
years is necessary to keep innovation up. Just some numbers: lang 2.0 has
been released on 02/Sep/03, lang 3.0 on 18/Jul/11...


>
> 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 :)
>

Very big +1 :-)


>
> Hen
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message