We could also mark these tasks as deprected and remove them with a 1.11.x release (sometimes in the future).
Jan -----Ursprüngliche Nachricht----- Von: Stefan Bodewig <bode...@apache.org> Gesendet: Sonntag, 19. September 2021 15:04 An: dev@ant.apache.org Betreff: Re: Impact of Java SecurityManager being deprecated for removal post Java 17 On 2021-09-19, Gintautas Grigelionis wrote: > On Mon, 23 Aug 2021 at 17:39, Stefan Bodewig <bode...@apache.org> wrote: >> On 2021-08-19, Gintautas Grigelionis wrote: >>> On Thu, 19 Aug 2021 at 12:01, Stefan Bodewig <bode...@apache.org> wrote: >>>> I didn't mean the Antlib to be backwards compatible, but rather to >>>> offer it and tell people to switch over to it. It would be the >>>> first time we'd remove a core feature of Ant completely, though, so >>>> we may need to discuss whether there is a better migration path. We >>>> have moved some source code management tool specific tasks to >>>> antlibs in the past, but never a core part. >>> Would it make sense to create a "legacy" antlib for, say, JEE (EJB, >>> JSP, >>> etc) and VCS tasks + anything that has been deprecated in JDK? >> I'd only do that if it reduces maintenance burden for anybody. > Is packaging away unmaintainable code (because of third-party > dependencies etc) a maintenance burden, or is it a one-off job to make > clear what's legacy? You may set the expectation things would become supported again if you create a new antlib just for the legacy stuff. Some of these tasks use internal APIs and may need to be adapted when these APIs change. Take for example the fixes for CVE-2020-1945 - commit https://gitbox.apache.org/repos/asf?p=ant.git;a=commit;h=9c1f4d905da59bf4465 70ac28df5b68a37281f35 touched a couple of tasks we'll probably consider legacy (cvstagdiff, ejb even jikes). With separate antlibs we need to make the change across X repos and cut new releases of the Antlibs in a situation like this. > There are about 60 old issues (11+ years) in Bugzilla for these tasks > that would never be actualised again. Very true. TBH I don't expect any of the orignal reporters still wait for us to come up with a fix. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
