On 17 October 2014 21:57, Paul Benedict <pbened...@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.

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 <seb...@gmail.com> wrote:
>
>> On 17 October 2014 21:37, Romain Manni-Bucau <rmannibu...@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" <djo...@apache.org> a écrit :
>> >
>> >> On 17 Oct 2014 21:11, "Romain Manni-Bucau" <rmannibu...@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" <seb...@gmail.com> a écrit :
>> >> >
>> >> > > On 17 October 2014 19:08, Romain Manni-Bucau <rmannibu...@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.ste...@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" <gudnabr...@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" <
>> >> rmannibu...@gmail.com>
>> >> > > >>>> wrote:
>> >> > > >>>>
>> >> > > >>>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <
>> brit...@apache.org>:
>> >> > > >>>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <
>> >> > > rmannibu...@gmail.com>:
>> >> > > >>>>>>
>> >> > > >>>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <
>> >> garydgreg...@gmail.com
>> >> >:
>> >> > > >>>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
>> >> > > >>>>>>> rmannibu...@gmail.com>
>> >> > > >>>>>>>> wrote:
>> >> > > >>>>>>>>
>> >> > > >>>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <
>> >> brit...@apache.org
>> >> >:
>> >> > > >>>>>>>>>> Hi,
>> >> > > >>>>>>>>>>
>> >> > > >>>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
>> >> > > >>>>> rmannibu...@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-unsubscr...@commons.apache.org
>> >> > > >>>>>>>>> For additional commands, e-mail:
>> dev-h...@commons.apache.org
>> >> > > >>>>>>>>>
>> >> > > >>>>>>>>>
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> --
>> >> > > >>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org
>> >> > > >>>>>>> For additional commands, e-mail:
>> dev-h...@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-unsubscr...@commons.apache.org
>> >> > > >>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>> >> > > >>>>>
>> >> > > >>>>>
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> ---------------------------------------------------------------------
>> >> > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> > > >> For additional commands, e-mail: dev-h...@commons.apache.org
>> >> > > >>
>> >> > > >
>> >> > > >
>> ---------------------------------------------------------------------
>> >> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> > > > For additional commands, e-mail: dev-h...@commons.apache.org
>> >> > > >
>> >> > >
>> >> > >
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> > > For additional commands, e-mail: dev-h...@commons.apache.org
>> >> > >
>> >> > >
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to