commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@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 Fri, 17 Oct 2014 20:57:31 GMT
FWIW, I have found no difficulty moving code from lang2 to lang3. It's a
breeze. I did a wholesale replacement of the package name and then fixed
any compiler problems due to API differences.


Cheers,
Paul

On Fri, Oct 17, 2014 at 3:51 PM, sebb <sebbaz@gmail.com> wrote:

> On 17 October 2014 21:37, Romain Manni-Bucau <rmannibucau@gmail.com>
> wrote:
> > Each time you break an api extract this part in compatibility
> (deprecated)
> > n-1 jar and export new one in the v n jar. Grabbing pom dependecy you get
> > by default n jars but if you want you can exclude include jars to get n-1
> > apis and moreover you didnt break anything for 80% of users.
>
> Moving deprecated classes to a separate jar is a very different issue.
> That will work provided that the whole deprecated class is moved to
> the compatibility jar.
> A new class will need to be created for the new code.
> In this case, there is no binary compatibility issue.
>
> In my earlier example, one would deprecate the Item class, and create
> Item2, or change its package.
>
> But this can start to get quite messy quickly.
>
> > I know it is far from being perfect but lang, collections...are often
> twice
> > in apps. A maybe better alternative is to do smaller modules this way you
> > get less impacted.
> > Le 17 oct. 2014 22:21, "Duncan Jones" <djones@apache.org> a écrit :
> >
> >> On 17 Oct 2014 21:11, "Romain Manni-Bucau" <rmannibucau@gmail.com>
> wrote:
> >> >
> >> > 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.
> >>
> >> You're not making a lot of sense here. Sebb explained a problem with
> your
> >> approach, but your response is that he's right in theory, but that's
> >> boring?
> >>
> >> I don't see how a multiple jar approach could work. Can you explain?
> >>
> >> Duncan
> >>
> >> > 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
> >> > >
> >> > >
> >>
>
> ---------------------------------------------------------------------
> 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