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
