On Mon, Jun 6, 2022 at 8:40 AM Amit Pande <amit.pa...@veritas.com.invalid> wrote: > > Thank you, Gary, for the response. > > Yes, it would be ideal to upgrade to latest 4.x. > We can/should do that where there is direct dependency. > > But what about when this collections jar is pulled in as a transitive > dependency? > > For example, commons validator requires 3.2.2. If we are using this library, > how could we proceed?
You can't. > Do we know if there is a plan for commons validator to consume this latest > 4.y series of commons-collections? The head of Validator's master branch depends on Java 7 and the head of Collections master branch depends on Java 8. Therefore, currency, Validator could only migrate to a very old version of Collections 4 that also depends on Java 7. This would still require updating at least the import statements in Validator. We could of course update Validator to Java 8 and then update the imports to the latest Collections. Any of this happening depends on the interest and availability of the volunteers here (like me) to do the work. There are currently no plans that I know of to do this but it seems like the right path forward. I think Validator might be the last Commons component that is not on Java 8. Gary > > Thanks, > Amit > > > Get Outlook for iOS<https://aka.ms/o0ukef> > ________________________________ > From: Gary Gregory <garydgreg...@gmail.com> > Sent: Monday, June 6, 2022 7:31:38 AM > To: Commons Users List <user@commons.apache.org> > Subject: [External] Re: Question regarding the 3.x.x commons-collections > library > > Hi Amit and all: > > I definitely recommend migrating to the latest of the 4.x line. > > We provide a kind of version 3.x support in the sense that anyone with > historical knowledge or the inclination can answer questions here. As > far as any new releases of the 3.x branch, I would say that this would > be quite unlikely unless the community was made aware of a critical > CVE and decided that a release was warranted, Security issues should > be discussed according to > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommons.apache.org%2Fsecurity.html&data=05%7C01%7CAmit.Pande%40veritas.com%7C9279d3e091724018767708da47b88c4e%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637901155203878773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=46U4Z6G6vLFIC1j909U6w%2BiCtDIt93dbGZdyMh3p9CI%3D&reserved=0 > > We have not made a formal EOL statement of the 3.x line but this would > seem like a good idea. > > Gary > > > On Fri, Jun 3, 2022 at 4:23 PM Amit Pande > <amit.pa...@veritas.com.invalid> wrote: > > > > Greetings all! > > > > Given that we have around four versions of the commons-collections version > > 4.x.x, I wanted to check if the 3.y.y versions are still supported or not? > > To put it differently, are the 3.y.y EOL'ed? > > > > If not, is it safe to believe that any security vulnerability fixes in > > 3.y.y series will still be made? > > > > I could not find anything on EOL of 3.y.y series, but our organization has > > recommended to move to the 4.x.x line. > > Unfortunately, this is not a drop-in replacement for 3.y.y artifacts and > > more over in some cases, commons-collections gets pulled in as transitive > > dependency of other libraries. > > As an example, the commons-validator mentions commons-collection 3.y.y as > > its dependency. > > (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommons.apache.org%2Fproper%2Fcommons-validator%2Fdependencies.html&data=05%7C01%7CAmit.Pande%40veritas.com%7C9279d3e091724018767708da47b88c4e%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637901155203878773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FyK64bzFK0tUzYD4d8Zf2j1jg9ghjG5%2F7sgpbXNe9BY%3D&reserved=0) > > > > Appreciate your feedback on this. > > > > Thanks, > > Amit > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
