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