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
