Re: Java 8 for AntUnit

[Gintautas Grigelionis]

On Sun, 13 Feb 2022 at 21:50, Matt Benson  wrote:

> Okay to stick with Java 5 for now, for the 1.9.x reason.
>
> Thanks,
> Matt
>

Can JUnit 3 be removed? I believe JUnit 4 has Java 5 as a baseline.

Gintas

Re: Antlib test classpath

[Gintautas Grigelionis]

On Sat, 5 Feb 2022 at 08:19, Stefan Bodewig  wrote:

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

The basic structure for using Ivy with different tasks is set in Ant's
check.xml
Watch out for Ant plugins that forget to put ant dependency in optional
(aka "compile only") scope when using POMs, though.

Gintas

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

[Gintautas Grigelionis]

On Sat, 2 Oct 2021 at 15:48, Gavin McDonald  wrote:

>
> Please not that the ASF nor its projects release Binaries.
> (They are provided to users as a convenience)
> We also do not vote on releases based on Binaries.
>
> The vote should be based on whether or not the 'source' - that
> is being released is good enough.
>
> Gav...
>

BCEL and commons-net dependency versions are not synced between
libraries.properties and respective POMs.

Gintas

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

[Gintautas Grigelionis]

On Thu, 7 Oct 2021 at 16:27, Jaikiran Pai  wrote:

>
> On 07/10/21 11:27 am, Gintautas Grigelionis wrote:
> > If the goal of 1.10.12 is to be compilable on Java 17,
>
> This 1.10.12 release of Ant (like our previous releases) is a bug fix
> release. Ant 1.10.x require a Java 8+ runtime. This release changes
> nothing on that front. One of the bug fixes in this release is a javadoc
> task fix that is only applicable for Java 17 - that's the only
> "relevance" of Java 17 to this release. Like previous 1.10.x releases we
> have been making sure users and projects using Ant can use Ant to build
> their projects using latest Java versions of their choice.
>

Apologies, I used "compilable" when I meant "buildable".
More precisely, Ant core cannot run all its unit tests on Java 17 without
optional dependendencies.


> >   shouldn't unit tests
> > for script-related tasks in Ant core be complemented with an assumption
> > that Rhino, Nashorn or Graal JS is around?
>
> I'm not sure what kind of assumption you mean. Is there any specific
> test case you have in mind? Our CI jobs run against various versions of
> Java, including early access releases and even the recently released
> Java 17. None of our tests have shown any relevant failures in these
> releases. If this is more of a general suggestion for our test cases in
> Ant and if this doesn't have an impact on the vote of this release,
> please create a separate thread to discuss that.
>

Maven (POM) builds should run against a set of JDKs as well to demonstrate
my point.
The assumption should be coded like

assumeNotNull("JavaScript not present", new
ScriptEngineManager().getEngineByName("javascript"));

Gintas

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

[Gintautas Grigelionis]

If the goal of 1.10.12 is to be compilable on Java 17, shouldn't unit tests
for script-related tasks in Ant core be complemented with an assumption
that Rhino, Nashorn or Graal JS is around?

Gintas


On Tue, 5 Oct 2021 at 10:58, Paul King  wrote:

> +0 (non-binding)
>
> I checked:
> * LICENSE & NOTICE seem okay
> * HASH & SIG seem okay
> * I ran against the Groovy test suite which has 100+ ant-related tests and
> all continue to pass (using JDK16 and the upcoming Groovy 4)
>
> I was surprised to see binary jars in the src archives under lib/optional.
> I don't know the history, so perhaps it is fine.
>
> Cheers, Paul.
>
>
>
> On Thu, Sep 30, 2021 at 12:58 PM Jaikiran Pai  wrote:
>
> > I've created a release candidate for 1.10.12:
> >
> > git tag: ANT_1.10.12_RC1
> >   on commit: cb7f242aa099c069bd75e6ee4d6e50b56fd73b71
> > tarballs: https://dist.apache.org/repos/dist/dev/ant/
> >revision: 50166
> > Maven artifacts:
> > https://repository.apache.org/content/repositories/orgapacheant-1051/
> > Snapcraft Build
> >Revision 21 in latest/candidate
> >
> > 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.
> >
> > This vote will be open at least for 72 hours and close no earlier than
> > 4th October 2021 03:00 AM UTC (given that it's a weekend in the next
> > couple of days, I decided to extend the voting period till Monday)
> >
> >
> > -Jaikiran
> >
> >
> >
> > -
> > 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?

[Gintautas Grigelionis]

On Tue, 28 Sept 2021 at 09:25, Stefan Bodewig  wrote:

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

That MR was waiting for Ivy 2.5 (SHA-2 support). I would like to revisit
it, but it may wait until the next release.

Thanks for reviewing the MR re Jakarta Mail. I will rework it as suggested.

Gintas

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

[Gintautas Grigelionis]

On Thu, 23 Sept 2021 at 15:55,  wrote:

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

Good proposal; there are some deprecated tasks already.

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

Gintas


> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig 
> Gesendet: Sonntag, 19. September 2021 15:04
> An: dev@ant.apache.org
> Betreff: Re: Impact of Java SecurityManager being deprecated for removal
> post Java 17
>
> On 2021-09-19, Gintautas Grigelionis wrote:
>
> > On Mon, 23 Aug 2021 at 17:39, Stefan Bodewig  wrote:
>
> You may set the expectation things would become supported again if you
> create a new antlib just for the legacy stuff.
>
> Some of these tasks use internal APIs and may need to be adapted when these
> APIs change. Take for example the fixes for CVE-2020-1945 - commit
>
> https://gitbox.apache.org/repos/asf?p=ant.git;a=commit;h=9c1f4d905da59bf4465
> 70ac28df5b68a37281f35
> <https://gitbox.apache.org/repos/asf?p=ant.git;a=commit;h=9c1f4d905da59bf446570ac28df5b68a37281f35>
> touched a couple of tasks we'll probably consider legacy (cvstagdiff, ejb
> even jikes).
>
> With separate antlibs we need to make the change across X repos and cut new
> releases of the Antlibs in a situation like this.
>
> > There are about 60 old issues (11+ years) in Bugzilla for these tasks
> > that would never be actualised again.
>
> Very true. TBH I don't expect any of the orignal reporters still wait for
> us
> to come up with a fix.
>
> Stefan
>

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

[Gintautas Grigelionis]

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?
There are about 60 old issues (11+ years) in Bugzilla for these tasks that
would never be actualised again.

Gintas

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

[Gintautas Grigelionis]

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?

Gintas

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

[Gintautas Grigelionis]

Hi,

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?

Regarding the permissions type: if the sandbox is gone in JDK, then
permissions should go, too.
For the reference, a summary of permissions classes is provided by Oracle
[1].
A summary of guidance re JEP 411 is available here [2].
Some ideas on the way forward are presented here [3].

Gintas

[1]
https://docs.oracle.com/javase/7/docs/technotes/guides/security/permissions.html
[2] https://www.infoq.com/news/2021/06/openjdk-post-securitymanager/
[3] https://foojay.io/today/jep-411-what-it-means-for-javas-security-model/

On Thu, 5 Aug 2021 at 15:54, Jaikiran Pai  wrote:

> Hello everyone,
>
> Some of you might have been following the recent discussions in JDK
> where the SecurityManager and related APIs will be deprecated (for
> removal) starting the upcoming Java 17 release. To be clear, this change
> in Java will have no impact in terms of API usage in Java 17 (except for
> warnings being logged). However, after Java 17, these APIs may not
> exist. The whole JEP is available at https://openjdk.java.net/jeps/411.
>
> 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.
>
> When a EA release of Java 17 was tested against the Ant project, it
> exposed issues around the amount of warning messages that were being
> logged by the new Java release for basic Ant builds. The JDK team took
> that input and fixed that part. Discussion about that can be seen in
> this thread[2].
>
> At this stage, the dust seems to have settled about the plans around
> SecurityManager in the JDK and it's clear that it will be gone post Java
> 17. We (the Ant project) will have to decide and come up with a way
> where we (the Ant project) will no longer support "permissions" or use
> SecurityManager APIs post Java 17. I personally haven't been involved in
> the original SecurityManager integration in Ant and don't have enough
> background knowledge about this part in Ant nor do I know how many of
> our users use the "permissions" type or rely on SecurityManager (I was
> in fact unaware we even had a "permissions" type, until I decided to dig
> around our code recently to see if/how we will be impacted by
> SecurityManager API changes). Given this, I would like to have some
> discussion on how we should proceed with this.
>
>
> [1] https://ant.apache.org/manual/Types/permissions.html
> [2]
> https://mail.openjdk.java.net/pipermail/security-dev/2021-June/026660.html
>
>
> -Jaikiran
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Release 1.10.10 of Ant?

[Gintautas Grigelionis]

BTW jasper-compiler 4.x artifacts seem to lack pom files in Maven Central.
There are 5.0.x and 5.5.x that contain pom files.

Gintas

On Thu, 25 Feb 2021 at 06:41, Gintautas Grigelionis 
wrote:

> PR 142?
>
> Gintas
>
> On Thu, 25 Feb 2021 at 03:56, Jaikiran Pai  wrote:
>
>> Our last release for 1.10.x of Ant happened in September 2020. There
>> have been a good number of bug fixes and enhancements done since
>> then[1]. Should we go ahead and release 1.10.10 in the coming weeks? I
>> don't have any specific bug fixes or enhancements pending. Is there
>> anything anyone else is working on, that needs to be part of the release?
>>
>>
>> [1] https://github.com/apache/ant/blob/master/WHATSNEW
>>
>> -Jaikiran
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>

Re: Release 1.10.10 of Ant?

[Gintautas Grigelionis]

PR 142?

Gintas

On Thu, 25 Feb 2021 at 03:56, Jaikiran Pai  wrote:

> Our last release for 1.10.x of Ant happened in September 2020. There
> have been a good number of bug fixes and enhancements done since
> then[1]. Should we go ahead and release 1.10.10 in the coming weeks? I
> don't have any specific bug fixes or enhancements pending. Is there
> anything anyone else is working on, that needs to be part of the release?
>
>
> [1] https://github.com/apache/ant/blob/master/WHATSNEW
>
> -Jaikiran
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Ivy expertise needed for Bug 65110

[Gintautas Grigelionis]

On Fri, 29 Jan 2021 at 08:59, Stefan Bodewig  wrote:

> On 2021-01-28, Jaikiran Pai wrote:
>
> > I had a quick look and to me this looks like a bug in our build.xml
> > itself and not related to Ivy.
>
> My bad. I must admit I really don't know much about Ivy at all and
> forgot how the jars we publish get prepared. I assumed Ivy was using our
> poms, which it obviously does not.
>
> Thank you for taking care of this
>
> Stefan
>

I had a proposal to use only Ivy (which requires 2.5.0 for SHA checksums).
I can complete that, if it is of interest.

Gintas

Re: Migrating build jobs

[Gintautas Grigelionis]

>
> Our build job for testing our POMs (by building Ant from POM) could be
> migrated (easily) because there is no type=Maven any more. Maybe building
> via Shell ...
>

Looks like "Freestyle Project" -> Build step "Execute top-level Maven
targets" is a possibility?

Gintas

Re: GraalVM JavaScript Again

[Gintautas Grigelionis]

On Mon, 10 Aug 2020 at 17:52, Stefan Bodewig  wrote:

> Hi
>
> right now master sets polyglot.js.allowAllAccess to true when it detects
> the script engine is a GraalVM engine. This is necessary if the script
> wants to use any of the Ant objects.
>
> Jaikiran suggests to enable full Nashorn compatibility mode, which I
> tend to agree with. Unfortunately you cannot do that via the
> ScriptEngine API, only via a system property or by creating the
> GraalJSScriptEngine directly - see
> https://github.com/graalvm/graaljs/blob/master/docs/user/ScriptEngine.md
>
> I see the following options:
>
> (1) leave things as they are right now and tell people to set system
> properties before starting Ant if they need more.
>
> (2) Set the "Nashorn compatibility mode" via the system property based
> on another magic property - and enable it by default
>
> (3) add graaljs as an alternative javax as script engine and add new
> magic properties to control it.
>
> (4) find all the places that might create script engines (script and
> scriptdef tasks as well as the script filter, at least) and add
> explicit options.
>
> Personally I'd prefer one of the first two options and would like option
> 3 the least.
>
> Stefan
>

Option 2

Gintas

Re: [CI] Creating Jobs on New ci-builds Machine

[Gintautas Grigelionis]

On Mon, 10 Aug 2020 at 16:23, Stefan Bodewig  wrote:

> On 2020-08-10, Stefan Bodewig wrote:
>
> > I intend to also migrate AntUnit (so we do have a template for Antlib
> > builds) and maybe the Windows Matrix for Ant's master.
>
> Both done, as well as Compress Antlib, Ivy, Ivy Tests and IvyDE. The
> IvyDE build fails because it wants Eclipse, I'm not familiar enough with
> the build to fix it.
>

It looks like you copied only the second Ant run which does "dist
checkstyle rat", but not the first one which does "clean jenkins-prepare".

Gintas

Re: [DISCUSS] EOL the 1.9.x branch with the 1.9.15 release

[Gintautas Grigelionis]

+1 if that counts. I don't think there's much use of Java 7- nowadays,
especially when networked.

Gintas

On Wed, 20 May 2020 at 13:24, Stefan Bodewig  wrote:

> It looks as if the vote will simply not pass because of a lack of
> participation - which is certainly fine. Unless we get more binding
> votes, I'll close the vote as failed soon.
>
> Mayby we should have discussed the motion here before I created the
> vote. Therefore I have created this separate thread. If you don't feel
> you want to discuss the topic then please just ignore me :-)
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Time for 1.10.8 release?

[Gintautas Grigelionis]

Thanks, the PR is ready now. Please have a look at  #111, too (a
cherry-pick of #110 for master branch).

Gintas

On Fri, 10 Jan 2020 at 15:30, Jaikiran Pai  wrote:

> There's time. If it's a straightforward PR, I'll merge it.
>
> -Jaikiran
>
> On 10/01/20 7:46 pm, Gintautas Grigelionis wrote:
> > I was planning a tiny PR to update the third party libraries, if there's
> > time still.
> >
> > Gintas
> >
> > On Fri, 10 Jan 2020 at 14:54, Jaikiran Pai  wrote:
> >
> >> I just noticed that we have added some good number of bug fixes[1] since
> >> our 1.10.7 release and it's been already 4 months since that release. If
> >> no one has any objections then I'll go ahead and start a vote for 1.10.8
> >> release, in the next few days.
> >>
> >> [1] https://github.com/apache/ant/blob/master/WHATSNEW#L1
> >>
> >> -Jaikiran
>

Re: Time for 1.10.8 release?

[Gintautas Grigelionis]

I was planning a tiny PR to update the third party libraries, if there's
time still.

Gintas

On Fri, 10 Jan 2020 at 14:54, Jaikiran Pai  wrote:

> I just noticed that we have added some good number of bug fixes[1] since
> our 1.10.7 release and it's been already 4 months since that release. If
> no one has any objections then I'll go ahead and start a vote for 1.10.8
> release, in the next few days.
>
> [1] https://github.com/apache/ant/blob/master/WHATSNEW#L1
>
> -Jaikiran
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Next plans for Ivy

[Gintautas Grigelionis]

On Sat, 2 Nov 2019 at 20:32, Matt Sicker  wrote:

> The more JDKs you require in the build, the harder it
> is to set up. If you target Java 8 but build at a newer release, you could
> possibly get away with a single JDK plus an API checker to avoid using new
> things.
>

Talking of API checkers, Animal Sniffer README states:

Please note this plugin is now in maintenance level as the exact same
feature can be now easily achieved using the --release flag from Javac

So, it seems it's primarily about defining a Java baseline. If it's set at
8, that's it.
If it's set at the latest-and-greatest, or at the latest LTS version, then
the rules must be devised for handling the code that,
say, peruses JPMS or the HTTP/2 client from Java 11, if Ivy would still be
usable on Java 8 runtime.
AFAICS, Ant is going with ad hoc, and that's partly the reason why e.g.
PR#89 is stuck.

But, what's even more interesting than compiling is running unit tests.
I'm afraid there's no way of avoiding multiple JDKs for that. "Write once,
test everywhere" :-)

Gintas

Re: Script task specification

[Gintautas Grigelionis]

By the way, the failure "unable to create engine" was due to OpenJDK 7
lacking Rhino.
Perhaps worth a mention, too.

Gintas

On Wed, 30 Oct 2019 at 21:59, Gintautas Grigelionis 
wrote:

