Re: New Confluence Wiki

2019-05-30 Thread 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

2019-03-28 Thread 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)

2018-12-27 Thread 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

2018-12-18 Thread 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

2018-12-02 Thread 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

2018-11-01 Thread 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

2018-10-29 Thread 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

2018-10-28 Thread 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

2018-10-28 Thread 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

2018-10-28 Thread 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

2018-10-28 Thread 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

2018-10-28 Thread 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

2018-10-28 Thread 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

2018-10-28 Thread 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

2018-10-25 Thread 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

2018-10-23 Thread 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

2018-10-22 Thread 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

2018-10-20 Thread 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

2018-10-12 Thread 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

2018-09-29 Thread 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

2018-09-11 Thread 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

2018-09-02 Thread 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

2018-08-29 Thread 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

2018-08-26 Thread 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

2018-08-15 Thread 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

2018-08-15 Thread 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

2018-08-14 Thread 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

2018-08-11 Thread 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

2018-08-08 Thread 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

2018-08-07 Thread 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

2018-08-05 Thread 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

2018-07-30 Thread 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

2018-07-28 Thread 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

2018-07-24 Thread 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

2018-07-24 Thread 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

2018-07-22 Thread 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

2018-07-22 Thread 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

2018-07-20 Thread 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

2018-07-19 Thread 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

2018-07-03 Thread 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

2018-07-03 Thread 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

2018-07-01 Thread 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

2018-07-01 Thread 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

2018-07-01 Thread 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

2018-06-28 Thread 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

2018-06-27 Thread 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

2018-06-27 Thread 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

2018-06-24 Thread Gintautas Grigelionis
+1 (let's save JUnit 4 for the future :-)

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

> 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

2018-06-24 Thread Gintautas Grigelionis
On Sun, 24 Jun 2018 at 14:38, Stefan Bodewig  wrote:

> So if we went to a JUnit 4 only model in antlib-commons with what you
> describe this would require the Antlib that updated to a new
> antlibs-commons version to change all existing JUnit tests?
>

My point was that should some antlib start using JUnit 4-style (annotated)
tests,
then it should depend on ant-testutil 1.9.5 or newer, and, by extension, on
Ant 1.9.x

On top of that, antlib-commons would need adjustments to check for classes
relevant
to JUnit 4; regardless, there are issues with target dependencies like
redundant resolve
or ordering (antlib after setup-for-junit-tests rather than the other way
around).

Gintas


Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

2018-06-24 Thread Gintautas Grigelionis
On Sun, 24 Jun 2018 at 12:43, Stefan Bodewig  wrote:

> On 2018-06-24, Gintautas Grigelionis wrote:
> > 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.
>
> Would moving to JUnit 4 force us to use BuildFileRule? I'm pretty sure
> we've used JUnit4 before 1.9.5 but may be wrong.
>

BuildFileRule is necessary when test case no longer extend BuildFileRule
which extends TestCase which is JUnit 3,

Gintas


Re: [VOTE] Release AntUnit 1.4 based on RC3

2018-06-24 Thread 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

2018-06-24 Thread 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

2018-06-22 Thread 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

2018-06-21 Thread 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

2018-06-21 Thread 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?

2018-06-20 Thread 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

2018-06-20 Thread 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

2018-06-18 Thread 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

2018-06-17 Thread 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

2018-06-16 Thread 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

2018-06-16 Thread 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

2018-06-16 Thread 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

2018-06-16 Thread 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

2018-06-16 Thread 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

2018-06-16 Thread 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

2018-06-16 Thread 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

2018-06-15 Thread Gintautas Grigelionis
That's what I'm working on. Considering that both reload settings and
refresh call launchResolve(), the behaviour is difficult to explain and may
depend on my workspace setup or some such.

There is yet another point (please bear with me) regarding manual
installation instructions. In Eclipse 4 series (which is our baseline) the
"dropins" have a separate directory [1]; I don't think manual copying
directly to features + plugins works anymore and the documentation must be
changed accordingly. I believe Nicolas had to change the build scripts for
that reason, too.

Gintas

[1]
https://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fp2_dropins_format.html

2018-06-16 6:51 GMT+02:00 Jaikiran Pai :

> I tried reproducing this issue but haven't been able to. Either way, given
> the nature of this issue, I personally don't consider it a blocker for this
> release vote to pass. Please do file a JIRA with the relevant details if
> this is reproducible.
>
> -Jaikiran
>
>
>
> On 14/06/18 12:53 AM, Gintautas Grigelionis wrote:
>
>> Another issue with UX on Oxygen: Ivy container icon in Package Explorer
>> seems to disappear after "Reload settings" and reappear after "Refresh".
>>
>> Gintas
>>
>> Den ons 13 juni 2018 kl 21:06 skrev Gintautas Grigelionis <
>> g.grigelio...@gmail.com>:
>>
>> 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

2018-06-14 Thread 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

2018-06-13 Thread 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

2018-06-13 Thread 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: [VOTE] Apache IvyDE 2.3.0-rc1 release

2018-06-13 Thread Gintautas Grigelionis
Another issue with UX on Oxygen: Ivy container icon in Package Explorer
seems to disappear after "Reload settings" and reappear after "Refresh".

Gintas

Den ons 13 juni 2018 kl 21:06 skrev Gintautas Grigelionis <
g.grigelio...@gmail.com>:

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


Re: [VOTE] Apache IvyDE 2.3.0-rc1 release

2018-06-13 Thread Gintautas Grigelionis
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 :

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


Re: Proposing Apache IvyDE release

2018-06-13 Thread 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

2018-06-12 Thread 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)

