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 <[email protected]>: > 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" <[email protected]> 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" <[email protected]> >>> wrote: >>> >>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <[email protected]>: >>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <[email protected]>: >>>>> >>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <[email protected]>: >>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau < >>>>>> [email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[email protected]>: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau < >>>> [email protected] >>>>>>> : >>>>>>>>> <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: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> E-Mail: [email protected] | [email protected] >>>>>>> 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: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> -- >>>>> http://people.apache.org/~britter/ >>>>> http://www.systemoutprintln.de/ >>>>> http://twitter.com/BenediktRitter >>>>> http://github.com/britter >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