> Thanks for prompt reply and all pointers. idReferences seem to have no
> connection to references that addBeans use.
>
> I am under impression that things were somewhat different with Ant 1.6
> (-ish), but the manual did not change since then
> so it probably needs an update with a reference to macrodef and friends as
> more useful for use cases like this.
> Maybe there's a point in making addBeans to instantiate all idReferences?
> Or at least to log which idReferences are not instantiated yet?
>
> Gintas
>
> On Tue, 29 Oct 2019 at 10:01, Jan Matèrne (jhm)  wrote:
>
>> The AntXMLContext stores the id-object pair in the project instance via
>> public void configureId(Object element, Attributes attr) {
>> String id = attr.getValue("id");
>> if (id != null) {
>> project.addIdReference(id, element);
>> }
>> }
>>
>> In the Projct class this is stored in a HashMap
>>
>> /** Map of id references - used for indicating broken build files */
>> private final HashMap idReferences = new HashMap<>();
>>
>> public void addIdReference(final String id, final Object value) {
>> idReferences.put(id, value);
>> }
>>
>> But I haven't found a place where this private field is read...
>>
>>
>> Jan
>>
>>
>>
>> > -Ursprüngliche Nachricht-
>> > Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
>> > Gesendet: Dienstag, 29. Oktober 2019 08:48
>> > An: 'Ant Developers List'
>> > Betreff: AW: Script task specification
>> >
>> > I placed some system-outs in the parsing code.
>> > The parsing is done by ProjectHelper2. Id is stored via AntXMLContext to
>> > the "UnknownElement".
>> >
>> > C:\projekte\apache-ant-svn\sandbox\script>ant
>> > Buildfile: C:\projekte\apache-ant-svn\sandbox\script\build.xml
>> > PH2.ElemeentHandler.onStartElement  tag=echo  taskname=echo
>> > AntXMLContext.configureId
>> > element=org.apache.tools.ant.UnknownElement@1f89ab83  id=foo
>> > PH2.ElemeentHandler.onStartElement  tag=script  taskname=script
>> > AntXMLContext.configureId
>> > element=org.apache.tools.ant.UnknownElement@383534aa  id=null
>> >
>> >
>> > main:
>> >[script] PH2.ElemeentHandler.onStartElement  tag=antlib
>> > taskname=antlib
>> >[script] AntXMLContext.configureId
>> > element=org.apache.tools.ant.UnknownElement@50cbc42f  id=null
>> >[script] PH2.ElemeentHandler.onStartElement  tag=componentdef
>> > taskname=componentdef
>> > ... more element definitions ...
>> >
>> > BUILD FAILED
>> > C:\projekte\apache-ant-svn\sandbox\script\build.xml:9:
>> > org.mozilla.javascript.EcmaError: ReferenceError: "foo" is not defined.
>> >
>> >
>> >
>> > Jan
>> >
>> >
>> > > -Ursprüngliche Nachricht-
>> > > Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
>> > > Gesendet: Dienstag, 29. Oktober 2019 08:03
>> > > An: 'Ant Developers List'
>> > > Betreff: AW: Script task specification
>> > >
>> > > It seems that the task must be executed before.
>> > > If you add a >depends="sub"< on the main target, that works.
>> > >
>> > > So the question is: when are id's stored?
>> > > The parsing is done via ProjectHelper's and their SAX-Parser-Handlers.
>> > > On the first view I would say, that the id is stored while parsing -
>> > > so before exucution.
>> > >
>> > >
>> > > Jan
>> > >
>> > > > -Ursprüngliche Nachricht-
>> > > > Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
>> > > > Gesendet: Montag, 28. Oktober 2019 14:25
>> > > > An: Ant Developers List
>> > > > Betreff: Script task specification
>> > > >
>> > > > The documentation of the script task states:
>> > > >
>> > > > "All items (tasks, targets, etc) of the running project are
>> > > > accessible from the script, using either their name or id attributes
>> > > > (as long as their names are considered valid Java identifiers, th

Re: Script task specification

[Gintautas Grigelionis]

Thanks for prompt reply and all pointers. idReferences seem to have no
connection to references that addBeans use.

I am under impression that things were somewhat different with Ant 1.6
(-ish), but the manual did not change since then
so it probably needs an update with a reference to macrodef and friends as
more useful for use cases like this.
Maybe there's a point in making addBeans to instantiate all idReferences?
Or at least to log which idReferences are not instantiated yet?

Gintas

On Tue, 29 Oct 2019 at 10:01, Jan Matèrne (jhm)  wrote:

> The AntXMLContext stores the id-object pair in the project instance via
> public void configureId(Object element, Attributes attr) {
> String id = attr.getValue("id");
> if (id != null) {
> project.addIdReference(id, element);
> }
> }
>
> In the Projct class this is stored in a HashMap
>
> /** Map of id references - used for indicating broken build files */
> private final HashMap idReferences = new HashMap<>();
>
> public void addIdReference(final String id, final Object value) {
> idReferences.put(id, value);
> }
>
> But I haven't found a place where this private field is read...
>
>
> Jan
>
>
>
> > -Ursprüngliche Nachricht-
> > Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> > Gesendet: Dienstag, 29. Oktober 2019 08:48
> > An: 'Ant Developers List'
> > Betreff: AW: Script task specification
> >
> > I placed some system-outs in the parsing code.
> > The parsing is done by ProjectHelper2. Id is stored via AntXMLContext to
> > the "UnknownElement".
> >
> > C:\projekte\apache-ant-svn\sandbox\script>ant
> > Buildfile: C:\projekte\apache-ant-svn\sandbox\script\build.xml
> > PH2.ElemeentHandler.onStartElement  tag=echo  taskname=echo
> > AntXMLContext.configureId
> > element=org.apache.tools.ant.UnknownElement@1f89ab83  id=foo
> > PH2.ElemeentHandler.onStartElement  tag=script  taskname=script
> > AntXMLContext.configureId
> > element=org.apache.tools.ant.UnknownElement@383534aa  id=null
> >
> >
> > main:
> >[script] PH2.ElemeentHandler.onStartElement  tag=antlib
> > taskname=antlib
> >[script] AntXMLContext.configureId
> > element=org.apache.tools.ant.UnknownElement@50cbc42f  id=null
> >[script] PH2.ElemeentHandler.onStartElement  tag=componentdef
> > taskname=componentdef
> > ... more element definitions ...
> >
> > BUILD FAILED
> > C:\projekte\apache-ant-svn\sandbox\script\build.xml:9:
> > org.mozilla.javascript.EcmaError: ReferenceError: "foo" is not defined.
> >
> >
> >
> > Jan
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> > > Gesendet: Dienstag, 29. Oktober 2019 08:03
> > > An: 'Ant Developers List'
> > > Betreff: AW: Script task specification
> > >
> > > It seems that the task must be executed before.
> > > If you add a >depends="sub"< on the main target, that works.
> > >
> > > So the question is: when are id's stored?
> > > The parsing is done via ProjectHelper's and their SAX-Parser-Handlers.
> > > On the first view I would say, that the id is stored while parsing -
> > > so before exucution.
> > >
> > >
> > > Jan
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> > > > Gesendet: Montag, 28. Oktober 2019 14:25
> > > > An: Ant Developers List
> > > > Betreff: Script task specification
> > > >
> > > > The documentation of the script task states:
> > > >
> > > > "All items (tasks, targets, etc) of the running project are
> > > > accessible from the script, using either their name or id attributes
> > > > (as long as their names are considered valid Java identifiers, that
> > is). "
> > > >
> > > > However, the following fails:
> > > >
> > > > 
> > > > 
> > > >   
> > > > Executing a task
> > > >   
> > > >
> > > >   
> > > >   
> > > > <![CDATA[
> > > > foo.setMessage("I'm a foo!")
> > > > sub.execute()
> > > > ]]>
> > > >   
> > > > 
> > > >
> > > > Surely there are more limitations? Besides, failure modes are
> > > > different in Rhino (unable to create engine) and Nashorn (reference
> > > not defined).
> > > >
> > > > Regards,
> > > > Gintas
> > >
> > >
> > > -
> > > 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: Next plans for Ivy

[Gintautas Grigelionis]

It will be good to be on the same page with major dependencies (and
hopefully fix that old nut listTokenValues() :-)
Please consider Java 11 for TLSv1.3 when time comes (or the next LTS
version, Java 17 when it's out --
by then, pack200 will surely be gone...)

Gintas

On Wed, 30 Oct 2019 at 20:26, Jan Matèrne (jhm)  wrote:

> Sounds good. Similar to Ant, on branch for maintaining the version for the
> old Java version and master for the new(er) one.
> And as suggested we shoundn't go farer than Ant itself, so Java8 is fine
> with me (no Java 13).
>
> So: +1
>
> Jan
>
>
> > -Ursprüngliche Nachricht-
> > Von: Jaikiran Pai [mailto:jaiki...@apache.org]
> > Gesendet: Mittwoch, 30. Oktober 2019 15:54
> > An: Ant Developers List
> > Betreff: Next plans for Ivy
> >
> > Now that Ivy 2.5.0 has been released, I would like to propose the
> > following ideas for the next goals for the project:
> >
> > 1. I would like to wait and watch for any bug reports for 2.5.0 and do
> > some relatively frequent bug fix releases for that version. So
> > essentially 2.5.x versions which are solely bug fixes. To accommodate
> > that, I would like to create a 2.5 branch in the Ivy project. Ivy 2.5.x
> > will continue to have minimum Java 7 as a requirement. Once we are
> > confident that the 2.5.x series is stable enough, we can stop releases
> > off that branch.
> >
> > 2. In the master branch, I would like to move Ivy to minimum Java 8
> > version (right now we are on minimum Java 7). I would like to mention
> > that, just because we move to Java 8, the goal isn't large/medium scale
> > refactoring of existing code. This is especially important given the
> > nature of the project - the code base is complex plus we don't have
> > enough knowledge of it. It literally took me months to be able to read
> > the code and understand what I'm dealing with to be able to confidently
> > do a change that could fix some of the recent bugs (especially IVY-
> > 1580). So even though we will move to Java 8, any refactoring, just for
> > the sake of it, of existing code will be discouraged. Of course, if new
> > code is being added, Java 8 constructs/API are welcome. Also if a bug
> > fix requires Java 8 construct/API that's welcome too. We will do 2.6.x
> > releases (whenever we decide to do so) off master branch.
> >
> > Any objections to these plans?
> >
> > -Jaikiran
> >
> >
> >
> > -
> > 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
>
>

Script task specification

[Gintautas Grigelionis]

The documentation of the script task states:

"All items (tasks, targets, etc) of the running project are accessible from
the script, using either their name or id attributes (as long as their
names are considered valid Java identifiers, that is). "

However, the following fails:



  
Executing a task
  

  
  

  


Surely there are more limitations? Besides, failure modes are different in
Rhino (unable to create engine) and Nashorn (reference not defined).

Regards,
Gintas

Re: Buliding IvyDE

[Gintautas Grigelionis]

Is there any documentation readily available? The links in the document
below are not easy to follow

https://www.eclipse.org/eclipse/development/porting/eclipse_4_12_porting_guide.html

Gintas

On Sat, 14 Sep 2019 at 09:20, Aleksandar Kurtakov 
wrote:

> On Fri, Sep 13, 2019 at 4:17 PM Tim Astle  wrote:
>
> > Ah, thanks Aleksandar.
> >
> > Has this work started?  Just wondering what branch I should be on if I
> > choose to play around.
> >
>
> This has been done already in the 2019-06 release .
>
> >
> > Tim
> >
> > On Fri, Sep 13, 2019 at 9:59 AM Aleksandar Kurtakov  >
> > wrote:
> > >
> > > On Fri, Sep 13, 2019 at 3:55 PM Tim Astle 
> > wrote:
> > >
> > > > I have the latest version of Eclipse, and unfortunately there isn't a
> > > > version of IvyDE that works with it.
> > > >
> > > > I'm not sure if there will be a version made available, so I
> attempted
> > > > to build it myself following this document:
> > > >
> > > >
> https://github.com/apache/ant-ivyde/blob/master/doc/src/dev/build.adoc
> > > >
> > > > I checked out the 2.3.0-rc1 tag (dunno, figured it's the right one)
> > > > and grabbed this version of Eclipse:
> > > >
> > > >
> >
> https://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/2019-06/R/eclipse-committers-2019-06-R-linux-gtk-x86_64.tar.gz_id=1249
> > > >
> > > > I created a local.build.properties that points to the unpacked distro
> > > > above.
> > > >
> > > > I ran `ant install-ivy`
> > > >
> > > > Then when I ran `ant build`, I get the following:
> > > >
> > > > [pde-build]
> > > >
> >
> /home/tastle/Downloads/eclipse/plugins/org.eclipse.pde.build_3.10.400.v20190320-1020/scripts/genericTargets.xml:112:
> > > > Processing inclusion from feature
> > > > org.apache.ivyde.eclipse.resolvevisualizer.feature: Bundle
> > > > org.apache.ivyde.eclipse.resolvevisualizer_2.3.0.rc1-201909130952-dev
> > > > failed to resolve.:
> > > > [pde-build] Missing required plug-in
> > org.eclipse.zest.core_[1.5.0,2.0.0).
> > > > [pde-build] Missing required plug-in
> > > > org.eclipse.zest.layouts_[1.1.0,2.0.0).
> > > > [pde-build]
> > > > [pde-build]
> > > > [pde-build] Total time: 1 second
> > > > [pde-build] [eclipse.buildScript] Some inter-plug-in dependencies
> have
> > > > not been satisfied.
> > > > [pde-build] [eclipse.buildScript] Bundle
> > > > org.apache.ivyde.eclipse.resolvevisualizer:
> > > > [pde-build] [eclipse.buildScript] Missing required plug-in
> > > > org.eclipse.zest.core_[1.5.0,2.0.0).
> > > > [pde-build] [eclipse.buildScript] Missing required plug-in
> > > > org.eclipse.zest.layouts_[1.1.0,2.0.0).
> > > > [pde-build] [eclipse.buildScript] Bundle
> > org.eclipse.epp.logging.aeri.ide:
> > > > [pde-build] [eclipse.buildScript] Unsatisfied import package
> > > > org.apache.lucene.document_[7.1.0,8.0.0).
> > > > [pde-build] [eclipse.buildScript] Unsatisfied import package
> > > > org.apache.lucene.index_[7.1.0,8.0.0).
> > > > [pde-build] [eclipse.buildScript] Unsatisfied import package
> > > > org.apache.lucene.search_[7.1.0,8.0.0).
> > > > [pde-build] [eclipse.buildScript] Unsatisfied import package
> > > > org.apache.lucene.store_[7.1.0,8.0.0).
> > > > [pde-build] An error has occurred. See the log file
> > > > [pde-build] /home/tastle/workspace/.metadata/.log.
> > > >
> > > > BUILD FAILED
> > > > /home/tastle/Dev/Code/ant-ivyde/build.xml:179: Java returned: 13
> > > >
> > > > Did I get the wrong distribution, or are the build instructions
> > incorrect?
> > > >
> > > > All I really want is IvyDE in the Eclipse Marketplace for the latest
> > > > version of eclipse...
> > > >
> > >
> > > Eclipse IDE has been moved to use lucene 8.x thus IvyDE has to be
> adapted
> > > too.
> > >
> > >
> > > >
> > > >
> > > > Tim
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > > > For additional commands, e-mail: dev-h...@ant.apache.org
> > > >
> > > >
> > >
> > > --
> > > Alexander Kurtakov
> > > Red Hat Eclipse Team
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
> >
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
>

Re: Planning to initiate a Ivy release

[Gintautas Grigelionis]

Thanks for prompt response. Please see the comments bellow.

On Sun, 8 Sep 2019 at 14:39, Jaikiran Pai  wrote:

>
> On 08/09/19 12:41 PM, Gintautas Grigelionis wrote:
> > Many thanks, Jaikiran. Please consider updating JSch to 0.1.55 (fixes
> bugs
> > with EC crypto)
>
> Done.
>
> >  and Commons VFS to 2.4.1 (upgrades HTTP Client to 4.5+).
>
> We can't move to 2.4.x of Commons VFS since that requires Java 8 and Ivy
> has a minimum requirement of Java 7.
>

Sorry, I missed Java version change for 2.3+. Well, that's unfortunate.

> May I suggest considering preemptive authentication (aka IVY-1280)
>
> Like I noted in the JIRA comment[1] and even acknowledged by another
> user in the PR[2], it's not yet in a state where we can confidently
> introduce that enhancement. It will need a bit of research as well as
> some testing to see how it behaves in the cases noted in that JIRA.
> Given that it's an enhancement, I don't want it to block this release.
> Having said that, I do have that JIRA (and few others) in mind, which I
> plan to come back to after the release, in a subsequent version. So this
> and other ideas aren't abandoned.
>

It is my understanding that preemptive authentication fixes the scheme.
The only question remaining is whether to support only Basic or Digest as
well
(which would require an implementation of DigestAuthenticator for testing
as well
as servers that accept random nonces, so I'm not quite sure whether it is
used live anywhere).

> and Ivy
> > reports without img links to Ivy website (aka IVY-922)?
>
> I had seen a PR for this one here[3]. Going by what the JIRA
> https://issues.apache.org/jira/browse/IVY-922 states, I would have
> expected any change related to it, to be relatively straightforward. I'm
> not an expert on image processing, but looking at that PR, I don't
> understand why it isn't as straightforward as pointing to local image
> resources. The PR has a big change (even to Java code) which seems to
> generate the SVG images on the fly, from some auto-generated code from some
> library. Plus there are some changes to css files too, which I'm not fully
> clear about. For this specific JIRA if the PR was just about using local
> (png) resources for the images then it would have been easier to review and
> merge it. Having said that, I don't have an objection on it being merged if
> someone else with a bit more experience with SVG, it's generation and usage
> feels this change looks good. I see Jan has already reviewed it. So if the
> current conflict being reported in that PR can be resolved and if Jan or
> others feel this is fine, I'll merge it in this release. Again, I don't
> consider this one a blocker too, so if the review and discussion takes
> time, we can always have it included in a next release.
>

That's a different PR. Sorry about confusion, I meant the first commit of
https://github.com/apache/ant-ivy/pull/60
(the second one contains a partial fix for IVY-450).


> [1]
>
> https://issues.apache.org/jira/browse/IVY-1280?focusedCommentId=16403338=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16403338
>
> [2] https://github.com/apache/ant-ivy/pull/64#issuecomment-362251800
>
> [3] https://github.com/apache/ant-ivy/pull/55
>
> -Jaikiran
>
>
>
> > Gintas
> >
> > On Sun, 8 Sep 2019 at 05:54, Jaikiran Pai  wrote:
> >
> >> So I finally found the time that was needed to read and understand a
> >> part of the Ivy codebase, in order to fix the major
> >> https://issues.apache.org/jira/browse/IVY-1580 issue. I have pushed a
> >> commit which contains the fix as well as a testcase to reproduce and
> >> verify the issue. Existing tests pass too.
> >>
> >> Given that this issue has been causing problems to users who have been
> >> using 2.5.0-rc1, I would like to go ahead and propose a new release in
> >> the coming days for Ivy. I plan to name it 2.5.0.
> >>
> >> This will be my first release for the Ivy project so I might take some
> >> extra time to get it done.
> >>
> >> Any objections to the release plan? If not, I will initiate the
> >> formalities in the coming days.
> >>
> >> -Jaikiran
> >>
> >>
> >> -
> >> 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: Planning to initiate a Ivy release

[Gintautas Grigelionis]

Many thanks, Jaikiran. Please consider updating JSch to 0.1.55 (fixes bugs
with EC crypto) and Commons VFS to 2.4.1 (upgrades HTTP Client to 4.5+).
May I suggest considering preemptive authentication (aka IVY-1280) and Ivy
reports without img links to Ivy website (aka IVY-922)?

Gintas

On Sun, 8 Sep 2019 at 05:54, Jaikiran Pai  wrote:

> So I finally found the time that was needed to read and understand a
> part of the Ivy codebase, in order to fix the major
> https://issues.apache.org/jira/browse/IVY-1580 issue. I have pushed a
> commit which contains the fix as well as a testcase to reproduce and
> verify the issue. Existing tests pass too.
>
> Given that this issue has been causing problems to users who have been
> using 2.5.0-rc1, I would like to go ahead and propose a new release in
> the coming days for Ivy. I plan to name it 2.5.0.
>
> This will be my first release for the Ivy project so I might take some
> extra time to get it done.
>
> Any objections to the release plan? If not, I will initiate the
> formalities in the coming days.
>
> -Jaikiran
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: New Confluence Wiki

[Gintautas Grigelionis]

Perhaps [1]  could be placed under Proposals?
Also, links to antbook.org should point to [2] instead.
And, FWIW, Kevin Lee has put his book on GitHub [3].

Gintas

[1] https://cwiki.apache.org/confluence/display/ANT/MergeCandidates18xBranch
[2] https://www.manning.com/books/ant-in-action
[3] https://github.com/akevinlee/buildmeister/tree/master/books

On Thu, 30 May 2019 at 15:52, Martijn  wrote:

> Furthermore I cleaned up somewhat, restoring some kind of structure.
>
> Some page I did not see where they were in the structure I moved to
> Orphaned, the People pages are all under People pages, as far as I am
> concerned these could be deleted.
>
> One spammy kind of page I did remove.
>
> Br Martijn
>
> Op 30-5-2019 om 15:05 schreef Martijn:
> > Hi all
> >
> > I went through the wiki and made sure that the entire page tree from
> > home was migrated - except for "personal" pages. Note that some pages
> > weren't automatically migrated, I have migrated those manually.
> >
> > Br Martijn
> >
> > Op 30-5-2019 om 11:55 schreef Stefan Bodewig:
> >> Hi all
> >>
> >> I've just triggered the wiki migration from Moin to Confluence, the new
> >> Wiki is https://cwiki.apache.org/confluence/display/ANT
> >>
> >> Right now I don't see any obvious spam pages (there are some in other
> >> migrated spaces) and am not missing anything. Please look through the
> >> new instance for things that are present in https://wiki.apache.org/ant
> >> but missing in Confluence so we can transfer them manually if necessary.
> >>
> >> There are some "home pages" people have created for themselves that we
> >> may want to delete. One option may be to ask the people to use
> >> Confluence's built-in mechanism for that and delete the pages after some
> >> time. WDYT?
> >>
> >> 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 inputs before starting a new RC for 1.10.6

[Gintautas Grigelionis]

On Thu, 28 Mar 2019 at 15:36, Stefan Bodewig  wrote:

> On 2019-03-28, Jaikiran Pai wrote:
>
> > As far as I understand the pom files that we maintain and publish to
> > Maven central are basic minimal. However, a bunch of relatively recent
> > commits have introduced certain changes to those poms. I have gone
> > through the mail discussion/commit logs to understand why this was done
> > and what goal it was trying to achieve and how it was trying to achieve
> > that. Reading that discussion, I haven't understood these changes and
> > nor do I understand them now after reviewing them again (there's more
> > than one commit).
>
> The goal was to build Ant from the poms AFAIR. There is a Jenkins Job
> that does that as part of the nightly build.
>
> https://builds.apache.org/view/A/view/Ant/job/Ant-Build-from-POMs/
>
> > However, the commit of note (or at least the issue I spotted was) is
> > this[1]. Specifically this content[2]. I don't understand why it's coded
> > to fetch a specific version of Ant.
>
> I must admit I've forgotten the rationaly behind this myself.
>
> > Furthermore, when these poms are now released, the released 1.10.6
> > version (for example) will now end up having this (artificial)
> > dependency on 1.10.5 Ant zip distribution and that's a public facing
> > pom. Is that the right thing?
>
> Two things - apart from trying to figure out whether this is really
> necessary at all:
>
> * this is not a dependency in the maven sense of things, so it is only
>   half bad for people actually using the POM.  * if we keep this, we
>   should be using http://archive.apache.org/dist/ant/binaries/ rather
>   than a mirror that is going to drop the old release as soon as we
>   release a new one.
>
> > Any thoughts on how I should proceed?
>
> I'd revert this particular change and try to do what the Jenkins job
> does in order to see what breaks. The build assumes you are trying to
> build the binaries via Maven so there is no binary of the current
> version of Ant available at that point in time,
>
> I offer to give it a try myself during the weekend as I think I've been
> somewhat involved back then.
>

The download is used in order to execute unit tests in Surefire.
There are some unit tests that are dependent on bootstrap, which is not
available in Maven build.
Perhaps the unit tests could be modified to avoid that. Otherwise, the test
code could be filtered out.
Another thing worth considering is Maven flatten plugin [1].

Gintas

[1] https://www.mojohaus.org/flatten-maven-plugin/

Re: [ant] branch master updated: Update JSCh (see http://www.jcraft.com/jsch/ChangeLog)

[Gintautas Grigelionis]

Thanks, sorry about missing pom.xml and the manual.

Gintas

On Thu, 27 Dec 2018 at 14:21, Jaikiran Pai  wrote:

> Hi Stefan,
>
> Thank you for reminding me of those files. I have now pushed a commit in
> both the branches which updates these files to use the new version.
>
> -Jaikiran
>
> On 27/12/18 3:04 PM, Stefan Bodewig wrote:
> > Hi Jaikiran
> >
> > you should probably also update manual/install.html as well as the
> > affected POMs (in this case src/etc/poms/ant-jsch/pomx.xml) for
> > consistency.
> >
> > Stefan
>

Re: Antlib SVN and antunit Java versions

[Gintautas Grigelionis]

On Tue, 18 Dec 2018 at 10:44, Dominique Devienne 
wrote:

> On Tue, Dec 18, 2018 at 9:21 AM Jaikiran Pai  wrote:
>
> > [...] 2 jobs[1][2] which are for Antlib SVN and Antunit libraries.
>
> Both these jobs are configure for JDK 5 [...]
> > However, the Maven central repo [...[ has been configured not to let
> > clients with
> > lower TLS versions (lesser than TLSv1.2) to communicate with it. [...]
>
> But this version of TLS is only supported in a Java release after Java 1.5.
> > [...]
>
> Should we now mandate Java 1.8 at least?
> >
>
> Sounds completely reasonable to me. Thanks for the clear message. +1. --DD
>

I'd say the choices are:

   -  use Java 6 or 7 with command line switch forcing TLSv1.2 or Java 8
   and crosscompile to Java 5
   -  change to Java 8 to follow Ant 1.10

Java 9+ can only crosscompile to Java 6+. It will be interesting to see if
JEP 332 [1] gets backported...

Gintas

[1] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8202625

Re: jmod and jlink support

[Gintautas Grigelionis]

On Fri, 30 Nov 2018 at 19:25, Craig Pell  wrote:

> Or am I misunderstanding the goal?  Are you suggesting that future
> versions of Ant should just be built with Java 9 (or later)?  If so,
> that would suggest that the "needs.jdk9+" selector is not needed, right?
>

I believe the goal is to compile Java 9+ classes when JRE 9+ is available,
and thus avoid branching.
So the selector only works when JRE 8 is used, which is the current
baseline, but custom versions of Ant can be built.
See
https://builds.apache.org/view/A/view/Ant/job/Ant-Build-Matrix-master-Linux/

Re: ant git commit: Add magic names for tests, run more tests in Surefire

[Gintautas Grigelionis]

On Mon, 29 Oct 2018 at 10:00, Stefan Bodewig  wrote:

> There is no cycle: core <- testutil <- tests of core
>
> It is just Maven's model that doesn't allow you to introduce test scope
> dependencies that depend on your code under test. A model I disagree
> with.
>
> So in the maven POMs we might be cheating Maven, but only because we
> have to circumvent Maven's model which doesn't fit ours.
>

Maven wants to isolate each module [1]. This is where I went down the
rabbit hole
and lost sight of the bigger picture, namely, that POM build creates
isolation on the fly
(which is cheating on Maven :-), because I was thinking of launcher-core
and core-junit
interdependencies on the test level, and I'd still like to figure out a way
of running
all Ant tests in Surefire while producing artifacts corresponding to Ant
build as closely as possible.

Gintas

[1]
https://blog.sonatype.com/2010/01/how-to-create-two-jars-from-one-project-and-why-you-shouldnt/

Re: ant git commit: Add magic names for tests, run more tests in Surefire

[Gintautas Grigelionis]

> Thanks, I'll merge it to master, then.
>

I've notice in Nightly that Ant treats MagicTestNames as a test, too.
Would it make sense to add a test method, checking for documented
properties?

Gintas

Re: ant git commit: Add magic names for tests, run more tests in Surefire

[Gintautas Grigelionis]

> The tests for core fail for me (CommandlineJava) anyway. I think I've
> already said that running Ant's unit tests in Maven is a non-goal for me
> :-)
>

I'll have a closer look at it tomorrow, if you don't mind. Could you please
provide some details of your setup?
Even if running unit tests with different tools is a no-goal for you, it's
a good check of robustness --
I noticed that the same tests which fail in Maven have a tendency to fail
in IDE, too, and I'd like the possibility to run tests from IDE.
Maybe that would also be of use should JUnit 5 be considered some day...

As to the refactoring, I'm sorry I got carried away with all the dependency
stuff.
I'm afraid we're cheating a little anyway by compiling testutil with core
tests first, and then building a separate jar file.
So your refactoring is fine. Thanks for bearing with me.

Gintas

Re: ant git commit: Add magic names for tests, run more tests in Surefire

[Gintautas Grigelionis]

On Sun, 28 Oct 2018 at 21:02, Stefan Bodewig  wrote:

> On 2018-10-28, Gintautas Grigelionis wrote:
> > On Sun, 28 Oct 2018 at 20:23, Stefan Bodewig  wrote:
>
> >> I guess I need to create a branch to either convince you it is possible
> >> or convince me that it is not :-)
>
> > No branch is necessary, just  activate launcher tests; the effect will be
> > the same.
>
> I'm afraid I can't follow you.
>
> What breaks in the remove-tests-constants-from-main-tree?
>
> > It is not a matter of test harness, either. It is a matter of
> > documentation and proper dependency management.
>
> > I'm only using a different tool to highlight the importance of the
> > latter (as far as running tests is concerned, anyway :-)
>
> And because of above I probably don't understand what you mean here
> either.
>

What I meant is the following: anyone who wishes to see the effect of test
dependencies
can replace the bogus directory "testcases" with the correct directory
"tests/junit" in
src/etc/poms/ant-launcher/pom.xml (line 77, the definition of
testSourceDirectory property).
Then run "mvn -f src/etc/poms/pom.xml clean package" (what Jenkins does).

If test constants are removed from main, then Ant core must build yet
another jar containing
test constants which would be a compile dependency for the code in
ant-testutil, because
Ant core in itself will not suffice. It is possible to cook such a jar file
using a Maven qualifier,
and it will pollute every build in the world which chooses to use Ant core.
As the saying over here
goes, "plague or cholera".

Gintas

Re: ant git commit: Add magic names for tests, run more tests in Surefire

[Gintautas Grigelionis]

On Sun, 28 Oct 2018 at 20:23, Stefan Bodewig  wrote:

> On 2018-10-28, Gintautas Grigelionis wrote:
> > On Sun, 28 Oct 2018 at 18:48, Stefan Bodewig  wrote:
> >> On 2018-10-28, Gintautas Grigelionis wrote:
> >>> On Sun, 28 Oct 2018 at 18:17, Stefan Bodewig 
> wrote:
> >>>> On 2018-10-28, Gintautas Grigelionis wrote:
> >>>>> On Sun, 28 Oct 2018 at 17:59, Stefan Bodewig 
> >> wrote:
>
> >>>>>> I wonder whether it wouldn't be a good idea to create a separate
> class
> >>>>>> for constants used during testing that lives in ant-testutil rather
> >> than
> >>>>>> poluting the "magic names" of Ant.
>
> >>>>> The problem is that should such class end up in ant-testutil, it
> makes
> >>>> ant
> >>>>> dependent on ant-util and that creates a dependency loop.
>
> >>>> I'm talking about the "magic names" only used in tests. The four
> >>>> properties with names that start with TEST_ should not be used inside
> >>>> the rest of Ant, are they?
>
> >>> I understand your point. TEST_ properties are only for tests. But, the
> >>> tests themselves are a part of Ant core.
>
> >> Are they? I really hope there are no test classes in ant.jar.
>
> >> The constants can be moved to the tests jar of Ant core (where Ant core
> >> likely means org.apache.ant:ant in Maven speak) and ant-testutil. All
> >> Maven artifacts that are not org.apache.ant:ant can have a test scope
> >> dependency on ant-testutil.
>
>
> > The scope does not matter, should the test constants be in ant-util,
> there
> > will be a dependency of ant on ant-testutil creating a loop.
>
> > Test classes in Ant core won't compile before ant-testutil is compiled
> and
> > packaged, which in turn would require ant to be compiled and packaged.
>
> I guess I need to create a branch to either convince you it is possible
> or convince me that it is not :-)
>

No branch is necessary, just  activate launcher tests; the effect will be
the same.


> > It's all nice and easy when there is a pile of code that can be compiled
> at
> > once and divided arbitrarily... not so simple when it has to be split
> > beforehand (see my remarks on AssertionsTest depending JUnit tasks or
> > launcher tests depending on Os).
>
> I'm not happy defining constants only used during testing in the main
> source tree so that a build tool other than Ant can be used to run the
> tests. Right now I believe this won't be necessary at all.
>

It is not a matter of test harness, either. It is a matter of documentation
and proper dependency management.
I'm only using a different tool to highlight the importance of the latter
(as far as running tests is concerned, anyway :-)

Gintas

Re: ant git commit: Add magic names for tests, run more tests in Surefire

[Gintautas Grigelionis]

On Sun, 28 Oct 2018 at 18:48, Stefan Bodewig  wrote:

> On 2018-10-28, Gintautas Grigelionis wrote:
> > On Sun, 28 Oct 2018 at 18:17, Stefan Bodewig  wrote:
> >> On 2018-10-28, Gintautas Grigelionis wrote:
> >>> On Sun, 28 Oct 2018 at 17:59, Stefan Bodewig 
> wrote:
>
> >>>> I wonder whether it wouldn't be a good idea to create a separate class
> >>>> for constants used during testing that lives in ant-testutil rather
> than
> >>>> poluting the "magic names" of Ant.
>
> >>> The problem is that should such class end up in ant-testutil, it makes
> >> ant
> >>> dependent on ant-util and that creates a dependency loop.
>
> >> I'm talking about the "magic names" only used in tests. The four
> >> properties with names that start with TEST_ should not be used inside
> >> the rest of Ant, are they?
>
> > I understand your point. TEST_ properties are only for tests. But, the
> > tests themselves are a part of Ant core.
>
> Are they? I really hope there are no test classes in ant.jar.
>
> The constants can be moved to the tests jar of Ant core (where Ant core
> likely means org.apache.ant:ant in Maven speak) and ant-testutil. All
> Maven artifacts that are not org.apache.ant:ant can have a test scope
> dependency on ant-testutil.
>

The scope does not matter, should the test constants be in ant-util, there
will be a dependency of ant on ant-testutil creating a loop.
Test classes in Ant core won't compile before ant-testutil is compiled and
packaged, which in turn would require ant to be compiled and packaged.
It's all nice and easy when there is a pile of code that can be compiled at
once and divided arbitrarily... not so simple when it has to be split
beforehand (see my remarks on AssertionsTest depending JUnit tasks or
launcher tests depending on Os).

Gintas

Re: ant git commit: Add magic names for tests, run more tests in Surefire

[Gintautas Grigelionis]

On Sun, 28 Oct 2018 at 18:17, Stefan Bodewig  wrote:

> On 2018-10-28, Gintautas Grigelionis wrote:
> > On Sun, 28 Oct 2018 at 17:59, Stefan Bodewig  wrote:
>
> >> I wonder whether it wouldn't be a good idea to create a separate class
> >> for constants used during testing that lives in ant-testutil rather than
> >> poluting the "magic names" of Ant.
>
> > The problem is that should such class end up in ant-testutil, it makes
> ant
> > dependent on ant-util and that creates a dependency loop.
>
> I'm talking about the "magic names" only used in tests. The four
> properties with names that start with TEST_ should not be used inside
> the rest of Ant, are they?
>

 I understand your point. TEST_ properties are only for tests. But, the
tests themselves are a part of Ant core.
Therefore, a separate class (MagicTestNames or some such) would still be a
part of Ant core.

Gintas

Re: Tests in Surefire

[Gintautas Grigelionis]

On Thu, 25 Oct 2018 at 09:05, Gintautas Grigelionis 
wrote:

> On Wed, 24 Oct 2018 at 00:29, Gintautas Grigelionis <
> g.grigelio...@gmail.com> wrote:
>
>> On Tue, 23 Oct 2018 at 12:25, Stefan Bodewig  wrote:
>>
>>> On 2018-10-20, Gintautas Grigelionis wrote:
>>>
>>> > I believe that in order to execute Ant test suite in Surefire one must
>>> > configure basedir which unfortunately affects Ant test projects.
>>>
>>> I'm not sure I share the goal of trying to run the tests via Surefire at
>>> all.
>>>
>>> Antoine has been the one who set up the maven poms and I don't remember
>>> us ever discussing what we wanted to achieve there. To me they've been a
>>> vehicle to get decent POMs for the jars we publish to Maven Central, not
>>> more. Here "decent" means "specifies the correct dependencies" and not
>>> even "can be used to compile the jar". I think it has outgrown my
>>> personal minimal requirement by far, so others must have had bigger
>>> plans :-)
>>>
>>> I do not believe we've been aware of Surefire bugs that prevented
>>> running. We've most likely never cared (and I still don't, obviously :-)
>>>
>>
>> It was in the README :-) the inability to set basedir/workingDir.
>>
>>
>>> > Perhaps it would make sense to have a magic property that (in
>>> > combination with detection of Surefire environment) would allow
>>> > BuildFileRule to call System.clearProperty("basedir")?
>>>
>>> If that's all it would take to make them work, that's fine with me. If
>>> we need further modifications to the tests them I'm not sure.
>>>
>>
>> Fair enough. I've hit some snags and I commented on them in the POMs.
>>
>
> I am at the point now where I must say "this is the farthest I could get
> without changing the tests".
> Please see the comments in src/etc/poms/ant/pom.xml, especially
> testExcludes section.
> Some tests, in particular in IncludeTest, are not robust (failure modes
> depend on XML parser,
> which may throw an exception because encoding is not specified, which was
> not the original intention).
> AntTest hardcodes directory structure (build/testcases) which apparently
> breaks modular builds in Jenkins
> (works locally). Also, current test failures in Jenkins apparently are an
> oddity of Maven,
> which uses ANT_HOME/jre/java on Java 8 or older SDKs precluding use of
> javac.
>
> Thanks, Gintas
>