2018-06-10 Thread 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+

2018-06-10 Thread 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

2018-06-09 Thread 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

2018-06-09 Thread 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+

2018-06-09 Thread 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


javadoc in Java 10+

2018-06-09 Thread Gintautas Grigelionis
... needs a -html4 or -html5 option, otherwise the standard doclet emits a
warning. Something for Bugzilla?

Gintas


Re: Tooling update

2018-06-09 Thread 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
>
>


Bz 62324

2018-06-08 Thread Gintautas Grigelionis
I was advised to solicit opinions regarding the change introduced as a fix
for the abovementioned issue. It concerns how an event that has both a
message and an exception is logged.

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?

Thanks,
Gintas


Tooling update

2018-06-08 Thread Gintautas Grigelionis
I took the liberty to sync QA tools among Ant, Ivy and IvyDE.
A couple of notes: Ant 1.10 having a Java 8 baseline permits migration
from FindBugs to SpotBugs; I decided to it now rather than wait for
dependency issues [1] to be resolved. Then I was surprised that
Dependency Check indicates that the latest XZ 1.8 has a vulnerability:
should we ask them to investigate?

Gintas

[1] https://github.com/spotbugs/spotbugs/issues/655

P.S. Here's the complete Dependency Check report:

[owasp:dependency-check] bsh-core-2.0b4.jar (org.beanshell:bsh-core:2.0b4,
cpe:/a:beanshell_project:beanshell:2.0.b4) : CVE-2016-2510
[owasp:dependency-check] jruby-1.6.8.jar (cpe:/a:jruby:jruby:1.6.8,
org.jruby:jruby:1.6.8) : CVE-2012-5370
[owasp:dependency-check] jython-2.7.0.jar (org.python:jython:2.7.0,
cpe:/a:jython_project:jython:2.7.0) : CVE-2016-4000
[owasp:dependency-check] xz-1.8.jar (cpe:/a:tukaani:xz:1.8,
org.tukaani:xz:1.8) : CVE-2015-4035
[owasp:dependency-check]
jruby-1.6.8.jar/META-INF/maven/org.jruby.ext.posix/jnr-posix/pom.xml
(org.jruby.ext.posix:jnr-posix:1.1.9, cpe:/a:jruby:jruby:1.1.9) :
CVE-2010-1330, CVE-2011-4838, CVE-2012-5370


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

2018-06-06 Thread Gintautas Grigelionis
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.

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.
Dangling symlinks should go into notFollowedSymlinks.
Regarding , included but not followed symlink must be left as is (eg
directories are not filtered either).

>
> The current semantics of fileset's followsymlinks is deeply rooted in
> "we don't know how to deal with links and can only handle files and
> directories". I'm afraid a bunch of tasks will not do what you expect if
> DirectoryScanner suddenly returned File instances that are not real
> files/directories. Either they'd simply follow the link or break down -
> I assume in most cases it will be the former.
>

True; I wonder if we can have an interim solution when selectors could use
proper followsymlinks semantics,
but behaviour of DirectoryScanner is unchanged?


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


> > whereas followsymlinks="true" skipsymlinks="true" is ambiguous: if
> > followsymlinks takes precedence, skipsymlinks is redundant; if
> > skipsymlinks takes precedence, then followsymlinks is ignored.
>
> So we'd need to decide what takes precedence and document it properly.
>
> As I said above, I don't think Ant's tasks are going to treat
> non-followed symlinks the way you'd expect them to. We could collect
> them separately and add a new getIncludedSymlinks method to
> DirectoryScanner so each task could do what it is supposed to do for
> not-followed links, but then we'll start documenting whether a given
> task X handles those links at all and if so what it does.
>

