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 > > > >
