Re: Is CacheResolver relevant?

2017-07-27 Thread Gintautas Grigelionis
Perhaps another JIRA issue [1] would cast some light?

[1] https://issues.apache.org/jira/browse/IVY-1227

Gintas

2017-07-27 18:10 GMT+02:00 Jaikiran Pai :

>
> On 27/07/17 9:34 PM, Jaikiran Pai wrote:
>
>> There's a JIRA[2] asking for the docs to be updated to explain this
>> resolver.
>>
>> ...
>> [2] https://issues.apache.org/jira/browse/IVY-804
>>
> I meant this JIRA which asks for it to be documented
> https://issues.apache.org/jira/browse/IVY-612
>
>
> -Jaikiran
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


[GitHub] ant-ivy pull request #56: use “Maven 2” consistently

2017-07-27 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/ant-ivy/pull/56


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



Re: Ivy logo as SVG

2017-07-27 Thread Gintautas Grigelionis
In case you missed among all GitHub chat: the SVG (and Draw 2D :-) logo has
arrived as PR-55.
A shoutout to Flamingo project (
https://github.com/kirill-grouchnikov/flamingo)
and its SVG transcoder (http://ebourg.github.io/flamingo-svg-transcoder/).

Gintas

2017-06-08 16:46 GMT+02:00 Dominique Devienne :

> On Thu, Jun 8, 2017 at 4:35 PM, Gintautas Grigelionis <
> g.grigelio...@gmail.com> wrote:
>
> > https://drive.google.com/open?id=0B2mVPD7ZO6sdcDFkX1lQdHJWZVRwU
> > UdSSXI1VnF3bk5xTFhF
>
>
> I like it! --DD
>


[GitHub] ant-ivy pull request #:

2017-07-27 Thread twogee
Github user twogee commented on the pull request:


https://github.com/apache/ant-ivy/commit/366fb741f0772c8309f9dfe963f6032b091d7b89#commitcomment-23340291
  
Sorry for a terse suggestion, I meant we could provide more information to 
the end user about the symlink/symlinkmass now that the former could be made to 
work on NTFS 3.1; but that's an excess if the focus is on deprecation. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



[GitHub] ant-ivy pull request #57: fix last inconsistencies in generics

2017-07-27 Thread twogee
GitHub user twogee opened a pull request:

https://github.com/apache/ant-ivy/pull/57

fix last inconsistencies in generics

... use collections, not arrays

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/twogee/ant-ivy consistent-generics

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant-ivy/pull/57.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 #57


commit e849096d3fb0070b0e4d5d387e38a2b7a42ebf8e
Author: twogee 
Date:   2017-07-27T19:38:15Z

fix last inconsistencies in generics (use collections, not arrays)




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



[GitHub] ant-ivy pull request #56: use “Maven 2” consistently

2017-07-27 Thread twogee
GitHub user twogee opened a pull request:

https://github.com/apache/ant-ivy/pull/56

use “Maven 2” consistently



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/twogee/ant-ivy maven-2-in-asciidoc

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant-ivy/pull/56.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 #56


commit 43c4b48d2f0cbac6c0a8fda4b98f599202de9678
Author: twogee 
Date:   2017-07-27T19:32:14Z

use “Maven 2” consistently




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



[GitHub] ant-ivy issue #53: Suppressed warnings

2017-07-27 Thread twogee
Github user twogee commented on the issue:

https://github.com/apache/ant-ivy/pull/53
  
With all due respect, there are some refactorings worth attention IMHO. 
Besides, some deprecations need to be followed through 😉 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



[GitHub] ant-ivy pull request #:

2017-07-27 Thread twogee
Github user twogee commented on the pull request:


https://github.com/apache/ant-ivy/commit/6607bdcb3ba69d2ab4f41be6292cc5a6df6365ba#commitcomment-23339716
  
In URLHandlerDispatcher,
```
@Override
public void download(final URL src, final File dest, final 
CopyProgressListener l) throws IOException {
this.download(src, dest, l);
}

@Override
public void upload(final File src, final URL dest, final 
CopyProgressListener l) throws IOException {
this.upload(src, dest, l);
}
```
look like recursion? Surely a default timeout constraint is missing?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



Re: Is CacheResolver relevant?

2017-07-27 Thread Jaikiran Pai


On 27/07/17 9:34 PM, Jaikiran Pai wrote:
There's a JIRA[2] asking for the docs to be updated to explain this 
resolver.


...
[2] https://issues.apache.org/jira/browse/IVY-804
I meant this JIRA which asks for it to be documented 
https://issues.apache.org/jira/browse/IVY-612


-Jaikiran

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



Is CacheResolver relevant?

2017-07-27 Thread Jaikiran Pai
There's this JIRA issue https://issues.apache.org/jira/browse/IVY-804 
where the user reports a genuine bug in our typedef.properties file 
where we list the "cache" property twice with different values. Once to 
consider the  element as a resolver and the other to consider 
the  element as the cache configurations.


This is a genuine bug and I suspect what this implies is that the "cache 
resolver" has never worked in the past decade (that's when this entry 
was added). Furthermore, although there's a CacheResolver[1] which 
represents this element, I don't see any references to that class in our 
code and no tests either. Also, our documentation doesn't mention it 
either. There's a JIRA[2] asking for the docs to be updated to explain 
this resolver.


Is this resolver being used and should this be supported? If it has to 
be supported, from what I see, it will involve fixing this 
typedef.properties and adding some kind of enhancement to our Ivy 
settings parser so that it can uniquely understand what this duplicated 
"cache" name means in different context. Probably won't be easy, but if 
we do want to support this, I think that's what we will have to do.


On the other hand, if we don't have to support this, then I can just 
remove it from that typedef.properties file.


[1] 
https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/plugins/resolver/CacheResolver.java


[2] https://issues.apache.org/jira/browse/IVY-804

-Jaikiran


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



[GitHub] ant-ivy issue #53: Suppressed warnings

2017-07-27 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant-ivy/pull/53
  
Commit 
https://github.com/apache/ant-ivy/pull/53/commits/414651c8841a09a9d9d4b0365ee8e7227fba8429
 in this PR has now been merged to upstream 
https://github.com/apache/ant-ivy/commit/1a283ab1be5b495f5be8cf6c2ab2b96453dd32f9

It had a merge conflict against latest upstream master which I had to 
resolve during the review/merge.

At this point, the only remaining commit that needs review in this PR is 
this one 
https://github.com/apache/ant-ivy/pull/53/commits/b7c26ac4ea31369e7c0945aea8552280857f951a.
 Given that this hasn't been rebased against latest master branch, can you 
please close this PR and reopen a new one containing this one single commit, 
rebased against latest master. That commit includes changes to many files, so 
having it rebased against latest master will help review it properly.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



[GitHub] ant-ivy pull request #:

2017-07-27 Thread jaikiran
Github user jaikiran commented on the pull request:


https://github.com/apache/ant-ivy/commit/366fb741f0772c8309f9dfe963f6032b091d7b89#commitcomment-23334838
  
Do you mean for the `symlinkmass` deprecation? In this release, I just 
wanted it to be deprecated with a log message showing up so that it doesn't 
blow up existing builds where user might be using that option. Internally, 
setting that option to `true` in the upcoming version will be same as setting 
the `symlink` to `true` and that's intentional to allow backward compatibility 
for at least one or two releases till users have a chance to remove that option 
in their builds. A few releases down the line, we will just remove that option 
and that will result in a relevant exception.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



[GitHub] ant-ivy pull request #:

2017-07-27 Thread twogee
Github user twogee commented on the pull request:


https://github.com/apache/ant-ivy/commit/366fb741f0772c8309f9dfe963f6032b091d7b89#commitcomment-23334637
  
Perhaps `UnsupportedOperationException` would be a useful heuristic?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



Re: AW: Ivy - Move to symlink creation standard Java API?

2017-07-27 Thread Jaikiran Pai


On 27/07/17 2:14 PM, Jan Matèrne (jhm) wrote:

Getting rid of that means being more standard compliant and having less to 
maintain. ;)
Agreed. Plus the fact that our previous implementation of this feature 
relied on the presence of the "ln" command on the systems, which 
effectively ruled out this feature on native Windows completely. With 
the usage of the standard API, that's no longer the case.


