Re: Release Ant 1.10.15?

[Stefan Bodewig]

On 2024-02-21, Jaikiran Pai wrote:

> If it's OK then I plan to do the next 1.10.x release in a few weeks,
> unless someone is working on anything that needs to be part of this
> release.

+1

I currently haven't got anything I'd be working on.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Issues with how Ivy processes maven dependency management dependencies compared to adding a classifier key

[Stefan Bodewig]

On 2024-02-15, Kittisopikul, Mark Andrew wrote:

> I applied for an account again.

Great, I've approved the request. Hope things are moving now.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Issues with how Ivy processes maven dependency management dependencies compared to adding a classifier key

[Stefan Bodewig]

Mark

can you please try to create a JIRA account again? I've been told it
should work now.

Thanks

Stefan

On 2024-02-03, Kittisopikul, Mark Andrew wrote:

> Hi Stefan,

> I submitted a cleaner pull request here to add the maven classifier to the 
> extra info key.
> https://github.com/apache/ant-ivy/pull/99

> I am not clear how to create an account to file the issue. When attempting to 
> set up an account via the self service and selecting ant it says
> "
> The project you have selected does not use Jira for issue tracking. Please 
> contact the project at dev@ant.apache.org to find out where to submit issues.
> "
> https://selfserve.apache.org/jira-account.html
> Sincerely,
> Mark
> ____
> From: Stefan Bodewig 
> Sent: Sunday, November 19, 2023 5:04 AM
> To: dev@ant.apache.org 
> Subject: Re: Issues with how Ivy processes maven dependency management 
> dependencies compared to adding a classifier key

> External Email: Use Caution

> Hi Mark

> first of all please go and read
> https://urldefense.com/v3/__https://lists.apache.org/thread/h372vt1ztd6gfmgmfkmqzrksx6fpw97g__;!!Eh6p8Q!GgynwlKf6QW3Ni-XDPMGKmczFHKLN_uAlLFMNWuYa6hCRFUwgy7ITEzA4_otBW07MduVoBD-ieBEm5kt19GVUSFtsQ$

> I very much doubt you will find any people who know Ivy's internals
> better than you do (by now) on this list.

> On 2023-11-17, Kittisopikul, Mark Andrew wrote:

>> Hello,

>> At the Howard Hughes Medical Institute Janelia Research Campus, we 
>> encountered an issue with transitive dependencies when using the IJava [1] 
>> Jupyter kernel that uses Apache Ivy for dependency resolution.

>> When adding the dependency org.janelia.saalfeld.lab.n5-ij [2] Ivy does not 
>> correctly recognize net.imglib2.imglib2 [3] as a compile dependency. This is 
>> because when processing the parent POM (pom-scijava [4]), Ivy only stores 
>> extra information with a groupId__artifactId key without the classifier.

>> The initial fix I have produced is to modify the key to include the 
>> classifier: groupId__artifiactId__classifierId. I have prototyped these 
>> changes on a Github fork [5]. I would like to discuss how we might upstream 
>> these changes to Apache Ivy.

> The changes are probably the same as in
> https://urldefense.com/v3/__https://github.com/mkitti/ant-ivy/pull/1/files__;!!Eh6p8Q!GgynwlKf6QW3Ni-XDPMGKmczFHKLN_uAlLFMNWuYa6hCRFUwgy7ITEzA4_otBW07MduVoBD-ieBEm5kt19EGrRpHlw$

> Before I'd try to understand the changes you've made I'd ask you to back
> out all changes that are not relevant to what you want to achieve. All
> changes to whitespace, ordering of imports or changes to the eclipse
> settings for example as they (1) are just noise when it comes to
> understanding your changes and (2) may hide changes that are overlooked
> when a reviewer thinks they can skip the changes as they "are just
> noise".

> This is not because I wouldn't trust you but rather because I don't
> trust myself as a reviewer. We've had more than one changeset in Ant
> that was big, looked good, and introduced subtle bugs that we
> overlooked.

> I vaguely recall having to change some classifier stuff in order to fix
> a bug a few months ago[A] so I am not surprised there are more issues
> lurking. Personally I'll be glad to review a PR and merge it - please
> open a JIRA issue as well.

> As for upstreaming the patch, even after we merged a PR we'd still have
> to cut a release. Even if we managed to get enough people interested in
> voting on that, I still want to point you at the thread linked from the
> top of the mail.

> Cheers

> Stefan

> [A] 
> https://urldefense.com/v3/__https://issues.apache.org/jira/browse/IVY-1642__;!!Eh6p8Q!GgynwlKf6QW3Ni-XDPMGKmczFHKLN_uAlLFMNWuYa6hCRFUwgy7ITEzA4_otBW07MduVoBD-ieBEm5kt19Fy1q8wZA$

> -
> 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

Re: Issues with how Ivy processes maven dependency management dependencies compared to adding a classifier key

[Stefan Bodewig]

On 2024-02-03, Kittisopikul, Mark Andrew wrote:

> I submitted a cleaner pull request here to add the maven classifier to the 
> extra info key.
> https://github.com/apache/ant-ivy/pull/99

I haven't looked into it, yet, will do some time later - can't promise
to do so this weekened.

> I am not clear how to create an account to file the issue. When attempting to 
> set up an account via the self service and selecting ant it says
> "
> The project you have selected does not use Jira for issue tracking. Please 
> contact the project at dev@ant.apache.org to find out where to submit issues.
> "
> https://selfserve.apache.org/jira-account.html

The selfservice page looks a bit strange, it used to be different. Ant
the product uses Bugzilla and Ivy uses Jira which the new page doesn't
seem to know about that.

I'll file a bug with our infra folks.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: IVY-1576 still exist in 2.5.2

[Stefan Bodewig]

On 2024-01-07, Austin Zhang wrote:

> So I think the tips for folks bumping into this issue is to clean the ivy
> cache.

Yes, absolutely. I'll try to carve out some time to update the Ivy
release notes for 2.5.2 to reflect this.

This seems to be true for all issues involving POM parsing errors. Ivy
will not overwrite existing ivy.xml files in the cache, so you are stuck
with whatever an earlier version has created.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: IVY-1576 still exist in 2.5.2

[Stefan Bodewig]

On 2023-12-13, Austin Zhang wrote:

> java -jar apache-ivy-2.5.2/ivy-2.5.2.jar -dependency "org.tensorflow"
> "tensorflow-core-platform-gpu" "0.5.0" -retrieve
> "ivy/[organization]_[artifact]-[revision](-[classifier]).[ext]" -confs
> "runtime" -debug

> files in ivy folder are:
> com.google.protobuf_protobuf-java-3.19.4.jar
> org.bytedeco_javacpp-1.5.8-windows-x86_64.jar
> org.bytedeco_javacpp-1.5.8-linux-x86_64.jar
> org.tensorflow_tensorflow-core-api-0.5.0-linux-x86_64-gpu.jar
> org.tensorflow_tensorflow-core-api-0.5.0-windows-x86_64-gpu.jar
> org.tensorflow_ndarray-0.4.0.jar

> Both org.bytedeco_javacpp-1.5.8.jar and
> org.tensorflow_tensorflow-core-api-0.5.0.jar
> are missing.

Running this with a freshly downloaded ivy-2.5.2.jar results in

$ ls ivy
com.google.protobuf_protobuf-java-3.19.4.jar
org.bytedeco_javacpp-1.5.8.jar
org.bytedeco_javacpp-1.5.8-linux-x86_64.jar
org.bytedeco_javacpp-1.5.8-windows-x86_64.jar
org.tensorflow_ndarray-0.4.0.jar
org.tensorflow_tensorflow-core-api-0.5.0.jar
org.tensorflow_tensorflow-core-api-0.5.0-linux-x86_64-gpu.jar
org.tensorflow_tensorflow-core-api-0.5.0-windows-x86_64-gpu.jar

for me. It seems as if I do get the expected results.

If you have tried to download things with an earlier version of Ivy
before you may be using cached ivy descriptors created from the Maven
POMs with the older version.

I don't think you are hitting IVY-1576 - which is not the only bug in
translating POMs. In 2.5.2 we fixed IVY-1642 (which looks more like the
problem you have) which in turn is a more complete fix of IVY-1580.

Please remove your cached artifacts of everythng and try again with Ivy
2.5.2.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Future of Ivy and IvyDE

[Stefan Bodewig]

Hi Eric

On 2023-12-04, Eric Milles wrote:

> It sounds to me like Ivy and IvyDE -- even as a retired subproject -- should 
> move out from under Apache Ant.  Just for my clarity, is Apache Ivy a 
> top-level project or a subproject of Apache Ant?

The top level ASF project here is "Apache Ant" and the corresponding PMC
oversees the Ant build tool, Apache Ivy, a few "Antlibs" and up to their
retirement IvyDE, EasyAnt and Antidote.

You may be aware of ASF discussions on the term "subproject" in other
places. We've called Ivy and IvyDE "projects", but that's just a
word. They are/have been components with releases the Ant PMC voted on -
just like the Ant build tool. Technically the Ant top-level project has
a single set of committers who are committers to all Ant "projects" and
release votes have always involved the full PMC.

Does that help?

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Need help with Ant tests

[Stefan Bodewig]

Hi Claude,

I've created https://github.com/Claudenw/creadur-rat/pull/4

The AntUnit tests all pass for me when run via "ant -f run-antunit.xml"
inside apache-rat-tasks. I don't know enough about the way classloaders
and I/O redrections work in Maven's antrun to be of any help here.

I needed to fix the classloader loading the custom matcher class as
otherwise you'd have two different IHeaderMatcher classes loaded and the
custom matcher simply has not been an instance of the class known to the
task's License class.

All tests around Ant's output simply worked on first try. This must be
an artifact of how antrun runs Ant. I haven't got any insights to offer,
sorry.

Finally the test aboud report and custom matchers simply don't work as
Report doesn't support nested IHeaderMatchers at all, it only accepts
nested Licenses.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[ANN] Apache IvyDE Retired