That's true; in the meantime, would it make sense to document what
"followsymlinks" means
in FileSet and what "followsymlinks" means in selectors that permit the
attribute?

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] :-).

So, what's the plan?

Gintas

[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=15244


  
  
  
  
  
  

  
  
  
  

  
  followsymlinks=true: ${toString:fileset}
  
  followsymlinks=false: ${toString:fileset-symlinks}
  

  
  symlink followsymlinks=true: ${toString:fileset-is-symlink}
  

  
  symlink followsymlinks=false:
${toString:fileset-symlinks-is-symlink}

  

  
  ownedby ${user.name}: ${toString:fileset-owned-by-user}
  

  
  followsymlinks=false ownedby ${user.name}:
${toString:fileset-symlinks-owned-by-user}

  
  

  
  group ${wheel.group}: ${toString:fileset-owned-by-group}
  

  
  followsymlinks=false group ${wheel.group}:
${toString:fileset-symlinks-owned-by-group}

  
  

  
  permissions ${file.permissions}:
${toString:fileset-with-permissions}
  

  
  followsymlinks=false permissions ${file.permissions}:
${toString:fileset-symlinks-with-permissions}



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

2018-06-06 Thread Gintautas Grigelionis
2018-06-06 10:50 GMT+02:00 Stefan Bodewig :

> On 2018-06-05, Gintautas Grigelionis wrote:
>
> > Stefan is right -- "followsymlinks" for the fileset should have been
> called
> > "skipsymlinks" or something like that.
>
> I'm afraid I don't follow you here, what did you expect followsymlinks
> going by the name? What would the "new semantics of followsymlinks" you
> talk about be?
>
> How would the combinations
>
> followsymlinks="true" skipsymlinks="true"
> followsymlinks="false" skipsymlinks="false"
>
> behave?
>

I expect the following:
followsymlinks="false" should select symbolic links (rather than omitting
them which seems to be its current behaviour);
followsymlinks="true" should select whatever the links point at to (unless
there is a loop).

Consequently, I expect
followsymlinks="false" skipsymlinks="false" to behave as
followsymlinks="false"; whereas
followsymlinks="true" skipsymlinks="true" is ambiguous: if followsymlinks
takes precedence, skipsymlinks is redundant;
if skipsymlinks takes precedence, then followsymlinks is ignored.

Gintas


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

2018-06-04 Thread Gintautas Grigelionis
2018-06-04 8:26 GMT+02:00 Stefan Bodewig :

> What happens when I do something like this
>
> 
>   
> 
>
> I believe - but haven't tested it - that for symlinks  is never
> going to be invoked at all as DirectoryScanner will skip the symlink so
> the attribute's value on ownedby is irrelevant. If I'm correct we should
> probably document it somewhere.
>
> Of course the same is true for the existing  selector, so this
> is a more general task.


Stefan is right -- "followsymlinks" for the fileset should have been called
"skipsymlinks" or something like that.

What's worse, the way things are now, there is a risk for confusion.
I'd like add "skipsymlinks" and change "followsymlinks" for the fileset so
that
a fileset behaves as follows:

none of the attributes set (default):

skipsymlinks=false, followsymlinks=true (for consistency -- breaks BWC);

one ore both attributes set:

followsymlinks=true, skipsymlinks not set => warn, followsymlinks=false and
skipsymlinks=false for BWC;
followsymlinks=false, skipsymlinks not set => warn and skipsymlinks=true
for BWC;

skipsymlinks=false, followsymlinks set => new semantics for followsymlinks;
skipsymlinks=false, followsymlinks not set => new semantics,
followsymlinks=true for consistency;
skipsymlinks=true => followsymlinks not set -- ditto, else a warning about
useless attribute?

What do you think?

Gintas


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

2018-06-04 Thread Gintautas Grigelionis
2018-06-04 8:26 GMT+02:00 Stefan Bodewig :

> What happens when I do something like this
>
> 
>   
> 
>
> I believe - but haven't tested it - that for symlinks  is never
> going to be invoked at all as DirectoryScanner will skip the symlink so
> the attribute's value on ownedby is irrelevant. If I'm correct we should
> probably document it somewhere.
>
> Of course the same is true for the existing  selector, so this
> is a more general task.


I'll try to create a test case and cover as many combinations as possible,
including selector containers. My expectation is that followsymlinks="false"
only makes sense for a selector when followsymlinks="false" for the fileset.
I also expect that  only works in that case.

If my expectation turns out to be correct, I will document that as a general
footnote for all selectors that may or may not deal with symlinks depending
on
what DirectoryScanner finds in the first place.
It would be of interest to glean the value of followsymlinks of the fileset
and issue a warning when a selector is rendered less useful.

Gintas


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

2018-06-01 Thread Gintautas Grigelionis
Hi Stefan,

thanks for reviewing this. I missed the fact that filesets had a similar
attribute.
Hope everything is consistent now.

Gintas

2018-05-28 17:00 GMT+02:00 Stefan Bodewig :

> Hi Gintas
>
> you should probably check and document how the new followlinks attribute
> interacts with fileset's followsymlinks attribute.
>
> Please add something to WHATSNEW.
>
> Some additional notes inline.
>
> On 2018-05-23,  wrote:
>
> > http://git-wip-us.apache.org/repos/asf/ant/blob/35a84fea/
> manual/Types/selectors.html
> > --
> > diff --git a/manual/Types/selectors.html b/manual/Types/selectors.html
> > index 955a1b2..e3289af 100644
> > --- a/manual/Types/selectors.html
> > +++ b/manual/Types/selectors.html
> > @@ -925,6 +925,11 @@
> >  Username of the expected owner
> >  Yes
> >
> > +
> > +  followlinks
> > +  Must the selector follow symbolic links?
> > +  No; defaults to false (was true before Ant
> 1.10.4)
> > +
> >  
>
> Why change the default?
>
> > http://git-wip-us.apache.org/repos/asf/ant/blob/35a84fea/
> src/main/org/apache/tools/ant/types/selectors/OwnedBySelector.java
>
> > +/**
> > + * Sets the "follow links" flag.
> > + * @param followLinks the user name
> > + */
> > +public void setFollowLinks(String followLinks) {
> > +this.followLinks = PropertyHelper.toBoolean(followLinks);
> > +}
>
> public void setFollowLinks(boolean followLinks) {
> this.followLinks = followLinks;
> }
>
> does the same and looks clearer to me. Same for the other attribute
> setters.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


Re: [1/2] ant git commit: Deprecate CollectionUtils and Enumerations; reduce explicit use of Enumeration

2018-05-21 Thread Gintautas Grigelionis
2018-05-20 21:05 GMT+02:00 Gintautas Grigelionis <g.grigelio...@gmail.com>:

> 2018-05-18 16:11 GMT+02:00 Johan Corveleyn <jcor...@gmail.com>:
>
>> 2) There is clearly no consensus here on the merits / desirability of
>> these bulk changes. Gintas, I understand your desire to move things
>> along, and you clearly have an opinion about it, but IMHO you really
>> need to stop doing any more bulk changes as long as there is no
>> consensus.
>>
>
> This time, I tried to start a discussion first, and I got no response.
> There were attempts to modernize the codebase about a year ago. AFAICS
> there was no discussion then.
> What was that saying: "don't vote, don't complain"? I'd like some
> discussion, that's all.
>
> I hear that the consensus is "new stuff is for new code, or at least
> whenever one happens to change old code fixing the bugs".
> I'm not quite sure whether that's a good idea, we should at least try to
> achieve some consistency
> -- and not necessarily sticking to the bottom line.
> Or maybe I'm too old school seeing major version changes as necessitating
> a porting effort ;-)
>

