ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <g.grigelio...@gmail.com>
Subject Re: Impact of Java SecurityManager being deprecated for removal post Java 17
Date Thu, 23 Sep 2021 18:49:36 GMT
On Thu, 23 Sept 2021 at 15:55, <apache@materne.de> wrote:

> We could also mark these tasks as deprected and remove them with a 1.11.x
> release (sometimes in the future).
>
> Jan
>

Good proposal; there are some deprecated tasks already.

I would like to clarify my point, since I used "antlib" loosely which
caused some confusion:
I meant a separate jar file in the Ant distribution (with a separate
pom.xml).
Whether the names of the obsolete tasks should be removed from
default.properties
(and placed in an own antlib.xml) is another question altogether.

Gintas


> -----Urspr√ľngliche Nachricht-----
> Von: Stefan Bodewig <bodewig@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 <bodewig@apache.org> wrote:
>
> 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
> <https://gitbox.apache.org/repos/asf?p=ant.git;a=commit;h=9c1f4d905da59bf446570ac28df5b68a37281f35>
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message