-Jaikiran

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



Re: Ivy - Move to symlink creation standard Java API?

2017-07-27 Thread Jaikiran Pai

Thank you for testing that kind of setup.

I have now pushed a commit which does the necessary changes to use Java 
standard API and also deprecates that use of symlinkmass option (which 
is no longer relevant) of the retrieve task. The testcases have been 
updated to make sure the tests are run on all systems (earlier they used 
to be run only on specific systems) and the logic in the tests has been 
updated to do a more robust check on ability to create symbolic links.


I have also updated the documentation and release notes to note and 
explain the deprecation of the symlinkmass option.


-Jaikiran


On 27/07/17 5:07 PM, Gintautas Grigelionis wrote:

I did a few simple tests on Windows 7 + Cygwin and NIO.2 seems to work just
fine (if privilege to create symlinks is granted).

+1

Gintas

2017-07-27 11:40 GMT+02:00 Gintautas Grigelionis :


There might be some issues with Cygwin, see Eclipse/JGit discussion [1]

Gintas

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=354367

2017-07-27 10:44 GMT+02:00 Jan Matèrne (jhm) :


If the new Java version supports the symlink creation and it's an
implementation detail
of Ivy (so not part of an API other could use) I am in favour of getting
rid of the old
implementation.
Getting rid of that means being more standard compliant and having less
to maintain. ;)

