commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)
Date Fri, 17 Oct 2014 20:11:27 GMT
Yes, that what i said we were not impacted even if the stack is big.

Once again in theory you are right but in practise that's boring and
creates averhead  for nothing.
Le 17 oct. 2014 22:08, "sebb" <sebbaz@gmail.com> a écrit :

> On 17 October 2014 19:08, Romain Manni-Bucau <rmannibucau@gmail.com>
> wrote:
> > I did it twice or more. it is not magic but the goal is to put
> > removed/changed classes outside the core project (yes it implies some
> > modules). this way the core part (what i call core here is what
> > doesn't change) stays the same with same packages and only what moves
> > changes.
>
> I still don't get it.
>
> Suppose you have the following method in the Item class:
>
> public int getLength()
>
> You want to change it to
>
> public long getLength()
>
> This is not binary compatible.
>
> Suppose I move the int version into a legacy jar.
> The long version is in the core jar.
> Both are in the same class.
>
> Now assume that appA uses the int version, and appB has been updated
> to use the long version.
>
> I don't see how one can make this work with Maven.
> The JVM classloader can only load a single version of the Item class.
>
> However appA needs one version, and appB needs the other.
>
> Note: I know that this can be made to work with OSGI (it uses multiple
> class-loaders) but that is a separate issue.
>
> > I know it is easier to just change everything but then you can't cry
> > cause the war does 200M to pring hello ;).
> >
> > Using maven pom dependencies can also make it smoother using the pom
> > dependency as an aggregator.
> >
> > it wouldn't be commons which is (are actually) everywhere I wouldn't
> > care that much but commons is so widely spread that it is a bit harder
> > to manage (it is comparable to asm if it speaks to anyone).
>
>
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-10-17 20:02 GMT+02:00 Phil Steitz <phil.steitz@gmail.com>:
> >> On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
> >>> Well maven showed the opposite. And this is clearly a theory vs
> practise
> >>> topic so not sure it does worth allimenting this thread since well not
> agree
> >>
> >> Top-posting this kind of statement does no good.  If you have a
> >> better approach, please describe it.
> >>
> >> Phil
> >>> Le 17 oct. 2014 15:52, "Matt Benson" <gudnabrsam@gmail.com> a écrit
:
> >>>
> >>>> It's not just the broken parts that your dependencies may be using.
> The
> >>>> strategy Commons uses is the only way any of us know to permit forward
> >>>> movement while avoiding jar hell.
> >>>>
> >>>> Matt
> >>>> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <rmannibucau@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <britter@apache.org>:
> >>>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <
> rmannibucau@gmail.com>:
> >>>>>>
> >>>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <garydgregory@gmail.com>:
> >>>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau
<
> >>>>>>> rmannibucau@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <britter@apache.org>:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau
<
> >>>>> rmannibucau@gmail.com
> >>>>>>>> :
> >>>>>>>>>> <snip>
> >>>>>>>>>>
> >>>>>>>>>>> In TomEE the stack uses [lang], then [lang3]
was created and
> now
> >>>>>>> TomEE
> >>>>>>>>>>> needs [lang] + [lang3] where actually it
only needs [lang]
> >>>>> features,
> >>>>>>>>>>> ie suppose package didn't change then we
wouldn't have had any
> >>>>> issue.
> >>>>>>>>>>> So it means you tend to import multiple
versions of the same
> lib
> >>>>> just
> >>>>>>>>>>> cause few parts were broken even if it doesn't
affect you.
> >>>> That's
> >>>>> a
> >>>>>>>>>>> bit sad IMO.
> >>>>>>>>>>>
> >>>>>>>>>> If there is anything missing in lang3 that blocks
you from
> >>>>> migrating
> >>>>>>>>>> completely, can you tell us what that is? Maybe
we can fix
> >>>> that...
> >>>>>>>>> Issue is not in [commons] but in dependencies. The
code we own
> >>>>>>>>> migrated but not all our deps.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I suggest you ask/Jira each dep to update their [lang]
to the
> >>>> latest.
> >>>>>>> That
> >>>>>>>> has worked for me in the past with different FOSS projects
I've
> made
> >>>>> the
> >>>>>>>> request about this and that libraries.
> >>>>>>>>
> >>>>>>>> Some projects will be receptive and at least reply to
you right
> >>>> away,
> >>>>>>>> others won't. Patches help of course since will require
at least
> >>>>> import
> >>>>>>>> changes.
> >>>>>>>>
> >>>>>>> yep, main issue ATM is some can't or doesn't maitain the
version we
> >>>>>>> use - excepted for security issues (we are bound to a EE
version
> for
> >>>>>>> instance). It meanse it will be forgotten in few years but
it also
> >>>>>>> means we can get the same with [lang3] and [lang4] so clearly
> >>>>>>> something to tackle at [commons] level. We can't just ask
> everybody to
> >>>>>>> update each time IMHO.
> >>>>>>>
> >>>>>> The alternative is, that TomEE won't run at all because of
> incompatible
> >>>>> API
> >>>>>> changes. I would vote for the lesser evil ;-)
> >>>>>>
> >>>>> No, if broken part are provided in a -legacy.jar or a
> >>>>> -compatibility.jar there would be no issue.
> >>>>>
> >>>>>>>> Gary
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> Benedikt
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> http://people.apache.org/~britter/
> >>>>>>>>>> http://www.systemoutprintln.de/
> >>>>>>>>>> http://twitter.com/BenediktRitter
> >>>>>>>>>> http://github.com/britter
> >>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>>>>>>> Java Persistence with Hibernate, Second Edition
> >>>>>>>> <http://www.manning.com/bauer3/>
> >>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/
> >
> >>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
> >>>>>>>> Blog: http://garygregory.wordpress.com
> >>>>>>>> Home: http://garygregory.com/
> >>>>>>>> Tweet! http://twitter.com/GaryGregory
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> http://people.apache.org/~britter/
> >>>>>> http://www.systemoutprintln.de/
> >>>>>> http://twitter.com/BenediktRitter
> >>>>>> http://github.com/britter
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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