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 Sat, 18 Oct 2014 19:05:41 GMT
Right but why should i have N times same binaries (cause broken apis are
minor as it was said)? In tomee we even thought to repackage everything to
avoid duplication
Le 18 oct. 2014 20:54, "Paul Benedict" <pbenedict@apache.org> a écrit :

> I don't understand the point your making. Because the two libraries have
> their code in completely separate packages, there will never be a conflict
> at compile time or runtime.
>
>
> Cheers,
> Paul
>
> On Sat, Oct 18, 2014 at 2:21 AM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > Le 17 oct. 2014 23:09, "sebb" <sebbaz@gmail.com> a écrit :
> > >
> > > On 17 October 2014 21:57, Paul Benedict <pbenedict@apache.org> wrote:
> > > > 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.
> > >
> >
> > When you own the code sure, that's the only issue.
> >
> > > Which is why we do it that way, rather than renaming individual
> classes.
> > >
> > > >
> > > > 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
> > > >>
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > 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