It has been eerily quiet here... anyway, here's the state of the test suite
vis-a-vis Surefire and modular Maven builds:

   - most cases that were dependent on assumed structure of build file tree
   are refactored to use build.tests.value property (corresponding to
   testOutputDirectory in Maven);
   - build.tests.value property is redundant where it is used in
   combination with java.class.path property and therefore is removed so that
   the corresponding test classes do not need to assert it;
   - root property is removed from all test build files except one,
   javadoc, where it is used to access Java sources; POMs do not set it, and
   perhaps build.xml needs not set it either;
   - I added build.classes.value property (corresponding to outputDirectory
   in Maven), it's only used in signjar tests currently; I chose build.*.value
   names for the properties in order to avoid accidental name collisions.

Currently, certain Ant core and junit/junitlauncher tests still fail in
Surefire. I would like to get them all working; however, I am afraid that
their logic should be changed quite drastically. Also. please see comments
in pom.xml about some dependencies that must be eliminated (launcher on
core, or core on junit).

I also activated test analysis in Ant_Nightly (build from POMs presents
test analysis automagically). Currently, it seems that Maven executes more
tests than Nightly, and I will look into that discrepancy, too.

Thanks, Gintas

Re: ant git commit: Add magic names for tests, run more tests in Surefire

[Gintautas Grigelionis]

On Sun, 28 Oct 2018 at 17:59, Stefan Bodewig  wrote:

> On 2018-10-23,  wrote:
>
> >
> http://git-wip-us.apache.org/repos/asf/ant/blob/679a9422/src/main/org/apache/tools/ant/MagicNames.java
>
> >+/**
> >+ * Magic property that makes unit tests based on BuildFileTest
> >+ * or BuildFileRule ignore externally set basedir
> >+ * (typically by Surefire/Failsafe)
> >+ *
> >+ * Value: {@value}
> >+ * @since Ant 1.10.6
> >+ */
> >+public static final String TEST_BASEDIR_IGNORE =
> "ant.test.basedir.ignore";
>
> I wonder whether it wouldn't be a good idea to create a separate class
> for constants used during testing that lives in ant-testutil rather than
> poluting the "magic names" of Ant.
>
> Stefan
>

The problem is that should such class end up in ant-testutil, it makes ant
dependent on ant-util and that creates a dependency loop.

Gintas

Re: Tests in Surefire

[Gintautas Grigelionis]

On Wed, 24 Oct 2018 at 00:29, Gintautas Grigelionis 
wrote:

> On Tue, 23 Oct 2018 at 12:25, Stefan Bodewig  wrote:
>
>> On 2018-10-20, Gintautas Grigelionis wrote:
>>
>> > I believe that in order to execute Ant test suite in Surefire one must
>> > configure basedir which unfortunately affects Ant test projects.
>>
>> I'm not sure I share the goal of trying to run the tests via Surefire at
>> all.
>>
>> Antoine has been the one who set up the maven poms and I don't remember
>> us ever discussing what we wanted to achieve there. To me they've been a
>> vehicle to get decent POMs for the jars we publish to Maven Central, not
>> more. Here "decent" means "specifies the correct dependencies" and not
>> even "can be used to compile the jar". I think it has outgrown my
>> personal minimal requirement by far, so others must have had bigger
>> plans :-)
>>
>> I do not believe we've been aware of Surefire bugs that prevented
>> running. We've most likely never cared (and I still don't, obviously :-)
>>
>
> It was in the README :-) the inability to set basedir/workingDir.
>
>
>> > Perhaps it would make sense to have a magic property that (in
>> > combination with detection of Surefire environment) would allow
>> > BuildFileRule to call System.clearProperty("basedir")?
>>
>> If that's all it would take to make them work, that's fine with me. If
>> we need further modifications to the tests them I'm not sure.
>>
>
> Fair enough. I've hit some snags and I commented on them in the POMs.
>

I am at the point now where I must say "this is the farthest I could get
without changing the tests".
Please see the comments in src/etc/poms/ant/pom.xml, especially
testExcludes section.
Some tests, in particular in IncludeTest, are not robust (failure modes
depend on XML parser,
which may throw an exception because encoding is not specified, which was
not the original intention).
AntTest hardcodes directory structure (build/testcases) which apparently
breaks modular builds in Jenkins
(works locally). Also, current test failures in Jenkins apparently are an
oddity of Maven,
which uses ANT_HOME/jre/java on Java 8 or older SDKs precluding use of
javac.

Thanks, Gintas

Re: Tests in Surefire

[Gintautas Grigelionis]

On Tue, 23 Oct 2018 at 12:25, Stefan Bodewig  wrote:

> On 2018-10-20, Gintautas Grigelionis wrote:
>
> > I believe that in order to execute Ant test suite in Surefire one must
> > configure basedir which unfortunately affects Ant test projects.
>
> I'm not sure I share the goal of trying to run the tests via Surefire at
> all.
>
> Antoine has been the one who set up the maven poms and I don't remember
> us ever discussing what we wanted to achieve there. To me they've been a
> vehicle to get decent POMs for the jars we publish to Maven Central, not
> more. Here "decent" means "specifies the correct dependencies" and not
> even "can be used to compile the jar". I think it has outgrown my
> personal minimal requirement by far, so others must have had bigger
> plans :-)
>
> I do not believe we've been aware of Surefire bugs that prevented
> running. We've most likely never cared (and I still don't, obviously :-)
>

It was in the README :-) the inability to set basedir/workingDir.


> > Perhaps it would make sense to have a magic property that (in
> > combination with detection of Surefire environment) would allow
> > BuildFileRule to call System.clearProperty("basedir")?
>
> If that's all it would take to make them work, that's fine with me. If
> we need further modifications to the tests them I'm not sure.
>

Fair enough. I've hit some snags and I commented on them in the POMs.

Gintas

Re: Tests in Surefire

[Gintautas Grigelionis]

Here's what happened: there's a Jenkins job that builds Ant using Maven,
since Ant project has POMs for all components.

I happened to create a new component, and realised I forgot to add it to
the master POM.
While doing that, I saw that the Jenkins job has been broken, and started
digging deeper.
It seems that once upon a time Ant was buildable with Maven including unit
tests
(even though the latter part was cludgy, mainly because the launcher sets
some magical properties,
but also due to limitations in earlier versions of Surefire).

However, running the tests independently through Surefire would help to
improve them,
partly because that would expose all magic that's happening under the cover,
and partly because the exclude/include rules are degraded to the point that
apache-ant Maven module
still tries to execute too many tests, while some tests (like those for ssh
task) seems to be ignored by pure Ant builds.

In order to get this sorted out, I came to the conclusion that I would like
BuildFileTest/BuildFileRule
to clear basedir property based on whether another magic property is set or
not before project.init() in configureProject().
I propose to call it "ant.test.basedir.ignore" or something like that; I
can open a PR for that.

Gintas

On Mon, 22 Oct 2018 at 07:34, Jaikiran Pai  wrote:

> Could you tell us a bit more about what is being attempted? Are you
> saying you plan to run the tests that are part of the Ant project,
> through the mvn command, while building Ant?
>
> -Jaikiran
>
>
> On 20/10/18 3:31 PM, Gintautas Grigelionis wrote:
> > I believe that in order to execute Ant test suite in Surefire one must
> > configure basedir which unfortunately affects Ant test projects. Perhaps
> it
> > would make sense to have a magic property that (in combination with
> > detection of Surefire environment) would allow BuildFileRule to call
> > System.clearProperty("basedir")?
> >
> > Gintas
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Tests in Surefire

[Gintautas Grigelionis]

I believe that in order to execute Ant test suite in Surefire one must
configure basedir which unfortunately affects Ant test projects. Perhaps it
would make sense to have a magic property that (in combination with
detection of Surefire environment) would allow BuildFileRule to call
System.clearProperty("basedir")?

Gintas

Re: Java 11 Compatibility Problem

[Gintautas Grigelionis]

Equinox JarProcessor [1] seems to use pack200 CLI.

1.
https://git.eclipse.org/c/equinox/rt.equinox.p2.git/plain/bundles/org.eclipse.equinox.p2.jarprocessor/src/org/eclipse/internal/provisional/equinox/p2/jarprocessor/JarProcessor.java

Gintas

On Thu, 11 Oct 2018 at 17:00, Nicolas Lalevée 
wrote:

> To be complete on this subject, the pack200 algorithm has been implemented
> to be able to resolve artifacts in an Eclipse updatesite. I don’t know how
> nowadays artifacts are packaged on a « p2 repository », but some
> documentation still exists and doesn’t contain any warnings:
>
> https://wiki.eclipse.org/Equinox_p2_Repository_Optimization#Pack200_Optimization
>
> Nicolas
>
>
>
> > Le 10 oct. 2018 à 14:04, Jaikiran Pai  a écrit :
> >
> > Hi Jan,
> >
> > For end users (of Ivy), the place where pack200 packaging becomes
> > visible is when they reference it in their dependencies as noted in our
> > doc[1]. So IMO, I think we should probably add a note/warning within our
> > documentation than a runtime log/warn message. But I still think, it's a
> > bit too early to do that. Maybe we should wait a few more releases of
> > Java and see if any alternatives show up?
> >
> > [1]
> >
> https://ant.apache.org/ivy/history/latest-milestone/concept.html#packaging
> >
> > -Jaikiran
> > On 10/10/18 11:09 AM, Jan Matèrne (jhm) wrote:
> >> If I understand Dragans point right, the warning comes when analyzing
> the code.
> >> Not just running Ivy.
> >> So the normal user won't see the warning. Maybe we should implement a
> warning?
> >>
> >> Jan
> >>
> >>> -Ursprüngliche Nachricht-
> >>> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
> >>> Gesendet: Mittwoch, 10. Oktober 2018 07:08
> >>> An: dev@ant.apache.org
> >>> Betreff: Re: Java 11 Compatibility Problem
> >>>
> >>> I agree with Stefan, at the moment I recommend ignoring those warnings.
> >>> There isn't anything else we can do (other than removing support for
> >>> pack200, which isn't a good option).
> >>>
> >>> -Jaikiran
> >>>
> >>>
> >>> On 10/10/18 9:56 AM, Stefan Bodewig wrote:
>  Hi Krzysztof
> 
>  I'm not actively working on Ivy so take my response with a grain of
>  salt.
> 
>  On 2018-10-09, Dragan, Krzysztof wrote:
> 
> > Hi,
> > scanning latest version of Apache Ivy(2.5.0-rc-1) using jdeprscan on
> > jdk11 I noticed two problems with this jar.
> > These two methods using internal jdk marked for removal and will be
> >>> deleted:
> >  * class org/apache/ivy/util/FileUtil uses deprecated class
> >java/util/jar/Pack200$Unpacker (forRemoval=true)
> >  * class org/apache/ivy/util/FileUtil uses deprecated class
> >java/util/jar/Pack200 (forRemoval=true)
>  For background see https://openjdk.java.net/jeps/336
> 
>  The Java community has decided to eventually remove support for the
>  pack200 format, but it still is there in Java11. Right now this is
>  only a warning, it will only become a real problem once the classes
>  actually get removed. They do not offer any alternative
> >>> implementation
>  right now, and may never do (unlike the JAXB case, which is available
>  as an external library now).
> 
>  I am aware of an alternative based on the former Apache Harmony code
>  in https://github.com/pfirmstone/pack200 but am unsure about its
> >>> state
>  - both technically and legally - I very vaguely recall the Pack200
>  spec was encumbered with Oracle patents but may be totally wrong.
> 
>  In Ivy's case the only save option right now was to remove support
> >>> for
>  pack200 archives and break existing setups that consume such archives
>  which seems to be excessive just in order to get rid of a warning.
> 
>  If yu ask me I'd recommend to live with the warning for now and wait
>  for an alternative to the class library's pack200 classes to become
>  available - which hopefully happens before the Java version removing
>  support gets released.
> 
>  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
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: 

Re: ant git commit: Check spelling

[Gintautas Grigelionis]

Point taken. Apologies for comments that could be considered lousy or
snarky.

Any opinions on code quality checks (Checkstyle/JaCoCo/SpotBugs/Simian etc)
in nightlies and doing something to improve their scores?

Gintas

On Thu, 13 Sep 2018 at 15:00, Nicolas Lalevée 
wrote:

>
> > [1] https://github.com/apache/ant/pull/66/files
> > [2]
> >
> https://github.com/apache/ant/commit/54b6df2f44c5cb4f9573f99330c2d2908f1bf506
> <
> https://github.com/apache/ant/commit/54b6df2f44c5cb4f9573f99330c2d2908f1bf506
> >
>
> At the *first* line of the diff presented on github, I can tell the commit
> is not only about check spelling.
>
> Not knowing if we have the same presentation, let’s be precise:
>
> https://github.com/apache/ant/commit/54b6df2f44c5cb4f9573f99330c2d2908f1bf506#diff-9ad784be5493fb9473c8d4e8a26aadedL25
> <
> https://github.com/apache/ant/commit/54b6df2f44c5cb4f9573f99330c2d2908f1bf506#diff-9ad784be5493fb9473c8d4e8a26aadedL25
> >
>
> Nicolas
>
> >
> > -Jaikiran
> >
> >
> > On 11/09/18 12:17 PM, Gintautas Grigelionis wrote:
> >> How was this different from PR #66?
> >>
> >> Gintas
> >>
> >> On Tue, 11 Sep 2018 at 06:55, Jaikiran Pai  wrote:
> >>
> >>> Things haven't changed (nor do I expect any changes anymore). To say
> the
> >>> least - it's followed the same pattern:
> >>>
> >>> - do changes like these
> >>>
> >>> - when requested not to do such changes, argue over it and move it to
> >>> some abstract discussion
> >>>
> >>> - then give an impression it won't be repeated
> >>>
> >>> - few days down the line push changes like these and repeat the whole
> >>> cycle again.
> >>>
> >>> Although I stay silent with these commits these days it's because I
> have
> >>> nothing good or new to say about this behaviour and am fully exhausted
> >>> with this exercise to the extent that I just delete such commit
> >>> notifications instead of reviewing them, to avoid it ruining any energy
> >>> I might have to contribute anything in my spare time.
> >>>
> >>> Committer rights is a privilege as well as a responsibility, but this
> >>> behaviour is nothing but an abuse of it and no different than being a
> >>> troll.
> >>>
> >>> -Jaikiran
> >>>
> >>>
> >>> On 10/09/18 5:12 AM, Nicolas Lalevée wrote:
> >>>> I have been away from the project out of boredom. Still curious, I
> came
> >>> to read some emails. It seems things didn’t changed much: yet another
> >>> unreadable commit with a log which doesn’t indicate what it actually
> do.
> >>>>
> >>>>> Le 9 sept. 2018 à 09:09, gin...@apache.org a écrit :
> >>>>>
> >>>>> Repository: ant
> >>>>> Updated Branches:
> >>>>> refs/heads/master fde6b0e94 -> 54b6df2f4
> >>>>>
> >>>>>
> >>>>> Check spelling
> >>>>>
> >>>>> Project: http://git-wip-us.apache.org/repos/asf/ant/repo
> >>>>> Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/54b6df2f
> >>>>> Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/54b6df2f
> >>>>> Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/54b6df2f
> >>>>>
> >>>>> Branch: refs/heads/master
> >>>>> Commit: 54b6df2f44c5cb4f9573f99330c2d2908f1bf506
> >>>>> Parents: fde6b0e
> >>>>> Author: Gintas Grigelionis 
> >>>>> Authored: Sat Sep 8 22:12:24 2018 +0200
> >>>>> Committer: Gintas Grigelionis 
> >>>>> Committed: Sun Sep 9 09:07:18 2018 +0200
> >>>>>
> >>>>>
> --
> >>>>> .../checkstyle-frames-sortby-check.xsl  | 194
> >>> +--
> >>>>> src/etc/jdepend-frames.xsl  |  18 +-
> >>>>> src/etc/jdepend.xsl |  48 +++--
> >>>>> src/etc/testcases/taskdefs/exec/exec.xml|   4 +-
> >>>>> .../taskdefs/optional/unix/symlink.xml  |  78 
> >>>>> .../optional/xml/endpiece-noSchema-invalid.xml  |   9 +-
> >>>>> .../taskdefs/optional/xml/endpiece-noSchema.xml |   7 +-
> >>>>> src/etc/test

Re: ant git commit: Check spelling

[Gintautas Grigelionis]

How was this different from PR #66?

Gintas

On Tue, 11 Sep 2018 at 06:55, Jaikiran Pai  wrote:

> Things haven't changed (nor do I expect any changes anymore). To say the
> least - it's followed the same pattern:
>
> - do changes like these
>
> - when requested not to do such changes, argue over it and move it to
> some abstract discussion
>
> - then give an impression it won't be repeated
>
> - few days down the line push changes like these and repeat the whole
> cycle again.
>
> Although I stay silent with these commits these days it's because I have
> nothing good or new to say about this behaviour and am fully exhausted
> with this exercise to the extent that I just delete such commit
> notifications instead of reviewing them, to avoid it ruining any energy
> I might have to contribute anything in my spare time.
>
> Committer rights is a privilege as well as a responsibility, but this
> behaviour is nothing but an abuse of it and no different than being a
> troll.
>
> -Jaikiran
>
>
> On 10/09/18 5:12 AM, Nicolas Lalevée wrote:
> > I have been away from the project out of boredom. Still curious, I came
> to read some emails. It seems things didn’t changed much: yet another
> unreadable commit with a log which doesn’t indicate what it actually do.
> >
> >
> >> Le 9 sept. 2018 à 09:09, gin...@apache.org a écrit :
> >>
> >> Repository: ant
> >> Updated Branches:
> >>  refs/heads/master fde6b0e94 -> 54b6df2f4
> >>
> >>
> >> Check spelling
> >>
> >> Project: http://git-wip-us.apache.org/repos/asf/ant/repo
> >> Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/54b6df2f
> >> Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/54b6df2f
> >> Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/54b6df2f
> >>
> >> Branch: refs/heads/master
> >> Commit: 54b6df2f44c5cb4f9573f99330c2d2908f1bf506
> >> Parents: fde6b0e
> >> Author: Gintas Grigelionis 
> >> Authored: Sat Sep 8 22:12:24 2018 +0200
> >> Committer: Gintas Grigelionis 
> >> Committed: Sun Sep 9 09:07:18 2018 +0200
> >>
> >> --
> >> .../checkstyle-frames-sortby-check.xsl  | 194
> +--
> >> src/etc/jdepend-frames.xsl  |  18 +-
> >> src/etc/jdepend.xsl |  48 +++--
> >> src/etc/testcases/taskdefs/exec/exec.xml|   4 +-
> >> .../taskdefs/optional/unix/symlink.xml  |  78 
> >> .../optional/xml/endpiece-noSchema-invalid.xml  |   9 +-
> >> .../taskdefs/optional/xml/endpiece-noSchema.xml |   7 +-
> >> src/etc/testcases/types/assertions.xml  | 178 +
> >> src/etc/testcases/types/selectors.xml   | 104 +-
> >> src/main/org/apache/tools/ant/Diagnostics.java  |   2 +-
> >> src/main/org/apache/tools/ant/taskdefs/Ant.java |   2 +-
> >> .../org/apache/tools/ant/taskdefs/Checksum.java |   2 +-
> >> .../org/apache/tools/ant/taskdefs/Exec.java |   2 +-
> >> .../org/apache/tools/ant/taskdefs/SignJar.java  |   2 +-
> >> src/main/org/apache/tools/ant/taskdefs/Zip.java |   2 +-
> >> .../ant/taskdefs/condition/IsReachable.java |   4 +-
> >> .../optional/ejb/GenericDeploymentTool.java |   4 +-
> >> .../optional/ejb/JonasDeploymentTool.java   |   4 +-
> >> .../tools/ant/taskdefs/optional/jsp/WLJspc.java |   2 +-
> >> .../junitlauncher/JUnitLauncherTask.java|   2 +-
> >> .../optional/junitlauncher/TestRequest.java |   8 +-
> >> .../tools/ant/taskdefs/optional/net/FTP.java|   4 +-
> >> .../optional/net/FTPTaskMirrorImpl.java |   4 +-
> >> .../tools/ant/taskdefs/optional/vss/MSVSS.java  |   2 +-
> >> .../ant/taskdefs/optional/vss/MSVSSCHECKIN.java |   2 +-
> >> .../org/apache/tools/ant/types/XMLCatalog.java  |   2 +-
> >> .../org/apache/tools/ant/util/FileUtils.java|   2 +-
> >> .../org/apache/tools/ant/util/ProxySetup.java   |   2 +-
> >> .../org/apache/tools/zip/ZipOutputStream.java   |   4 +-
> >> src/script/antenv.cmd   |   2 +-
> >> src/script/envset.cmd   |   2 +-
> >> src/tests/antunit/taskdefs/echoxml-test.xml |   2 +-
> >> .../apache/tools/ant/taskdefs/UnzipTest.java|   2 +-
> >> .../ant/taskdefs/optional/TraXLiaisonTest.java  |   2 +-
> >> .../tools/ant/util/ReaderInputStreamTest.java   |   4 +-
> >> 35 files changed, 350 insertions(+), 362 deletions(-)
> >> --
> >>
> >>
> >>
> http://git-wip-us.apache.org/repos/asf/ant/blob/54b6df2f/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl
> >> --
> >> diff --git a/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl
> b/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl
> >> index 060f878..1f02b90 100644
> >> --- a/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl
> >> +++ b/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl
> >> @@ -22,7 +22,7 @@
> >> -->
> >>
> >> 
> >> 

Re: Jenkins-Builds failing

[Gintautas Grigelionis]

I see that Ant 1.9.13 is available as a choice, but Ivy Check job is still
owned by hibou, and thus it is not possible to change the configuration.
Is there a case about changing the ownership of all Ivy jobs? Or is it so
that dependencies between Jenkins jobs are still an issue?

Gintas

On Mon, 13 Aug 2018 at 12:26, Jaikiran Pai  wrote:

> Noted. Just waiting for the infra team to sort out the access issue.
>
> -Jaikiran
>
>
> On 12/08/18 2:28 AM, Gintautas Grigelionis wrote:
> > Hi Jan and Jaikiran,
> >
> > looks like IvyDE trunk build needs attention, too (SSL protocol failure
> > when resolving Checkstyle).
> >
> > Thanks, Gintas
> >
> > On Wed, 8 Aug 2018 at 13:23, Jan Matèrne (jhm) 
> wrote:
> >
> >> Tried to change from "Ant 1.9.9" to "Ant (latest)".
> >> An "Ant 1.10.1" or an "Ant 1.9.9" are the latest available named
> versions.
> >>
> >> Got an
> >>   Access denied
> >>   This job's current authorization strategy does not permit jhm to
> modify
> >> the job configuration
> >>
> >> Asked in https://issues.apache.org/jira/browse/INFRA-16799 for
> >> checking+fixing all of our jobs.
> >>
> >>
> >> Jan
> >>
> >>> -Ursprüngliche Nachricht-
> >>> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
> >>> Gesendet: Montag, 6. August 2018 06:45
> >>> An: dev@ant.apache.org
> >>> Betreff: Re: Jenkins-Builds failing
> >>>
> >>> Sure, will fix it this week. Right now, I don't have necessary
> >>> permissions to edit it.
> >>>
> >>> -Jaikiran
> >>>
> >>>
> >>> On 05/08/18 8:58 PM, Gintautas Grigelionis wrote:
> >>>> There's one more Jenkins job failing due to outdated Ant, Ivy Check (
> >>>> https://builds.apache.org/view/All/job/Ivy-check/).
> >>>> Could you please check it, Jaikiran?
> >>>>
> >>>> Thanks, Gintas
> >>>>
> >>>> On Sun, 29 Jul 2018 at 15:13, Jaikiran Pai 
> >>> wrote:
> >>>>> I would like to test/import a few more projects (that Nicolas
> >>>>> mentioned in one the mails) locally into the latest upstream version
> >>>>> of the IDE, before starting a release. I have only tested a few so
> >>> far.
> >>>>> -Jaikiran
> >>>>>
> >>>>> On 28/07/18 2:28 PM, Gintautas Grigelionis wrote:
> >>>>>> Thanks, Jaikiran. Would you be willing to restart the release
> >>>>>> process for IvyDE now? Gintas On Fri, 27 Jul 2018 at 15:43,
> >>> Jaikiran
> >>>>>> Pai  wrote:
> >>>>>>> On 25/07/18 6:45 PM, Jaikiran Pai wrote:
> >>>>>>>> Almost all jobs that I know of have been taken care of now.
> >>>>>>>> There's a "Ivy-tests-Windows" job which is pending, but for that
> >>> I
> >>>>>>>> need some help from infra team. I am discussing it with them
> >>>>>>>> separately and I expect it to be resolved soon. I'll fix that job
> >>> tomorrow.
> >>>>>>> This is now done too. -Jaikiran
> >>>>>>> --
> >>> -
> >>>>>>> -- 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
> >>
> >>
> >> -
> >> 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: ant-ivy git commit: Update the release notes

[Gintautas Grigelionis]

I like the idea, though. One thing that should be investigated further is
places where location is obtained by getResource().getName()
AFAICS that happens in CacheResolver (deprecated), BasicResolver (where
also a Resource is constructed from location), and
DefaultRepositoryCacheManager. There's no uniformity in
Resource-implementing classes either, sometimes getName() works on an URI,
sometimes a path string.

Gintas

On Wed, 29 Aug 2018 at 08:34, Jaikiran Pai  wrote:

> More of a FYI - I'm still not convinced that my fix for this handles all
> the necessary cases (looks like the ArtifactOrigin#location gets used in
> various different ways), so I may either revert back my changes or
> decide to change it in a different way. So right now, in its current
> form, my changes aren't a fix.
>
> -Jaikiran
>
>
> On 29/08/18 11:34 AM, gin...@apache.org wrote:
> > Repository: ant-ivy
> > Updated Branches:
> >   refs/heads/master d976a4a27 -> fd81f4461
> >
> >
> > Update the release notes
> >
> > Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/fd81f446
> > Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/fd81f446
> > Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/fd81f446
> >
> > Branch: refs/heads/master
> > Commit: fd81f44619b05a176ecbf4ff1499d64b39251520
> > Parents: d976a4a
> > Author: Gintas Grigelionis 
> > Authored: Wed Aug 29 08:03:13 2018 +0200
> > Committer: Gintas Grigelionis 
> > Committed: Wed Aug 29 08:05:12 2018 +0200
> >
> > --
> >  asciidoc/release-notes.adoc | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > --
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/fd81f446/asciidoc/release-notes.adoc
> > --
> > diff --git a/asciidoc/release-notes.adoc b/asciidoc/release-notes.adoc
> > index cc53bb3..efa7057 100644
> > --- a/asciidoc/release-notes.adoc
> > +++ b/asciidoc/release-notes.adoc
> > @@ -85,6 +85,7 @@ For details about the following changes, check our
> JIRA install at link:https://
> >  - FIX: Don't throw a CircularDependencyException when parsing an import
> scoped dependency in dependencyManagement section of a pom (jira:IVY-1588[])
> >  - FIX: Respect exclude regardless of resolution order (jira:IVY-1486[])
> (thanks to David Turner)
> >  - FIX: ModuleDescriptorMemoryCache didn't detect outdated entries when
> Ivy file was updated in the cache by another process
> > +- FIX: Store ArtifactOrigin's location as a URL
> >
> >  - IMPROVEMENT: Throw an IllegalStateException when retrieving the
> resolutionCacheRoot on the DefaultResolutionCacheManager if the basedir (or
> IvySettings) is not set (jira:IVY-1482[])
> >  - IMPROVEMENT: Optimization: limit the revision numbers scanned if
> revision prefix is specified (Thanks to Ernestas Vaiciukeviius)
> > @@ -181,7 +182,6 @@ Here is the list of people who have contributed
> source code and documentation up
> >  * Tobias Himstedt
> >  * Achim Huegen
> >  * Pierre Hgnestrand
> > -* Ilya
> >  * Matt Inger
> >  * Anders Jacobsson
> >  * Anders Janmyr
> > @@ -196,6 +196,7 @@ Here is the list of people who have contributed
> source code and documentation up
> >  * Sebastian Krueger
> >  * Thomas Kurpick
> >  * Costin Leau
> > +* Ilya Leoshkevich
> >  * Tat Leung
> >  * Antoine Levy-Lambert
> >  * Tony Likhite
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: ant git commit: Remove redundancies

[Gintautas Grigelionis]

On Thu, 23 Aug 2018 at 07:06, Stefan Bodewig  wrote:

> On 2018-08-22, Matt Sicker wrote:
>
> > Pretty much every implementation of javac will automatically convert the
> > string concatenation code into StringBuilders. Decompile the byte code
> and
> > see for yourself.
>
> I know that :-)
>
> The thing I qibble about is the commit message says "remove
> redundancies" and I don't see any redundancy in the original code.
>

Sorry, my bad. That should have been "early suboptimisation".
I believe, Java 9+ optimises string concatenation differently (or,
actually, it may use invokedynamic to delay it :-).

Gintas

Re: ant git commit: Use try-with-resources and ExpectedException

[Gintautas Grigelionis]

Jaikiran,

your code allowed for false positives, too

Gintas

On Wed, 15 Aug 2018 at 09:11, Gintautas Grigelionis 
wrote:

> I believe we discussed writing tests before. It is not a matter of style,
> but of keeping assumptions and assertions explicit.
> You replaced a JUnit 4 assertion with some code that works, but is far
> from being clear.
> There is a reason why JUnit provides specialised assert... methods and you
> could have at least used assertEquals()
> on exception message rather than rethrowing it. That would have been
> helpful in eventual migration to JUnit 5, too.
>
> Gintas
>
> On Wed, 15 Aug 2018 at 03:14, Jaikiran Pai  wrote:
>
>> Gintas,
>>
>>
>> On 14/08/18 10:14 PM, gin...@apache.org wrote:
>> >
>> http://git-wip-us.apache.org/repos/asf/ant/blob/e648224f/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>> > --
>> > diff --git
>> a/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>> b/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>> > index a77fc92..0d0c36a 100644
>> > ---
>> a/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>> > +++
>> b/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>> > @@ -25,6 +25,7 @@ import org.junit.Assert;
>> >  import org.junit.Before;
>> >  import org.junit.Rule;
>> >  import org.junit.Test;
>> > +import org.junit.rules.ExpectedException;
>> >
>> >  /**
>> >   * TODO : develop these testcases - the email task needs to have
>> attributes allowing
>> > @@ -35,6 +36,9 @@ public class EmailTaskTest {
>> >  @Rule
>> >  public BuildFileRule buildRule = new BuildFileRule();
>> >
>> > +@Rule
>> > +public ExpectedException thrown = ExpectedException.none();
>> > +
>> >  @Before
>> >  public void setUp() {
>> >
>> buildRule.configureProject("src/etc/testcases/taskdefs/email/mail.xml");
>> > @@ -45,14 +49,9 @@ public class EmailTaskTest {
>> >   */
>> >  @Test
>> >  public void test1() {
>> > -try {
>> > -buildRule.executeTarget("test1");
>> > -} catch (BuildException e) {
>> > -// assert it's the expected one
>> > -if (!e.getMessage().equals("SMTP auth only possible with
>> MIME mail")) {
>> > -throw e;
>> > -}
>> > -}
>> > +thrown.expect(BuildException.class);
>> > +thrown.expectMessage("SMTP auth only possible with MIME mail");
>> > +buildRule.executeTarget("test1");
>> >  }
>> >
>> >  /**
>> > @@ -60,14 +59,9 @@ public class EmailTaskTest {
>> >   */
>> >  @Test
>> >  public void test2() {
>> > -try {
>> > -buildRule.executeTarget("test2");
>> > -} catch (BuildException e) {
>> > -// assert it's the expected one
>> > -if (!e.getMessage().equals("SSL and STARTTLS only possible
>> with MIME mail")) {
>> > -throw e;
>> > -}
>> > -}
>> > +thrown.expect(BuildException.class);
>> > +thrown.expectMessage("SSL and STARTTLS only possible with MIME
>> mail");
>> > +buildRule.executeTarget("test2");
>> >  }
>> >
>> >  /**
>>
>> Could you tell me what was technically wrong with the way I had
>> committed it yesterday and why you felt that it had to be changed into
>> this form?
>>
>> When I looked into this test during the last couple of days, I realized
>> they weren't functional and were broken. So I fixed them and used a
>> particular coding style that I am comfortable with. I am not a fan of
>> using the @Rule based expected exceptions which are stored as member
>> variables in the class and which then have to be setup before the actual
>> testing happens. To me the try/catch block is much more intuitive and
>> gives me more control as well as a better read of what the test case
>> expects. Keeping that detail aside, I decided to use a particular coding
>> style that I was comfortable with when adding that code. The tests are
>> working fine. So what was the need to override that commit with a coding
>> style change? Is this how you are going to continue with your future
>> commits?
>>
>> -Jaikiran
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>

Re: ant git commit: Use try-with-resources and ExpectedException

[Gintautas Grigelionis]

I believe we discussed writing tests before. It is not a matter of style,
but of keeping assumptions and assertions explicit.
You replaced a JUnit 4 assertion with some code that works, but is far from
being clear.
There is a reason why JUnit provides specialised assert... methods and you
could have at least used assertEquals()
on exception message rather than rethrowing it. That would have been
helpful in eventual migration to JUnit 5, too.

Gintas

On Wed, 15 Aug 2018 at 03:14, Jaikiran Pai  wrote:

> Gintas,
>
>
> On 14/08/18 10:14 PM, gin...@apache.org wrote:
> >
> http://git-wip-us.apache.org/repos/asf/ant/blob/e648224f/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
> > --
> > diff --git
> a/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
> b/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
> > index a77fc92..0d0c36a 100644
> > ---
> a/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
> > +++
> b/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
> > @@ -25,6 +25,7 @@ import org.junit.Assert;
> >  import org.junit.Before;
> >  import org.junit.Rule;
> >  import org.junit.Test;
> > +import org.junit.rules.ExpectedException;
> >
> >  /**
> >   * TODO : develop these testcases - the email task needs to have
> attributes allowing
> > @@ -35,6 +36,9 @@ public class EmailTaskTest {
> >  @Rule
> >  public BuildFileRule buildRule = new BuildFileRule();
> >
> > +@Rule
> > +public ExpectedException thrown = ExpectedException.none();
> > +
> >  @Before
> >  public void setUp() {
> >
> buildRule.configureProject("src/etc/testcases/taskdefs/email/mail.xml");
> > @@ -45,14 +49,9 @@ public class EmailTaskTest {
> >   */
> >  @Test
> >  public void test1() {
> > -try {
> > -buildRule.executeTarget("test1");
> > -} catch (BuildException e) {
> > -// assert it's the expected one
> > -if (!e.getMessage().equals("SMTP auth only possible with
> MIME mail")) {
> > -throw e;
> > -}
> > -}
> > +thrown.expect(BuildException.class);
> > +thrown.expectMessage("SMTP auth only possible with MIME mail");
> > +buildRule.executeTarget("test1");
> >  }
> >
> >  /**
> > @@ -60,14 +59,9 @@ public class EmailTaskTest {
> >   */
> >  @Test
> >  public void test2() {
> > -try {
> > -buildRule.executeTarget("test2");
> > -} catch (BuildException e) {
> > -// assert it's the expected one
> > -if (!e.getMessage().equals("SSL and STARTTLS only possible
> with MIME mail")) {
> > -throw e;
> > -}
> > -}
> > +thrown.expect(BuildException.class);
> > +thrown.expectMessage("SSL and STARTTLS only possible with MIME
> mail");
> > +buildRule.executeTarget("test2");
> >  }
> >
> >  /**
>
> Could you tell me what was technically wrong with the way I had
> committed it yesterday and why you felt that it had to be changed into
> this form?
>
> When I looked into this test during the last couple of days, I realized
> they weren't functional and were broken. So I fixed them and used a
> particular coding style that I am comfortable with. I am not a fan of
> using the @Rule based expected exceptions which are stored as member
> variables in the class and which then have to be setup before the actual
> testing happens. To me the try/catch block is much more intuitive and
> gives me more control as well as a better read of what the test case
> expects. Keeping that detail aside, I decided to use a particular coding
> style that I was comfortable with when adding that code. The tests are
> working fine. So what was the need to override that commit with a coding
> style change? Is this how you are going to continue with your future
> commits?
>
> -Jaikiran
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: ant git commit: Update contributor lists, trim trailing whitespace

[Gintautas Grigelionis]

I checked the logs and used the contributors page on project website.

Gintas

> On 14 Aug 2018, at 09:41, Dominique Devienne  wrote:
> 
> That's 20+ more contributors in one go.
> 
> You've combed the commit log to add these people?
> What process exactly did you us?
> 
> --DD
> 
>> On Mon, Aug 13, 2018 at 8:28 PM  wrote:
>> 
>> Repository: ant
>> Updated Branches:
>>  refs/heads/master c9c41729a -> 1afbe154a
>> 
>> 
>> Update contributor lists, trim trailing whitespace
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/ant/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/1afbe154
>> Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/1afbe154
>> Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/1afbe154
>> 
>> Branch: refs/heads/master
>> Commit: 1afbe154ab4048d7804486101b82d4cd3fb9ba30
>> Parents: c9c4172
>> Author: Gintas Grigelionis 
>> Authored: Mon Aug 13 20:27:54 2018 +0200
>> Committer: Gintas Grigelionis 
>> Committed: Mon Aug 13 20:27:54 2018 +0200
>> 
>> --
>> CONTRIBUTORS  | 22 +
>> contributors.xml  | 89 ++
>> manual/Tasks/available.html   |  2 +
>> manual/Tasks/junitlauncher.html   | 38 +++
>> manual/install.html   |  9 ++--
>> src/etc/poms/ant-javamail/pom.xml |  6 +--
>> 6 files changed, 140 insertions(+), 26 deletions(-)
>> --
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/ant/blob/1afbe154/CONTRIBUTORS
>> --
>> diff --git a/CONTRIBUTORS b/CONTRIBUTORS
>> index 933a8fd..944f3f4 100644
>> --- a/CONTRIBUTORS
>> +++ b/CONTRIBUTORS
>> @@ -2,9 +2,11 @@ Amongst other, the following people contributed to ant:
>> 
>> Adam Blinkinsop
>> Adam Bryzak
>> +Adam Murdoch
>> Adam Retter
>> Adam Sotona
>> Adrian Nistor
>> +Adrien Grand
>> Aleksandr Ishutin
>> Alex Rosen
>> Alexei Yudichev
>> @@ -28,13 +30,16 @@ Anthony Wat
>> Antoine Baudoux
>> Antoine Levy-Lambert
>> Anton Mazkovoi
>> +Arcadius Ahouansou
>> Arjan Veenstra
>> Arnaud Vandyck
>> Arnout J. Kuiper
>> +Arun Jamwal
>> Aslak Hellesôy
>> Atsuhiko Yamanaka
>> Avik Sengupta
>> Balazs Fejes 2
>> +barney2k7
>> Bart Vanhaute
>> Ben Galbraith
>> Ben Gertzfield
>> @@ -50,6 +55,7 @@ Brian Felder
>> Brian Repko
>> Bruce Atherton
>> Cedomir Igaly
>> +Charles Duffy
>> Charles Hudak
>> Charlie Hubbard
>> Chris Hegarty
>> @@ -66,6 +72,7 @@ Clemens Hammacher
>> Clement OUDOT
>> Clive Brettingham-Moore
>> Conor MacNeill
>> +Costin Manolache
>> Craeg Strong
>> Craig Cottingham
>> Craig R. McClanahan
>> @@ -87,6 +94,7 @@ Daniel Trebbien
>> Danno Ferrin
>> Danny Yates
>> Dante Briones
>> +Darrell DeBoer
>> Davanum Srinivas
>> Dave Brondsema
>> Dave Brosius
>> @@ -111,6 +119,7 @@ Don Brown
>> Don Ferguson
>> Don Jeffery
>> Donal Quinlan
>> +Donald Leslie
>> Drew Sudell
>> Earl Hood
>> Edison Guo
>> @@ -133,6 +142,7 @@ Frank Zeyda
>> František Kučera
>> Frédéric Bothamy
>> Frederic Lavigne
>> +Gal Shachor
>> Gary S. Weaver
>> Gautam Guliani
>> Gene-Sung Chung
>> @@ -165,8 +175,10 @@ Ivan Ivanov
>> J Bleijenbergh
>> JC Mann
>> Jack J. Woehr
>> +Jacobus Martinus Kruithof
>> Jaikiran Pai
>> James Duncan Davidson
>> +James Todd
>> Jan Cumps
>> Jan Matèrne
>> Jan Mynarik
>> @@ -201,12 +213,14 @@ John Sisson
>> Jon Dickinson
>> Jon Skeet
>> Jon S. Stevens
>> +Jonathan K. Schneider
>> Jose Alberto Fernandez
>> Joseph Walton
>> Josh Lucas
>> Juerg Wanner
>> Julian Simpson
>> Justin Vallon
>> +Justyna Horwat
>> Karl Jansen
>> Keiron Liddle
>> Keith Visco
>> @@ -281,10 +295,13 @@ Mounir El Hajj
>> Nathan Beyer
>> Nick Chalko
>> Nick Crossley
>> +Nick Davis
>> Nick Fortescue
>> +Nick King
>> Nick Pellow
>> Nico Seessle
>> Nicola Ken Barozzi
>> +Nicolas Lalevée
>> Nigel Magnay
>> Oliver Merkel
>> Oliver Rossmueller
>> @@ -316,11 +333,13 @@ Philip Hourihane
>> Phillip Wells
>> Pierre Delisle
>> Pierre Dittgen
>> +Preston Bannister
>> Ralf Hergert
>> Rami Ojares
>> Randy Watler
>> Raphael Pierquin
>> Ray Waldin
>> +Razzi Abuissa
>> Reinhard Pointner
>> Remie Bolte
>> René Krell
>> @@ -360,6 +379,7 @@ Sean P. Kane
>> Sebastian Kantha
>> Sebastien Arod
>> Shiraz Kanga
>> +Simeon Fitch
>> Simon Law
>> Simone Bordet
>> Stefan Bodewig
>> @@ -408,10 +428,12 @@ Ulrich Schmidt
>> Uwe Schindler
>> Valentino Miazzo
>> Victor Toni
>> +Ville Skyttä
>> Vimil Saju
>> Vincent Legoll
>> Vincent Privat
>> Vitold Sedyshev
>> +Vladislav Bauer
>> Volker Leidl
>> Waldek Herka
>> Wang Weijun
>> 
>> http://git-wip-us.apache.org/repos/asf/ant/blob/1afbe154/contributors.xml
>> --
>> 

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

Re: Jenkins-Builds failing

[Gintautas Grigelionis]

Hi Jan and Jaikiran,

looks like IvyDE trunk build needs attention, too (SSL protocol failure
when resolving Checkstyle).

Thanks, Gintas

On Wed, 8 Aug 2018 at 13:23, Jan Matèrne (jhm)  wrote:

> Tried to change from "Ant 1.9.9" to "Ant (latest)".
> An "Ant 1.10.1" or an "Ant 1.9.9" are the latest available named versions.
>
> Got an
>   Access denied
>   This job's current authorization strategy does not permit jhm to modify
> the job configuration
>
> Asked in https://issues.apache.org/jira/browse/INFRA-16799 for
> checking+fixing all of our jobs.
>
>
> Jan
>
> > -Ursprüngliche Nachricht-
> > Von: Jaikiran Pai [mailto:jaiki...@apache.org]
> > Gesendet: Montag, 6. August 2018 06:45
> > An: dev@ant.apache.org
> > Betreff: Re: Jenkins-Builds failing
> >
> > Sure, will fix it this week. Right now, I don't have necessary
> > permissions to edit it.
> >
> > -Jaikiran
> >
> >
> > On 05/08/18 8:58 PM, Gintautas Grigelionis wrote:
> > > There's one more Jenkins job failing due to outdated Ant, Ivy Check (
> > > https://builds.apache.org/view/All/job/Ivy-check/).
> > > Could you please check it, Jaikiran?
> > >
> > > Thanks, Gintas
> > >
> > > On Sun, 29 Jul 2018 at 15:13, Jaikiran Pai 
> > wrote:
> > >
> > >> I would like to test/import a few more projects (that Nicolas
> > >> mentioned in one the mails) locally into the latest upstream version
> > >> of the IDE, before starting a release. I have only tested a few so
> > far.
> > >>
> > >> -Jaikiran
> > >>
> > >> On 28/07/18 2:28 PM, Gintautas Grigelionis wrote:
> > >>> Thanks, Jaikiran. Would you be willing to restart the release
> > >>> process for IvyDE now? Gintas On Fri, 27 Jul 2018 at 15:43,
> > Jaikiran
> > >>> Pai  wrote:
> > >>>> On 25/07/18 6:45 PM, Jaikiran Pai wrote:
> > >>>>> Almost all jobs that I know of have been taken care of now.
> > >>>>> There's a "Ivy-tests-Windows" job which is pending, but for that
> > I
> > >>>>> need some help from infra team. I am discussing it with them
> > >>>>> separately and I expect it to be resolved soon. I'll fix that job
> > tomorrow.
> > >>>> This is now done too. -Jaikiran
> > >>>> --
> > -
> > >>>> -- 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
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: IVYDE-379

[Gintautas Grigelionis]

Thanks, Jan, most locations look good, though Ivy still refers to
Subversion. I'll check again tomorrow.

Gintas

On Wed, 8 Aug 2018 at 12:57, Jan Matèrne (jhm)  wrote:

> Changed in SVN.
> 'Our' locations are now:
>
>   https://ant.apache.org/doap_Ant.rdf
>   https://ant.apache.org/antlibs/antunit/doap_AntUnit.rdf
> 
>   
> https://ant.apache.org/antlibs/compress/doap_CompressAntlib.rdf
>   https://ant.apache.org/antlibs/dotnet/doap_DotnetAntlib.rdf
> 
>   https://ant.apache.org/antlibs/props/doap_PropsAntlib.rdf
> 
>   https://ant.apache.org/antlibs/vss/doap_VSSAntlib.rdf
> 
>   
> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob_plain;f=doap_Ivy.rdf;hb=HEAD
> 
>   
> https://git-wip-us.apache.org/repos/asf?p=ant-ivyde.git;a=blob_plain;f=doap_IvyDE.rdf;hb=HEAD
> 
>
> Jan
>
> > -Ursprüngliche Nachricht-
> > Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> > Gesendet: Dienstag, 7. August 2018 19:46
> > An: Ant Developers List
> > Betreff: IVYDE-379
> >
> > https://projects.apache.org still refers to DOAP files of Ant project
> > in Subversion.
> > Any idea of how
> > https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/
> > projects.xml
> > is changed?
> >
> > Gintas
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

IVYDE-379

[Gintautas Grigelionis]

https://projects.apache.org still refers to DOAP files of Ant project in
Subversion.
Any idea of how
https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml
is changed?

Gintas

Re: Jenkins-Builds failing

[Gintautas Grigelionis]

There's one more Jenkins job failing due to outdated Ant, Ivy Check (
https://builds.apache.org/view/All/job/Ivy-check/).
Could you please check it, Jaikiran?

Thanks, Gintas

On Sun, 29 Jul 2018 at 15:13, Jaikiran Pai  wrote:

> I would like to test/import a few more projects (that Nicolas mentioned
> in one the mails) locally into the latest upstream version of the IDE,
> before starting a release. I have only tested a few so far.
>
> -Jaikiran
>
> On 28/07/18 2:28 PM, Gintautas Grigelionis wrote:
> > Thanks, Jaikiran. Would you be willing to restart the release process
> > for IvyDE now? Gintas On Fri, 27 Jul 2018 at 15:43, Jaikiran Pai
> >  wrote:
> >> On 25/07/18 6:45 PM, Jaikiran Pai wrote:
> >>> Almost all jobs that I know of have been taken care of now. There's
> >>> a "Ivy-tests-Windows" job which is pending, but for that I need some
> >>> help from infra team. I am discussing it with them separately and I
> >>> expect it to be resolved soon. I'll fix that job tomorrow.
> >> This is now done too. -Jaikiran
> >> -
> >> 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
>
>

Linux PR build failures

[Gintautas Grigelionis]

I noticed that Linux PR builds fail quite frequently, unable to pull from
GitHub, something for infra to look into?

Gintas

Re: Jenkins-Builds failing

[Gintautas Grigelionis]

Thanks, Jaikiran. Would you be willing to restart the release process for
IvyDE now?

Gintas

On Fri, 27 Jul 2018 at 15:43, Jaikiran Pai  wrote:

>
> On 25/07/18 6:45 PM, Jaikiran Pai wrote:
> > Almost all jobs that I know of have been taken care of now. There's a
> > "Ivy-tests-Windows" job which is pending, but for that I need some help
> > from infra team. I am discussing it with them separately and I expect it
> > to be resolved soon. I'll fix that job tomorrow.
> This is now done too.
>
> -Jaikiran
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Jenkins-Builds failing

[Gintautas Grigelionis]

Thank you for all attempts, the failure occurs in run-tutorial macro
(forked JVM).
What would be the best way to forwarding Java arguments/system properties?

Gintas

On Tue, 24 Jul 2018 at 09:14, Gintautas Grigelionis 
wrote:

> It must be set as Java parameter, not Ant parameter.
>
> Gintas
>
> On Tue, 24 Jul 2018 at 08:38, Jan Matèrne (jhm)  wrote:
>
>> "Looks like someone called 'hibou' restricted the job to themselves. (See
>> screenshot attached to this ticket)"
>>
>> This was a "run as hibou" configuration.
>>
>> @Nicolas: What was the reason to add that? Is it required?
>>
>>
>> Gavin removed that part and I could add the https.protocols=TLSv1.2
>> parameter.
>> Job restarted.
>>
>>
>> Jan
>>
>>
>> > -Ursprüngliche Nachricht-
>> > Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
>> > Gesendet: Sonntag, 22. Juli 2018 12:54
>> > An: 'Ant Developers List'
>> > Betreff: AW: Jenkins-Builds failing
>> >
>> > Checked by myself that a PMC chair could do (AFAIK).
>> > Opened a ticket
>> > https://issues.apache.org/jira/browse/INFRA-16799
>> >
>> > Jan
>> >
>> > > -Ursprüngliche Nachricht-
>> > > Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
>> > > Gesendet: Sonntag, 22. Juli 2018 10:48
>> > > An: Ant Developers List
>> > > Betreff: Re: Jenkins-Builds failing
>> > >
>> > > Should we ask infra if nobody else knows about Jenkins authorization?
>> > >
>> > > Gintas
>> > >
>> > > On Fri, 20 Jul 2018 at 11:26, Jan Matèrne (jhm) 
>> > > wrote:
>> > >
>> > > > Neither do I.
>> > > >
>> > > > Jan
>> > > >
>> > > > > -Ursprüngliche Nachricht-
>> > > > > Von: Jaikiran Pai [mailto:jai.forums2...@gmail.com]
>> > > > > Gesendet: Freitag, 20. Juli 2018 10:15
>> > > > > An: dev@ant.apache.org
>> > > > > Betreff: Re: Jenkins-Builds failing
>> > > > >
>> > > > > Now that I checked the job's logs, I think that's true. We had
>> > > > > this issue in Ant too (not really against Maven repos, but HTTPS
>> > > > > hosted Apache infrastructure). I tried setting that property in
>> > > > > the job, but I too don't have the necessary authorization. I
>> > don't
>> > > > > remember if I ever had those permissions or if it's something
>> > that
>> > > > > changed with the recent Jenkins upgrade.
>> > > > >
>> > > > > -Jaikiran
>> > > > >
>> > > > >
>> > > > > On 20/07/18 1:34 PM, Gintautas Grigelionis wrote:
>> > > > > > My hypothesis is that Java 7 must have TLS version forced to
>> > 1.2
>> > > > > > in order to avoid protocol errors when downloading new binaries
>> > > > > > from Maven Central because earlier versions are disabled [1]
>> > > > > > (and TLS 1.0 is the default in Java 7).
>> > > > > >
>> > > > > > Gintas
>> > > > > >
>> > > > > > 1.
>> > > > > > https://blog.pcisecuritystandards.org/are-you-ready-for-30-
>> > june-
>> > > 20
>> > > > > > 18-
>> > > > > s
>> > > > > > ayin-goodbye-to-ssl-early-tls
>> > > > > >
>> > > > > > On Fri, 20 Jul 2018 at 09:31, Jaikiran Pai
>> > > > > > 
>> > > > > wrote:
>> > > > > >
>> > > > > >> Haven't checked the job, but why is this system property
>> > > required
>> > > > > >> to be set?
>> > > > > >>
>> > > > > >> -Jaikiran
>> > > > > >>
>> > > > > >>
>> > > > > >> On 20/07/18 12:51 AM, Gintautas Grigelionis wrote:
>> > > > > >>> I'd like to add a Java option to Ivy builds
>> > > > > >>> -Dhttps.protocols=TLSv1.2
>> > > > > >> but I
>> > > > > >>> get
>> > > > > >>> This job's current authorization strategy does not permit
>> > >

Re: Jenkins-Builds failing

[Gintautas Grigelionis]

It must be set as Java parameter, not Ant parameter.

Gintas

On Tue, 24 Jul 2018 at 08:38, Jan Matèrne (jhm)  wrote:

> "Looks like someone called 'hibou' restricted the job to themselves. (See
> screenshot attached to this ticket)"
>
> This was a "run as hibou" configuration.
>
> @Nicolas: What was the reason to add that? Is it required?
>
>
> Gavin removed that part and I could add the https.protocols=TLSv1.2
> parameter.
> Job restarted.
>
>
> Jan
>
>
> > -Ursprüngliche Nachricht-
> > Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> > Gesendet: Sonntag, 22. Juli 2018 12:54
> > An: 'Ant Developers List'
> > Betreff: AW: Jenkins-Builds failing
> >
> > Checked by myself that a PMC chair could do (AFAIK).
> > Opened a ticket
> > https://issues.apache.org/jira/browse/INFRA-16799
> >
> > Jan
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> > > Gesendet: Sonntag, 22. Juli 2018 10:48
> > > An: Ant Developers List
> > > Betreff: Re: Jenkins-Builds failing
> > >
> > > Should we ask infra if nobody else knows about Jenkins authorization?
> > >
> > > Gintas
> > >
> > > On Fri, 20 Jul 2018 at 11:26, Jan Matèrne (jhm) 
> > > wrote:
> > >
> > > > Neither do I.
> > > >
> > > > Jan
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Jaikiran Pai [mailto:jai.forums2...@gmail.com]
> > > > > Gesendet: Freitag, 20. Juli 2018 10:15
> > > > > An: dev@ant.apache.org
> > > > > Betreff: Re: Jenkins-Builds failing
> > > > >
> > > > > Now that I checked the job's logs, I think that's true. We had
> > > > > this issue in Ant too (not really against Maven repos, but HTTPS
> > > > > hosted Apache infrastructure). I tried setting that property in
> > > > > the job, but I too don't have the necessary authorization. I
> > don't
> > > > > remember if I ever had those permissions or if it's something
> > that
> > > > > changed with the recent Jenkins upgrade.
> > > > >
> > > > > -Jaikiran
> > > > >
> > > > >
> > > > > On 20/07/18 1:34 PM, Gintautas Grigelionis wrote:
> > > > > > My hypothesis is that Java 7 must have TLS version forced to
> > 1.2
> > > > > > in order to avoid protocol errors when downloading new binaries
> > > > > > from Maven Central because earlier versions are disabled [1]
> > > > > > (and TLS 1.0 is the default in Java 7).
> > > > > >
> > > > > > Gintas
> > > > > >
> > > > > > 1.
> > > > > > https://blog.pcisecuritystandards.org/are-you-ready-for-30-
> > june-
> > > 20
> > > > > > 18-
> > > > > s
> > > > > > ayin-goodbye-to-ssl-early-tls
> > > > > >
> > > > > > On Fri, 20 Jul 2018 at 09:31, Jaikiran Pai
> > > > > > 
> > > > > wrote:
> > > > > >
> > > > > >> Haven't checked the job, but why is this system property
> > > required
> > > > > >> to be set?
> > > > > >>
> > > > > >> -Jaikiran
> > > > > >>
> > > > > >>
> > > > > >> On 20/07/18 12:51 AM, Gintautas Grigelionis wrote:
> > > > > >>> I'd like to add a Java option to Ivy builds
> > > > > >>> -Dhttps.protocols=TLSv1.2
> > > > > >> but I
> > > > > >>> get
> > > > > >>> This job's current authorization strategy does not permit
> > > gintas
> > > > > >>> to
> > > > > >> modify
> > > > > >>> the job configuration
> > > > > >>>
> > > > > >>> Gintas
> > > > > >>>
> > > > > >>> On Tue, 3 Jul 2018 at 19:09, Gintautas Grigelionis <
> > > > > >> g.grigelio...@gmail.com>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>> Ant nightly is stuck on archiving for 30 hours now.
> > > > > >>>> It should be escalated, I beli

Ant Unicode

[Gintautas Grigelionis]

I've found out that ant () is a Unicode character from 6.0 (2010)
and a part of Emoji 1.0 as well. I wonder if we could have some good use of
ant in red violet (or, actually, #a81c7d) emoji?

And, while we're at that, how about using Nick King's vectorised Ant logo
[1] (which some good folks converted to SVG and put on Wikimedia [2] --
although we'd need a new version with TM and  in white to use
on the web site). I'd happily open a PR placing the original EPS and
different variants of SVG in the manual.

Gintas

P.S.: Shouldn't we lobby for an ivy character in Unicode? ;-D

[1]
http://mail-archives.apache.org/mod_mbox/ant-dev/200202.mbox/%3c3c7e0526.e1bb9...@remoteapps.com%3E
[2] https://commons.wikimedia.org/wiki/File:Apache-Ant-logo.svg

Re: Jenkins-Builds failing

[Gintautas Grigelionis]

Should we ask infra if nobody else knows about Jenkins authorization?

Gintas

On Fri, 20 Jul 2018 at 11:26, Jan Matèrne (jhm)  wrote:

> Neither do I.
>
> Jan
>
> > -Ursprüngliche Nachricht-
> > Von: Jaikiran Pai [mailto:jai.forums2...@gmail.com]
> > Gesendet: Freitag, 20. Juli 2018 10:15
> > An: dev@ant.apache.org
> > Betreff: Re: Jenkins-Builds failing
> >
> > Now that I checked the job's logs, I think that's true. We had this
> > issue in Ant too (not really against Maven repos, but HTTPS hosted
> > Apache infrastructure). I tried setting that property in the job, but I
> > too don't have the necessary authorization. I don't remember if I ever
> > had those permissions or if it's something that changed with the recent
> > Jenkins upgrade.
> >
> > -Jaikiran
> >
> >
> > On 20/07/18 1:34 PM, Gintautas Grigelionis wrote:
> > > My hypothesis is that Java 7 must have TLS version forced to 1.2 in
> > > order to avoid protocol errors when downloading new binaries from
> > > Maven Central because earlier versions are disabled [1] (and TLS 1.0
> > > is the default in Java 7).
> > >
> > > Gintas
> > >
> > > 1.
> > > https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-
> > s
> > > ayin-goodbye-to-ssl-early-tls
> > >
> > > On Fri, 20 Jul 2018 at 09:31, Jaikiran Pai 
> > wrote:
> > >
> > >> Haven't checked the job, but why is this system property required to
> > >> be set?
> > >>
> > >> -Jaikiran
> > >>
> > >>
> > >> On 20/07/18 12:51 AM, Gintautas Grigelionis wrote:
> > >>> I'd like to add a Java option to Ivy builds
> > >>> -Dhttps.protocols=TLSv1.2
> > >> but I
> > >>> get
> > >>> This job's current authorization strategy does not permit gintas to
> > >> modify
> > >>> the job configuration
> > >>>
> > >>> Gintas
> > >>>
> > >>> On Tue, 3 Jul 2018 at 19:09, Gintautas Grigelionis <
> > >> g.grigelio...@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> Ant nightly is stuck on archiving for 30 hours now.
> > >>>> It should be escalated, I believe that could have something to do
> > >>>> with
> > >> the
> > >>>> last upgrade of Jenkins.
> > >>>>
> > >>>> Gintas
> > >>>>
> > >>>> On Mon, 2 Jul 2018 at 14:18, Jan Matèrne  wrote:
> > >>>>
> > >>>>> Several of our Jenkins builds are failing:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> IvyDE:
> > >>>>>
> > >>>>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/
> > >>>>>
> > >>>>>
> > https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/cons
> > >>>>> ole
> > >>>>>
> > >>>>> Can't get
> > >>>>>
> > >>>>>
> > >> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-
> > 2
> > >> 0130208
> > >>>>> 151217/wtp4x-R-3.4.2-20130208151217.zip
> > >>>>> <
> > >> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-
> > 2
> > >> 0130208151217/wtp4x-R-3.4.2-20130208151217.zip
> > >>>>> to
> > >>>>>
> > >>>>>
> > >> /home/jenkins/jenkins-slave/workspace/IvyDE/dependencies/wtp4x-R-
> > 3.4.
> > >> 2-20130
> > >>>>> 208151217.zip
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> The source URL gives a 404.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> AntLib - AntUnit
> > >>>>>
> > >>>>> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/
> > >>>>>
> > >>>>>
> > >>>>>
> > >> https://builds.apache.org/view/A/view/Ant/job/AntLib-
> > antunit/lastBuil
> > >> d/conso
> > >>>>> le
> > >>>>>
> > >>>>> [ivy:resolve] 

Re: Jenkins-Builds failing

[Gintautas Grigelionis]

My hypothesis is that Java 7 must have TLS version forced to 1.2 in order
to avoid protocol errors when downloading new binaries from Maven Central
because earlier versions are disabled [1] (and TLS 1.0 is the default in
Java 7).

Gintas

1.
https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls

On Fri, 20 Jul 2018 at 09:31, Jaikiran Pai  wrote:

> Haven't checked the job, but why is this system property required to be
> set?
>
> -Jaikiran
>
>
> On 20/07/18 12:51 AM, Gintautas Grigelionis wrote:
> > I'd like to add a Java option to Ivy builds -Dhttps.protocols=TLSv1.2
> but I
> > get
> > This job's current authorization strategy does not permit gintas to
> modify
> > the job configuration
> >
> > Gintas
> >
> > On Tue, 3 Jul 2018 at 19:09, Gintautas Grigelionis <
> g.grigelio...@gmail.com>
> > wrote:
> >
> >> Ant nightly is stuck on archiving for 30 hours now.
> >> It should be escalated, I believe that could have something to do with
> the
> >> last upgrade of Jenkins.
> >>
> >> Gintas
> >>
> >> On Mon, 2 Jul 2018 at 14:18, Jan Matèrne  wrote:
> >>
> >>> Several of our Jenkins builds are failing:
> >>>
> >>>
> >>>
> >>> IvyDE:
> >>>
> >>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/
> >>>
> >>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/console
> >>>
> >>> Can't get
> >>>
> >>>
> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-20130208
> >>> 151217/wtp4x-R-3.4.2-20130208151217.zip
> >>> <
> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-20130208151217/wtp4x-R-3.4.2-20130208151217.zip
> >
> >>> to
> >>>
> >>>
> /home/jenkins/jenkins-slave/workspace/IvyDE/dependencies/wtp4x-R-3.4.2-20130
> >>> 208151217.zip
> >>>
> >>>
> >>>
> >>> The source URL gives a 404.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> AntLib - AntUnit
> >>>
> >>> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/
> >>>
> >>>
> >>>
> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/lastBuild/conso
> >>> le
> >>>
> >>> [ivy:resolve]   Server access error at url
> >>>
> >>>
> https://repo1.maven.org/maven2/org/apache/ant/ant-testutil/1.8.1/ant-testuti
> >>> l-1.8.1.pom
> >>> <
> https://repo1.maven.org/maven2/org/apache/ant/ant-testutil/1.8.1/ant-testutil-1.8.1.pom
> >
> >>> (javax.net.ssl.SSLException: Received fatal alert:
> >>> protocol_version)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> AntLib - SVN
> >>>
> >>> same problem as for AU
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Ivy
> >>>
> >>> https://builds.apache.org/view/A/view/Ant/job/Ivy/
> >>>
> >>> https://builds.apache.org/view/A/view/Ant/job/Ivy/lastBuild/console
> >>>
> >>> same problem as for AU
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Ant Nightly
> >>>
> >>> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/
> >>>
> >>>
> >>>
> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/lastBuild/console
> >>>
> >>> all runs fine, but "Archiving artifacts" requires lt of time …
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Ideas?
> >>>
> >>>
> >>>
> >>> Jan
> >>>
> >>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Jenkins-Builds failing

[Gintautas Grigelionis]

I'd like to add a Java option to Ivy builds -Dhttps.protocols=TLSv1.2 but I
get
This job's current authorization strategy does not permit gintas to modify
the job configuration

Gintas

On Tue, 3 Jul 2018 at 19:09, Gintautas Grigelionis 
wrote:

> Ant nightly is stuck on archiving for 30 hours now.
> It should be escalated, I believe that could have something to do with the
> last upgrade of Jenkins.
>
> Gintas
>
> On Mon, 2 Jul 2018 at 14:18, Jan Matèrne  wrote:
>
>> Several of our Jenkins builds are failing:
>>
>>
>>
>> IvyDE:
>>
>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/
>>
>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/console
>>
>> Can't get
>>
>> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-20130208
>> 151217/wtp4x-R-3.4.2-20130208151217.zip
>> <http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-20130208151217/wtp4x-R-3.4.2-20130208151217.zip>
>> to
>>
>> /home/jenkins/jenkins-slave/workspace/IvyDE/dependencies/wtp4x-R-3.4.2-20130
>> 208151217.zip
>>
>>
>>
>> The source URL gives a 404.
>>
>>
>>
>>
>>
>> AntLib - AntUnit
>>
>> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/
>>
>>
>> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/lastBuild/conso
>> le
>>
>> [ivy:resolve]   Server access error at url
>>
>> https://repo1.maven.org/maven2/org/apache/ant/ant-testutil/1.8.1/ant-testuti
>> l-1.8.1.pom
>> <https://repo1.maven.org/maven2/org/apache/ant/ant-testutil/1.8.1/ant-testutil-1.8.1.pom>
>> (javax.net.ssl.SSLException: Received fatal alert:
>> protocol_version)
>>
>>
>>
>>
>>
>> AntLib - SVN
>>
>> same problem as for AU
>>
>>
>>
>>
>>
>> Ivy
>>
>> https://builds.apache.org/view/A/view/Ant/job/Ivy/
>>
>> https://builds.apache.org/view/A/view/Ant/job/Ivy/lastBuild/console
>>
>> same problem as for AU
>>
>>
>>
>>
>>
>> Ant Nightly
>>
>> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/
>>
>>
>> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/lastBuild/console
>>
>> all runs fine, but "Archiving artifacts" requires lt of time …
>>
>>
>>
>>
>>
>> Ideas?
>>
>>
>>
>> Jan
>>
>>

Re: Jenkins-Builds failing

[Gintautas Grigelionis]

Ant nightly is stuck on archiving for 30 hours now.
It should be escalated, I believe that could have something to do with the
last upgrade of Jenkins.

Gintas

On Mon, 2 Jul 2018 at 14:18, Jan Matèrne  wrote:

> Several of our Jenkins builds are failing:
>
>
>
> IvyDE:
>
> https://builds.apache.org/view/A/view/Ant/job/IvyDE/
>
> https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/console
>
> Can't get
>
> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-20130208
> 151217/wtp4x-R-3.4.2-20130208151217.zip
> 
> to
>
> /home/jenkins/jenkins-slave/workspace/IvyDE/dependencies/wtp4x-R-3.4.2-20130
> 208151217.zip
>
>
>
> The source URL gives a 404.
>
>
>
>
>
> AntLib - AntUnit
>
> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/
>
>
> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/lastBuild/conso
> le
>
> [ivy:resolve]   Server access error at url
>
> https://repo1.maven.org/maven2/org/apache/ant/ant-testutil/1.8.1/ant-testuti
> l-1.8.1.pom
> 
> (javax.net.ssl.SSLException: Received fatal alert:
> protocol_version)
>
>
>
>
>
> AntLib - SVN
>
> same problem as for AU
>
>
>
>
>
> Ivy
>
> https://builds.apache.org/view/A/view/Ant/job/Ivy/
>
> https://builds.apache.org/view/A/view/Ant/job/Ivy/lastBuild/console
>
> same problem as for AU
>
>
>
>
>
> Ant Nightly
>
> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/
>
> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/lastBuild/console
>
> all runs fine, but "Archiving artifacts" requires lt of time …
>
>
>
>
>
> Ideas?
>
>
>
> Jan
>
>

Re: ant task mail fails on jdk10

[Gintautas Grigelionis]

libraries.properties for Ant 1.10.x specify javax.mail 1.6.1 which pulls in
activation 1.1

Gintas

On Tue, 3 Jul 2018 at 08:19, Jan Matèrne (jhm)  wrote:

> Did my own test:
>
>   password="${mail.pwd}" from="${from}" subject="Testemail">
>  
>  
> Ant-Version:  ${ant.version}
> Java-Version: ${java.version}
>  
>  
>
> Running with Java8 + Java10, and I got my two mails:
>
> Ant-Version:  Apache Ant(TM) version 1.10.1 compiled on
> February
> 2 2017
> Java-Version: 1.8.0_171
>
> respectively
>
> Ant-Version:  Apache Ant(TM) version 1.10.1 compiled on
> February
> 2 2017
> Java-Version: 10.0.1
>
>
> I contrast to my last mail, I could install activation via fetch.xml.
> I had run "ant -f fetch -Ddest=system" before.
>
>
> Jan
>
>
>
> > -Ursprüngliche Nachricht-
> > Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> > Gesendet: Dienstag, 3. Juli 2018 07:43
> > An: 'Ant Developers List'
> > Betreff: AW: ant task mail fails on jdk10
> >
> > We already have something:
> > mail: "This task may depend on external libraries that are not included
> > in the Ant distribution. See Library Dependencies for more
> > information."
> > dependencies:
> > "mail.jar Mail task with Mime encoding, and the MimeMail task
> > http://www.oracle.com/technetwork/java/index-138643.html
> >  activation.jar   Mail task with Mime encoding, and the MimeMail task
> > http://www.oracle.com/technetwork/java/javase/jaf-135115.html;
> >
> > mail.jar could be downloaded via "ant -f fetch.xml javamail", but
> > activation has to be installed.
> >
> >
> > So what changed with Java10?
> >
> >
> > Jan
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Stefan Bodewig [mailto:bode...@apache.org]
> > > Gesendet: Montag, 2. Juli 2018 18:00
> > > An: dev@ant.apache.org; Simon IJskes - QCG
> > > Betreff: Re: ant task mail fails on jdk10
> > >
> > > Thank you, Simon
> > >
> > > On 2018-07-02, Simon IJskes - QCG wrote:
> > >
> > > > As bugzilla is unreachable for now:
> > >
> > > > 
> > > >  > > > subject="Testemail"  >
> > > > 
> > > > 
> > > > 
> > >
> > > > $ JAVA_HOME=/usr/lib/jvm/java-8-oracle/
> > > > ~/opt/apache-ant-1.10.4/bin/ant _testmail
> > >
> > > > runs ok.
> > >
> > > > _testmail:
> > > >  [mail] Sending email: Testemail
> > > >  [mail] Sent email with 0 attachments
> > >
> > >
> > > > $ JAVA_HOME=/usr/lib/jvm/java-10-oracle/
> > > > ~/opt/apache-ant-1.10.4/bin/ant _testmail
> > >
> > > > _testmail:
> > > >  [mail] Failed to send email: javax.activation.DataHandler
> > >
> > > JAF has been removed from Java 10, so now you need to provide its
> > > replacement https://github.com/javaee/activation when starting Ant.
> > >
> > > I don't really think we need to change anything inside of Ant but
> > > should document the fact and likely add something to the FAQ in
> > > addition to the mail task's manual page.
> > >
> > > 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: Testing IvyDE

[Gintautas Grigelionis]

On Sun, 1 Jul 2018 at 21:30, Jan Matèrne (jhm)  wrote:

> > It looks like Ant nightly is stuck (possibly due to plugin update in
> > Jenkins) and it's blocking all other builds.
> >
> > Gintas
>
> I can't do it myself so I'll ask for killing the job.
>
> Jan
>

Ant nightly aborted, now IvyDE is stuck near artifact archiving...
Besides, IvyDE build could not find WTP 3.4.2, and the archive page at
http://archive.eclipse.org/webtools/downloads/
seems to be broken. Strangely, the patch drop
http://download.eclipse.org/webtools/patches/drops/R3.4.2/P-3.4.2-20130826221819/
is available...

Gintas

Re: Testing IvyDE

[Gintautas Grigelionis]

It looks like Ant nightly is stuck (possibly due to plugin update in
Jenkins) and it's blocking all other builds.

Gintas

Re: Testing IvyDE

[Gintautas Grigelionis]

On Sun, 1 Jul 2018 at 15:05, Nicolas Lalevée 
wrote:

> I have found the issue and pushed a fix.
>
> I am then worried that the master is not well tested nor used after the
> big cleanups. Two big bugs were raised during the release process.
>
> So I suggest we do a little testing now of the master.
>
> To help with that, there is a folder in the IvyDE project which contains
> projects ready to be imported into Eclipse, they are samples of many
> different configurations which should be supported:
> https://github.com/apache/ant-ivyde/tree/master/test <
> https://github.com/apache/ant-ivyde/tree/master/test>
> And the last build can be installed from an update site built there:
> https://builds.apache.org/view/A/view/Ant/job/IvyDE-updatesite/ <
> https://builds.apache.org/view/A/view/Ant/job/IvyDE-updatesite/>
>
> Nicolas
>

The nightly build is still pending...

Gintas

Re: [Bug 33169] KIndly update the date feature

[Gintautas Grigelionis]

On Thu, 28 Jun 2018 at 11:43, Jan Matèrne (jhm)  wrote:

> > > Just curious about our bugzilla infrastructure - do random users get
> > > to change the content of these bugs, even if they aren't the ones who
> > > reported the issue?
> >
> > Yes.
> >
> > Back when Bugzilla was introduced the developers and admins falsely
> > assumed only sensible people would be using the tool.
> >
> > Stefan
>
> Do you know if JIRA is more secure?
> Also against spam attacks?
> If yes, we could about thinking to migrate ...
>
> Jan
>

Jira has roles [1]; Bugzilla has groups, but I cannot figure out whether
they could be as flexible or easy to administrate.

Gintas

[1]
https://confluence.atlassian.com/jirakb/jira-permissions-made-simple-717062767.html

Re: [VOTE] Release 2.3.0-rc1 of Apache IvyDE

[Gintautas Grigelionis]

Who's Ross? :-S

For me, "reload" is resulting in an empty container, and the contents are
updated by subsequent "refresh".
Codewise, "reload" does

container.reloadSettings()

which is the same as

state.setIvySettingsLastModified(-1);
launchResolve(false, null);

(and the last line is the same as "resolve") vs

container.launchResolve(true, null);

I don't think that code was modified a lot; AFAICS, there are two changes
made in code of IvyClasspathContainerImpl:
first, generics in Comparator in setClassPath() entries; then, path was
made final.
Before that, there's a javadoc fix and a fix for IVYDE-361.

If there's something suspicious, then it's path being final.

Gintas

On Wed, 27 Jun 2018 at 18:43, Nicolas Lalevée 
wrote:

> Everything looks good apart from the bug Ross reported which I have been
> able to reproduce. And it seems pretty consistent, not very random. And I
> see no error in Eclipse’s log.
>
> I have been able to reproduce it with the Eclipse version:
> Version: Neon.3 Release (4.6.3)
> Build id: 20170314-1500
>
> I am also using java 10, which is a bit tricky to make it run smoothly due
> to the modules thing. Maybe it is related.
>
> And the project I tried to build in Eclipse is the Ivy project, which is
> about just an ivy.xml and a version.properties.
>
> I know that the IvyDE code which is triggering the update of the classpath
> is tricky, it is quite sensible, partly due to the non trivial Eclipse
> APIs. Maybe with the last « cleanup » the resolve process has been messed
> up, and somehow it still work in the refresh case.
>
> Since there is a work around (hitting refresh after resolve) and it is an
> RC, we could ship it like that and fix it later. But due to the automatic
> update via the update site, I bet most users will update even if it is an
> RC.
> So I am not sure what I should vote.
>
> So I vote -0 for me for now.
>
> Nicolas
>
> > Le 25 juin 2018 à 07:52, Jaikiran Pai  a
> écrit :
> >
> > I'm initiating a newer vote mail for 2.3.0-rc1 release of Apache IvyDE
> project. This addresses the blocker issue that Nicolas identified, the last
> time a vote was initiated for this version.
> >
> > The newly updated tag is here
> https://git-wip-us.apache.org/repos/asf?p=ant-ivyde.git;a=tag;h=refs/tags/2.3.0-rc1
> with sha1 3581a61ec159ede16005f36e58e5e258d32090fa
> >
> > You can download the distribution from this URL:
> https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/ at rev 27709
> >
> > The Eclipse p2 repository is here:
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806251008-RELEASE/
> at rev 27707
> >
> > The 2.3.0-rc1 release of IvyDE consists of the following changes:
> >
> > * FIX: xml bomb in workspace causes hang in Ivy code during Search or
> Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354)
> > * FIX: Deadlock in classpath container (
> https://issues.apache.org/jira/browse/IVYDE-361)
> > * FIX: Typo in IvyResolveJob (
> https://issues.apache.org/jira/browse/IVYDE-362)
> > * FIX: User-selected configurations not checked in the viewer (
> https://issues.apache.org/jira/browse/IVYDE-378)
> > * FIX: Fix ClassCastException (
> https://issues.apache.org/jira/browse/IVYDE-386)
> > * FIX: Fix the issue where the IvyDE preferences couldn't be saved (
> https://issues.apache.org/jira/browse/IVYDE-388)
> >
> > * NEW: Support for OSGi 'Bundle-Classpath' directive
> > * NEW: Basic support for the workspace resolver to find OSGi bundles
> managed by Ivy in the workspace
> > * NEW: Support for storing credentials securely
> >
> >
> > Do you vote for the release of these binaries?
> >
> > -Jaikiran
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
>
>

Re: [VOTE] Release 2.3.0-rc1 of Apache IvyDE

[Gintautas Grigelionis]

+1

Gintas

P.S. Disappearing Ivy container seems to be default Eclipse behaviour in
Oxygen where the filtering of
empty library containers is on in Package Explorer. The filter was first
introduced in Neon

[1]
https://www.eclipse.org/eclipse/news/4.6/M7/#hide-empty-library-containers-project-explorer

On Mon, 25 Jun 2018 at 07:53, Jaikiran Pai  wrote:

> I'm initiating a newer vote mail for 2.3.0-rc1 release of Apache IvyDE
> project. This addresses the blocker issue that Nicolas identified, the
> last time a vote was initiated for this version.
>
> The newly updated tag is here
>
> https://git-wip-us.apache.org/repos/asf?p=ant-ivyde.git;a=tag;h=refs/tags/2.3.0-rc1
> with sha1 3581a61ec159ede16005f36e58e5e258d32090fa
>
> You can download the distribution from this URL:
> https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/ at rev 27709
>
> The Eclipse p2 repository is here:
>
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806251008-RELEASE/
> at rev 27707
>
> The 2.3.0-rc1 release of IvyDE consists of the following changes:
>
> * FIX: xml bomb in workspace causes hang in Ivy code during Search or
> Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354)
> * FIX: Deadlock in classpath container
> (https://issues.apache.org/jira/browse/IVYDE-361)
> * FIX: Typo in IvyResolveJob
> (https://issues.apache.org/jira/browse/IVYDE-362)
> * FIX: User-selected configurations not checked in the viewer
> (https://issues.apache.org/jira/browse/IVYDE-378)
> * FIX: Fix ClassCastException
> (https://issues.apache.org/jira/browse/IVYDE-386)
> * FIX: Fix the issue where the IvyDE preferences couldn't be saved
> (https://issues.apache.org/jira/browse/IVYDE-388)
>
> * NEW: Support for OSGi 'Bundle-Classpath' directive
> * NEW: Basic support for the workspace resolver to find OSGi bundles
> managed by Ivy in the workspace
> * NEW: Support for storing credentials securely
>
>
> Do you vote for the release of these binaries?
>
> -Jaikiran
>

Re: [VOTE] Release AntUnit 1.4 based on RC3

[Gintautas Grigelionis]

After looking at build rules, I realised that full support for JUnit 4
would require all antlibs
(and AntUnit in particular) to depend on Ant 1.9.5; however, the rules are
set in antlibs-common,
so maybe It's worth a separate discussion.

Gintas

On Fri, 22 Jun 2018 at 09:00, Maarten Coene 
wrote:

> +1
> Maarten
>
>   Van: Stefan Bodewig 
>  Aan: dev@ant.apache.org
>  Verzonden: vrijdag 22 juni 7:32 2018
>  Onderwerp: [VOTE] Release AntUnit 1.4 based on RC3
>
> Hi all
>
> this is the third RC for AntUnit 1.4 with the problems Gintas identified
> fixed.
>
> tag:
>
> https://git-wip-us.apache.org/repos/asf?p=ant-antlibs-antunit.git;a=tag;h=fb7a42470f8a6de50686f37519e27a068c576606
>
> tarballs:
> https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/
> svn revision 27641
>
> Maven artifacts:
>
> https://repository.apache.org/content/repositories/orgapacheant-1033/org/apache/ant/ant-antunit/1.4/
>
> vote will be open for 72 hours and not close before 2018-06-25 05:30 UTC.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>
>
>

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

[Gintautas Grigelionis]

On Fri, 22 Jun 2018 at 09:45, Stefan Bodewig  wrote:

> On 2018-06-22, Gintautas Grigelionis wrote:
>
> > Well, setup-for-junit-tests states that JUnit is not available and
> > quits.
>
> So it lacks a dependency on resolve.
>
> > I'd like to understand why setup targets are there at all.
>
> They predate resolve by far. The initial build system for Antlibs didnt
> use Ivy at all but expected manual configuration and the setup targets
> ensured everything was there. When Ivy was added later (by Jan?) he
> probably missed to adapt a few places - like setup-for-junit-tests.
>

Actually, the targets are written in a way that checks explicitly for JUnit
3.
Should they be rewritten to check for JUnit 4, the baseline has to be moved
to
all the way Ant 1.9.5 because of BuildFileRule being first available in
that version.

Then, the order of compile-tests target dependencies must be changed so
that setup-for-junit-tests comes after antlib (which does resolve,
therefore explicit
resolve becomes redundant) and uses classpaths defined by resolve to
check for JUnit.

Gintas

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

[Gintautas Grigelionis]

On Fri, 22 Jun 2018 at 07:22, Stefan Bodewig  wrote:

> On 2018-06-21, Gintautas Grigelionis wrote:
> > P.S. I'm struggling to understand why "ant test" of antlibs bails
> > because "compile-tests" goes "setup-for-junit-tests, antlib, resolve"
> > rather than doing "resolve" first and using the retrieved
> > dependencies?
>
> antlib depends on compile which depends on resolve - so resolve is
> supposed to be run long before any of the other targets,
>
> Not sure what "bails" in your case (it doesn't for me) but maybe we are
> missing a dependency somewhere in the graph.
>

Well, setup-for-junit-tests states that JUnit is not available and quits.
I'd like to
understand why setup targets are there at all.

Gintas

Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

[Gintautas Grigelionis]

On Thu, 21 Jun 2018 at 11:17, Stefan Bodewig  wrote:

> On 2018-06-21, Gintautas Grigelionis wrote:
>
> > POM template has inconsistent Ant versions, 1.7.1 in compile scope and
> > 1.8.1 in provided scope.
>
> True.
>
> This happened in c3f8655 which updated the dependencies to 1.8.1 because
> one of the unit tests used a method of ant-testutil that hasn't been
> present in Ant 1.7.
>
> We could fix the test or explicitly document Ant 1.8.x as new
> requirement - which really doesn't exist except for the tests.
>
> The upgrade would be a breaking change but I don't expect it would break
> anything in real life. Some of the other antlibs may require Ant 1.7 but
> the only other one I'd expect to get new releases (Compress) is at 1.8
> already, so upgrading the dependency probably doesn't do any harm to
> them.
>

I decide to look at antlib builds, and I wonder why common/build.properties
contain

javac.-source=1.2
javac.-target=1.2

Shouldn't antlibs be baselined to something more recent? If I remember it
correctly,
Ant 1.8 was meant for Java 1.4, so I would suggest either that or the
oldest maintained
version of Ant, i.e. 1.9, corresponding to Java 5.

Gintas

P.S. I'm struggling to understand why "ant test" of antlibs bails because
"compile-tests" goes "setup-for-junit-tests, antlib, resolve" rather than
doing "resolve" first
and using the retrieved dependencies?

Re: [VOTE] Release AntUnit 1.4 Based on RC2

[Gintautas Grigelionis]

POM template has inconsistent Ant versions, 1.7.1 in compile scope and
1.8.1 in provided scope.

Gintas

On Thu, 21 Jun 2018 at 08:57, Stefan Bodewig  wrote:

> Hi all
>
> this is the second RC for AntUnit 1.4 with the problems Jaikiran
> identified fixed.
>
> tag:
>
> https://git-wip-us.apache.org/repos/asf?p=ant-antlibs-antunit.git;a=tag;h=21c61e523c767bd1433544596478e9af7ce98858
>
> tarballs:
>  https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/
>  svn revision 27611
>
> Maven artifacts:
>
> https://repository.apache.org/content/repositories/orgapacheant-1032/org/apache/ant/ant-antunit/1.4/
>
> vote will be open for 72 hours and not close before 2018-06-24 07:00 UTC.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: .git(modules|attributes|ignore) files in source dists?

[Gintautas Grigelionis]

Please see [1]

Gintas

[1] https://feeding.cloud.geek.nz/posts/excluding-files-from-git-archive/

On Wed, 20 Jun 2018 at 05:43, Jaikiran Pai  wrote:

> I don't have a preference on whether or not to include the SCM related
> files, but at least in the recent IvyDE release process, I setup the
> build to use "git archive" command to generate these source tar/zip
> packages[1]. The documentation of git archive doesn't explicitly state
> anything about files like .gitignore being packaged into the archive. So
> I looked into the generated source tar and those are indeed present.
>
> I actually can't think of a reason why we should exclude these files.
>
> [1] https://github.com/apache/ant-ivyde/blob/master/build.xml
>
> -Jaikiran
>
>
> On 19/06/18 8:12 PM, Stefan Bodewig wrote:
> > Hi all
> >
> > when I set up the build for AntUnit I realized the source tarball didn't
> > contain the git config files that are part of the source repo and
> > changed the antlibs-common module to include them (they are part of
> > Ant's defaultexcludes for DirectoryScanner).
> >
> > Later it dawned on me this may not be a good idea as we don't include
> > anything else that is SCM related either, so maybe not including the
> > files has been the correct choice all along.
> >
> > Any opinions on whether we should include or exclude them?
> >
> > 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
>
>

Re: [2/2] ant git commit: Bz 22370: followlinks attribute

[Gintautas Grigelionis]

More symlinks related issues (see [5] ... below)

Gintas

On Wed, 6 Jun 2018 at 21:30, Gintautas Grigelionis 
wrote:

>
> There are other issues, like support for symlinks in archives (JRE does
> not support them in
> zip files [1], rather one -- like Gradle [2] -- must use Commons
> Compress). Actually, there are a couple
> of old Bugzilla issues addressing symlinks [3, 4] :-).
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8184973
> [2] https://github.com/paleozogt/symzip-plugin
>
[3] https://bz.apache.org/bugzilla/show_bug.cgi?id=14320
>
[4] https://bz.apache.org/bugzilla/show_bug.cgi?id=15031
> [5] https://bz.apache.org/bugzilla/show_bug.cgi?id=15244
>
[6] https://bz.apache.org/bugzilla/show_bug.cgi?id=19252
>
[7] https://bz.apache.org/bugzilla/show_bug.cgi?id=40059
> [8] https://bz.apache.org/bugzilla/show_bug.cgi?id=56700
>

Re: thinking about new releases

[Gintautas Grigelionis]

Me too.

Gintas

On Mon, 18 Jun 2018 at 11:19, Jaikiran Pai  wrote:

> I am willing to test and vote on an AntUnit release.
>
> -Jaikiran
>
>
> On 18/06/18 12:45 PM, Stefan Bodewig wrote:
> > OK, then I'll revert the antunit change so the source release ships with
> > a released version of it and prepare release candidates sometime the
> > coming days.
> >
> > The alternative would be to cut an AntUnit release first which also
> > works for me if enough people are willing to vote on that.
> >
> > 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
>
>

Re: [VOTE] Apache IvyDE 2.3.0-rc1 release

[Gintautas Grigelionis]

I tested the plugin with Ivy 2.5.0 RC on Mars, Neon and Oxygen (install,
activate, resolve/reload settings/refresh).

+1

Gintas

P.S. I noticed another issue which is difficult to reproduce: sometimes,
properties defined in Ivy settings
for e.g. parameterizing revisions in ivy.xml become unavailable when
starting a resolve, which then fails.
It seems to require a certain combination of reload
settings/resolve/refresh, though.

Den sön 17 juni 2018 kl 08:45 skrev Jaikiran Pai :

> This is a newer vote mail that I'm initiating for the 2.3.0-rc1 release
> of IvyDE.
>
> The newly updated tag is here
>
> https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=commit;h=refs/tags/2.3.0-rc1
>
> You can download the distribution from this URL:
> https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/
>
> The Eclipse p2 repository is here:
>
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806171016-RELEASE/
>
> The 2.3.0-rc1 release of IvyDE consists of the following changes:
>
> * FIX: xml bomb in workspace causes hang in Ivy code during Search or
> Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354)
> * FIX: Deadlock in classpath container
> (https://issues.apache.org/jira/browse/IVYDE-361)
> * FIX: Typo in IvyResolveJob
> (https://issues.apache.org/jira/browse/IVYDE-362)
> * FIX: User-selected configurations not checked in the viewer
> (https://issues.apache.org/jira/browse/IVYDE-378)
> * FIX: Fix ClassCastException
> (https://issues.apache.org/jira/browse/IVYDE-386)
>
> * NEW: Support for OSGi 'Bundle-Classpath' directive
> * NEW: Basic support for the workspace resolver to find OSGi bundles
> managed by Ivy in the workspace
> * NEW: Support for storing credentials securely
>
>
> Do you vote for the release of these binaries?
>
>
> -Jaikiran
>

Re: Java modules as Ant resources

[Gintautas Grigelionis]

Den lör 16 juni 2018 kl 17:47 skrev Stefan Bodewig :

> On 2018-06-16, Gintautas Grigelionis wrote:
>
> > if services would become a new mechanism for adding tasks, modules
> > would be of help by providing an API to discover them.
>
> Which may be a bit more tricky than it looks as currently tasks don't
> provide metadata about themselves (tag name, namespace uri) as this is
> handled by the surounding concepts like the antlib task.
>

Namespace is usually derived from package name and can be derived from
module name.
Tag name can be derived from service name, and it looks like provider
method [1] could be used as a mechanism for aliasing.

> Since modules are a jar with a twist, it seems that they could be
> > abstracted as resources if one would like to expose what's happening
> > under the hood/bonnet.
>
> The term resource might be overloaded and mean different things to you
> and me. In Ant terms a module would be a ResourceCollection, probably.
>

I see. Thanks for correction.


> > The question was more about whether that exposure would be useful (so
> > that there could be ModuleSets, etc).
>
> Something like a ZipGroupFileset?
>

Exactly.

Gintas

[1]
https://docs.oracle.com/javase/9/docs/api/java/util/ServiceLoader.html#developing-service-providers

Re: thinking about new releases

[Gintautas Grigelionis]

Den lör 16 juni 2018 kl 18:08 skrev Stefan Bodewig :

> Hi all
>
> given https://dev.snyk.io/research/zip-slip-vulnerability lists Ant
> 1.9.12 as a release fixing a security problem it might be a good idea to
> actually release 1.9.12 :-)
>
> AFAICS there is no unfinished work in either branch, but I may be
> wrong. I am aware there ar enhancement requests around javadoc that may
> be worth waiting for for 1.10.x. Is anybody else planning to do
> something that should be finished before creating release candidates?
>

I assume that you're referring to [1] and [2].
I merely documented the new switches of javadoc in Java 9+, but that's all.
+1 to release 1.9.12 and 1.10.4

Gintas

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=62424
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=62441

Re: [2/2] ant git commit: Bz 22370: followlinks attribute

[Gintautas Grigelionis]

Den lör 16 juni 2018 kl 17:29 skrev Stefan Bodewig :

> On 2018-06-16, Gintautas Grigelionis wrote:
>
> > 2018-06-16 15:42 GMT+02:00 Stefan Bodewig :
>
> >> On 2018-06-06, Gintautas Grigelionis wrote:
>
> >>> 2018-06-06 14:31 GMT+02:00 Stefan Bodewig :
>
> >>>> Would the symlink be included in DirectoryScanner's "included files"
> or
> >>>> "included directories"? What will  do to a symlink that is
> >>>> included but not followed.
>
> >>> "Files or directories" dichotomy might be a straitjacket, but symlinks
> >> can
> >>> be fitted into it depending on what their target is.
>
> >> DirectoryScanner's interface provides you with files and directories and
> >> as it stands these File objects may actually by symlinks and the
> >> implicit expectation is that whoever uses them follows the links and in
> >> the end works on the target.
>
> > If things work as you believe, then it's simple -- FileSets just pass
> > the symlinks to consumers which may or may not check whether File
> > objects are symlinks. In the former case, they might use the new
> > semantics, in the latter case nothing's changed.
>
> In that case - the later - the followsymlinks="false" and
> skipsymlinks="false" would behave the same as followsymlinks="true" for
> those who do not check whether a file is a symlink, correct?
>

Correct.

In case of followsymlinks="false" and skipsymlinks="false" I expect
FileSets or
DirSets to contain symlinks as such; but well-behaved symlink-unaware tasks
would follow the symlinks effectively behaving as if followsymlinks="true"
(the default) with the old semantics.


> >>> I wonder if we can have an interim solution when selectors could use
> >>> proper followsymlinks semantics, but behaviour of DirectoryScanner is
> >>> unchanged?
>
> >> You may give it a try, I'm not sure exactly what you mean.
>
> > I attached a test case to one of my previous e-mails to illustrate
> > what I mean.
>
> The mailing list is configured to not allow attachments.
>

I just included in my reply on 6/6 at 21.30 without describing what it was
:-(
See [1] below.

> One part of it would be symlink support in archives (zip and tar).
>
> To which extent?
>
> When creating archives you may need to decide whether you want to use a
> relative or an absolute path to the target (I must admit I have no idea
> whether nio allows us to know how the target has been specified as
> opposed to just what the target is). When extracting and trying to
> re-create symlinks you may also need to watch out for path traversal
> problems.
>

To the extent where tarfilesets and zipfilesets can make use of symlinks in
the same way as filesets would do.
I am aware of extra complexity with path traversals that may cause loops
etc.

What is your time-frame for this? I've been thinking about cutting Ant
> releases soonish, but this is something for a different thread.
>

This is for the future, I'm quite content with what I could do with
selectors so far
(unless I missed something). I'm looking forward to spend time on symlinks
in other parts of Ant later this summer.

Gintas

[1] http://marc.info/?l=ant-dev=152833304425275=2

Re: [2/2] ant git commit: Bz 22370: followlinks attribute

[Gintautas Grigelionis]

2018-06-16 15:42 GMT+02:00 Stefan Bodewig :

> On 2018-06-06, Gintautas Grigelionis wrote:
>
> > 2018-06-06 14:31 GMT+02:00 Stefan Bodewig :
>
> >> I guess here our API breaks down as we only ever deal with files or
> >> directories (outside of the symlink task).
>
> > FileSet documentation should be more explicit about the matter, in
> > particular explaining what "followsymlinks" really means.
>
> You are right. In a Java world where you couldn't really do anything
> with symlinks it has probably been clear implicitly.
>

I would argue that things are less clear implicitly since Java 7, we just
seemed to ignore it.
Too bad change of Java ownership left things unfinished, as in archive
support.


> >> Would the symlink be included in DirectoryScanner's "included files" or
> >> "included directories"? What will  do to a symlink that is
> >> included but not followed.
>
> > "Files or directories" dichotomy might be a straitjacket, but symlinks
> can
> > be fitted into it depending on what their target is.
>
> DirectoryScanner's interface provides you with files and directories and
> as it stands these File objects may actually by symlinks and the
> implicit expectation is that whoever uses them follows the links and in
> the end works on the target.
>

If things work as you believe, then it's simple -- FileSets just pass the
symlinks to consumers
which may or may not check whether File objects are symlinks. In the former
case, they might
use the new semantics, in the latter case nothing's changed.


> We could add new array of symlinks that are not supposed to be followed
> but most tasks would simply ignore them (all tasks that we don't change
> ourselves).
>
> > Dangling symlinks should go into notFollowedSymlinks.  Regarding
> > , included but not followed symlink must be left as is (eg
> > directories are not filtered either).
>
> Probably. There will not be a interpretation that will work for all
> tasks, it will be on a task by task basis. As we can only control the
> tasks that are inside of Ant's codebase, this means we must not change
> the interpretation of the files and directories returned by
> DirectoryScanner at all.
>

That is fine as long the tasks follow symlinks in a FileSet and no
additional structures for keeping them is needed.
If there are tasks that might choke on/skip a File which is a symlink, or,
as is the case with shared libraries on U*X,
add multiple copies of the same file to an archive by following symlinks,
then there's more work to do.


> > I wonder if we can have an interim solution when selectors could use
> > proper followsymlinks semantics, but behaviour of DirectoryScanner is
> > unchanged?
>
> You may give it a try, I'm not sure exactly what you mean.
>

I attached a test case to one of my previous e-mails to illustrate what I
mean.


> >>> Consequently, I expect
> >>> followsymlinks="false" skipsymlinks="false" to behave as
> >>> followsymlinks="false";
>
> >> which would be the same as skipsymlinks="true", right?
>
> > No, under the new proposal that would include the symlinks as symlinks,
> not
> > files or directories.
>
> Where would DirectoryScanner put those included symlinks?
>

Either treat them as files/directories, or put in a separate structure, as
discussed above.

> in the meantime, would it make sense to document what "followsymlinks"
> > means in FileSet and what "followsymlinks" means in selectors that
> > permit the attribute?
>
> We must document that, I'd say :-)
>

That's done.


> > There are other issues, like support for symlinks in archives (JRE does
> not
> > support them in
> > zip files [1], rather one -- like Gradle [2] -- must use Commons
> Compress).
> > Actually, there are a couple
> > of old Bugzilla issues addressing symlinks [3, 4] :-).
>
> I know Commons Compress pretty well ;-) and it doesn't really support
> symlinks in archives either. Given that Ant's zip package is the parent
> of Compress' zip support we should be able to do whatever Commons
> Compress can do here as well. There is a good reason why we don't use
> java.util.zip at all.
>

Hmm, I've got an impression that Commons Compress was more capable;
if Ant can handle zip and tar files with symlinks, then a big part of the
job is done.


> > So, what's the plan?
>
> It's your itch, what is your plan? :-)
>

One part of it would be symlink support in archives (zip and tar).
Another part would be investigating of what DirectoryScanner could do and
what is
expected of FileSet/DirSet, then deciding whether it is possible to fit the
symlinks in there.

Gintas

Re: Java modules as Ant resources

[Gintautas Grigelionis]

2018-06-16 16:04 GMT+02:00 Stefan Bodewig :

> On 2018-06-16, Gintautas Grigelionis wrote:
>
> > 2018-06-16 15:30 GMT+02:00 Stefan Bodewig :
>
> >> On 2018-06-10, Gintautas Grigelionis wrote:
>
> >>> I would treating Java modules as Ant resources help in this scenario?
>
> >> What exactly - beyond using a module as a zipfileset - would you want
> >> to do?
>
> > What about dependency graphs and service discovery? :-) [1]
>
> I'm afraid I'm too slow today. What exactly do you mean when you say you
> want to support Java modules as Ant resources?
>
> An Ant Resource (the class in org.apache.tools.ant.types) is something
> we can read from like a file or an URI and sometimes write to. I don't
> think this is what you have in mind as we can already do that to a Java
> module (which is a jar) and it is not related to dependency graphs or
> service discovery at all.
>

Sorry for not presenting the idea clearly because of time skip: if services
would become
a new mechanism for adding tasks, modules would be of help by providing an
API to discover them.
Since modules are a jar with a twist, it seems that they could be
abstracted as resources
if one would like to expose what's happening under the hood/bonnet.
The question was more about whether that exposure would be useful
(so that there could be ModuleSets, etc).

Gintas

Re: Java modules as Ant resources

[Gintautas Grigelionis]

2018-06-16 15:30 GMT+02:00 Stefan Bodewig :

> On 2018-06-10, Gintautas Grigelionis wrote:
>
> > I would treating Java modules as Ant resources help in this scenario?
>
> What exactly - beyond using a module as a zipfileset - would you want
> to do?
>

What about dependency graphs and service discovery? :-) [1]

Gintas

[1]
https://docs.oracle.com/javase/9/docs/api/java/lang/module/package-summary.html

Re: [VOTE] Apache IvyDE 2.3.0-rc1 release

[Gintautas Grigelionis]

I suppose that deserves a mention in the doc/src/dev...

Gintas

2018-06-14 19:15 GMT+02:00 Nicolas Lalevée :

> Just a quick comment on the mirror url not working. The page is telling
> "The requested file or directory is not on the mirrors. »
> And indeed, the artifacts are not published yet to the final location, the
> release is not accepted yet.
>
> Nicolas
>
>
>
> > Le 14 juin 2018 à 10:19, Gintautas Grigelionis 
> a écrit :
> >
> > 2018-06-14 8:15 GMT+02:00 Stefan Bodewig  bode...@apache.org>>:
> >
> >> On 2018-06-13, Gintautas Grigelionis wrote:
> >>
> >>> org.xml.sax.SAXParseException; systemId:
> >>> http://ant.apache.org/ivy/ivyde/updatesite/p2-mirrors--xml.
> >> cgi?path=ivyde-2.3.0.rc1-201806132023-RELEASE=
> >> se=1=xml;
> >>> lineNumber: 39; columnNumber: 3; Element type "link" lack matching end
> >> tag
> >>> "".
> >>
> >> When I follow the link above, I get an HTML page which is not
> >> well-formed XML, so the messages are to be expected.
> >>
> >> BTW, wherever thos link comes from, it would be good if it used https
> >> rather than http.
> >
> >
> > I followed the link to the source in svn
> >
> > https://svn.apache.org/viewvc/ant/site/ivyde/production/
> updatesite/p2-mirrors--xml.cgi?view=markup <https://svn.apache.org/
> viewvc/ant/site/ivyde/production/updatesite/p2-
> mirrors--xml.cgi?view=markup>
> >
> > #!/bin/sh
> > # Wrapper script around mirrors.cgi script
> > # (we must change to that directory in order for python to pick up the
> > # python includes correctly)
> > cd /www/www.apache.org/dyn/mirrors <http://www.apache.org/dyn/mirrors>
> > /www/www.apache.org/dyn/mirrors/mirrors.cgi <http://www.apache.org/dyn/
> mirrors/mirrors.cgi> $
> >
> > It seems that mirrors.cgi bails out, since it redirects to a (correct
> > HTML-wise, incorrect XML-wise) page containing
> >
> > The requested file or directory is *not* on the mirrors.
> >
> > I wonder whether there is some documentation available on what output
> > the CGI script (and corresponding HTML template?) should produce.
> > Apparently, they do not work as intended since last changes were made
> > 6 years ago.
> >
> > Gintas
>
>

Re: [VOTE] Apache IvyDE 2.3.0-rc1 release

[Gintautas Grigelionis]

2018-06-14 8:15 GMT+02:00 Stefan Bodewig :

> On 2018-06-13, Gintautas Grigelionis wrote:
>
> > org.xml.sax.SAXParseException; systemId:
> > http://ant.apache.org/ivy/ivyde/updatesite/p2-mirrors--xml.
> cgi?path=ivyde-2.3.0.rc1-201806132023-RELEASE=
> se=1=xml;
> > lineNumber: 39; columnNumber: 3; Element type "link" lack matching end
> tag
> > "".
>
> When I follow the link above, I get an HTML page which is not
> well-formed XML, so the messages are to be expected.
>
> BTW, wherever thos link comes from, it would be good if it used https
> rather than http.


I followed the link to the source in svn

https://svn.apache.org/viewvc/ant/site/ivyde/production/updatesite/p2-mirrors--xml.cgi?view=markup

#!/bin/sh
# Wrapper script around mirrors.cgi script
# (we must change to that directory in order for python to pick up the
# python includes correctly)
cd /www/www.apache.org/dyn/mirrors
/www/www.apache.org/dyn/mirrors/mirrors.cgi $

It seems that mirrors.cgi bails out, since it redirects to a (correct
HTML-wise, incorrect XML-wise) page containing

The requested file or directory is *not* on the mirrors.

I wonder whether there is some documentation available on what output
the CGI script (and corresponding HTML template?) should produce.
Apparently, they do not work as intended since last changes were made
6 years ago.

Gintas

Re: [VOTE] Apache IvyDE 2.3.0-rc1 release

[Gintautas Grigelionis]

XML parse errors occur at installation of plugins, I see them for both Ivy
and IvyDE RC.
They seem to be unrelated to the distribution, rather caused by the output
of the CGI script.

Gintas

2018-06-14 5:43 GMT+02:00 Jaikiran Pai :

> Gintas,
>
> When and where do you see these messages? What activity triggers it?
>
> -Jaikiran
>
>
>
> On 14/06/18 12:36 AM, Gintautas Grigelionis wrote:
>
>> I am testing on Oxygen 3.A and seeing errors like
>>
>> org.xml.sax.SAXParseException; systemId:
>> http://ant.apache.org/ivy/ivyde/updatesite/p2-mirrors--xml.
>> cgi?path=ivyde-2.3.0.rc1-201806132023-RELEASE=
>> se=1=xml;
>> lineNumber: 39; columnNumber: 3; Element type "link" lack matching end tag
>> "".
>>
>> Gintas
>>
>> Den ons 13 juni 2018 kl 17:48 skrev Jaikiran Pai <
>> jai.forums2...@gmail.com>:
>>
>> I have built a release candidate 2.3.0-rc1 for Apache IvyDE.
>>>
>>> The tag is here:
>>>
>>> https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=
>>> commit;h=refs/tags/2.3.0-rc1
>>>
>>> You can download the distribution from this URL:
>>> https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1
>>>
>>> The Eclipse p2 repository is there:
>>>
>>> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/
>>> ivyde-2.3.0.rc1-201806132023-RELEASE/
>>>
>>>
>>> This release consists of the following changes:
>>>
>>> * FIX: xml bomb in workspace causes hang in Ivy code during Search or
>>> Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354)
>>> * FIX: Deadlock in classpath container
>>> (https://issues.apache.org/jira/browse/IVYDE-361)
>>> * FIX: Typo in IvyResolveJob
>>> (https://issues.apache.org/jira/browse/IVYDE-362)
>>> * FIX: User-selected configurations not checked in the viewer
>>> (https://issues.apache.org/jira/browse/IVYDE-378)
>>> * FIX: Fix ClassCastException
>>> (https://issues.apache.org/jira/browse/IVYDE-386)
>>>
>>> * NEW: Support for OSGi 'Bundle-Classpath' directive
>>> * NEW: Basic support for the workspace resolver to find OSGi bundles
>>> managed by Ivy in the workspace
>>> * NEW: Support for storing credentials securely
>>>
>>>
>>> Do you vote for the release of these binaries?
>>>
>>> -Jaikiran
>>>
>>>
>>> -
>>> 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: [VOTE] Apache IvyDE 2.3.0-rc1 release

[Gintautas Grigelionis]

On Mars 2, Ivy container does not disappear after "Reload settings", only
empties until "Refresh".
I can give the plugin a spin on Neon tomorrow.

Gintas​

Re: Proposing Apache IvyDE release

[Gintautas Grigelionis]

+1

P.S. What is the status of IVY-1580?

2018-06-13 9:25 GMT+02:00 Jaikiran Pai :

> I'm in the process of releasing Apache IvyDE Eclipse plugin. As I go along
> in the release process, I'm updating the (outdated) build/release process.
> Once the binaries are built, I'll send out a mail for voting on the release.
>
> Following the recent convention of Ivy release, I am planning to call this
> release 2.3.0-rc1.
>
> -Jaikiran
>

Re: Tooling update

[Gintautas Grigelionis]

Nightlies are publishing Checkstyle, SpotBugs and Simian now. AFAICS
there's no plugin for Rat :-(
Next, I think of publishing JaCoCo in Matrix builds. And, perhaps, adding
build status icons to [1]
(what is the status of plans to move the website to Git?)

Gintas

[1] https://ant.apache.org/nightlies.html

2018-06-09 9:08 GMT+02:00 Gintautas Grigelionis :

> Thanks, Stefan. Meanwhile, SpotBugs is reactivated in the nighlies now.
> I noticed, however, that execution order is important: if SpotBugs runs
> before Checkstyle,
> the latter bails out because of ANTLR.
>
> Gintas
>
> 2018-06-08 20:42 GMT+02:00 Stefan Bodewig :
>
>> On 2018-06-08, Gintautas Grigelionis wrote:
>>
>> > Then I was surprised that Dependency Check indicates that the latest
>> > XZ 1.8 has a vulnerability: should we ask them to investigate?
>>
>> That's a false positive.
>>
>> https://www.cvedetails.com/cve/CVE-2015-4035/ applies to the command
>> line tooling and is not related to XZ for Java at all.
>>
>> Stefan
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>
>

Java modules as Ant resources (was: Generate manifest files and add automatic module names for JPMS)

[Gintautas Grigelionis]

2018-02-07 18:25 GMT+01:00 Stefan Bodewig :

>
>> Maybe it will be easier to digest if we start at a higher level of what
>> needs to be changed. I don't think moving classes so we don't have any
>> split packages anymore will be enough.
>>
>> I'd expect we'd need to replace all code that deals with classloaders
>> and replace it with ServiceLoaders if we want to avoid complex startup
>> scenarios for example. Given there is no interface or base class tasks
>> or types must implement this may again force us to change this model. Or
>> maybe I'm just wrong.
>>
>> If we want a broader audience we may want to change the subject :-)
>>
>
I would treating Java modules as Ant resources help in this scenario?

Gintas

Re: javadoc in Java 10+

[Gintautas Grigelionis]

2018-06-09 13:40 GMT+02:00 Gintautas Grigelionis :

> 2018-06-09 12:54 GMT+02:00 Stefan Bodewig :
>
>> On 2018-06-09, Gintautas Grigelionis wrote:
>>
>> > ... needs a -html4 or -html5 option, otherwise the standard doclet
>> emits a
>> > warning. Something for Bugzilla?
>>
>> +1
>>
>> Stefan
>>
>
> Please see https://bz.apache.org/bugzilla/show_bug.cgi?id=6244
>
> Gintas
>

Sorry, that was supposed to be
https://bz.apache.org/bugzilla/show_bug.cgi?id=62441

Gintas

Re: Bz 62324

[Gintautas Grigelionis]

2018-06-09 13:56 GMT+02:00 Jaikiran Pai :

>
> On 09/06/18 5:22 PM, Gintautas Grigelionis wrote:
>
>>
>> Thanks for review, Jaikiran. You're correct, that is the proposed
>> solution,
>> adding a separator
>> (a newline followed by an exception name for clarity -- mind that
>> exception
>> is logged only in debug mode).
>>
> The exception class name would already be part of the stacktrace anyway,
> so IMO, that wouldn't be of much use. Plus the bugzilla
> description/comments state that the thing that's being logged twice is a
> message (is it the message from the exception class?). So even with this
> change, it will still end up being logged twice right?
>

Yes, but the double logging only occurs in debug mode AND when the message
is encapsulated in the exception which is added to the same event.

By the way, is this issue specific to the delete task?
>

I didn't investigate, because it is not easy to figure out if a task
creates an event which contains a message both per se and encapsulated in
an exception.

Gintas

Re: Bz 62324

[Gintautas Grigelionis]

2018-06-09 13:31 GMT+02:00 Jaikiran Pai :

> For easy reference, the bug in discussion is this one
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62324
>
>
> On 09/06/18 12:38 AM, Gintautas Grigelionis wrote:
>
>> Namely, a stack trace of the exception is logged (in debug mode only)
>> without any separator from the preceding message. While it seems that the
>> idea is that the stack trace should be presented as a continuation of the
>> message, IMO it would require a specially formatted message or, well, some
>> separator to be visually consistent.
>>
>> So the question is whether there is better solution than the one currently
>> proposed?
>>
> I saw a commit that was made linking to this bug
> https://github.com/apache/ant/commit/69a3f1c1577ef0cf43d2a93
> 4a109cb0843c5b754. Is that the proposed solution?
>
> I haven't investigated the issue myself, but I can't relate that commit as
> a solution to what's being discussed in that bug. If I understand it
> correctly, the commit seems to be now using the exception class' simple
> name (which by the way can be obtained by getClass().getSimpleName()
> instead of substring substitutions) and printing a newline and the
> exception class simple name and then follows it with the complete
> stacktrace. Earlier, before this commit, it used to print just the
> stacktrace. I don't see how this change would solve what's being discussed
> in that bugzilla.
>
> If this isn't the proposed solution, is there some other place I can read
> up on what's being proposed?
>
>
> -Jaikiran
>

Thanks for review, Jaikiran. You're correct, that is the proposed solution,
adding a separator
(a newline followed by an exception name for clarity -- mind that exception
is logged only in debug mode).

Gintas

Re: javadoc in Java 10+

[Gintautas Grigelionis]

2018-06-09 12:54 GMT+02:00 Stefan Bodewig :

> On 2018-06-09, Gintautas Grigelionis wrote:
>
> > ... needs a -html4 or -html5 option, otherwise the standard doclet emits
> a
> > warning. Something for Bugzilla?
>
> +1
>
> Stefan
>

Please see https://bz.apache.org/bugzilla/show_bug.cgi?id=6244

Gintas