[Stefan Bodewig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Apache Ant Project Management Commitee has voted[1] to retire its
IvyDE subproject. This means all its resources are removed or made read
only and no further development will be done.

Apache IvyDE let you manage your dependencies declared in an Apache Ivy
ivy.xml in your Java Eclipse projects.

The existing website and documentation will stay but no longer get
updated. The same is true for the source code repositories and the JIRA
issue tracker. All releases of IvyDE remain avaiable from the Apache
release archive[2].

Should a new community grow around IvyDE, the subproject could be
reactivated[3].

We want to thank the people who created or contributed to IvyDE over the
years.

Stefan Bodewig on behalf of the Ant PMC.

[1] https://lists.apache.org/thread/wo32q8s8o8z9m126gz3m533q2fnqq21o

[2] 
https://ant.apache.org/processes.html#Reactivate%20a%20subproject%20or%20component

[3] 
https://ant.apache.org/processes.html#Reactivate%20a%20subproject%20or%20component
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAmVjbhsACgkQohFa4V9ri3LinQCeMiN4U0fZWnhboEdBqfOhjkVR
oYIAni6+c4Fuhj9Ql7DwUFGN7l0fsK5g
=rfPg
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [RESULT] Retire the IvyDE Subproject

[Stefan Bodewig]

Stefan Bodewig  writes:

> I'll now proceeded with the process outlines at
> https://ant.apache.org/processes.html#Retire%20a%20subproject%20or%20component

https://issues.apache.org/jira/browse/INFRA-25209
https://issues.apache.org/jira/browse/INFRA-25210

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[RESULT] Retire the IvyDE Subproject

[Stefan Bodewig]

Hi all,

with +1s by PMC members Jaikiran Pai, Dominique Devienne, Nicolas
Lalevée, Maarten Coene and Martijn Kruithof (I seem to have forgotten to
vote myself, but am +1) - and no other votes, it is decided IvyDE is
going to be retired.

I'll now proceeded with the process outlines at
https://ant.apache.org/processes.html#Retire%20a%20subproject%20or%20component

Many thanks to thos who have voted

 Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[VOTE] Retire the IvyDE Subproject

[Stefan Bodewig]

I'm really sorry and embarrassed but I seem to have misunderstood the
purpose of the Attic, it is not responsible for retiring subprojects,
only for top level projects like Ant as a whole with all subprojects.

The correct process to follow is
https://ant.apache.org/processes.html#Retire%20a%20subproject%20or%20component

This is a new vote as I do not want to assume I could transfer the votes
of a different vote and repurpose them.

The actual vote:

Following our own rules I propose zo retire IvyDE.

Vote will be open for at lease 72 hours, will not end before 2023-11-26T07:30 
UTC

Sorry

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [RESULT] Send IvyDE to the Apache Attic

[Stefan Bodewig]

On 2023-11-22, Stefan Bodewig wrote:

> I'll draft the board resolution and will coordinate adding it to the
> next board meeting agenda.

I'm really sorry and embarrassed but I seem to have misunderstood the
purpose of the Attic, it is not responsible for retiring subprojects,
only for top level projects like Ant as a whole with all subprojects.

The correct process to follow is
https://ant.apache.org/processes.html#Retire%20a%20subproject%20or%20component

I'll start a new vote as I do not want to assume I could transfer the
votes of a different vote and repurpose them.

Sorry

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[RESULT] Send IvyDE to the Apache Attic

[Stefan Bodewig]

Hi all

with +1s by the PMC members Jaikiran Pai, Martijn Kruithof, Nicolas
Lalevée, Maarten Coene, Dominique Devienne and myself - and no other
votes - the vote has passed.

I'll draft the board resolution and will coordinate adding it to the
next board meeting agenda.

Many thanks for those who voted

 Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Send IvyDE to the Apache Attic

[Stefan Bodewig]

On 2023-11-20, Nicolas Lalevée wrote:

> PS: a little part of me is crying, this project was my first substantial 
> involvement in the ASF ^^

I understand you far better than you will know. Letting go is hard and I
can't say I'd be happy calling for this vote..

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Packaging ivy with Eclipse

[Stefan Bodewig]

On 2023-11-21, Jörn Guy Süß wrote:

> Does anyone know how challenging it would be w.r.t. licenses to package ivy
> with the main Eclipse distribution? I feel having ivy on board would make a
> big difference to usability.

After now having an Eclipse installation I thought it would be easy to
find where the "main distribution" content may be, but no.

Anyway, I'm pretty sure Eclipse already bundles several Apache projects
(commons projects would be my first bet) and many of the plugins
certainly depend on things that use the Apache Software License (as
Spring does, for example). I know some part ships XMLUnit (which I
maintain, Apache licensed as well) as the Eclipse legal folks once asked
me about it.

Legally there shouldn't be any problem AFAICT. Of course I'm not a lawyer.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Send IvyDE to the Apache Attic

[Stefan Bodewig]

officially recording my own vote

On 2023-11-19, Stefan Bodewig wrote:

> So here is the formal vote:

> I hereby propose to create a board resolution that will send IvyDE to
> the Apache Attic.

+1

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[VOTE] Send IvyDE to the Apache Attic

[Stefan Bodewig]

Hi all,

within the "Future of Ivy and IvyDE" thread[1] I started about three
months ago to me it seemed as if people wouldn't be happy if IvyDE died
but I also didn't sense there was a community willing to keep it
alive. Consequently I now call for a vote to send IvyDE to the Apache
Attic following the rules layed out in https://attic.apache.org/process.html

The attic doesn't have to be a dead-end. If there are people who want to
fork IvyDE outside of the ASF they are free to (and have always
been). Basically it would resolve the Ant PMC of the duty of oversight
over the code base.

This vote will require either three PMC members to vote +1 to pass or
alternatively less than three -1s - but I really hope we don't end up
with not getting enough votes at all. If there is any -1 by a PMC member
I'm willing to immediately cancel the vote and rediscuss.


So here is the formal vote:

I hereby propose to create a board resolution that will send IvyDE to
the Apache Attic.

This vote will stay open at least 72 hours and won't be closed before
2023-11-22 17:30 UTC - likely later.

Cheers

Stefan

[1] https://lists.apache.org/thread/h372vt1ztd6gfmgmfkmqzrksx6fpw97g

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Trying my hands at an ivy-updatesite (was Re: Future of Ivy and IvyDE)

[Stefan Bodewig]

On 2023-09-05, Nicolas Lalevée wrote:

> And we tried our best to be opened on how to build and release the
> plugin and the updatesite, it is documented [2]. On my machine which
> just have Ant and Java installed, I just tried and I have been able to
> build of the updatesite with the last release of Ivy without much
> effort.

Many thanks for the pointer, Nicolas.

In my case it immediately stopped with

,
| eclipse-startup-check:
| 
| BUILD FAILED
| /home/stefan/devel/ASF/ivy-updatesite/build.xml:39: An Eclipse install is 
needed to run the build. Set your Eclipse install dir into the baseLocation 
property.
`

and I haven't got any idea of which version of Eclipse I'd need to
install. So I went with 202309 and kept my fingers crossed. At least the
build proceeded.

https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.2.final_20230817170011/
is what I created. TBH I have no idea what I have created and signed -
nor do I have any way of verifying it works.

If anybody wants - and is able - to check what I've created, I'd be
grateful. Even then I don't really feel comfortable calling for a vote
on something I don't even trust myself.

Cheers

Stefan

> [2] https://ant.apache.org/ivy/ivyde/history/latest-milestone/dev.html

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Issues with how Ivy processes maven dependency management dependencies compared to adding a classifier key

[Stefan Bodewig]

Hi Mark

first of all please go and read
https://lists.apache.org/thread/h372vt1ztd6gfmgmfkmqzrksx6fpw97g

I very much doubt you will find any people who know Ivy's internals
better than you do (by now) on this list.

On 2023-11-17, Kittisopikul, Mark Andrew wrote:

> Hello,

> At the Howard Hughes Medical Institute Janelia Research Campus, we 
> encountered an issue with transitive dependencies when using the IJava [1] 
> Jupyter kernel that uses Apache Ivy for dependency resolution.

> When adding the dependency org.janelia.saalfeld.lab.n5-ij [2] Ivy does not 
> correctly recognize net.imglib2.imglib2 [3] as a compile dependency. This is 
> because when processing the parent POM (pom-scijava [4]), Ivy only stores 
> extra information with a groupId__artifactId key without the classifier.

> The initial fix I have produced is to modify the key to include the 
> classifier: groupId__artifiactId__classifierId. I have prototyped these 
> changes on a Github fork [5]. I would like to discuss how we might upstream 
> these changes to Apache Ivy.

The changes are probably the same as in
https://github.com/mkitti/ant-ivy/pull/1/files

Before I'd try to understand the changes you've made I'd ask you to back
out all changes that are not relevant to what you want to achieve. All
changes to whitespace, ordering of imports or changes to the eclipse
settings for example as they (1) are just noise when it comes to
understanding your changes and (2) may hide changes that are overlooked
when a reviewer thinks they can skip the changes as they "are just
noise".

This is not because I wouldn't trust you but rather because I don't
trust myself as a reviewer. We've had more than one changeset in Ant
that was big, looked good, and introduced subtle bugs that we
overlooked.

I vaguely recall having to change some classifier stuff in order to fix
a bug a few months ago[A] so I am not surprised there are more issues
lurking. Personally I'll be glad to review a PR and merge it - please
open a JIRA issue as well.

As for upstreaming the patch, even after we merged a PR we'd still have
to cut a release. Even if we managed to get enough people interested in
voting on that, I still want to point you at the thread linked from the
top of the mail.

Cheers

Stefan

[A] https://issues.apache.org/jira/browse/IVY-1642

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Need help with Ant tests

[Stefan Bodewig]

Hi Claude

On 2023-10-01, Claude Warren wrote:

> I have been working on RAT-321 [1] and am trying to rework the ant tests
> for the new structure.

> My goal has been to get all options supported in any of the 3 configuration
> interfaces (cli, Ant, Maven) to be supported in the ReportConfiguration
> object.  I think I have mostly achieved this.

> I modified the Ant task to configure the o.a.r.ReportConfiguration and
> herein lies my problem.  I am not conversant in the internals of ant tasks
> and the antunit library.  There are 6 tests that fail, they are all in the
> report-normal-operations.xml antunit library. [2]  They  are all commented
> out and tagged with "FIXME" so they are easy to find and they broadly fall
> into 2 categories:

>1. Adding new elements based on either the IHeaderMatcher
>orIHeaderMatcher.Builder implementations.
>2. Detecting text in the Ant output when it is not sent to a file.

> All of these tests work when executed using the BuildFileRule under the
> o.a.r.anttasks.ReportTest.[3]

> Is there anyone here that can take a look at the tests and see what I did
> wrong?  I would greatly appreciate it.


Sorry for the delay. I have written the RAT Ant task a very long time
ago and also written the tests. Unfortunately I no longer spend as much
time on open source software as I did a few years ago, so it took quite
some time to respond. I'll try to carve out some time to look into your
changes an what to do about the tests in the coming days.

Many thanks for trying to maintain the Ant integration of RAT.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Need help with release versions in bugzilla

[Stefan Bodewig]

No problem, I was just afraid I might have done something wrong.

Stefan

On 2023-09-11, Jaikiran Pai wrote:

> Thank you Stefan. I probably didn't look correctly when trying to
> close a recent bug that got fixed. I see that the bug is now correctly
> fixed for 1.10.15. Thank you.

> -Jaikiran

> On 08/09/23 12:13 pm, Stefan Bodewig wrote:
>> On 2023-09-08, Jaikiran Pai wrote:

>>> Can someone with admin permissions please mark 1.10.14 as a released
>>> version in Ant bugzilla and create a new 1.10.15 release in it?
>> I think I've already done so when the release was published, let me
>> check. Yes, I see them in the admin interface.

>> Cheers

>>  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


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Need help with release versions in bugzilla

[Stefan Bodewig]

On 2023-09-08, Jaikiran Pai wrote:

> Can someone with admin permissions please mark 1.10.14 as a released
> version in Ant bugzilla and create a new 1.10.15 release in it?

I think I've already done so when the release was published, let me
check. Yes, I see them in the admin interface.

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Future of Ivy and IvyDE

[Stefan Bodewig]

On 2023-08-28, Cohen, Ross wrote:

> Perhaps someone from the Ant team can poke the Eclipse people and tell
> them that there are devs/teams that will simply move to another IDE
> rather than give up Ant/Ivy/IvyIDE; it might be very much in their
> best interest to put a dev part time on Ivy/IvyIDE.

My guess is the impact would be bigger if actual users of IvyDE told
them.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Future of Ivy and IvyDE

[Stefan Bodewig]

On 2023-08-22, Jason Guild wrote:

> I can confirm that in the not very distant past there were multiple
> people (including myself) who submitted pull requests for Ivy to both
> make improvements as well as address bugs. They were left to rot for
> far too long.

This is unfortunate. In a way this may have happened because nobody is
left around who'd be able to acually verify your changes. This is not
what it should have been, but it happened. And I'm not sure it wouldn't
happen again.

> It was frustrating to me that even a very simple patch required both a
> debate on its utility and then navigating pedantries on the coding
> approach before then taking nearly two years to get merged and
> incorporated into a release.

Ouch. And sorry for that.

> I feel that people who were trying to get started maintaining Ivy,
> like myself, were simply put off by unresponsive
> committers. Absolutely I understand there is a lacking in capacity of
> people to verify changes but the situation, at least with me, felt
> like simple gatekeeping.

It is good you say this, Jason. Believe me, it is not
gatekeeping. Nobody is around anymore who'd want to stand at the gate at
all.

And I'm not sure how to move forward. "giving the keys to people who
want them" sounds a lot simpler than it may be in the end.

> I would really appreciate an update site for Ivy though as I've
> wondered how I can upgrade my IDE, easily, to use Ivy 2.5.{1,2}.
> It would be great if the existing update site for IvyDE [0] could at
> least be updated for the artifacts we have.

I have built the 2.5.{1,2} releases. I have no idea what an update site
is and how to create one. OK, I do have a vague idea what it is, but
absolutely no idea how to create one.

If you (or anybody else) can coach me through the process of creating an
update site starting with a jar and nothing else, then I'm game. Being
able to verify the thing actually works would be great. Bonus points if
I don't need to install anything I wouldn't use otherwise.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Future of Ivy and IvyDE

[Stefan Bodewig]

Hi

sorry for my bad timing sending out an email and then being unbale to
answer for days. This is not what I intended.

Let me try to answer what I've seen so far. And I'll try to keep my
personal opinion out this time.

It is pretty obvious Ivy is used today and maybe even loved by
some. This is great for any project.

As is probably true with all volunteer based open source projects people
come and go as their interests and focus change.

In the case of Ivy this unfortunately means it is not maintained well
today and this is not going to change with the current set of Ant
developers. All of us work on Ant in our spare time and we've picked
developing Ant for several different reasons - none of these reasons
seem to apply to Ivy for anybody of us.

It is not my intention to kill Ivy. Not at all. But if maintenance of
Ivy is left with the current set of Ant developers this is what is
likely going to happen, eventually.

It just seemed to be fair to inform Ivy's users about the current
state.

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Future of Ivy and IvyDE

[Stefan Bodewig]

Hi all

before I get to the actual content of this mail:

* I'm cross-posting to three lists but I ask you to keep responses to
  dev@ant only (and join the list if necessary) if you want to respond.

* what I write is my personal opinion and not shared by the PMC as a
  whole. The people on the PMC know I'd be writing a mail like this
  sooner or later, though.

* this is a discussion, not a vote.

phew

I'm not quite sure what I hope to achieve with this email, but I'd like
to share my thoughts - and raise the awareness of an elephant being in
the room.

Over the past year we've had three security vulnerabilities discovered
in Ivy and it took us much too long to get them fixed. The reason for
this is there are no people left around who are familiar with the Ivy
code base. Most of the remaining developers around Ant are not even
users of Ivy - I know I am not and have never been.

When it comes to IvyDE things are probably even worse as nobody of us
uses Eclipse, either. But then again I've not managed to create an
Eclipse update site for the last two Ivy releases so maybe nobody is
using IvyDE anymore anyway.

At least *I* don't see myself digging deeper into the Ivy code base in
order to fix non-critical bugs. And even for the critical ones I feel we
are not doing an adequate job. To me it looks as if Ivy and in
particilar IvyDE are no longer really supported by the Ant project.

TBH I'm not quite sure what to do about this. Even if people stepped up
to maintain Ivy, the rest of the Ant devs would probably be unable to
verify the changes they want to make. At least I certainly am not
willing to review bigger PRs/patches to a code base I don't understand
well.

Personally I believe we should send IvyDE to the Apache Attic
immediately, and this likely should be the destination for Ivy sooner or
later as well. In the case of Ivy we know there are people who depend on
it (hi, Groovy folks) so maybe we should give a date in the future until
which we are providing security bug fixes to give people time to move
off.

There may be the need for a dependency management system inside of Ant,
I'm not sure. If so, then this should be driven by people who feel the
actual need IMO. There may already be alternatives to Ivy I am not aware
of.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

CVE-2022-46751: Apache Ivy: XML External Entity vulnerability in Apache Ivy

[Stefan Bodewig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Severity: moderate

Affected versions:

- - Apache Ivy 1.0.0 through 2.5.1

Description:

Improper Restriction of XML External Entity Reference, XML Injection (aka Blind 
XPath Injection) vulnerability in Apache Software Foundation Apache Ivy.This 
issue affects any version of Apache Ivy prior to 2.5.2.

When Apache Ivy prior to 2.5.2 parses XML files - either its own configuration, 
Ivy files or Apache Maven POMs - it will allow downloading external document 
type definitions and expand any entity references contained therein when used.

This can be used to exfiltrate data, access resources only the machine running 
Ivy has access to or disturb the execution of Ivy in different ways.

Starting with Ivy 2.5.2 DTD processing is disabled by default except when 
parsing Maven POMs where the default is to allow DTD processing but only to 
include a DTD snippet shipping with Ivy that is needed to deal with existing 
Maven POMs that are not valid XML files but are nevertheless accepted by Maven. 
Access can be be made more lenient via newly introduced system properties where 
needed.

Users of Ivy prior to version 2.5.2 can use Java system properties to restrict 
processing of external DTDs, see the section about "JAXP Properties for 
External Access restrictions" inside Oracle's "Java API for XML Processing 
(JAXP) Security Guide".

Credit:

CC Bomber, Kitri BoB (finder)
Jenkins Security Team (reporter)

References:

https://docs.oracle.com/en/java/javase/13/security/java-api-xml-processing-jaxp-security-guide.html#GUID-94ABC0EE-9DC8-44F0-84AD-47ADD5340477
https://gitbox.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=2be17bc18b0e1d4123007d579e43ba1a4b6fab3d
https://lists.apache.org/thread/9gcz4xrsn8c7o9gb377xfzvkb8jltffr
https://ant.apache.org/
https://www.cve.org/CVERecord?id=CVE-2022-46751

Timeline:

2022-11-30: reported to the ASF security team
2023-08-20: made public
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAmTiYP0ACgkQohFa4V9ri3J5AACfQZlPRXWN0pU73Rm5o24EbBE+
cAoAn3XtnwhZYn395m1cw+9tadrX0oWv
=d+kA
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[ANN] Apache Ivy 2.5.2 Released

[Stefan Bodewig]

The Apache Ant Team is pleased to announce the release of Apache Ivy
2.5.2.

Apache Ivy is a dependency manager focusing on flexibility and
simplicity with strong integration into the Apache Ant build tool.

Ivy 2.5.2 is bugfix release and addresses an XML external entity
injection vulnerability, see the upcoming CVE announcement or
https://ant.apache.org/ivy/security.html for details.

Source and binary distributions are available for download from the
Apache Ivy download site:

https://ant.apache.org/ivy/download.cgi

When downloading, please verify signatures using the KEYS file available
at the above location when downloading the release.

Changes in 2.5.2 include:
=

- FIX: ivy:retrieve could fail because of a `NullPointerException` 
(jira:IVY-1641[])
- FIX: reading POMs may loose dependencies when multiple Maven
  dependencies only differ in `classifier` (jira:IVY-1642[])
- IMPROVEMENT: Upgrade Apache HttpClient to 4.5.13 (jira:IVY-1644[])
- FIX: CVE-2022-46751: Apache Ivy Is Vulnerable to XML External Entity 
Injections

For complete information on Ivy, including instructions on how to submit
bug reports, patches, or suggestions for improvement, see the Apache Ivy
website:

https://ant.apache.org/ivy/

Stefan Bodewig, on behalf of the Apache Ant community

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[RESULT] Release Ivy 2.5.2 Based on RC2

[Stefan Bodewig]

Hi

with three binding +1s by Maarten, Jaikiran and myself, the vote has
passed. I'll proceed with publishing the release artifacts and will
announce the release after the mirros had time to catch up.

Thanks to all who took a look at the release candidate

   Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Release Ivy 2.5.2 Based on RC2

[Stefan Bodewig]

just officially registering my implicit +1

Stefan

On 2023-08-17, Stefan Bodewig wrote:

> Hi all

> I've cancelled the previous vote as the NOTICE file didn't contain
> 2023. sorry about this. Now I've built a new release candidate for Ivy
> 2.5.2

> Changelog:

> - FIX: ivy:retrieve could fail because of a `NullPointerException` (IVY-1641)
> - FIX: reading POMs may loose dependencies when multiple Maven
>   dependencies only differ in `classifier` (IVY-1642)
> - IMPROVEMENT: Upgrade Apache HttpClient to 4.5.13 (IVY-1644)

> The release artifacts can be found at
> https://dist.apache.org/repos/dist/dev/ant/ivy/ (svn revision 63486)

> Maven Repo is
> https://repository.apache.org/content/repositories/orgapacheant-1061/org/apache/ivy/ivy/2.5.2/

> Again I have not built the update site, but we never did for 2.5.1
> either and it never bothered anybody.

> Do you vote for the release of these binaries?

> [ ] Yes
> [ ] No

> This vote will be open for 72 hours as usual, I'll close it on
> 2023-08-20 17:00 UTC.

> Thanks

> 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

[VOTE] Release Ivy 2.5.2 Based on RC2

[Stefan Bodewig]

Hi all

I've cancelled the previous vote as the NOTICE file didn't contain
2023. sorry about this. Now I've built a new release candidate for Ivy
2.5.2

Changelog:

- FIX: ivy:retrieve could fail because of a `NullPointerException` (IVY-1641)
- FIX: reading POMs may loose dependencies when multiple Maven
  dependencies only differ in `classifier` (IVY-1642)
- IMPROVEMENT: Upgrade Apache HttpClient to 4.5.13 (IVY-1644)

The release artifacts can be found at
https://dist.apache.org/repos/dist/dev/ant/ivy/ (svn revision 63486)

Maven Repo is
https://repository.apache.org/content/repositories/orgapacheant-1061/org/apache/ivy/ivy/2.5.2/

Again I have not built the update site, but we never did for 2.5.1
either and it never bothered anybody.

Do you vote for the release of these binaries?

[ ] Yes
[ ] No

This vote will be open for 72 hours as usual, I'll close it on
2023-08-20 17:00 UTC.

Thanks

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Release Ivy 2.5.2 Based on RC1

[Stefan Bodewig]

On 2023-08-17, Jaikiran Pai wrote:

> On 17/08/23 10:02 am, Stefan Bodewig wrote:
>> I have not built the update site because I couldn't get the build
>> process to work, so if anybody with the proper build environment wants
>> to create one, thank you. I'm sure we can create it after the release if
>> we want to.

> Is this the Eclipse update site?

Yes.

> From what I remember that requires an Eclipse installation locally,
> that too a very specific version. Unfortunately, it's been an
> extremely long time since I ever used Eclipse and I don't even have
> the setup I used many years back when releasing Ivy.

I didn't manage to create it for 2.5.1 either and so far nobody has
complained, so I'll just assume it is no longer needed.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[CANCELLED][VOTE] Release Ivy 2.5.2 Based on RC1

[Stefan Bodewig]

On 2023-08-17, Jaikiran Pai wrote:

> The NOTICE file however will need an update to the year (it's
> currently having 2022).

Ah, too bad, let me re-roll the artifacts.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Release Apache Ant 1.10.14 based on RC1

[Stefan Bodewig]

On 2023-08-16, Jaikiran Pai wrote:

> I've created RC1 release candidate for Ant 1.10.14 release:

+1

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[VOTE] Release Ivy 2.5.2 Based on RC1

[Stefan Bodewig]

Hi all

I've built a release candidate for Ivy 2.5.2

Changelog:

- FIX: ivy:retrieve could fail because of a `NullPointerException` (IVY-1641)
- FIX: reading POMs may loose dependencies when multiple Maven
  dependencies only differ in `classifier` (IVY-1642)
- IMPROVEMENT: Upgrade Apache HttpClient to 4.5.13 (IVY-1644)

The release artifacts can be found at
https://dist.apache.org/repos/dist/dev/ant/ivy/ (svn revision 63477)

Maven Repo is
https://repository.apache.org/content/repositories/orgapacheant-1060/org/apache/ivy/ivy/2.5.2/

I have not built the update site because I couldn't get the build
process to work, so if anybody with the proper build environment wants
to create one, thank you. I'm sure we can create it after the release if
we want to.

Do you vote for the release of these binaries?

[ ] Yes
[ ] No

This vote will be open for 72 hours as usual, I'll close it on
2023-08-20 4:30 UTC.

Thanks

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Release Ivy 2.5.2

[Stefan Bodewig]

Hi all

while Jaikiran talks about release Ant, I intend to cut a new Ivy
release soonish. We've seen two bug fixes to Ivy
 and  I
believe IVY-1642 shows a serious incompatibility with Ivy.

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Release Ant 1.10.14?

[Stefan Bodewig]

Jaikiran Pai  writes:

> If there are no objections then I'll send out a formal vote mail for
> the 1.10.14 release, this coming week.

Sounds good to me.

Thanks

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Issues running tests on Gump after switching to Java 21

[Stefan Bodewig]

Hi all

Mark has upgraded Gump to Java21 and it seems running tests with Ant is
somehow broken.  http://vmgump.apache.org/project_todos.html

I haven't looked into the details myself, yet, just wanted to point out
the issues.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Need Help Understanding Ivy's dependency/artifacts

[Stefan Bodewig]

Maarten Coene  writes:

> thanks for looking into this.
> After having a quick look at the diffs and without being able to look into 
> the code myself, I think I prefer your approach to solve the issue.
>
> Maybe Jaikiran can remember more details, but I'd go for backing out the 
> changes to IvyNodeUsage and push your fix.
>

Thanks Maarten, I'll do so.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Need Help Understanding Ivy's dependency/artifacts

[Stefan Bodewig]

Hi all

tldr; there is a bug report about Ivy no handling dependencies to
modules with multiple artifacts - some with classifier, but not all -
and the way I fixed this seems to work. But I have no idea whether I am
fixing it the correct way and need help by somebody understanding Ivy'
semantics - I don't.

longer story:

Over on the ivy-user list somebody reported Ivy would only resolve the
"data" classified artifact as transitive dependency of Saxon-HE where
Saxon's POM contains


  org.xmlresolver
  xmlresolver
  5.1.1


  org.xmlresolver
  xmlresolver
  5.1.1
  data


and yes, this is true for the current master branch. This is the ivy.xml
created from the POM snippet above


  


I created https://issues.apache.org/jira/browse/IVY-1642 and tried to
fix it. My understanding was that this Ivy dependency means Saxon-HE
depends on the "data" artifact and only the data artifact and the
correct solution would be to add a second artifact that matches the
"default" name/type/ext.

So I "fixed" PomModuleDescriptorBuilder to do what I believed to be the
correct translation of the POM.

When I ran the tests ResolveTest#testIvy1580 failed. The modified code
would suddenly return three artifacts as dependency not two as
expected. The non-classifier artifact was returned twice.

First of all this made me discover
https://issues.apache.org/jira/browse/IVY-1580 which, I believe,
describes the same error as the new IVY-1642.

Jaikiran fixed the problem back then with
https://github.com/apache/ant-ivy/commit/d714d9dffbaa2c91855297a7df1c5d9ddfe6d0b0
. He tackled it from a different angle, rather than changing the way POM
dependencies are translated he changed the way dependencies are resolved
by throwing in an "include everything" rule under certain
circumstances. I must admit this change is beyond my understanding of
Ivy.

Backing out his change to IvyNodeUsage fixed the test in my branch. So
maybe my change alone would be enough to resolve the problem? Or there
are two different issues at hand and each of us just fixed one part of
it?

In my branch I decided to keep the IVY-1580 change and "fix" the test by
making sure Ivy's reported dependencies don't contain any
duplicates. The result can be seen here

https://github.com/apache/ant-ivy/compare/ivy-1642

I must admit that I just don't know whether this is correct - apart from
that it fixes the bug reproducer for IVY-1642.

I'll be grateful for any insight

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Improvement ideas for Ant 1.10.13

[Stefan Bodewig]

On 2023-03-02, Stefan Bodewig wrote:

> On 2023-02-27, KUNES Michael wrote:

>> 1) I agree that this NPE might not occur under normal
>> circumstances. Therefore, I am quite sure that the finding is due to
>> our static code analysis tool remarks and just some
>> beautification. But danger to introduce problems is quite low.

> Do you want to prepare a formal bug report and patch - or a github pull
> request? Or should I just go ahead and add a null check myself? Either
> way is fine with me.

I just realized it would be good to scan for other places where we don't
check File#list's result properly

https://github.com/apache/ant/commit/38b7e94c17c304aa3b7e13fc7d9ccdb47e4a4f89

This also addresses the TarEntry case.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Improvement ideas for Ant 1.10.13

[Stefan Bodewig]

On 2023-03-02, KUNES Michael wrote:

> Thank you for the hint! We will evaluate that alternative soon.

> Problem for such an evaluation is: we've a huge amount of different HW types 
> (all embedded) with SW from brand new to VERY old (10y+). Therefore, such 
> replacements always are dangerous and need lot of tests. In these cases: 
> "never change a running SW" really has a meaning...

Ah, I see. In the case of "really old HW" the required minimum Java
version might become an issue. For Commons Compress and Ant 1.10.x that
would be Java 8 and might be too ambituous for your usage. (feels a bit
odd to write that in times where major frameworks move to Java 17 as
baseline, but I've worked on very conservative long running projects
myself :-).

The second issue you reported should have been fixed with Ant 1.8.0
which is compatible with Java 1.4 (like any other 1.8.x release).

The 1.9.x branch which is still maintained by us for serious bug fixes
requires Java 5 with 1.9.16 being the latest release.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Improvement ideas for Ant 1.10.13

[Stefan Bodewig]

On 2023-02-27, KUNES Michael wrote:

> We are using tar as part of our software to prepare data sent to
> devices that use tar or tgz format for receiving e.g.: CSV,
> XML,... files

Then I'd strongly recommend you look into replacing it with Commons
Commpress at one point in time. The libary does support some POSIX
tricks Ant's codebase doesn't support and they've added a TarFile class
for random access (much like ZipFile) that would be out of scope for
Ant.

Still.

> 1) I agree that this NPE might not occur under normal
> circumstances. Therefore, I am quite sure that the finding is due to
> our static code analysis tool remarks and just some
> beautification. But danger to introduce problems is quite low.

Do you want to prepare a formal bug report and patch - or a github pull
request? Or should I just go ahead and add a null check myself? Either
way is fine with me.

> 2) we did this fix some 10-15 years ago since we had some problem with
> one of our embedded devices that is not very fault-tolerant. But to be
> true, that's all I remember.  Big sorry!

No problem at all. It would be good if you could give the updated Ant
codebase with Arrays.fill a try to verify this really fixes the problem
for you as well.

Many thanks

 Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Improvement ideas for Ant 1.10.13

[Stefan Bodewig]

Hi Michael

many thanks for your suggestions. You could have just opened enahncement
requests in Bugzilla but personally I appreciate you trying to have a
discussion about the changes here first.

I am wondering whether you are using the tar package directly or you are
actually facing issues with the code as it is while running Ant. In the
former case I'd suggest you move to Apache Commons Compress which
contains an improved offspring of Ant's tar package - it may even
already contain fixes that are nor present in Ant's original code as
they have not been backported.

On 2023-02-23, KUNES Michael wrote:

> 1) org.apache.tools.tar.TarEntry
> The method public TarEntry[] getDirectoryEntries() could be improved to make 
> a null check for
> final String[] list = this.file.list();
> because the result of this statement could be null and in this case the next 
> statement would fail with NPE

you are correct.

Commons Compress solves this by not invoking #list anymore
https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveEntry.java#L856

The case of #list returning null is a curious case since it probably
represents and I/O error according to the javadoc - the other reason
file not being a directory has already been checked for. Still returning
an empty array probably is a better fallback than throwing an NPE.

> 2) org.apache.tools.tar.TarBuffer
> The method writeBlock() has this statement
> this.outStream.write(this.blockBuffer, 0, this.blockSize);
> we think, that this statement
> this.outStream.write(this.blockBuffer, 0, this.currRecIdx * 
> this.recordSize);
> would be a better solution

> Reason: with original code, after the EOF-blocks, the remaining data 
> (garbage) from the last block was also put to the outstream

Doesn't the Arrays.fill at the end of writeBlock ensure there is no
remaining garbage in the block buffer?

Actually Common Compress writes records directly instead of batching
them to full blocks and only ensures EOF is padded with 0-blocks to fill
the last block, so it effectively avoid the garbage problem you talk
about.

The proper fix here probably would be to apply your suggestion and in
addition write enough data to fill the rest with 0s - or make sure
blckbuffer is padded with zeros before writing it completely.

Sounds a lot like https://issues.apache.org/jira/browse/COMPRESS-81
which lead me to find
https://bz.apache.org/bugzilla/show_bug.cgi?id=47421 which suggest the
same change you did. And back then I changed the code to zero out the
block buffer. You said you were using th ecode of an older version of
Ant, maybe you haven't applied
https://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/tar/TarBuffer.java?r1=789556=789555=789556
?

If you are already using the current master code then I wonder how the
garbage gets into the blockBuffer so we can better understand how to fix
this.

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Pass secret to Exec task

[Stefan Bodewig]

On 2023-01-30, Gilles Querret wrote:

> I have to pass a secret to an Exec task (in a custom Ant plugin), and one
> way to do that is to pipe the output of another command line to this exec
> task.

Unfortunately there is no direct support for pipes.

> I've tried setInputString, but the passphrase is visible when using "ant
> -v", and I'd like to avoid that. I'd also like to avoid having to use
> temporary files with the passphrase, as this is usually not very secure.
> Is it possible to use the Redirector element from Java code ?

I quickly thought you could try using named pipes rather than temporary
files on an OS that supports it, but I must admit I've never tried that
myself from within Ant. And it would have the same security implications
as a temporary file anyway.

Using Redirector should work, you don't create a redirector but rather a
RedirectorElement and send that to ExecTask#addConfiguredRedirector.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Need help with Ant versions in bugzilla

[Stefan Bodewig]

On 2023-01-10, Jaikiran Pai wrote:

> Now that we have released 1.10.13 of Ant, could someone with bugzilla
> access please create a new 1.10.13 product version and a new 1.10.14
> milestone version, for Ant?

I have already done so when you closed the vote :-)

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Release Apache Ant 1.10.13 based on RC1

[Stefan Bodewig]

On 2023-01-04, Jaikiran Pai wrote:

> Happy new year, everyone :)

to you as well

> I've created RC1 release candidate for Ant 1.10.13 release:

> git tag: ANT_1.10.13_RC1

>     on commit: 6996b80b5fb59cc2769f7098d837de32680a

> tarballs: https://dist.apache.org/repos/dist/dev/ant/

+1

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Release Ant 1.10.13?

[Stefan Bodewig]

On 2022-12-11, Jaikiran Pai wrote:

> On 26/11/22 11:33 pm, Stefan Bodewig wrote:
>> On 2022-11-19, Stefan Bodewig wrote:

>> Finding A solution was a nice puzzle, but that doesn't mean we have to
>> use it.

> I had a look at that commit and the PR discussion where the initial
> fix was made. I don't have enough knowledge of this area to provide
> relevant inputs, but from what you have explained here and in the PR
> and looking at the code it looks fine to me. You (and the original
> contributor) note that there are still issues that this change won't
> solve, but I think that is OK for now. I say that because the current
> state/fix addresses an actual issue that was reported[1].

Yes, I'm fine with keeping the code the way it is in master right now.

Thanks

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Jira account with IvyDE issue reporting ability

[Stefan Bodewig]

On 2022-12-10, KDV wrote:

> i would like to vote for a bug and add comment to it in IvyDE project.

> could you please...?

I've moderated this mail through to the list as at least I have missed
the annoucement of our infra team which said we'd no longer allow public
signup of JIRA ccounts. For more details see
https://infra.apache.org/jira-guidelines.html#who

As the pages states the requests should go to Ant's private list, not
the dev list. I doubt people want to have their account information on a
publically archived list by default. It also says what kind of
information we need in order to proceed, so to the requester (BCCed in
this message), please provide all information we need in case you are a
real person.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Release Ant 1.10.13?

[Stefan Bodewig]

On 2022-11-19, Stefan Bodewig wrote:

> while running all tests locally I realized
> https://github.com/apache/ant/pull/194 introduces a bug when tars have
> an encoding set. You can see this with UntarTest failing. A multibyte
> encoding like UTF16 may contain NUL bytes inside of the "normal" part of
> the name. I'll have to think about a way to solve this, but we should
> not release Ant with this regression.

https://github.com/apache/ant/commit/e04fbe7ffa4f549bdc00bdfce688fb587120eedd
fixes tthe problem, at least for our test.

It makes parsing tar archives a bit slower, but that likely won't matter
much for single-byte encodings (tar isn't meant to be used with
multi-byte encodings). Also I don't think reading tars is what a normal
build does for the majority of its time.

Anyway, I'd appreciate a review of the code I've written there.

What I wanted to do is to ask the encoding how it would represent a NUL
and look search for that when finding the string terminator - as opposed
to looking for a single NUL byte.

Our testcase used UTF-16 BE with a BOM, so encoding "\0" ends up with
two bytes BOM + 0x00 0x00 - while I really only wanted to 0x00
0x00. Next attempt was to encode an empty string to see whether there is
a common prefix, but an empty string is encoded as 0 bytes, no BOM. :-)

So finally I compared "X" to "X\0" and stripped what seems to be
"X". I'm pretty sure this breaks for certain encodings, but not worse
than it has worked before.

And then I sprinkled some memoization on top.

TBM I could also live with reverting the whole commit, saying "don't use
multi-byte encodings in tars" and be done. The original test we had
worked by accident, if the old test had used UTF16-LE instead and a 49
character file name it would have failed as we'd try to decode a byte
array with an odd number of bytes.

Finding A solution was a nice puzzle, but that doesn't mean we have to
use it.

Stefan


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Release Ant 1.10.13?

[Stefan Bodewig]

On 2022-11-18, Stefan Bodewig wrote:

> On my personal TODO list there are a few minor things like Java 20
> removing another target option that we may want to tell users
> about. Nothing of this is critical AFAIR and shouldn't hold up a release
> if I don't get to them soon enough.

I'm through with this BUT

while running all tests locally I realized
https://github.com/apache/ant/pull/194 introduces a bug when tars have
an encoding set. You can see this with UntarTest failing. A multibyte
encoding like UTF16 may contain NUL bytes inside of the "normal" part of
the name. I'll have to think about a way to solve this, but we should
not release Ant with this regression.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Release Ant 1.10.13?

[Stefan Bodewig]

On 2022-11-16, Jaikiran Pai wrote:

> Users can still use the current released Ant version against these
> recent Java versions, but they additionally have to set a system
> property while launching Ant to allow setting the security
> manager. Ant's mainline code has changes where it does the necessary
> work (to the extent possible) to set this property internally without
> forcing the users to do that. So releasing this version of Ant should
> help projects building against these recent versions.

I guess you've seen Earl Hood's response, I haven't looked into it
myself, yet.

On my personal TODO list there are a few minor things like Java 20
removing another target option that we may want to tell users
about. Nothing of this is critical AFAIR and shouldn't hold up a release
if I don't get to them soon enough.

+1 on releasing a new version soonish.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Pull request process

[Stefan Bodewig]

On 2022-11-07, Keith Campbell wrote:

> I created https://github.com/apache/ant/pull/194, but since that
> repository is just a mirror, perhaps I should instead create a pull
> request at https://gitbox.apache.org/repos/asf?p=ant.git;a=summary
> instead.

No, everything you've done is correct.

We only support pull requests at github - and old-fashioned patches for
the ASF repo directly. :-)

The github mirror works both ways, so merging a PR via the github UI
will also apply it to the ASF repository.

As for your particular PR, please bear with us. We may be a bit slow at
times and in the case of your PR I need to find the format spec I read
when I wrote the code in question - and then a of undisturbed time. I
vaguelly recall there was a reason why we started looking for the
zero-byte from the end of the array, just need to remember why.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

CVE-2022-37866: Apache Ivy: Ivy Path traversal

[Stefan Bodewig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Severity: medium

Description:

When Apache Ivy downloads artifacts from a repository it stores them in
the local file system based on a user-supplied "pattern" that may
include placeholders for artifacts coordinates like the organisation,
module or version.

If said coordinates contain "../" sequences - which are valid characters
for Ivy coordinates in general - it is possible the artifacts are stored
outside of Ivy's local cache or repository or can overwrite different
artifacts inside of the local cache.

In order to exploit this vulnerability an attacker needs collaboration
by the remote repository as Ivy will issue http requests containing ".."
sequences and a "normal" repository will not interpret them as part of
the artifact coordinates.

Mitigation:

Users of Apache Ivy 2.0.0 to 2.5.1 should upgrade to Ivy 2.5.1.

Credit:

This issue was discovered by Kostya Kortchinsky of the Databricks Security Team.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAmNk8sYACgkQohFa4V9ri3JXVgCfZGdMMMpBiGNSJ+tThEhGsCdj
YQUAoJzfXVkx1ZMIYe0wmlk0iTSQWjDV
=ZYMI
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

CVE-2022-37865: Apache Ivy allow create/overwrite any file on the system

[Stefan Bodewig]

Severity: medium

Description:

With Apache Ivy 2.4.0 an optional packaging attribute has been
introduced that allows artifacts to be unpacked on the fly if they used
pack200 or zip packaging.

For artifacts using the "zip", "jar" or "war" packaging Ivy prior to
2.5.1 doesn't verify the target path when extracting the archive. An
archive containing absolute paths or paths that try to traverse
"upwards" using ".." sequences can then write files to any location on
the local fie system that the user executing Ivy has write access to.

Mitigation:

Ivy users of version 2.4.0 to 2.5.0 should upgrade to Ivy 2.5.1.

Credit:

This issue was discovered by Kostya Kortchinsky of the Databricks Security Team.

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[ANN] Apache Ivy 2.5.1 Released

[Stefan Bodewig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Apache Ant Team is pleased to announce the release of Apache Ivy
2.5.1.

Apache Ivy is a dependency manager focusing on flexibility and
simplicity with strong integration into the Apache Ant build tool.

Ivy 2.5.1 is bugfix release and addresses two path traversal
vulnerabilities, see the upcoming CVE announcement or
https://ant.apache.org/ivy/security.html for details.

Source and binary distributions are available for download from the
Apache Ivy download site:

https://ant.apache.org/ivy/download.cgi

When downloading, please verify signatures using the KEYS file available
at the above location when downloading the release.

Changes in 2.5.1 include:
=

- - BREAKING: Removed old fr\jayasoft\ivy\ant\antlib.xml AntLib definition file 
(see IVY-1612)
- - FIX: ResolveEngine resets dictator resolver to null in the global 
configuration (see IVY-1618)
- - FIX: ConcurrentModificationException in MessageLoggerHelper.sumupProblems 
(see IVY-1628)
- - FIX: useOrigin="true" fails with file-based ibiblio (see IVY-1616)
- - FIX: ivy:retrieve Ant task didn't create an empty fileset when no files 
were retrieved to a non-empty directory (see IVY-1631)
- - FIX: ivy:retrieve Ant task relied on the default HTTP header "Accept" which 
caused problems with servers that interpret it strictly (e.g. AWS CodeArtifact) 
(see IVY-1632)

- - IMPROVEMENT: Ivy command now accepts a URL for the -settings option (see 
IVY-1615)
- - FIX: CVE-2022-37865 allow create/overwrite any file on the system (see 
https://ant.apache.org/ivy/security.html)
- - FIX: CVE-2022-37866 Path traversal in patterns (see 
https://ant.apache.org/ivy/security.html)

For complete information on Ivy, including instructions on how to submit
bug reports, patches, or suggestions for improvement, see the Apache Ivy
website:

https://ant.apache.org/ivy/

Stefan Bodewig, on behalf of the Apache Ant community
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAmNk8ecACgkQohFa4V9ri3KZ5wCgqMKXyK121kiPGiRi1HsLckAi
S+0Anjhk4KTIXfSbQVZEomvv6AxVBQ1W
=XsJz
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[RESULT] Release Iyv 2.5.1 Based on RC1

[Stefan Bodewig]

Hi all

with +1s by Jaikiran, Martijn and my own implicit one, the vote has
passed. I'll start publishing the reease and send out the announcements
soonish.

Thanks to all who helped with the release

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[VOTE] Release Iyv 2.5.1 Based on RC1

[Stefan Bodewig]

Hi all

I've built a release candidate for Ivy 2.5.1

Changelog:

- BREAKING: Removed old fr\jayasoft\ivy\ant\antlib.xml AntLib definition file 
(jira:IVY-1612[])
- FIX: ResolveEngine resets dictator resolver to null in the global 
configuration (jira:IVY-1618[])
- FIX: ConcurrentModificationException in MessageLoggerHelper.sumupProblems 
(jira:IVY-1628[])
- FIX: useOrigin="true" fails with file-based ibiblio (jira:IVY-1616[])
- FIX: ivy:retrieve Ant task didn't create an empty fileset when no files were 
retrieved to a non-empty directory (jira:IVY-1631[])
- FIX: ivy:retrieve Ant task relied on the default HTTP header "Accept" which 
caused problems with servers that interpret it strictly (e.g. AWS CodeArtifact) 
(jira:IVY-1632[])

- IMPROVEMENT: Ivy command now accepts a URL for the -settings option 
(jira:IVY-1615[])

The release artifacts can be found at
https://dist.apache.org/repos/dist/dev/ant/ivy/ (svn revision 57703)

Maven Repo is
https://repository.apache.org/content/repositories/orgapacheant-1055/org/apache/ivy/ivy/2.5.1/

I have not built the update site because I couldn't get the build
process to work, so if anybody with the proper build environment wants
to create one, thank you. I'm sure we can create it after the release if
we want to.

Do you vote for the release of these binaries?

[ ] Yes
[ ] No

This vote will be open for 72 hours as usual, I'll close it on
2022-11-04 10 UTC.

Thanks

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Ivy 2.5.1 Release

[Stefan Bodewig]

Hi all

it's been three years since we last had a release of Ivy and there are a
few fixes in master, so I'm planning to cut a patch release.

For the release notes I'm going through the commits to make sure I've
got all things covered. I should be labelling all JIRA issues that I
find so https://issues.apache.org/jira/projects/IVY/versions/12352487
should sooner or later be complete.

Does anybody recall making a change that should be part of the release
notes and is not included in JIRA?

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Migrate from Bugzilla to GitHub Issues

[Stefan Bodewig]

Hi Vladimir

I guess we have to agree that we disagree - and this is fine. Our
perception of how development of Ant happens are quite different. The
issue you are trying to solve is a non-issue for me. And the reasons I
do not want to move to github issues are likely irrelevant to you. No
need to drag the discussion further as we are not going to convince each
other.

Personally I'd prefer to have less github in ASF projects rather than
more, but that may just be me. This has more to do with the ASF being in
control of its own fate than with technical reasons.

Fortunately I'm not the only voice around here :-)

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Migrate from Bugzilla to GitHub Issues

[Stefan Bodewig]

On 2022-08-08, Vladimir Sitnikov wrote:

> Have you considered migrating from Bugzilla to GitHub Issues?

I don't think we ever talked about that, no.

> I think co-locating issues and PRs at GitHub would make it easier to
> navigate between issues and PRs.

PRs are not the only way of contributing to Ant at all - maybe not even
the primary. More often than not issues are raised without any patch or
PR.

> Moving issues to GitHub would simplify cross-references.

between issues and PRs, yes. But not between issues and old
issues. Marking something as a duplicate of a different issue in
Bugzilla wouldn't work.

Personally I really don't believe we want to migrate more than 20 years
of Bugzilla history that is referenced in commit messages and the
WHATSNEW file and in several other places. But I may be wrong.

When working on Ant I barely ever interact with github at all. So at
least I wouldn't see any benefit but a whole lot of work being wasted.

This is not a veto or spmething like that, just an opinion.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: synchronized and Loom

[Stefan Bodewig]

On 2022-06-06, Jaikiran Pai wrote:

> My personal opinion is that we continue with our release plans
> (whenever we do it) instead of waiting for completing these
> changes. The virtual threads feature is a preview feature in JDK 19,
> so I think as long as our tests pass and Ant is usable in Java 19 with
> --enable-preview, I think that's a good enough for an Ant release.

Not having looked into Loom too much I thought we had to remove all uses
of synchronized - largely by seeing some change made else-place. You
seem to have a much better grasp on what Loom means to a code-base than
I have, I fully trust your judegment.

Thanks

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

synchronized and Loom

[Stefan Bodewig]

Hi

right now the Loom prototype doesn't play well with synchronized and the
recommended approach is to use ReentrantLock instead. A quick grep over
Ant's codebase turns up more than 500 hits for synchronized - many of
which in method declarations. So updating it will be a bigger task, in
particular if we wanted to take the time to think through the reasons
for synchronization and whether splitting read/write locks may be
useful.

Do you feel we should do this before the next release or should we defer
it? Another option might be to mechanically replace synchronized with
reentrantlock now and do the "read/write lock separation would be good"
assessment later.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [ant] branch master updated: support default value for scriptdef attribute

[Stefan Bodewig]

On 2022-03-06, Matt Benson wrote:

> I fully planned to do so once I know what next version number we'd be
> targeting.

Ah, thanks

> Minor or point?

I believe the last time we did a minor release has been five years ago,
it's just not going on that much anymore :-)

Most likely we'll have to drop Java 8 support one day - and we could
decide to do so earlier than strictly necessary on a 1.11.x release
train - but we haven't talked about doing anything like that at all,
yet.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [ant] branch master updated: support default value for scriptdef attribute

[Stefan Bodewig]

On 2022-03-06, Stefan Bodewig wrote:

> On 2022-02-25,  wrote:

>>>  
>>>default
>>>the default value of the attribute
>>>No
>>>  

> please add "since ..." somewhere here and a small note in WHATSNEW.

and please do the same for the other attributes an elements you've
added.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [ant] branch master updated: support default value for scriptdef attribute

[Stefan Bodewig]

On 2022-02-25,  wrote:

>>  
>>default
>>the default value of the attribute
>>No
>>  

please add "since ..." somewhere here and a small note in WHATSNEW.

Thanks

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Jenkins build became unstable: Ant » Ant-Build-Matrix-master-Linux » ubuntu,jdk_1.8_latest #128

[Stefan Bodewig]

On 2022-02-15, Matt Benson wrote:

> So my tests for scriptcondition return values were using beanshell
> because I couldn't figure out any way to get rhino to return a value
> from the script. I can't understand which optional dependencies are
> present during the build, where they are, nor how they get there. Are
> they in the lib of the actual Ant installation used by Jenkins? Who
> can help me with this?

Sorry, I'm pretty ,uch restricted to weekends right now - or even less.

AFAIK there the Ant installation does not come with any optional
dependencies, but I may be wrong.

This is what the build job definition for building master on Linux
currently says:

java -version && ./build.sh -f fetch.xml -Ddest=optional && ./bootstrap.sh && 
./build.sh clean jars javadocs test

so dependencies should be in lib/optional

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: New Antlib

[Stefan Bodewig]

On 2022-02-20, Matt Benson wrote:

> The plan from this thread is two years old, so I want to revisit. As
> of now the extant antlibs seem to have their own repos. If I am
> creating a new one, do I want to create its own repo now, or would we
> rather create a sandbox repo and promote its children as they
> "graduate" to their own repos?

I believe there hasn't been any change to the list of antlibs in this
two years. Neither of them is really active. And to be honest I don't
expect any of the existing sandbox antilibs to ever leave that state.

If you plan to bring the Antlib from sandox to proper anyway, I'd
recommend starting with a new targetted repository reight from the
start. This is not an incredibly strong preference, though.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Java 8 for AntUnit

[Stefan Bodewig]

On 2022-02-09, Matt Benson wrote:

> Similarly to the question on Ivy, is there any compelling reason we should
> continue to constrain this antlib to its current level of Java (1.)5?

We still create Ant 1.9.x releases from time to time and 1.9.x would not
be able to use newer releases. Having said that, it is not as if we had
much active development of AntUnit, so it wouldn't miss out much.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19

[Stefan Bodewig]

On 2022-02-08, Jaikiran Pai wrote:

> Hello Earl,

> On 08/02/22 12:59 am, Earl Hood wrote:
>> How exactly does setting the sysprop for only 18 and 19 allow folks to test
>> their stuff?  If Ant currently depends on the security manager to operate,
>> why not set the sysprop regardless, then remove in future when a
>> replacement API exists?

> Java 18 and 19 now throw a runtime exception by default when
> System.setSecurityManager is called at runtime. This behaviour can be
> changed to prevent the exception being thrown and let it behave like
> older versions, by setting the Java system property
> java.security.manager=allow. We (Ant) cannot set it by default to all
> versions of Java because this "allow" value was only introduced in
> Java 12
> https://www.oracle.com/java/technologies/javase/12-relnote-issues.html#JDK-8191053.
>  Ant
> 1.10.x supports using earlier versions than Java 12 (like Java 8), so
> we (Ant) cannot blindly set that value without these Java version
> checks.

I couldn't find what the property does prior to Java 12, so let me add
this for completeness. This is what happens when you set it on Java 8:

Error occurred during initialization of VM
java.lang.InternalError: Could not create SecurityManager: allow
at sun.misc.Launcher.(Launcher.java:106)
at sun.misc.Launcher.(Launcher.java:54)
at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1444)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1429)

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19

[Stefan Bodewig]

On 2022-02-07, Jaikiran Pai wrote:

> So the launch scripts (the Linux one and the .bat for Windows one)
> have both been updated to set this system property only for Java 18
> and 19. I expect this to be a temporary thing till the new API is
> available. Once the new API is available, I think we should just get
> rid of this setting of system property even for Java 18 and 19 (since
> I don't expect many to be using these releases once the newer versions
> are available).

You are more optimistic than me WRT a replacement API. :-)

If you believe this is just going to be an issue for two or three
releases then I can live with a lenghty if. I want to avoid that we need
to cut a new release with every new Java EA just because the replacement
API still hasn't been added.

> Now coming to the actual implementation of this, it took me multiple
> weekends to get the .bat version to correctly work. Mainly due to lack
> of easy access to a Windows setup plus my general lack of knowledge of
> bat scripting and some gotchas when it comes to .bat parsing and the
> "errorlevel" values.

I'm sorry to hear that. And I must admit my .bat programming skills are
no more exhaustive than yours, most probably even less so.

> Ultimately the one I committed ant.bat now launches the Java command
> twice and expects it to dump certain property values, which are then
> used by "find" to see if the version is 18 or 19.

Ouch

Would

jrunscript -e 
"print(java.lang.System.getProperty('java.specification.version'))"

work? TBH I'm not sure jrunscript is available in a JRE rather than a
JDK for versions where there actually is a difference.

Also findstr[1] looks as if you could use it to bring the number of
extra jvm executions down to one as it should allow regexes so

find "java.specification.version = 1[89]"

may work - unless Java 20 still comes without the replacement API as it
looks as if the regex subset supported by findstr doesn't include
alternatives.

> With these changes the CI builds which run Ant tests against Java 18,
> 19 and previous version like Java 17 now work fine. However, like I
> said my scripting skills are minimal, so if any of these changes in
> these scripts can be done in a better way, please feel free to do
> so. I would do it myself, but it's going to take me trial and error
> methods to get it right :)

It would be completely unfair to place the burden on you. I can live
with the current solution even though I'm not happy with it. I might
find a bit of time to experiment this week, but I can't promise
anything.

Stefan

[1] 
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/findstr

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19

[Stefan Bodewig]

On 2022-02-07,  wrote:

> - if [ "$JAVA_SPEC_VERSION" = "java.specification.version=18" ]; then
> + if [ "$JAVA_SPEC_VERSION" = "java.specification.version=18" ] || [ 
> "$JAVA_SPEC_VERSION" = "java.specification.version=19" ]; then

Bourne shell's case may make this more
readable (not sure whether there is a Windows batch file equivalent)

case $JAVA_SPEC_VERSION in
 java.specification.version=18 | \
 java.specification.version=19 )
   ...
   ;;
esac

But I'm afraid this is not going to scale :-)

In the long run we probably are better off by enumerating the JDKs where
we don't want to set the property (ten from 8 to 17, but this is a fixed
list that doesn't need to change with every release).

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Antlib test classpath

[Stefan Bodewig]

On 2022-02-04, Matt Benson wrote:

> I am working on a new antlib (discussed a couple of years ago on list), and
> trying to figure out how to get antunit to run tests using Ivy's created
> classpath.test from the common build framework. I have tried combinations
> of the (hidden) classloader task with antunit references, etc., so far to
> no avail. Does anyone (Stefan?) have any basic suggestions I can try?

I must admit that I never tried to use things with Ivy at all. When I
run tests I do so with several -lib arguments (and always need to figure
out what is required as I don't do it often enough).

If you figured things out it would probably be a good idea to update the
common build structure as needed.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Apache Ant Vulnerability

[Stefan Bodewig]

Hi Ashish

On 2022-02-02, Ashish Verma V wrote:

> We are using "maven-antrun-plugin" that internally uses apache ant.

> Recently high severity vulnerability
> (CVE-2020-11979) is observed
> specific to apache ant

> Kindly let us know the plan to take the latest ant version to fix this
> vulnerability.

The maven antrun plugin is not maintained by the Apache Ant project, but
by the Apache Maven project[1]. You may want to ask over there.

It is possible that Maven configures the temporary directory for the
antrun plugin in a totally different way and thus the plugin is not
affected by the vulnerability. But I am by no means an expert for the
antrun plugin and you really should ask over in Maven land to see
whether it is affected or not.

Please note the CVE we are talking about has been published more than a
year ago.

Cheers

Stefan

[1] https://maven.apache.org/plugins/maven-antrun-plugin/

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Need help with new versions in bugzilla for Ant

[Stefan Bodewig]

On 2021-10-19, Jaikiran Pai wrote:

> Can someone with access to Bugzilla please create a new 1.10.12
> product version and a new 1.10.13 milestone version, for Ant?

Done.

I don't think anybody else of the project team has enough karma. We may
want to change that.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Release Apache Ant 1.10.12 based on RC2

[Stefan Bodewig]

On 2021-10-13, Jaikiran Pai wrote:

> I've created a new RC2 release candidate for 1.10.12:

+1

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Release Apache Ant 1.10.12 based on RC1

[Stefan Bodewig]

On 2021-09-30, Jaikiran Pai wrote:

> This release is mainly a bug fix release and the exact changes are
> noted in
> https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.12.html. Of
> particular interest is the relatively minor bug fix in the javadoc
> task which is necessary for it to work properly in the recently
> released Java 17 version.

+1

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Release 1.10.12 of Ant?

[Stefan Bodewig]

On 2021-09-26, Jaikiran Pai wrote:

> I was planning to initiate a release tonight, but trying to upgrade
> one of the optional dependencies has shown up some interesting issue
> in the maven ant task (which apparently has been EOLed[1]) that we use
> in our fetch.xml.

Maybe you skip upgrading optional dependencies for now? ;-)

I think there is a MR by Gintas to replace the Maven Ant Tasks with
Ivy. Might be time to revisit it.

Thank you for pushing forward with the release

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Impact of Java SecurityManager being deprecated for removal post Java 17

[Stefan Bodewig]

On 2021-09-19, Gintautas Grigelionis wrote:

> On Mon, 23 Aug 2021 at 17:39, Stefan Bodewig  wrote:

>> On 2021-08-19, Gintautas Grigelionis wrote:

>>> On Thu, 19 Aug 2021 at 12:01, Stefan Bodewig  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=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

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Release 1.10.12 of Ant?

[Stefan Bodewig]

On 2021-09-16, Stefan Bodewig wrote:

> On 2021-09-15, Jaikiran Pai wrote:

>> I wanted to look into and sort out
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=65424 in this release
>> too, but it looks like I may not be able to do that and I'm not sure
>> how many more days I'll need to get to that issue.

> The coming weekend I may (or may not) find some time to lend a hand.

> I believe the HELPERS Hashtable (as well as others) in
> IntrospecitonHelper could be replaced with a ConcurrentHashMap and some
> synchronization could be removed if we really want to do that. Unlike
> some other parts of Ant we don't expose the data structures in public
> APIs.

Actually forget the ConcurrentHashMap thought for now, I'll comment in
the ticket with a more detailed answer.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Release 1.10.12 of Ant?

[Stefan Bodewig]

On 2021-09-15, Jaikiran Pai wrote:

> Java 17 has been released yesterday. We have a relatively minor fix in
> javadoc task which affects Java 17 in cases where
> failonwarn=true. Should we consider releasing 1.10.12 of Ant in
> upcoming days to provide this fix and other fixes that we have done
> since 1.10.11 release?

Sounds good.

> I wanted to look into and sort out
> https://bz.apache.org/bugzilla/show_bug.cgi?id=65424 in this release
> too, but it looks like I may not be able to do that and I'm not sure
> how many more days I'll need to get to that issue.

The coming weekend I may (or may not) find some time to lend a hand.

I believe the HELPERS Hashtable (as well as others) in
IntrospecitonHelper could be replaced with a ConcurrentHashMap and some
synchronization could be removed if we really want to do that. Unlike
some other parts of Ant we don't expose the data structures in public
APIs.

> Are there any other issues that others are working on and want to be
> part of this release?

I'm not actively working on anything.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Impact of Java SecurityManager being deprecated for removal post Java 17

[Stefan Bodewig]

On 2021-08-23, Jaikiran Pai wrote:

> On 19/08/21 3:23 pm, Stefan Bodewig wrote:
>> On 2021-08-19, Jaikiran Pai wrote:

>>> Hello Stefan,
>>> On 19/08/21 1:15 pm, Stefan Bodewig wrote:
>>>> At a cursory glance I only see JUnitTask and ExecuteJava deal with the
>>>> SecurityManager if permissions have been defined. Where else do we use
>>>> one?
>>>  From what I see in the Java task code[1], the "execute()" method of
>>> that task calls, "checkConfiguration()"[2] method, which in a
>>> non-forked mode, creates a Permissions instance if no explicit
>>> permissions has been configured[3].
>> I only searched for SecurityManager :-) Thanks.

>> So we are using Ant's permissions system internally to preven
>> System.exit, I see. This is the stuff we will need to replace with
>> whatever is going to be the new API that prevents System.exit. Let's
>> hope all this is not going to become an ugly hack.

> Work has already started to "disallow" SecurityManager as early as
> some upcoming JDK 18 EA release[1]. What that means is any calls to
> System.setSecurityManager(...) would start throwing exceptions. I
> haven't seen much discussion around any proposed API for the
> System.exit(...) usecase. So I decided to explain Ant's use case and
> request for the new API to be included in Java 18
> hopefully. Discussion is here[2].

Thanks. I'm not sure I understand Alan's answer, but if I do then it
might happen that setSecurityManager throws exceptions before a
different API is in place - and the only thing we can do is to tell our
users to fork new VMs rather then run in process.

This is not exactly the user experience I'd be hoping for, but so be it.

> I hope I included the correct details and didn't miss anything. I
> don't have historical knowledge around this code in Ant and it's all
> based on what I read in the Ant code. If I missed something or mispoke
> about the usage, please feel free to join that discussion and reply.

My recollection is vague at best. I don't see any mistake in what you
have described.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Impact of Java SecurityManager being deprecated for removal post Java 17

[Stefan Bodewig]

On 2021-08-19, Gintautas Grigelionis wrote:

> On Thu, 19 Aug 2021 at 12:01, Stefan Bodewig  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.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Impact of Java SecurityManager being deprecated for removal post Java 17

[Stefan Bodewig]

On 2021-08-19, Jaikiran Pai wrote:

> On 19/08/21 1:15 pm, Stefan Bodewig wrote:

>> ... One migration option might be to offer an antlib containing the
>> permissions stuff and deprecate the core types - and remove them from
>> core once the next Java LTS version without SecurityManager arrives.

> This is an interesting point. It would however mean that core Ant will
> now depend on an (in theory external) antlib.

Avtually I wouldn't make core depend on it but tell people to use this
antlib if they need permissions support. This antlib may need to come
with its own version of a java task for things to work.

> I haven't checked if we already have such dependencies and if not,
> whether it's OK to add such a dependency.

No, we haven't. In the beginning Ant has been very proud of the fact
that you could bootstrap it with a pretty trivial shell script and the
only dependencies except for the JDK has been an XML parser - this has
been before JAXP became part of the Java class library, i.e. Java prior
to 1.3.

Of course the pretty trivial shell script is not so trivial anymore, but
it still holds that all pieces of Ant we consider core do not have any
external dependency at all. Personally I appreciate this property, but
that may just be me.

> Furthermore, to make this usable/backward compatible, we would have to
> use the same package namespace for this permissions stuff in that new
> antlib jar, which I think can cause issues when the same package
> "org.apache.tools.ant.types" is now loaded/available in 2 separate
> CodeSources (jars) - one in core Ant jar and one in this antlib jar.

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.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Impact of Java SecurityManager being deprecated for removal post Java 17

[Stefan Bodewig]

On 2021-08-19, Jaikiran Pai wrote:

> Hello Stefan,

> On 19/08/21 1:15 pm, Stefan Bodewig wrote:

>> At a cursory glance I only see JUnitTask and ExecuteJava deal with the
>> SecurityManager if permissions have been defined. Where else do we use
>> one?

> From what I see in the Java task code[1], the "execute()" method of
> that task calls, "checkConfiguration()"[2] method, which in a
> non-forked mode, creates a Permissions instance if no explicit
> permissions has been configured[3].

I only searched for SecurityManager :-) Thanks.

So we are using Ant's permissions system internally to preven
System.exit, I see. This is the stuff we will need to replace with
whatever is going to be the new API that prevents System.exit. Let's
hope all this is not going to become an ugly hack.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Impact of Java SecurityManager being deprecated for removal post Java 17

[Stefan Bodewig]

On 2021-08-05, Gintautas Grigelionis wrote:

> The most acute problem is this: SecurityManager seems to be involved in
> handling of return code from forked processes.
> How does JDK 17+ solve that?

JDK17 doesn't try to solve that as I understand it, the use-case of
"prevent System.exit" has been identified and an API to address this may
be defined later. I'd hope this new API will not only prevent
System.exit but also provide a way to capture its argument.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Impact of Java SecurityManager being deprecated for removal post Java 17

[Stefan Bodewig]

On 2021-08-05, Jaikiran Pai wrote:

> Ant project will be impacted by this. Ant provides a "permissions"
> type[1] whose whole goal is to integrate with the Java SecurityManager
> to allow users to configure the necessary security permissions. With
> the SecurityManager and the APIs potentially gone after Java 17, we
> can no longer support this. One additional point to note here is that,
> Ant also uses the SecurityManager APIs even when "permissions" type is
> not involved, at least in the "java" task and the "junit" task, where
> we setup a SecurityManager with very minimal permissions.

At a cursory glance I only see JUnitTask and ExecuteJava deal with the
SecurityManager if permissions have been defined. Where else do we use
one?

For permissions something like the apprach we've taken for other removed
parts (rmi, javah) may work. We detect they are no longer supported at
runtime and fail the build if it tries to use it. For tools lik rmic or
javah this has been simple as we either started a new process or didn't
have any compile time dependencies for other reasons.

We could conditionally not compile the permissions stuff, which would
mean you'd need an "old" JDK to build the Ant distribution at one point
in time. This may be acceptable until 17 runs out of its LTS support
time. One migration option might be to offer an antlib containing the
permissions stuff and deprecate the core types - and remove them from
core once the next Java LTS version without SecurityManager arrives.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[ANN] Apache Ant 1.9.16 and 1.10.11 Released

[Stefan Bodewig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Apache Ant Team is pleased to announce the releases of Apache Ant
1.9.16 and 1.10.11.

Apache Ant is a Java library and command-line tool that helps building
software.

The Apache Ant team currently maintains two lines of development. The
1.9.x releases require Java5 at runtime and 1.10.x requires Java8 at
runtime. Both lines are based off of Ant 1.9.7 and the 1.9.x releases
are mostly bug fix releases while additional new features are developed
for 1.10.x. We recommend using 1.10.11 unless you are required to use
versions of Java prior to Java8 during the build process.

Ant 1.10.11 contains a superset of 1.9.16 - with the exception of a few
tasks and features that no longer work with Java8 anyway (like the apt
task).

Both releases address potential denial of service vulnerabilities, see
the upcoming CVE announcement or https://ant.apache.org/security.html
for details.

Source and binary distributions are available for download from the
Apache Ant download site:

https://ant.apache.org/bindownload.cgi

When downloading, please verify signatures using the KEYS file available
at the above location when downloading the release.

Changes in 1.10.11 include:
==

Fixed bugs:
- ---

 * a race condition could lead to NullPointerExceptions when running
   tasks in parallel.
   Bugzilla Report 65316

 * fixed potential OutOfMemory errors when reading broken archives
   using the tar or zip formats or formats derived from zip.

Other changes:
- --

 * 
org.apache.tools.ant.taskdefs.optional.junitlauncher.confined.JUnitLauncherTask 
now
   has a new protected createExecuteWatchdog() method for allowing it to be 
overriden.
   Github Pull Request #147

 * Upgraded AntUnit to 1.4.1.

Changes in 1.9.16 include:
==

Other changes:
- --

 * Upgraded AntUnit to 1.4.1.

Fixed bugs:
- ---

 * Fixes a bug where the ant-testutil-sources.jar that gets published to Maven
   central repository didn't contain any source files.
   Bugzilla Report 65110

 * fixed potential OutOfMemory errors when reading broken archives
   using the tar or zip formats or formats derived from zip.

For complete information on Ant, including instructions on how to submit
bug reports, patches, or suggestions for improvement, see the Apache Ant
website:

https://ant.apache.org/

Stefan Bodewig, on behalf of the Apache Ant community
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAmDty0UACgkQohFa4V9ri3J/fACcDdV5LR1N/2Jrb8jNn/eZmwYq
e/MAoM8OvDCeEYH76QbDWJYVfnE1raI3
=D8Oy
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Release Apache Ant 1.10.11 based on RC1

[Stefan Bodewig]

With +1s by

Martijn Kruithof
Jaikiran Pai
Maarten Coene
Stefan Bodewig

the vote has passed, I'll publish the artifacts and after the mirrors
had time to catch up will annpunce the release.

Thanks to all who have verified the artifacts

   Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[RESULT] Release Apache Ant 1.9.16 based on RC1

[Stefan Bodewig]

With +1s by

Martijn Kruithof
Jaikiran Pai
Maarten Coene
Stefan Bodewig

the vote has passed, I'll publish the artifacts and after the mirrors
had time to catch up will annpunce the release.

Thanks to all who have verified the artifacts

   Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Release Apache Ant 1.10.11 based on RC1

[Stefan Bodewig]

making my own +1 explicit

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Release Apache Ant 1.9.15 based on RC1

[Stefan Bodewig]

making my own +1 explicit

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[VOTE] Release Apache Ant 1.10.11 based on RC1

[Stefan Bodewig]

Hi all

I've created a release candidate for 1.10.11:

git tag: ANT_1.10.11_RC1
 on commit: 01ce0c3b1
tarballs: https://dist.apache.org/repos/dist/dev/ant/
 revision: 48767
Maven artifacts:
 
https://repository.apache.org/content/repositories/orgapacheant-1049/org/apache/ant/

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Release Apache Ant 1.9.16 based on RC1

[Stefan Bodewig]

[re-send with fixed subject, sorry]

Hi all

I've created a release candidate for 1.9.16:

git tag: ANT_1.9.16_RC1
 on commit: ea698c454
tarballs: https://dist.apache.org/repos/dist/dev/ant/
 revision: 48766
Maven artifacts:
 
https://repository.apache.org/content/repositories/orgapacheant-1049/org/apache/ant/

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[VOTE] Release Apache Ant 1.9.15 based on RC1

[Stefan Bodewig]

Hi all

I've created a release candidate for 1.9.16:

git tag: ANT_1.9.16_RC1
 on commit: ea698c454
tarballs: https://dist.apache.org/repos/dist/dev/ant/
 revision: 48766
Maven artifacts:
 
https://repository.apache.org/content/repositories/orgapacheant-1049/org/apache/ant/

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[ANN] Apache AntUnit 1.4.1 Released

[Stefan Bodewig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Apache Ant Team is pleased to announce the releases of Apache
AntUnit 1.4.1.

Apache AntUnit is an Antlib that provides a test framework for Apache
Ant tasks and types.

This release fixes the antlib.xml descriptor so that AntUnit now also
works if users have overridden the default XML namespace for this
antlib.

Source and binary distributions are available for download from the
Apache Ant download site:

https://ant.apache.org/antlibs/bindownload.cgi
https://ant.apache.org/antlibs/srcdownload.cgi

When downloading, please verify signatures using the KEYS file
available at the above location when downloading the release.

Changes in 1.4.1 include


Fixed Bugs:
- ---

* We didn't follow our own best practice and hard-coded the
  AntUnit URI inside the Antlib descriptor instead of using
  ant:current.
  BugZilla Issue 65315

For complete information on AntUnit, including instructions on how to
submit bug reports, patches, or suggestions for improvement, see the
Apache AntUnit website:

https://ant.apache.org/antlibs/antunit/index.html

Stefan Bodewig, on behalf of the Apache Ant community
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAmDlwIkACgkQohFa4V9ri3Kv+gCgwT8kpP+KTTAws41j9CnVxQb0
BGgAn07er/Xotz0gmGYARKmn34TLb7AH
=S4i9
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[RESULT][VOTE] Release Apache AntUnit 1.4.1 based on RC1

[Stefan Bodewig]

Hi all

with +1s by Jaikiran Pai, Maarten Coene, Jan Materne, Martijn Kruithof
and myself and no other votes the vote has passed.

I'll publish the artifacts now and send out the announcement / update
the site later today.

Many thanks to all who evaluated the release

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Release Apache AntUnit 1.4.1 based on RC1

[Stefan Bodewig]

I completely forgot to vote myself.

+1

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[VOTE] Release Apache AntUnit 1.4.1 based on RC1

[Stefan Bodewig]

Hi all

I've created a release candidate for AntUnit 1.4.1:

git tag: 1_4_1_RC1
 on commit: e436acf
tarballs: https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/
 revision: 48645
Maven artifacts:
 
https://repository.apache.org/content/repositories/orgapacheant-1048/org/apache/ant/ant-antunit/1.4.1/

This Vote will be open at least for 72 hours and close no earlier than
2021-07-06 13:00UTC.

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org