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