Jan




-Ursprüngliche Nachricht-
Von: Nicolas Lalevée [mailto:nicolas.lale...@hibnet.org]
Gesendet: Mittwoch, 26. Juli 2017 18:19
An: Ant Developers List
Betreff: Re: Ivy - Move to symlink creation standard Java API?



Le 26 juil. 2017 à 15:25, Jaikiran Pai  a

écrit :

I was looking into a JIRA related to symlinking in Ivy and realized

that (for reasons noted in the docs and the implementation)
ourimplementation of symlinking relies on launching a process from
within the JVM to invoke a shell command to create the symlinks.
"retrieve" task is the only one that deals with symlink creation, from
what I can see. Furthermore, knowing that this operation is expensive,
we even had to introduce an additional optionfor that task to allow
"mass symlinking"[1] so that we launch a single process to create N
symlinks instead of N processes.

In short, the current implementation of symlinking in Ivy is

expensive for reasons that have been known. Now that we have moved to
Java 7, which has a standard APIfor symlink creation[2], I think we
should just change our internal implementation to use this new standard
API.Of course, we continue to fail to create symlinks on systems that
don't support it, just like we do now, except that we let the Java API
implementation handle those details.

Furthermore, once we move to thisstandard API, I don't think we need

the "symlinkmass" option onthe retrieve task anymore since the whole
purpose of it was to avoid launching N processes. So I think we can
deprecate that option in the upcoming release.

Any thoughts?

Sounds good to me.

Nicolas


-
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



[GitHub] ant-ivy pull request #55: use vectorised logo

2017-07-27 Thread twogee
GitHub user twogee opened a pull request:

https://github.com/apache/ant-ivy/pull/55

use vectorised logo

I'd like to remove downloaded.gif, error.gif, evicted.gif and searched.gif 
as well.
Maybe we could vote on colours for downloaded and evicted 😉 if green is 
too dark or fuchsia is too garish (I took it because it's one of "safe" 
colours).

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/twogee/ant-ivy svg-logo

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant-ivy/pull/55.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 #55


commit 4fc1b04068194894decd755db032a6ed91063b6e
Author: twogee 
Date:   2017-07-27T13:32:44Z

use vectorised logo




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



Re: Ivy - Move to symlink creation standard Java API?

2017-07-27 Thread Gintautas Grigelionis
I did a few simple tests on Windows 7 + Cygwin and NIO.2 seems to work just
fine (if privilege to create symlinks is granted).

+1

Gintas

2017-07-27 11:40 GMT+02:00 Gintautas Grigelionis :

> There might be some issues with Cygwin, see Eclipse/JGit discussion [1]
>
> Gintas
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=354367
>
> 2017-07-27 10:44 GMT+02:00 Jan Matèrne (jhm) :
>
>> If the new Java version supports the symlink creation and it's an
>> implementation detail
>> of Ivy (so not part of an API other could use) I am in favour of getting
>> rid of the old
>> implementation.
>> Getting rid of that means being more standard compliant and having less
>> to maintain. ;)
>>
>> Jan
>>
>>
>>
>> > -Ursprüngliche Nachricht-
>> > Von: Nicolas Lalevée [mailto:nicolas.lale...@hibnet.org]
>> > Gesendet: Mittwoch, 26. Juli 2017 18:19
>> > An: Ant Developers List
>> > Betreff: Re: Ivy - Move to symlink creation standard Java API?
>> >
>> >
>> > > Le 26 juil. 2017 à 15:25, Jaikiran Pai  a
>> > écrit :
>> > >
>> > > I was looking into a JIRA related to symlinking in Ivy and realized
>> > that (for reasons noted in the docs and the implementation)
>> > ourimplementation of symlinking relies on launching a process from
>> > within the JVM to invoke a shell command to create the symlinks.
>> > "retrieve" task is the only one that deals with symlink creation, from
>> > what I can see. Furthermore, knowing that this operation is expensive,
>> > we even had to introduce an additional optionfor that task to allow
>> > "mass symlinking"[1] so that we launch a single process to create N
>> > symlinks instead of N processes.
>> > >
>> > > In short, the current implementation of symlinking in Ivy is
>> > expensive for reasons that have been known. Now that we have moved to
>> > Java 7, which has a standard APIfor symlink creation[2], I think we
>> > should just change our internal implementation to use this new standard
>> > API.Of course, we continue to fail to create symlinks on systems that
>> > don't support it, just like we do now, except that we let the Java API
>> > implementation handle those details.
>> > >
>> > > Furthermore, once we move to thisstandard API, I don't think we need
>> > the "symlinkmass" option onthe retrieve task anymore since the whole
>> > purpose of it was to avoid launching N processes. So I think we can
>> > deprecate that option in the upcoming release.
>> > >
>> > > Any thoughts?
>> >
>> > Sounds good to me.
>> >
>> > Nicolas
>> >
>> >
>> > -
>> > 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: Ivy - Move to symlink creation standard Java API?