Just another .02€ -- if we agree on porting guidelines, there's no need to
squabble about "personal preferences".
At the moment, the only "global" issues I see are "informally deprecated"
JRE APIs (Vector, Hashtable, Stack,...) and the use of streams/lambdas.

Gintas


Re: dependeset-test failures

2018-05-20 Thread Gintautas Grigelionis
2018-05-20 19:52 GMT+02:00 Stefan Bodewig :

> > Hi all
>
> > while running all tests locally I saw dependeset-test is failing, they
> > are also failing on Jenkins.
>
> Found it
>
> https://github.com/apache/ant/commit/11422630936848e82c7b13a
> b3fa68a3003e10195#diff-d84918760549fe4c0e195ba6cbfef4d3R268
>
> this must be max() - the order of the original compare may have been
> unexpected, I dont know. I've fixed it by now.
>
> May I use this as an additional hint that performing bulk changes that
> nobody really reviews is a bad idea. In addition the test must have
> failed everywhere where it was run.
>

Sorry, my bad, no failures occurred locally, but I saw failures at
JetBrains and you've beaten me to it.

Gintas


Re: [1/2] ant git commit: Deprecate CollectionUtils and Enumerations; reduce explicit use of Enumeration

2018-05-20 Thread Gintautas Grigelionis
2018-05-20 16:08 GMT+02:00 Stefan Bodewig :

