[GitHub] ant-ivy issue #70: Make Main.run() usable programmatically

Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/70 Actually, you should be able to do ``` try { ResolveReport report = Main.run(args, false); // iterate through the report } catch (Exception e) { // do

[GitHub] ant-ivy issue #70: Make Main.run() usable programmatically

Github user supertick commented on the issue: https://github.com/apache/ant-ivy/pull/70 I agree @twogee now that I've seen your change, your solution would be better. I felt too, adding a new command line option was not the best, but also felt strongly, with minimal work the

[GitHub] ant-ivy issue #69: 2.4.x

Github user supertick commented on the issue: https://github.com/apache/ant-ivy/pull/69 I think it would be great "not" to have an additional CLI option, but then you cannot have a System.exit(1) terminating the client code

[GitHub] ant-ivy issue #69: 2.4.x

Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/69 I suggest closing this PR. The main problem here is that programmatic use should not be adressed by adding CLI options which make no sense. Also, if resolve() ends with errors, it's best to throw an

[GitHub] ant-ivy issue #70: Make Main.run() usable programmatically

Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/70 This addresses IVY-1321 and IVY-1578 --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail:

[GitHub] ant-ivy pull request #70: Make Main.run() usable programmatically

GitHub user twogee opened a pull request: https://github.com/apache/ant-ivy/pull/70 Make Main.run() usable programmatically Inspired by #69 You can merge this pull request into a Git repository by running: $ git pull https://github.com/twogee/ant-ivy ivy-1321 Alternatively

[GitHub] ant-ivy issue #69: 2.4.x

Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/69 Could you please provide a unit test to demonstrate what is wrong with [IVY-1576 fix](https://github.com/apache/ant-ivy/commit/3b17df0ab67a1f14794bc6c60b735f3354caec9e)? ---

Re: ant git commit: Add dependency description

2018-03-17 16:09 GMT+01:00 Gintautas Grigelionis : > > > I was wondering why junitlauncher task depended on all jars being present > in Ant classpath with no possibility to set a separate classpath for the > task? > ... especially because ant -f fetch.xml seems to fetch

Re: Snapshot access to regular users of Ant

On 2018-03-19, Gintautas Grigelionis wrote: > Starting from > https://rawgit.com/apache/ant/master/manual/tutorial-tasks-filesets-properties.html#contribute > to the end of document. Cf > https://ant.apache.org/manual/tutorial-tasks-filesets-properties.html#contribute > which still talks

Re: Snapshot access to regular users of Ant

Starting from https://rawgit.com/apache/ant/master/manual/tutorial-tasks-filesets-properties.html#contribute to the end of document. Cf https://ant.apache.org/manual/tutorial-tasks-filesets-properties.html#contribute which still talks about Java 1.2, CVS, etc Gintas 2018-03-19 8:35

Re: Snapshot access to regular users of Ant

On 2018-03-17, Gintautas Grigelionis wrote: > On the other hand, I rewrote the manual (which was still talking about > CVS), suggesting that the proper way to propose code changes would be > a GitHub PR rather than an archive uploaded to Bugzilla, so please > correct me if I'm wrong before Ant

Re: Snapshot access to regular users of Ant

On 2018-03-17, Jaikiran Pai wrote: > I was about to send a mail to the user mailing list about the Ant > nightly job which publishes the daily snapshots, so that they can test > some bug fixes and new features (JUnit 5 in particular). However, I > happened to read the Apache release policy[1]

Re: When is Ant 1.10.3 release expected?

On 2018-03-17, Jaikiran Pai wrote: > I (finally) merged the JUnit 5 work to master. Rest of the fork > related work for this task is something that I don't plan to make > available in this release (the work is going to take some time). So I > guess, we can make a new release. I can see whether I

Re: User implementations of custom interfaces can have access to Task instance?

On 2018-03-17, Jaikiran Pai wrote: > Thanks for the input, Stefan. I took your suggestion and exposed a API > to get the Project on that custom interface. It doesn't/can't directly > use the IntrospectionHelper support available to project components, > since unlike nested elements of a task,