2017-07-27 Thread Gintautas Grigelionis
There might be some issues with Cygwin, see Eclipse/JGit discussion [1]

Gintas

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=354367

2017-07-27 10:44 GMT+02:00 Jan Matèrne (jhm) :

> If the new Java version supports the symlink creation and it's an
> implementation detail
> of Ivy (so not part of an API other could use) I am in favour of getting
> rid of the old
> implementation.
> Getting rid of that means being more standard compliant and having less to
> maintain. ;)
>
> Jan
>
>
>
> > -Ursprüngliche Nachricht-
> > Von: Nicolas Lalevée [mailto:nicolas.lale...@hibnet.org]
> > Gesendet: Mittwoch, 26. Juli 2017 18:19
> > An: Ant Developers List
> > Betreff: Re: Ivy - Move to symlink creation standard Java API?
> >
> >
> > > Le 26 juil. 2017 à 15:25, Jaikiran Pai  a
> > écrit :
> > >
> > > I was looking into a JIRA related to symlinking in Ivy and realized
> > that (for reasons noted in the docs and the implementation)
> > ourimplementation of symlinking relies on launching a process from
> > within the JVM to invoke a shell command to create the symlinks.
> > "retrieve" task is the only one that deals with symlink creation, from
> > what I can see. Furthermore, knowing that this operation is expensive,
> > we even had to introduce an additional optionfor that task to allow
> > "mass symlinking"[1] so that we launch a single process to create N
> > symlinks instead of N processes.
> > >
> > > In short, the current implementation of symlinking in Ivy is
> > expensive for reasons that have been known. Now that we have moved to
> > Java 7, which has a standard APIfor symlink creation[2], I think we
> > should just change our internal implementation to use this new standard
> > API.Of course, we continue to fail to create symlinks on systems that
> > don't support it, just like we do now, except that we let the Java API
> > implementation handle those details.
> > >
> > > Furthermore, once we move to thisstandard API, I don't think we need
> > the "symlinkmass" option onthe retrieve task anymore since the whole
> > purpose of it was to avoid launching N processes. So I think we can
> > deprecate that option in the upcoming release.
> > >
> > > Any thoughts?
> >
> > Sounds good to me.
> >
> > Nicolas
> >
> >
> > -
> > 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
>
>


AW: Ivy - Move to symlink creation standard Java API?

2017-07-27 Thread jhm
If the new Java version supports the symlink creation and it's an 
implementation detail 
of Ivy (so not part of an API other could use) I am in favour of getting rid of 
the old 
implementation.
Getting rid of that means being more standard compliant and having less to 
maintain. ;)

Jan



> -Ursprüngliche Nachricht-
> Von: Nicolas Lalevée [mailto:nicolas.lale...@hibnet.org]
> Gesendet: Mittwoch, 26. Juli 2017 18:19
> An: Ant Developers List
> Betreff: Re: Ivy - Move to symlink creation standard Java API?
> 
> 
> > Le 26 juil. 2017 à 15:25, Jaikiran Pai  a
> écrit :
> >
> > I was looking into a JIRA related to symlinking in Ivy and realized
> that (for reasons noted in the docs and the implementation)
> ourimplementation of symlinking relies on launching a process from
> within the JVM to invoke a shell command to create the symlinks.
> "retrieve" task is the only one that deals with symlink creation, from
> what I can see. Furthermore, knowing that this operation is expensive,
> we even had to introduce an additional optionfor that task to allow
> "mass symlinking"[1] so that we launch a single process to create N
> symlinks instead of N processes.
> >
> > In short, the current implementation of symlinking in Ivy is
> expensive for reasons that have been known. Now that we have moved to
> Java 7, which has a standard APIfor symlink creation[2], I think we
> should just change our internal implementation to use this new standard
> API.Of course, we continue to fail to create symlinks on systems that
> don't support it, just like we do now, except that we let the Java API
> implementation handle those details.
> >
> > Furthermore, once we move to thisstandard API, I don't think we need
> the "symlinkmass" option onthe retrieve task anymore since the whole
> purpose of it was to avoid launching N processes. So I think we can
> deprecate that option in the upcoming release.
> >
> > Any thoughts?
> 
> Sounds good to me.
> 
> Nicolas
> 
> 
> -
> 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