> I'm afraid you misunderstood my question. I didn't ask why streams may
> be preferable over Enumerations when you write new code or change
> existing code. I was asking how does this benefit the existing code
> right now when there is no other change at all.
>

Sorry if I was unclear but the point was that the stream is parallelizable.
So, potentially higher thoughput on multicore?

Gintas


Re: [1/2] ant git commit: Deprecate CollectionUtils and Enumerations; reduce explicit use of Enumeration

2018-05-20 Thread Gintautas Grigelionis
2018-05-18 16:11 GMT+02:00 Johan Corveleyn :

> 2) There is clearly no consensus here on the merits / desirability of
> these bulk changes. Gintas, I understand your desire to move things
> along, and you clearly have an opinion about it, but IMHO you really
> need to stop doing any more bulk changes as long as there is no
> consensus.
>

This time, I tried to start a discussion first, and I got no response.
There were attempts to modernize the codebase about a year ago. AFAICS
there was no discussion then.
What was that saying: "don't vote, don't complain"? I'd like some
discussion, that's all.

I hear that the consensus is "new stuff is for new code, or at least
whenever one happens to change old code fixing the bugs".
I'm not quite sure whether that's a good idea, we should at least try to
achieve some consistency
-- and not necessarily sticking to the bottom line.
Or maybe I'm too old school seeing major version changes as necessitating a
porting effort ;-)

Gintas


Re: [1/2] ant git commit: Deprecate CollectionUtils and Enumerations; reduce explicit use of Enumeration

2018-05-20 Thread Gintautas Grigelionis
2018-05-18 16:51 GMT+02:00 Stefan Bodewig <bode...@apache.org>:

