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" <pbened...@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 <rmannibu...@gmail.com > > > wrote: > > > Le 17 oct. 2014 23:09, "sebb" <seb...@gmail.com> a écrit : > > > > > > 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. > > > > > > > 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 <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 > > > > > >
