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

[twogee]

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 something to handle error
}
```

But, I was hasty and the tests still fail. I'll try to rectify that later 
today.


---

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

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

[supertick]

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 standalone interface could be supported.  
I'm glad your change supports the interface without the additional option.

Now perhaps these 
https://www.google.com/search?q=ivy+programmatic+stackoverflow 
can be answered simply with 

```
try {
CommandLineParser parser = getParser();
// parse the command line arguments   
CommandLine line = parser.parse(args);   
ResolveReport  report = Main.run(line, false);
// iterate through the report
} catch (Exception e) {
// do something to handle error
}
```

Thanks.


---

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

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

[supertick]

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 
(https://github.com/apache/ant-ivy/blob/2.4.x/src/java/org/apache/ivy/Main.java#L313)
 just because of an error.

The errors (and the successes) can be queried out of the ResolveReport.  A 
client can programmatically make decisions based on the data returned. And the 
run() methods still throw their respective exceptions which could be caught by 
the client consumer. 

The new option is to alleviate the problematic design of having an error 
terminate a client consumer  with a System.exit.

Perhaps a design would be to copy/paste Main.java to IvyClient.java and 
remove the System.exit - but then it would be less normalized, which has its 
own flaws.


---

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

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

[twogee]

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 exception encapsulating 
whatever relevant information is available, rather than blithely carrying on.


---

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

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

[twogee]

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: dev-h...@ant.apache.org

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

[twogee]

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 you can review and apply these changes as the patch at:

https://github.com/apache/ant-ivy/pull/70.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #70


commit ab638a8f5bb74d83299d006fcc0f041c21338610
Author: twogee 
Date:   2018-03-20T00:00:13Z

Make Main.run() usable programmatically




---

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

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

[twogee]

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


---

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

Re: ant git commit: Add dependency description

[Gintautas Grigelionis]

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

Gintas

Re: Snapshot access to regular users of Ant

[Stefan Bodewig]

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 about Java 1.2, CVS, etc

Ah, I see. I guess nobody of us has been aware the tutorials contain
contribution guidelines (at least I wasn't).

IMHO it would be better to have a single place that talks about it and
link to it from inside the tutorial and wherever else. CONTRIBUTING.md
is really only there for github, maybe a new page on the website under
the "Contributing" section?

Stefan

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

Re: Snapshot access to regular users of Ant

[Gintautas Grigelionis]

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 GMT+01:00 Stefan Bodewig :

> 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 1.10.3 gets released...
>
> As long as what you write is consistent with CONTRIBUTING.md which also
> recommends github PRs by now, this is fine :-)
>
> Can you point us at the changes you've made?
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Snapshot access to regular users of Ant

[Stefan Bodewig]

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 1.10.3 gets released...

As long as what you write is consistent with CONTRIBUTING.md which also
recommends github PRs by now, this is fine :-)

Can you point us at the changes you've made?

Stefan

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

Re: Snapshot access to regular users of Ant

[Stefan Bodewig]

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] which states regular
> users aren't even meant to know about such snapshots.

The idea of the policy is that users must be aware they are using
something that hasn't been tested extensively and may contain
bugs. Nobody should consider the snapshots production ready, that's why
they shouldn't get advertised outside of the developement community.

People who are willing to test a feature under development are part of
the development communinity :-)

If you reach out to the user list and ask people to test the junit5
feature, this is fine IMHO. Telling them to use the SNAPSHOTs as a way
to fix a certain bug is not (while it is OK to use it as a way to verify
the fix, this is subtle).

Stefan

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

Re: When is Ant 1.10.3 release expected?

[Stefan Bodewig]

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 find time the coming days, but should be able to cut
releases during the weekend the latest.

Stefan

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

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

[Stefan Bodewig]

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, this custom class can be
> plugged in something like:

>  classname="some.custom.class.implementing.an.task.specific.interface"/>

> plus the fact that this custom class can reside in a classloader
> defined by nested  elements of this task.

Just a few remarks, do with them however you see fit :-)

* you can use part of IntrospectionHelper's infrastructure, of
  course. At least Project#setProjectReference so you don't have to
  reinvent the reflrection logic.

* Your approach for listeners is that of the original JUnit task and
  predates support for typedef together with

  public void add(SomeInterface child);

  for nested elements. Later we would have used the newer approach (see
  for example the  task accepting arbitrary Condition
  implementations.

  You may consider using

  public void addConfigured(ListenerInterface l) { ... }

  in your task and

  
  

  

   in the build file. You'd even get classloader support for free.

Stefan

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