> On 2018-05-18, Gintautas Grigelionis wrote:
>
> > I believe that Streams API can at least implement the logic run by an
> > original Enumeration in a more concise way, or provide more powerful
> idioms.
> > That IMO makes it worth the while to investigate the Streams
> alternatives.
>
> I agree to do that as soon as we want to change the code to do something
> that wants to use said idioms. I don't really see a reason to change the
> code before that point in time.
>
> > In the process I also found out that other iterators could be used in a
> > more efficient way, or that there is a redundant object construction
> going
> > on.
> > If you wish, I may spend some time to describe the changes I introduced,
> > and maybe then we could discuss the their merits.
>
> Let's use the concrete example that raised Maarten's email. In
> ZipScanner we've gone from
>
> Enumeration e = zf.getEntries();
> while (e.hasMoreElements()) {
> ZipEntry entry = e.nextElement();
>
> to
>
> StreamUtils.enumerationAsStream(zf.getEntries()).forEach(entry
> -> {
>
> the Enumeration instance is created in both cases. What is the benfit
> for the ZipScanner class right now?
>

FWIW, the original java.util.ZipFile has a stream() that is based on an
iterator since Java 8 [1].
What is the reason for adding that method if Enumeration is so much better?
;-)
I dare say, the benefit is that streams are parallelizable.

Gintas

[1]
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/java/util/zip/ZipFile.java#ZipFile.stream%28%29


Re: [1/2] ant git commit: Deprecate CollectionUtils and Enumerations; reduce explicit use of Enumeration

2018-05-18 Thread Gintautas Grigelionis
I accepted the original criticism that going Enumeration -> List -> Stream
has an overhead and I tried to address that by using a decorator.
I believe that Streams API can at least implement the logic run by an
original Enumeration in a more concise way, or provide more powerful idioms.
That IMO makes it worth the while to investigate the Streams alternatives.

In the process I also found out that other iterators could be used in a
more efficient way, or that there is a redundant object construction going
on.
If you wish, I may spend some time to describe the changes I introduced,
and maybe then we could discuss the their merits.

Gintas

2018-05-18 8:30 GMT+02:00 Jaikiran Pai <jai.forums2...@gmail.com>:

> If your objection is that I claimed that these qualify as "most of the
> cases" - I really don't know what else to say then. The original commit
> which did this change is this[1]. I haven't reviewed it fully, but the very
> first few changes that are done are these [2] [3] [4] [5][6].
>
> Of course, there's a subsequent commit which then uses a different new
> util, instead of just using the existing iterator/enumeration. Speaking of
> the subsequent commit, it still doesn't undo the (IMO unnecessary) change
> that was done to some of the code (take a look at
> ArgumentProcessorRegistry.java for example).
>
> Even if these don't fall under "most of the cases", why even change these
> places? I'm sure you would know this - the Enumeration or APIs that you
> refactored aren't even deprecated in Java version 10.
>
> Anyway, I'm really getting tired of these back and forth arguments on
> refactoring. The reason I get involved in certain open source projects is
> to get a chance to work with like minded developers and learn something out
> of it and not to go wage a war on which coding style is better or try and
> be critical of other committers' commits. Unfortunately, in the recent
> past, this has reached a state where I have ended up spending more time
> being critical of changes that have gone in, than actually adding much code
> of value. As much as I try to stay away from reviews or checking the commit
> logs, I just keep going back to them. I don't want to end up being a grumpy
> guy criticizing the commits. I'm just going to take a break from this for
> some days and be a regular user and come back and see if I still enjoy
> contributing.
>
> [1] https://github.com/apache/ant/commit/070c3bc86f85e8f01cb624f
> e50ae82f0d11171b2
>
> [2] https://github.com/apache/ant/commit/070c3bc86f85e8f01cb624f
> e50ae82f0d11171b2#diff-21eb59eaf9f2b5d0b487aeb5e5022ccdL746
> [3] https://github.com/apache/ant/commit/070c3bc86f85e8f01cb624f
> e50ae82f0d11171b2#diff-21eb59eaf9f2b5d0b487aeb5e5022ccdL834
> [4] https://github.com/apache/ant/commit/070c3bc86f85e8f01cb624f
> e50ae82f0d11171b2#diff-21eb59eaf9f2b5d0b487aeb5e5022ccdL888
> [5] https://github.com/apache/ant/commit/070c3bc86f85e8f01cb624f
> e50ae82f0d11171b2#diff-21eb59eaf9f2b5d0b487aeb5e5022ccdL1359
>
> [6] https://github.com/apache/ant/commit/070c3bc86f85e8f01cb624f
> e50ae82f0d11171b2#diff-b98a3d2097d6a9b5d7e0fc2eac033f24L348
>
>
> -Jaikiran
>
>
>
> On 18/05/18 11:15 AM, Gintautas Grigelionis wrote:
>
>> I'm not quite sure that what you say was true "in most of the cases".
>>
>> Gintas
>>
>> 2018-05-18 6:52 GMT+02:00 Jaikiran Pai <jai.forums2...@gmail.com>:
>>
>> To be honest, I don't think this deprecation/conversion change is
>>> good(including this recent commit whichintroduces a
>>> StreamUtils.enumerationAsStream(...))
>>>
>>> To give you an example, the code that was previously present would (in
>>> most of the cases) get hold of an enumeration and would iterate over it
>>> and
>>> during that iteration would runcertain logic. With the changes that went
>>> in
>>> (which again is a bulk change!) the code now gets hold of an enumeration
>>> and instead of just getting on the business of iterating and running
>>> certain logic, instead now passes this enumeration aroundto convert it
>>> into
>>> some other form (thus additional code plus additional objects allocated
>>> in
>>> the process), all this to iterate over it and run some logic on it - all
>>> of
>>> which was already possible with the enumeration that was already
>>> available.
>>>
>>>
>>> -Jaikiran
>>>
>>>
>>>
>>> On 18/05/18 12:22 AM, Gintautas Grigelionis wrote:
>>>
>>> Thanks for reviewing, I hope Spliterators will do a better job.
>>>>
>>>> Gintas
>>>>
>>>> 2018-05-17 8:

Re: [1/2] ant git commit: Deprecate CollectionUtils and Enumerations; reduce explicit use of Enumeration

2018-05-17 Thread Gintautas Grigelionis
I'm not quite sure that what you say was true "in most of the cases".

Gintas

2018-05-18 6:52 GMT+02:00 Jaikiran Pai <jai.forums2...@gmail.com>:

> To be honest, I don't think this deprecation/conversion change is
> good(including this recent commit whichintroduces a
> StreamUtils.enumerationAsStream(...))
>
> To give you an example, the code that was previously present would (in
> most of the cases) get hold of an enumeration and would iterate over it and
> during that iteration would runcertain logic. With the changes that went in
> (which again is a bulk change!) the code now gets hold of an enumeration
> and instead of just getting on the business of iterating and running
> certain logic, instead now passes this enumeration aroundto convert it into
> some other form (thus additional code plus additional objects allocated in
> the process), all this to iterate over it and run some logic on it - all of
> which was already possible with the enumeration that was already available.
>
>
> -Jaikiran
>
>
>
> On 18/05/18 12:22 AM, Gintautas Grigelionis wrote:
>
>> Thanks for reviewing, I hope Spliterators will do a better job.
>>
>> Gintas
>>
>> 2018-05-17 8:37 GMT+02:00 Jaikiran Pai <jai.forums2...@gmail.com>:
>>
>> I agree. Especially when it's being done on something like for archive
>>> entries which can betoo many depending on the archive that is being dealt
>>> with.
>>>
>>> -Jaikiran
>>>
>>>
>>>
>>> On 17/05/18 12:04 PM, Maarten Coene wrote:
>>>
>>> Converting an Enumeration to a List just for iterating it doesn't seem
>>>> performance and memory wise a good idea to me.
>>>> Maarten
>>>>
>>>> Van: "gin...@apache.org" <gin...@apache.org>
>>>>Aan: notificati...@ant.apache.org
>>>>Verzonden: woensdag 16 mei 19:13 2018
>>>>Onderwerp: [1/2] ant git commit: Deprecate CollectionUtils and
>>>> Enumerations; reduce explicit use of Enumeration
>>>>  Repository: ant
>>>> Updated Branches:
>>>> refs/heads/master ac35c0014 -> 070c3bc86
>>>>
>>>>
>>>> http://git-wip-us.apache.org/repos/asf/ant/blob/070c3bc8/src
>>>> /main/org/apache/tools/ant/types/ZipScanner.java
>>>> --
>>>> diff --git a/src/main/org/apache/tools/ant/types/ZipScanner.java
>>>> b/src/main/org/apache/tools/ant/types/ZipScanner.java
>>>> index a3df040..5667159 100644
>>>> --- a/src/main/org/apache/tools/ant/types/ZipScanner.java
>>>> +++ b/src/main/org/apache/tools/ant/types/ZipScanner.java
>>>> @@ -20,7 +20,7 @@ package org.apache.tools.ant.types;
>>>>  import java.io.File;
>>>>import java.io.IOException;
>>>> -import java.util.Enumeration;
>>>> +import java.util.Collections;
>>>>import java.util.Map;
>>>>import java.util.zip.ZipException;
>>>>@@ -62,10 +62,7 @@ public class ZipScanner extends ArchiveScanner {
>>>>   "Only file provider resources are supported"));
>>>> try (ZipFile zf = new ZipFile(srcFile, encoding)) {
>>>> -
>>>> -Enumeration e = zf.getEntries();
>>>> -while (e.hasMoreElements()) {
>>>> -ZipEntry entry = e.nextElement();
>>>> +for (ZipEntry entry : Collections.list(zf.getEntries())) {
>>>>   Resource r = new ZipResource(srcFile, encoding,
>>>> entry);
>>>>   String name = entry.getName();
>>>>   if (entry.isDirectory()) {
>>>>
>>>>
>>>>
>>>>
>>>>
>>> -
>>> 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: [1/2] ant git commit: Deprecate CollectionUtils and Enumerations; reduce explicit use of Enumeration

2018-05-17 Thread Gintautas Grigelionis
Thanks for reviewing, I hope Spliterators will do a better job.

Gintas

2018-05-17 8:37 GMT+02:00 Jaikiran Pai :

> I agree. Especially when it's being done on something like for archive
> entries which can betoo many depending on the archive that is being dealt
> with.
>
> -Jaikiran
>
>
>
> On 17/05/18 12:04 PM, Maarten Coene wrote:
>
>> Converting an Enumeration to a List just for iterating it doesn't seem
>> performance and memory wise a good idea to me.
>> Maarten
>>
>>Van: "gin...@apache.org" 
>>   Aan: notificati...@ant.apache.org
>>   Verzonden: woensdag 16 mei 19:13 2018
>>   Onderwerp: [1/2] ant git commit: Deprecate CollectionUtils and
>> Enumerations; reduce explicit use of Enumeration
>> Repository: ant
>> Updated Branches:
>>refs/heads/master ac35c0014 -> 070c3bc86
>>
>>
>> http://git-wip-us.apache.org/repos/asf/ant/blob/070c3bc8/src
>> /main/org/apache/tools/ant/types/ZipScanner.java
>> --
>> diff --git a/src/main/org/apache/tools/ant/types/ZipScanner.java
>> b/src/main/org/apache/tools/ant/types/ZipScanner.java
>> index a3df040..5667159 100644
>> --- a/src/main/org/apache/tools/ant/types/ZipScanner.java
>> +++ b/src/main/org/apache/tools/ant/types/ZipScanner.java
>> @@ -20,7 +20,7 @@ package org.apache.tools.ant.types;
>> import java.io.File;
>>   import java.io.IOException;
>> -import java.util.Enumeration;
>> +import java.util.Collections;
>>   import java.util.Map;
>>   import java.util.zip.ZipException;
>>   @@ -62,10 +62,7 @@ public class ZipScanner extends ArchiveScanner {
>>  "Only file provider resources are supported"));
>>try (ZipFile zf = new ZipFile(srcFile, encoding)) {
>> -
>> -Enumeration e = zf.getEntries();
>> -while (e.hasMoreElements()) {
>> -ZipEntry entry = e.nextElement();
>> +for (ZipEntry entry : Collections.list(zf.getEntries())) {
>>  Resource r = new ZipResource(srcFile, encoding, entry);
>>  String name = entry.getName();
>>  if (entry.isDirectory()) {
>>
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


Re: JdkObsolete

2018-05-16 Thread Gintautas Grigelionis
Nobody seems to be interested...

Anyway, I commited a bunch of changes that deprecate CollectionUtils and
Enumerations (in optional/junit) as well as reduce explicit use of
Enumeration.

2018-05-09 9:08 GMT+02:00 Gintautas Grigelionis <g.grigelio...@gmail.com>:

> AFAICS, nobody has discussed [1] previously; do you think it's worth the
> while to do something about it?
>
> [1] http://errorprone.info/bugpattern/JdkObsolete
>


Re: [GitHub] ant pull request #:

2018-05-13 Thread Gintautas Grigelionis
Thanks, great work! I hope you don't mind me taking the liberty to adjust
WHATSNEW.

Gintas

2018-05-13 6:01 GMT+02:00 Jaikiran Pai :

> I did plan to addit yesterday, but my local tests did not trigger the
> package-info constant pool entry for some reason. So I decided to not rush
> it in and spend some time to get the test right, to make sure it works
> fine. I'll add it in either tonight or tomorrow once I get to see what's
> going on.
>
> -Jaikiran
>
>
>
> On 12/05/18 9:19 PM, twogee wrote:
>
>> Github user twogee commented on the pull request:
>>
>>  https://github.com/apache/ant/commit/d0f9c2e121e2b3a18b6
>> 79705c2f2164426e7e6fb#commitcomment-28953469
>> In src/main/org/apache/tools/ant/taskdefs/optional/depend/const
>> antpool/ConstantPoolEntry.java:
>>  In 
>> src/main/org/apache/tools/ant/taskdefs/optional/depend/constantpool/ConstantPoolEntry.java
>> on line 77:
>>  Please add 20 (package), too
>>
>>
>> ---
>>
>> -
>> 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
>
>


JdkObsolete

2018-05-09 Thread Gintautas Grigelionis
AFAICS, nobody has discussed [1] previously; do you think it's worth the
while to do something about it?

[1] http://errorprone.info/bugpattern/JdkObsolete


Re: Migrating Ivy and IvyDE site to asciidoc

2018-05-07 Thread Gintautas Grigelionis
2018-05-07 13:17 GMT+02:00 Nicolas Lalevée :

> The issue isn’t about the format of the image but about the layout of the
> page. If you have some proof of concept of how a home page can be done in
> asciidoc, please share, in a gist of whatever.


Which part of the front page is tricky? I guess it would be easiest to keep
the four links/icons in the table as they are now; otherwise one could try
something like a float
group -- only to come to conclusion that images must be cropped
appropriately to align them properly -- at which point one may start
thinking of SVG :-) not to mention a custom CSS.

Gintas

[.float-group]
--
:figure-caption!:
.https://ant.apache.org/ivy/download.html[download]
image::https://ant.apache.org/ivy/images/ivy-dl-2.5.0-rc1.png[float=left,link=https://ant.apache.org/ivy/download.html]

.https://ant.apache.org/ivy/history/latest-milestone/index.html[documentation
++ & tutorials]
image::https://ant.apache.org/ivy/images/ivy-book.png[float=left,link=https://ant.apache.org/ivy/history/latest-milestone/index.html]

.https://ant.apache.org/ivy/demo.html[demo]
image::https://ant.apache.org/ivy/images/ivy-demo.png[float=left,link=https://ant.apache.org/ivy/demo.html]

.https://ant.apache.org/ivy/mailing-lists.html[share your experience]
image::https://ant.apache.org/ivy/images/ivy-forum.png[float=left,link=https://ant.apache.org/ivy/mailing-lists.html]
--


  1   2   3   4   >