Re: [VOTE] Retire the IvyDE Subproject

[Dominique Devienne]

On Thu, Nov 23, 2023 at 8:19 AM Stefan Bodewig  wrote:

> Following our own rules I propose to retire IvyDE.
>

+1. --DD

Re: [VOTE] Send IvyDE to the Apache Attic

[Dominique Devienne]

On Sun, Nov 19, 2023 at 6:40 PM Stefan Bodewig  wrote:

> I hereby propose to create a board resolution that will send IvyDE to
> the Apache Attic.
>

+1. --DD

Re: Antlib SVN and antunit Java versions

[Dominique Devienne]

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

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

[Dominique Devienne]

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

Re: Ant documentation

[Dominique Devienne]

On Thu, Mar 1, 2018 at 7:28 AM, Gintautas Grigelionis <
g.grigelio...@gmail.com> wrote:

> I made an attempt to convert the manual to HTML 5, the rationale being that
> HTML 5 deprecates tt tag and recommends to replace it with tags like code,
> kbd, samp and var, which could be used in a more consistent way to achieve
> something closer to a semantic markup.
>
> I tried then to use the replacement tags as consistently as possible in
> such a large body of text, but I realised that we perhaps need a kind of a
> style guide. Would you like to discuss it? Where would it best fit in the
> source code tree?
>

Isn't the HTML manual generated? Sure it's checked-in, but I thought there
was a generation process.
If that's the case (I may have dreamed it) then it's likely the generator
that needs fixing, not the build product. --DD

Re: Mapped resources NPEs - Potential fix causes a failure in one specific test

[Dominique Devienne]

On Fri, Feb 9, 2018 at 11:05 AM, Jaikiran Pai <jai.forums2...@gmail.com>
wrote:

>
> On 09/02/18 2:47 PM, Dominique Devienne wrote:
>
>> On Fri, Feb 9, 2018 at 10:06 AM, Jaikiran Pai <jai.forums2...@gmail.com>
>> wrote:
>>
>> I need some inputs on how we should go about this specific change/test?
>>> Should this test continue to expect a exception or is it fine to expect
>>> that target to complete cleanly (without copying anything)?
>>>
>>> What's the source of the NPE?
>> If it's an implementation detail, then it's fine to no longer throw IMHO.
>>
> We have FileNameMapper interface which has a:
>
> String[] mapFileName(String sourceFileName);
>
> API. The contract/javadoc of this API says:
>
>  * Returns an array containing the target filename(s) for the
>  * given source file.
>  *
>  * if the given rule doesn't apply to the source file,
>  * implementation must return null
>
> We have an implementation of this interface, the IdentityMapper, whose
> implementation so far, IMO, wasn't following this contract. If it was
> passed a null source file name, that implementation would return an
> String[] with one element and the contained element in that array would be
> null.
>
> Callers of this API are expected to understand that the API itself might
> return null, so they used to just check the return value and not its
> contents. They would then go and start working on these individual elements
> in the array and start running into NPEs in a bunch of places.
>
> The change I made was to the implementation of IdentityMapper, so that it
> returns null instead of an array with one null element, when the input to
> it is null. That way, the callers' logic of checking the return value for
> null, is enough for them to skip such resources.
>
> So to me, this does look like something that we should take care off in
> that specific test, so that it no longer expects a build exception to be
> thrown.


Agreed. +1. Thanks for the details and "walking me through the code". --DD

Re: Mapped resources NPEs - Potential fix causes a failure in one specific test

[Dominique Devienne]

On Fri, Feb 9, 2018 at 10:06 AM, Jaikiran Pai 
wrote:

> I need some inputs on how we should go about this specific change/test?
> Should this test continue to expect a exception or is it fine to expect
> that target to complete cleanly (without copying anything)?
>

What's the source of the NPE?
If it's an implementation detail, then it's fine to no longer throw IMHO.
If OTOH it was another IO-related exception, it might still be fine, but as
long as there's a visible trace of the IO exception, like an error message
(in normal or at least verbose mode).
So except in the latter case, and there's no message at any log level, I'm
fine with what you propose to no longer throw. My $0.02, based on your
message only. --DD

Re: ant-ivy git commit: tidy up the code

[Dominique Devienne]

On Fri, Dec 8, 2017 at 3:26 PM, Gintautas Grigelionis <
g.grigelio...@gmail.com> wrote:

> So, my rule was simple: an "if ((..." with multiple leading parens is only
> necessary where the logical condition is indeed complex.
>

I guess my point is more that such changes are a bit futile,
and code churn just for the sake of it. It's also somewhat inconsistent
since in ternaries you added parens instead of removing them.
Elsewhere you removed lines between cases.
Or changed ternaries into if's. Etc...
These are zero-sum gains IMHO.

If you actually worked in that area of the code, or made fixes in there,
"drive by" style changes might be more justified, even though like Jaikiran
mentioned one should refrain in general from doing so in a collective code
base.

I'll leave it at that. I don't want to make a big deal of it, nor temper
any enthusiasm
for engaging with the Ant or Ivy code-bases. I just think there are better
uses of
everyone's brain cycles (doing the changes or reviewing the commits) than
on such changes. --DD

PS: An yes, I can see the irony of me making noises about it instead of
just letting it go...

Re: ant-ivy git commit: tidy up the code

[Dominique Devienne]

On Fri, Dec 8, 2017 at 7:53 AM,  wrote:

> Repository: ant-ivy
> Updated Branches:
>   refs/heads/master 1b84f2ee7 -> 12aeeec70
>
> tidy up the code
> -if ((currentTask.getTaskName() != null)
> +if (currentTask.getTaskName() != null
>  && currentTask.getTaskName().equals(((Task)
> task).getTaskName())) {
>  // The current AntMessageLogger already logs with the same
>  // prefix as the given task. So we shouldn't do
> anything...
> ...
>


> -if ((otherRef != null) && OVERRIDE_NOT_ALLOWED.equals(override))
> {
> +if (otherRef != null && OVERRIDE_NOT_ALLOWED.equals(override)) {
>

Hi Gintas,

Why? I myself prefer having the parens you removed.
Is this some kind of automated code formatter? Or personnal preference?
I've never been one to rely on implicit associativity rule, and like
explicit parens in those cases.

It's not a -1, but maybe we could have a short conversation here on whether
this is desirable or not,
or even if people just don't care.

Thanks, --DD

Re: Ivy logo as SVG

[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

Re: Ant Contrib

[Dominique Devienne]

On Mon, Jun 5, 2017 at 3:13 PM, Jan Matèrne (jhm)  wrote:

> Some years ago there were a discussion about having ant-contrib a part of
> Ant.
> Result was that it wasn't possible due IP (and therefore legal) reasons.
>
> Having a look at the tasklist [1] there are some I would use:
> ...

* outofdate: no idea
>

 was done by Peter Reilly, who's already an Ant commiter,
so that one should be OK (and we can always ask Peter). Same for  IIRC.

I was a heavy user of  myself, which is much better than
.
I always felt it should have been in Ant proper, but I also didn't have a
problem adding
Ant-Contrib either, so no big deal. FWIW. --DD

Re: [VOTE] Increase minimum Java version for Ivy to Java7

[Dominique Devienne]

On Fri, May 19, 2017 at 7:25 AM, Jan Matèrne  wrote:

> As discussed on this mailing list [1] we should increase the minimum Java
> version [2] from current (Ivy-2.4.0) Java5 to Java 7 (Ivy-2.5.0).
>

+1. --DD

PS: Ivy already has trouble attracting dev attention, so I feel we should
let those making the effort
to work on it not have to jump through hoops by supporting a mostly
obsolete Java5.

Re: Facing Issues with Ant 1.10.0

[Dominique Devienne]

On Mon, Jan 9, 2017 at 4:52 PM, Stefan Bodewig  wrote:

> On 2017-01-09, Sarika Sinha wrote:
>
> > I am trying to incorporate Ant 1.9.8 / 1.10.0 with Eclipse IDE. [...]
> > Where as 1.9.8 works fine with existing Ant framework in eclipse, having
> > many issues with Ant 1.10.0 like below and some more
> > - missing stack frames while debugging Ant with breakpoints
> > - Getting error while using Ant 1.1.0 and Java 1.8 - Specifying an
> > InputHandler is an Ant 1.5.* feature. Please update your Ant classpath to
> > include an Ant version greater than this.
>
> The later makes me suspect this is an Eclipse issue with the Eclipse
> integration for Ant trying to parse Ant's version number by using the
> first digit after the dot and assuming with 1 < 5 you must be using a
> very old version of Ant. I don't think Ant can fix that.
>

Or maybe it's parsing 1.10 in base-2/binary, leading to 1.2 decimal, also <
to 1.5 decimal :)
Joking aside, that's a great hypothesis for the symptoms Stefan! Cheers,
--DD

Re: VOTE Retire IvyDE

[Dominique Devienne]

+1

On Wed, Dec 7, 2016 at 8:41 AM, Jean-Louis Boudart <
jeanlouis.boud...@gmail.com> wrote:

> +1
>
> Le 6 déc. 2016 6:51 PM, "Nicolas Lalevée"  a
> écrit :
>
> > +1
> >
> > Nicolas
> >
> > > Le 6 déc. 2016 à 17:22, Stefan Bodewig  a écrit :
> > >
> > > On 2016-12-05, Jan Matèrne (jhm) wrote:
> > >
> > >> I start a vote for retiring IvyDE.
> > >
> > > +0
> > >
> > > The discussion in the "Ivy" thread makes me think we'd probably want to
> > > update it with new Ivy releases, even if nothing else changes in
> > > between.
> > >
> > > 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 Retire EasyAnt subproject

[Dominique Devienne]

+1

On Wed, Dec 7, 2016 at 8:14 AM, Jean-Louis Boudart <
jeanlouis.boud...@gmail.com> wrote:

> +1
>
> 2016-12-07 1:05 GMT+01:00 Conor MacNeill :
>
> > +1
> >
> > Conor
> >
> >
> > On 5 December 2016 at 18:04, Jan Matèrne (jhm) 
> wrote:
> > > I start a vote for retiring EasyAnt and all its components:
> > >
> > > - core
> > >
> > > - buildtypes
> > >
> > > - plugins
> > >
> > > - skeletons
> > >
> > > - tasks
> > >
> > > - easyant4e
> > >
> > >
> > >
> > > We never had a real release after the incubator.
> > >
> > > The last 'real' activity in vcs was in 09/2015 for EA-Core and 07/2013
> > for
> > > EA4E.
> > >
> > >
> > >
> > > It seems that we havent the community, committers and PMC to hold this
> > > subproject.
> > >
> > >
> > >
> > > The general procedure is described in http://ant.apache.org/
> > processes.html.
> > >
> > >
> > >
> > >
> > >
> > > I start with my +1.
> > >
> > >
> > >
> > >
> > >
> > > Jan
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
> >
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://ant.apache.org/easyant/
>

Re: Multi-Release JARs

[Dominique Devienne]

On Wed, Sep 21, 2016 at 2:08 PM, Jan Matèrne (jhm) 
wrote:

> I did a simple version using plain  and .
>

Nice and simple. Great test. I like it! --DD

Re: JDK9 DateFormat changes

[Dominique Devienne]

On Thu, Jul 28, 2016 at 5:44 PM, Stefan Bodewig  wrote:

> The text for the pattern attribute says "Defaults to MM/DD/ HH:MM
> AM_or_PM or MM/DD/ HH:MM:SS AM_or_PM" - which indicates we should be
> using a (thread-local) SimpleDateFormat rather than rely on the
> standard patterns.


Hi Stefan. I agree, we should retain BC if possible, despite Java9's
efforts to break it. --DD

PS: I've been lurking in the recent JIRA activity regarding this, thank you
for your efforts.
PPS: How to retain BC (thread-local or not), I'll leave it to you and
others :)

Re: [VOTE] Adopt Java8 as Baseline for 1.10 on master Branch

[Dominique Devienne]

On Tue, Mar 22, 2016 at 1:11 PM, Stefan Bodewig  wrote:

> after the recent discussion, I'd like to propose the following:
>
> * create a branch 1.9.x that we use for Java5 compatible maintenance
>   releases - with Jenkins Matrix Builds, of course.
>
> * change the version number of the master branch to 1.10.0alpha
>   (-SNAPSHOT, whatever) and make Java8 the new baseline for that - with
>   Gump and Jenkins Matrix Builds for Java8 (and 9 once it becomes
>   available).
>

+1. --DD

Re: overriding targets that are extension-of an extension point

[Dominique Devienne]

On Mon, Jul 28, 2014 at 5:33 PM, Daniel Walden daniel.wal...@csgi.com
wrote:

 [...] I am making use of target overriding in combination with
 extension-points.
 I have the same problem as that discussed here, which will hit me when I
 upgrade to ant 1.9:
 https://issues.apache.org/bugzilla/show_bug.cgi?id=56337
 [...] In Comment #2 it was mentioned that the latter case is considered
 dangerous,
 but isn't overriding *any* target dangerous in that sense? As a script
 developer I would first
 go and see what I am overriding, see what it depends on, see what it
 extends, etc.

 Is it that the philosophy of removing flow control logic out of
 project-specific scripts
 is not the Ant Way?


Not really, at least the way I understand it.

Reading the thread on BugZilla, and your message, it sounds logical to me
to be able to override an extension-of target just the same way as a
regular target. Yes, it's dangerous in a way, but as you say, so is target
overriding in general. Note that despite having done lots of large complex
builds with Ant, with import and target overriding and all, that was prior
to extension-of's introduction, and I don't even recall if I participated
in the design discussions (or to what extent if I did), so it's possible I
misunderstand, since I never used it myself. Ideally, one should be able to
decide for oneself whether to inherit the depends attribute, or even the
extension-of attribute when overriding targets, and in the case of depends
to inject dependencies before and/or after the ones from the overriden
target. I've always felt the target body-content and its depends
attribute are two separate things, that one often wants to override
separately, and that's why in my build script I often separated the two,
with a empty-body target with depends, and depends-less target doing the
work, the first depending on the second (again, before there was
extension-of). This is all years away for me, so maybe I'm off base here
:). --DD

Re: former svn:externals: subtree merge or submodule

[Dominique Devienne]

On Fri, May 30, 2014 at 4:39 PM, Stefan Bodewig bode...@apache.org wrote:
 On 2014-05-29, Stefan Bodewig wrote:

 AFAIU we have two options to replace the svn:externals, submodules[1] or
 subtrees[2].  I've never used either so haven't got any first hand
 experience.  Anybody else?  I'll also reach out to some co-workers for
 their experience.

 Practically all of my colleages who have used either recommended
 submodules.

Funny, I just watch a GopherCon video that said the reverse.

http://www.youtube.com/watch?v=Y1-RLAl7iOI#t=1300

Was in the context of vendoring (i.e. snapshoting) github dependencies.

FWIW, since I'm GIT-ignorant myself :) --DD

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

Re: migration to git and web site publication

[Dominique Devienne]

On Tue, Apr 29, 2014 at 5:00 AM, Antoine Levy Lambert anto...@gmx.de wrote:
 On Apr 28, 2014, at 1:29 AM, Jan Matèrne (jhm) apa...@materne.de wrote:
 The web sites will remain in svn in any event because svnpubsub is the
 only supported mechanism to maintain web sites AFAIK.
 [...] git/gitpubsub is working?

  Apache Infra does not support gitpubsub for [...] web site.

 git is not the tool of choice to deal with large files such as the ones on 
 dist.apache.org.
 That might be part of the reason why infra supports only svn for the web site.

Just for info, what makes you say that? Why would git be worse than
SVN for large files?

Is that because all clones must copy all versions (compressed deltas
I guess) of those large files? --DD

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

Re: migration to git and web site publication

[Dominique Devienne]

On Tue, Apr 29, 2014 at 12:15 PM, Antoine Levy Lambert anto...@gmx.de wrote:
 On Apr 29, 2014, at 3:32 AM, Dominique Devienne ddevie...@gmail.com wrote:
 Just for info, what makes you say that? Why would git be worse than
 SVN for large files?

 Below see some references found in google, the first one says that each 
 version of a large file is stored
 (or maybe each version with a different md5).

[DD] Read this old thread [1], I get the impression that git supports
deltas both during network transfers, and in the remote repo, but
chooses performance by default over disk-space, by keeping full copies
of files. But git does support delta-compression, even across files
apparently. So I guess it's more the matter of DCVS' in general
forcing you to get the whole repos, that is the main drawback of
storing large files in them. But I'm definitely out of my depth here,
so I'll stop here :). --DD

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

Re: [VOTE] migration to git

[Dominique Devienne]

On Mon, Apr 28, 2014 at 8:54 AM, Conor MacNeill co...@apache.org wrote:
 On 28 April 2014 13:02, Antoine Levy Lambert anto...@gmx.de wrote:
 Let's vote about migrating to git :

+0 on all. --DD

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

Re: DirectoryScanner and strange File entities

[Dominique Devienne]

On Tue, Mar 4, 2014 at 5:05 AM, Conor MacNeill co...@apache.org wrote:
 I agree with Antoine, dropping seems the simplest.

 On 4 March 2014 14:57, Antoine Levy Lambert anto...@gmx.de wrote:
 just dropping them works for me.

 On Mar 3, 2014, at 8:39 AM, Stefan Bodewig bode...@apache.org wrote:
 I think it would be easy to add guards to only treat files as files and
 dirs as dirs, the question is what to do with File objects that are
 neither.  Drop them?  Treat them as files?  Add another user-controlled 
 option?

Just drop them, I agree. --DD

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

Re: [VOTE] Jean-Louis Boudart as a PMC member

[Dominique Devienne]

On Tue, Nov 26, 2013 at 12:04 PM, Nicolas Lalevée 
nicolas.lale...@hibnet.org wrote:

 Jean-Louis has been around for a very long time, owned committership,
 contributed a lot to bring EasyAnt into the Ant PMC, and he is
 participating to the vote in the release process.

 Thus, let's invite Jean-Louis to be part of the PMC.

 Here is my +1


+1. --DD

Re: Target object names

[Dominique Devienne]

On Sun, Dec 2, 2012 at 5:51 PM, Gábor Guta the.ga...@gmail.com wrote:
   If I list the target names of a project from the build node, there
 is an extra target with name . Is this target represents the global
 declarations?

from http://ant.apache.org/manual/using.html :

since Ant 1.6.0, every project includes an implicit target that
contains any and all top-level tasks and/or types. This target will
always be executed as part of the project's initialization, even when
Ant is run with the -projecthelp option.

I believe this  target is the implicit target mentioned. --DD

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

Re: [GUMP@vmgump]: Project test-ant-1.8.x (in module ant-1.8.x) failed

[Dominique Devienne]

On Wed, Oct 10, 2012 at 1:01 PM, Gump Integration Build
bode...@apache.org wrote:
 To whom it may engage...

 This is an automated request, but not an unsolicited one. For
 more information please visit http://gump.apache.org/nagged.html,
 and/or contact the folk at gene...@gump.apache.org.

 Project test-ant-1.8.x has an issue affecting its community integration.
 This issue affects 1 projects,
  and has been outstanding for 128 runs.

FYI: JarTest and hostinfo-test failures:

[junit] Testsuite: org.apache.tools.ant.taskdefs.JarTest
[junit] Tests run: 30, Failures: 1, Errors: 0, Time elapsed: 51.047 sec
[junit]
[junit] Testcase:
testRecreateWithUpdateNewerFile(org.apache.tools.ant.taskdefs.JarTest): FAILED
[junit] jar has been recreated in testRecreateWithUpdateNewerFile
[junit] junit.framework.AssertionFailedError: jar has been
recreated in testRecreateWithUpdateNewerFile
[junit] at junit.framework.Assert.fail(Assert.java:57)
[junit] at junit.framework.Assert.assertTrue(Assert.java:22)
[junit] at junit.framework.TestCase.assertTrue(TestCase.java:192)
[junit] at
org.apache.tools.ant.taskdefs.JarTest.testRecreate(JarTest.java:139)
[junit] at
org.apache.tools.ant.taskdefs.JarTest.testRecreateWithUpdateNewerFile(JarTest.java:123)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit] at java.lang.reflect.Method.invoke(Method.java:601)
[junit] at junit.framework.TestCase.runTest(TestCase.java:176)
[junit] at junit.framework.TestCase.runBare(TestCase.java:141)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:122)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:142)
[junit] at junit.framework.TestResult.run(TestResult.java:125)
[junit] at junit.framework.TestCase.run(TestCase.java:129)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:255)
[junit] at junit.framework.TestSuite.run(TestSuite.java:250)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:520)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1060)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:884)
[junit]
[junit]
[junit] TEST org.apache.tools.ant.taskdefs.JarTest FAILED

[au:antunit] Build File:
/srv/gump/public/workspace/ant-1.8.x/src/tests/antunit/taskdefs/hostinfo-test.xml
[au:antunit] Tests run: 5, Failures: 2, Errors: 0, Time elapsed: 2.931 sec
[au:antunit] Target: testUndef took 1.39 sec
[au:antunit] Target: testApacheNoPrefix  FAILED
[au:antunit]at line 70, column 22
[au:antunit]Message: Assertion failed
[au:antunit]took 0.387 sec
[au:antunit] Target: testReverse took 0.927 sec
[au:antunit] Target: testApache  FAILED
[au:antunit]at line 53, column 22
[au:antunit]Message: Assertion failed
[au:antunit]took 0.002 sec
[au:antunit] Target: testLocal took 0.002 sec

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

Re: [GUMP@vmgump]: Project test-ant-no-xerces (in module ant) failed

[Dominique Devienne]

On Wed, Oct 10, 2012 at 12:38 PM, Gump Integration Build
bode...@apache.org wrote:
 This is an automated request, but not an unsolicited one. For
 more information please visit http://gump.apache.org/nagged.html,
 and/or contact the folk at gene...@gump.apache.org.

 Project test-ant-no-xerces has an issue affecting its community integration.
 This issue affects 1 projects,
  and has been outstanding for 128 runs.

FYI: XMLResultAggregatorTest and archives-test failures:

[junit] Testsuite:
org.apache.tools.ant.taskdefs.optional.junit.XMLResultAggregatorTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.192 sec
[junit]
[junit] Testcase:
testFrames(org.apache.tools.ant.taskdefs.optional.junit.XMLResultAggregatorTest):
   Caused
an ERROR
[junit] Errors while applying transformations: Fatal error during
transformation
[junit] Errors while applying transformations: Fatal error during
transformation
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.AggregateTransformer.transform(AggregateTransformer.java:267)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.XMLResultAggregator.execute(XMLResultAggregator.java:158)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.XMLResultAggregatorTest.testFrames(XMLResultAggregatorTest.java:82)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit] at java.lang.reflect.Method.invoke(Method.java:601)
[junit] at junit.framework.TestCase.runTest(TestCase.java:176)
[junit] at junit.framework.TestCase.runBare(TestCase.java:141)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:122)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:142)
[junit] at junit.framework.TestResult.run(TestResult.java:125)
[junit] at junit.framework.TestCase.run(TestCase.java:129)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:255)
[junit] at junit.framework.TestSuite.run(TestSuite.java:250)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:520)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1060)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:884)
[junit] Caused by: Fatal error during transformation
[junit] at
org.apache.tools.ant.taskdefs.XSLTProcess.handleTransformationError(XSLTProcess.java:1271)
[junit] at
org.apache.tools.ant.taskdefs.XSLTProcess.process(XSLTProcess.java:860)
[junit] at
org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:388)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.AggregateTransformer.transform(AggregateTransformer.java:265)
[junit] ... 17 more
[junit] Caused by: Fatal error during transformation
[junit] at
org.apache.tools.ant.taskdefs.optional.TraXLiaison.fatalError(TraXLiaison.java:531)
[junit] at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:895)
[junit] at
org.apache.tools.ant.taskdefs.optional.TraXLiaison.readTemplates(TraXLiaison.java:300)
[junit] at
org.apache.tools.ant.taskdefs.optional.TraXLiaison.createTransformer(TraXLiaison.java:317)
[junit] at
org.apache.tools.ant.taskdefs.optional.TraXLiaison.transform(TraXLiaison.java:178)
[junit] at
org.apache.tools.ant.taskdefs.XSLTProcess.process(XSLTProcess.java:850)
[junit] ... 19 more
[junit] Caused by:
javax.xml.transform.TransformerConfigurationException: Could not
compile stylesheet
[junit] at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:885)
[junit] ... 23 more
[junit]
[junit]
[junit] TEST
org.apache.tools.ant.taskdefs.optional.junit.XMLResultAggregatorTest
FAILED

[au:antunit] Build File:
/srv/gump/public/workspace/ant/src/tests/antunit/types/resources/archives-test.xml
[au:antunit] Tests run: 5, Failures: 0, Errors: 3, Time elapsed: 0.197 sec
[au:antunit] Target: testCircularReference took 0.001 sec
[au:antunit] Target: testMixingZipsAndTars  caused an ERROR
[au:antunit]at line 43, column 29
[au:antunit]Message:
/srv/gump/public/workspace/ant/src/tests/antunit/types/resources/${ant.home}/lib
does not exist.
[au:antunit]took 0.004 sec
[au:antunit] Target: testReference  caused an ERROR
[au:antunit]at line 70, column 29
[au:antunit]Message:
/srv/gump/public/workspace/ant/src/tests/antunit/types/resources/${ant.home}/lib
does not exist.
[au:antunit]took 0.002 sec
[au:antunit] Target: testExtractJars  caused an 

Re: [GUMP@vmgump]: Project test-ant (in module ant) failed

[Dominique Devienne]

On Wed, Oct 10, 2012 at 12:20 PM, Gump Integration Build
bode...@apache.org wrote:
 Project test-ant has an issue affecting its community integration.
 This issue affects 1 projects,
  and has been outstanding for 128 runs.

FYI: archives-test failures:

[au:antunit] Build File:
/srv/gump/public/workspace/ant/src/tests/antunit/types/resources/archives-test.xml
[au:antunit] Tests run: 5, Failures: 0, Errors: 3, Time elapsed: 0.459 sec
[au:antunit] Target: testCircularReference took 0.002 sec
[au:antunit] Target: testMixingZipsAndTars  caused an ERROR
[au:antunit]at line 43, column 29
[au:antunit]Message:
/srv/gump/public/workspace/ant/src/tests/antunit/types/resources/${ant.home}/lib
does not exist.
[au:antunit]took 0.004 sec
[au:antunit] Target: testReference  caused an ERROR
[au:antunit]at line 70, column 29
[au:antunit]Message:
/srv/gump/public/workspace/ant/src/tests/antunit/types/resources/${ant.home}/lib
does not exist.
[au:antunit]took 0.002 sec
[au:antunit] Target: testExtractJars  caused an ERROR
[au:antunit]at line 24, column 29
[au:antunit]Message:
/srv/gump/public/workspace/ant/src/tests/antunit/types/resources/${ant.home}/lib
does not exist.
[au:antunit]took 0.001 sec
[au:antunit] Target: testZipManualExample took 0.398 sec

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

Re: Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all local, New: global task

[Dominique Devienne]

On Sun, Sep 16, 2012 at 5:24 PM, Matt Benson gudnabr...@gmail.com wrote:
 [...] only I had intended to support regex matching.

Can't propertyset's selection logic be reused? --DD

PS: Didn't look at the patch, so maybe it is.

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

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

[Dominique Devienne]

On Sat, Feb 18, 2012 at 11:02 AM, Gilles Scokart gscok...@gmail.com wrote:
 For me, one feature for a 2,0 would be a different style of dependency
 tree that would allow better parallel execution (on the same machine,
 or why not on distributed machines).

Agreed. I was in fact thinking of this one as well when I wrote my
integrated build generator/manipulator.

 I see the 'targets' being more declarative, becoming a state
 transition saying : I need this resources in that state, I will use
 this other resources (and I don't want the to change during my
 execution, and I will produce this other resources in that other
 state.

Yep, with the modulo that I see 'targets' in a fine-grained way, i.e.
you know the graph of actions to transition all input files/resources
and come up with the optimum way to achieve the stated goals given the
hardware resources (single cpu computer, multi-core computer, grid of
computers). That's basically Makefile territory in a way, and similar
to what Peter's outofdate does as well. Right now Ant's targets
typically deal with macro dependencies (build all .class file before
building all .jar ones), and not micro dependencies at the file
level, so the opportunities to do stuff in parallel are lessened IMHO.
One reason Ant doesn't care much about this kind of parallelism is
that Javac is fast-enough and cannot be distributed really, and it's
the compilation of native languages like C++ that benefit most from
those, and that's not Ant's territory in fact.

 The dependency tree would be an logical engine finding the shortest
 path to go to the desired state, using parallel/distributed processing
 when possible.

 That's what I miss with existing build system : I want to go as
 quickly as possible to a desired build state (from a current state).

Have you read the 4 part series about how Google does its builds?
Below's a link to part#4. --DD

http://google-engtools.blogspot.com/2011/10/build-in-cloud-distributing-build.html

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

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

[Dominique Devienne]

2012/2/17 Bruce Atherton br...@callenish.com:
 A lot of companies have their own, internally written build file generators
 just so their build systems are consistent and exactly what they want. Our
 Related Projects and External Tools page has some of these that were made
 public, I suspect.

 Surely there is a better way than requiring users of Ant to write generators
 to deal with the complexity and keep it customized.

At one point I did write a build(s) (XSLT-based) generator
specifically for a large and hairy project. Later I rewrote the whole
thing with macrodefs. But my point is that I don't view build
generators as bad, in fact it often helps IMHO to have a declarative
custom DSL (in XML in my case, so read DSL with a grain of salt)
that's used as the input for generating Ant build fragments, and have
those fragments be able to insert them into the target graph. I've
also long felt Ant needed generalized if/unless/os (and my own
extensions like ifTrue, unlessTrue, when) on any XML tag (or
UnknownElement if you prefer), just read the recent add if/unless to
javac's compilerarg thread. macrodef is nice, but you can't use
it for arbitrary, *and conditional*, XML fragments inside tasks. All
those things you can often do more easily with a generator, but that's
often cumbersome, doesn't play well with IDEs, etc... I guess I'm
saying I've often wished for generator-like features as a built-in
part of Ant. Do you see what I'm saying? Ant now does late
conversion from UnkownElement to actual configuration of the Java
code it maps to, and a way to influence/transform that almost AST-like
graph would make Ant more powerful and flexible, perhaps at the
expense of creating dialects unreadable to someone not familiar with
them. Given Ant's XML roots, perhaps a tighter built-in integration
with XSLT to dynamically rewrite the build at runtime/buildtime
would be one way to achieve what I envision (notwithstanding the talks
of non-XML front-ends of course).

Stepping of my soapbox now :)  What I'm saying has nothing to do with
Java7, nor necessarily require a rewrite either. --DD

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

Re: [VOTE] Drop JDK 1.4 after 1.8.3

[Dominique Devienne]

On Sat, Jan 28, 2012 at 6:54 AM, Stefan Bodewig bode...@apache.org wrote:
 On 2012-01-27, Jesse Glick wrote:
 As suggested in 1.8.3 thread, I propose we drop JDK 1.4 support in
 trunk after Ant 1.8.3 is released. It is long past EOL
 http://www.oracle.com/technetwork/java/eol-135779.html and
 cumbersome to even get installed for testing. (Note that JDK 5 is also
 past EOL, but I am not proposing dropping JDK 5 support in this vote.)

 +1 for dropping Java 1.4 support in trunk after 1.8.3.  I'm with Maarten
 that we should switch to 1.9.0 in trunk then.

+1. --DD

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

Re: Sources of the ant jars into the maven repository

[Dominique Devienne]

2011/4/12 Nicolas Lalevée nicolas.lale...@hibnet.org:
 The more I used automatic dependency management and working with open source 
 project, the more I expect to quickly have a development environment in which 
 I can debug. So I often expect to have the sources attached to the jar I have 
 automatically download. But for the ant jars, there are no source attached.

[DD] Agreed. I did something similar in a now defunct ad-hoc Ivy
look-alike, and it also guarantees access to the exact sources used to
produce the jar(s) without having to hunt for them in the SCM using a
tag or rev.

 Currently the release of ant doesn't publish any source in the maven 
 repository via nexus. So I would like to change the build so that each ant 
 jar has its corresponding source jar. And I think I'll also make an 
 ant-1.8.3-javadocs.jar too. Theses jars would be only published to the maven 
 repository, they won't be part of the distribution tgz.

[DD] +1.

 Is there any objection regarding the publication of such jars ?

[DD] Sounds reasonable to me. --DD

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

Re: Can Anybody Fix our Logos?

[Dominique Devienne]

On Tue, Nov 16, 2010 at 9:13 AM, Stefan Bodewig bode...@apache.org wrote:
 Conor, Bruce, Dominique or Steve (or who else has been around in 2002)
 do you still have a vector format version of the logo around?  Christoph
 Wilhelms may have, I could ping him if nobody else can find it.

Sorry Stefan, I think this was before I got into Ant.
Note also that my graphic designer skills are limited to MS Paint ;) --DD

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

Re: Submitting EasyAnt project to Apache Software Foundation

[Dominique Devienne]

On Wed, Nov 17, 2010 at 4:42 AM, Jean-Louis Boudart
jeanlouis.boud...@gmail.com wrote:
 Yes you're right both tools share the same objectives.
 There are a lot differences between Gradle and EasyAnt though.

 Gradle *can use* ant + ivy whereas easyant is *based over* ant + ivy.

Thanks for this good write-up. A lot of it resonates well with my own
beliefs and despite not having dug into EasyAnt, your thorough
philosophy discussion makes me more supportive of EasyAnt's
integration into the Ant ecosystem, especially given that it gives
back to Ant and Ivy as you pointed out. I wouldn't have -1'd EasyAnt
in the first place. Thanks, --DD

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

Re: svn commit: r1035335 - in /ant/core/trunk/src/main/org/apache/tools/ant: ProjectHelper.java helper/ProjectHelper2.java taskdefs/BindTargets.java

[Dominique Devienne]

On Mon, Nov 15, 2010 at 10:09 AM,  hi...@apache.org wrote:
 +    public final static class OnMissingExtensionPoint {

I was actually thinking of
org.apache.tools.ant.types.EnumeratedAttribute when I mentioned an
enum, because from my recollection IntrospectionHelper was aware of
it, but perhaps the valueOf() method you defined is a similar
protocol / convention IH is aware of as well, and the derivation
from EnumeratedAttribute is not necessary? --DD

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

Re: svn commit: r1035335 - in /ant/core/trunk/src/main/org/apache/tools/ant: ProjectHelper.java helper/ProjectHelper2.java taskdefs/BindTargets.java

[Dominique Devienne]

2010/11/15 Nicolas Lalevée nicolas.lale...@hibnet.org:
 I saw that class EnumeratedAttribute, but it helps to define enums only from 
 the IntrospectionHelper. When I started to use that class, the strings 
 no-so-enum were still leaked through the Java API of the ProjectHelper.

Right.

 So I implemented a class that behave like the Java 5 enums, where there is no 
 possibility at compile time to have any other value than the predefined ones.

Right. Note that that if it was serializable, new instances would
still be recreated by the framework, and would need to be replaced
before the world could see them (using readReplace()).

 Then on the IntrospectionHelper side, it still see a simple string. So the 
 code that checks the values is still in the implementation of the target 
 (well actually delegated with some error rethrowing).

Which still leaves the door open for passing any string at the API
level. But I agree that EnumeratedAttribute's string-based approach is
not ideal either.

 But maybe I should continue, make an EnumeratedAttribute which make the 
 bridge with the enum like class OnMissingExtensionPoint. But it won't save 
 much code.

Yep.

 I got an idea. What about creating an interface Enum which will be a marker 
 for classes which are expected to have a valueOf static method (like for 
 every enum in java 5), and have IntrospectionHelper support that ? I think 
 that it could be done easily in IntrospectionHelper#getEnumSetter .
 WDYT ?

Given that IH already handles java.lang.Enum, maybe it's too late to
do this. Then again, Ant being JDK 1.4 based could use it.

This is all nitpicking on my part already, so don't worry about it.
What you have it fine. --DD

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

Re: svn commit: r1032922 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/BindTargets.java

[Dominique Devienne]

2010/11/9 Nicolas Lalevée nicolas.lale...@hibnet.org:
 Note: I'll commit the unit test and doc I have wrote about this task. I don't 
 want to enforce anything, just share the work I have done. It is still up to 
 debate and can still be reverted.

Well, process-wise we tend to discuss things out on the ML before
committing, or go thru the sandbox. As Stefan, I still don't quite see
the use case, or more precisely why the use case you describe can't be
achieved some other way. --DD

PS: There's no enum-like type for onMissingExtensionPoint? Taking it
as a string allow passing anithing.

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

Re: svn commit: r1032990 - in /ant/core/trunk: WHATSNEW docs/manual/tasklist.html src/main/org/apache/tools/ant/taskdefs/BindTargets.java src/main/org/apache/tools/ant/taskdefs/defaults.properties src

[Dominique Devienne]

On Tue, Nov 9, 2010 at 8:14 AM,  hi...@apache.org wrote:
 +  target name=binded

%s/binded/bound/g

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

Re: svn commit: r1032931 - /ant/core/trunk/src/main/org/apache/tools/ant/Main.java

[Dominique Devienne]

On Tue, Nov 9, 2010 at 5:35 AM,  hi...@apache.org wrote:
 +                    msg.append(   depends of: );

That doesn't sound correct somehow.  depends on ?  dependent of/on ?

Could native speakers chime in please? Thanks, --DD

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

Re: svn commit: r1032922 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/BindTargets.java

[Dominique Devienne]

2010/11/9 Nicolas Lalevée nicolas.lale...@hibnet.org:
 That's what I thought, this proposed task being quite trivial and having no 
 side effect.
 Obviously for larger patch or behavior change I would come first to the ML, 
 like I did for the project helpers for instance.

Fair enough. A follow up email to the ML is good though, to explain
rational etc... before the commit watch patrol has to ask for it :)

 the use case, or more precisely why the use case you describe can't be
 achieved some other way.

 It can definitively be handled without that task. With Ant 1.8.1, to bind the 
 targets jar and source to an extension point dist is to create a third 
 target:
 target name=bind-to-dist depends=jar,source extensionOf=dist /

 I find it cleaner to avoid creating yet another target and implement this 
 simple bindtargets task.
 If there are objection, I'll remove it. Use that work around for classical 
 build files. And put this task in EasyAnt from which I got the idea.

Not being quite up-to-speed on extension-point, I wasn't sure, thanks.

The reason I'm a little reluctant on bindtargets is that it's a task
that affects the dependency graph of targets, but bypassing the normal
means to do that, via target. Since it's a task, it can be run at
any time, conditionally or not, inside a target or not, and especially
after the dependency graph was computed, when it does/can change the
dependency graph. Maybe that's OK, but it just make me a little
uncomfortable and I'm not sure we see all the possible ramifications.

It doesn't mean I'm necessarily against it, but if it's only
notational convenience, and the alternative is hardly longer or
uglier, I'm not sure it's worth it. My $0.02. --DD

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

Re: svn commit: r1032922 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/BindTargets.java

[Dominique Devienne]

2010/11/9 Nicolas Lalevée nicolas.lale...@hibnet.org:
 From the doc you just checked in, I now read:

 +pThe bindtargets task may only be used as a top-level task. This means 
 that
 +it may not be used in a target./p

 So maybe I was wrong. I didn't see the code enforcing that though?
 What prevents this task from being inside a target?

 I have to admit I have blindly trusted the existing code in ImportTask.java. 
 In the execute there is:
        if (getOwningTarget() == null
            || !.equals(getOwningTarget().getName())) {
            throw new BuildException(import only allowed as a top-level 
 task);
        }

I missed that, thanks. If the doc clearly state that this is just
syntax sugar and show what the equivalent syntax is using target,
then I have no further comments ;) --DD

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

Re: [VOTE] Accept Bushel Donation

[Dominique Devienne]

On Fri, Nov 5, 2010 at 9:45 AM, Stefan Bodewig bode...@apache.org wrote:
 So, do we want to accept the Bushel donation?

+1. --DD

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

Re: How do I share data between custom Ant tasks?

[Dominique Devienne]

On Mon, Oct 25, 2010 at 11:19 AM, Kevin Connor Arpe kevina...@gmail.com wrote:
 I wrote a StackOverflow.com post, but was unable to get help on this issue.

SO is great, but the official user and dev lists is the best place to
ask Ant questions.

 ?xml version=1.0 encoding=UTF-8?
 project name=MyTask basedir=. default=init
   target name=init
           description=test the custom task
   
      taskdef name=CustomTask1
               classname=AntCustomTask1
               classpath=C:\my_custom_ant_task_class_files
      /
      taskdef name=CustomTask2
               classname=AntCustomTask2
               classpath=C:\my_custom_ant_task_class_files
      /
      CustomTask1/
      CustomTask2/
   /target
 /project

 Do all of the above and you will see alloc logged twice. I cannot
 get these two custom tasks to share the big data.

Because each is loaded thru a different class loader, and there's a
different static member per independent class loader. If you are new
to Java, class loaders is a very interesting advanced topic to look
into btw :)

I don't remember the details, but it's likely your two independent
taskdef that force using separate class loaders. Using either a
single taskdef loading a .properties file, or using a classpathref
might use the same classloader instead. Also putting your tasks into
an AntLib in its own Jar with a proper antlib.xml manifest would also
likely use a single class loader.

But as Jeffrey wrote, you could have your tasks read/write properties
to communicate, or pass them a reference to a datatype instance as
well.

mytype id=foo ...  ... /mytype
mytask1 mytyperef=foo.../mytask1
mytask2 
  mytype ref=foo / !-- or is it idref? I don't recall the naming
convention --
  ...
/mytask2

Trouble is, reference-handling in task is not implicit, you have to
manually code it in, and there are many examples in the code. Note the
two ways references are passed to tasks typically, via a xyzref
attribute, or a nested xyz with only a ref (or idref?) attribute.

Hope this help. Sorry my Ant is getting very rusty. --DD

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

Re: Testlistener Events in JUnit Slows Down Forked Tests in 1.8.x

[Dominique Devienne]

On Mon, Aug 9, 2010 at 2:42 AM, Stefan Bodewig bode...@apache.org wrote:
 The short story is that with the changed StreamPumper code and
 useAvailable=true forked JUnit tests now take a longer time because the
 test time is influenced by the time it takes to send the output for test
 events back to Ant.

 For more background http://marc.info/?t=12797517134r=1w=2.

 Testlistener events have been introduced to support advanced UIs that
 show progress bars while running the tests
 https://issues.apache.org/bugzilla/show_bug.cgi?id=31885

 If I disable those events, tests in 1.8.x finish as quickly as they do
 in 1.7.1.

 I plan to add an disableTestListenerEvents (any ideas for a different
 name?)  attribute to junit that can be used to disable Testlistener
 events (that's trivial to implement, all the necessary hooks are already
 there), set it to false for backwards compatibility reasons and strongly
 recommend to set it true unless you really need them (running inside of
 NetBeans) in the manual page as well as WHATSNEW.

Makes sense.

 We could add a YAMP (yet another magic property) ...

Might be useful as well, yes.

 Comments?

Just a bit thank you? :) --DD

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

Re: [VOTE] Release Manuals of Last Five Ant Releases

[Dominique Devienne]

On Mon, Jul 19, 2010 at 10:59 AM, Peter Reilly
peter.kitt.rei...@gmail.com wrote:
 +1 release the manuals

+1 as well. --DD

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

Re: bug in DOMElementWriter

[Dominique Devienne]

On Mon, Jun 28, 2010 at 4:03 AM, Stefan Bodewig bode...@apache.org wrote:
 By now I tend to agree with Jon that DOMElementWriter should encode \n,
 \r and \t when writing attribute values (and only when writing attribute 
 values).

Despite giving an example involving nested text (so technically
correct ;), and mentioning whitespace normalization in passing, I now
see that I missed Jon's issue was with attribute values, Apologies.
Now I stand corrected by Stefan and Jesse, and I can go back hiding in
my little corner where I should have remained. --DD

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

Re: bug in DOMElementWriter

[Dominique Devienne]

On Sat, Jun 26, 2010 at 6:54 PM, Jon Stevens latch...@gmail.com wrote:
 For example, attr=amp; comes out as attr=amp; and not attr=... I
 don't have to write attr=amp;amp; to get what I want. The same is true
 with attr=gt;... it comes out as attr=gt; instead of attr=. This is
 all because DOMElementWriter.encode() is smart about those entities.

 attr=#10; should come out as attr=#10;, not attr=\n

Well, I'm afraid Antoine is right, and the comparison you make is not fair.

, , and  are special in XML, and must always be encoded in
attribute values and textual content. \n is not.

echoxml never sees the amp; text, it sees whatever the XML parser
reports, a , and the XML serializer Ant uses knows it must encode
that char into amp;, thus it ends up back the way it was. But with
\n, which is just like any other character*, the serializer doesn't do
anything special, and the output the also contain a plain \n.

The is XML, and Ant can do nothing about it. The textual
representation of the XML infoset doesn't matter, what matters is
the info, and the XML parser doesn't always report the info as it was
in the text of the XML but as it's equivalent is. Most parsers offer
configurations that control how it reports stuff, but you can never
get a fully exact representation of the XML text, without digging into
the parser itself. --DD

* Well it's whitespace, so it could be normalized too.

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

Re: bug in DOMElementWriter

[Dominique Devienne]

On Sun, Jun 27, 2010 at 8:55 PM, Jon Stevens latch...@gmail.com wrote:
 However, the character that went into the attribute was not a \n, it was a
 #10;. I'd expect ant to give me #10; back out, not \n. The point of
 echoxml is to echo xml, is it not? In that case, the point here should be
 to echo out the encoded value as xml, not something that is useless.

Jon, in XML land #10; *is* \n, whatever you say about it.

See 
http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references

You *can* have a plain '\n' char (i.e. an actual LF, not '\\' and 'n')
in XML, and for the parser that's the *same*.

Furthermore, whatever you feed your echoxml-generated XML file to,
will / should not care either whether it see a '\n' or a #10; if it
uses a compliant XML parser.

Don't get hand up on the textual  representation of the XML file. This

foo#10;/foo

and this

foo
/foo

is exactly the same thing as far as XML is concerned.

If you absolutely want your #10; in the echoxml output, you must
follow Antoine's advice.

I suggest you read more on XML and again Ant, for better or worse,
uses an XML parser so will only see '\n' and not your XML char entity.
--DD

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

Re: [Proposal] Capture attributes in unknown namespaces

[Dominique Devienne]

On Thu, Jun 24, 2010 at 2:50 PM, Danny Yates da...@codeaholics.org wrote:
 What would be kind of cool would be that if the parser encounters attributes
 in a namespace that it doesn't recognise, then instead of ignoring them (as
 it does now), it records them and makes them available through an API on the
 Project and Target objects. This would allow the executor to inspect them.

Something related to that was discussed in the past to allow arbitrary
cross-cutting attributes to be added to tasks which wouldn't
normally support them, typically in the context of adding global
ant:if and ant:unless attributes (or maybe I just thought about it,
I'm no longer sure ;)

 I realise this is very specific to my parallel executor project, but I think
 adding it would be a non-breaking change that wouldn't have any impact on
 existing consumers of the API.

True. But I'd be more in favor of an opt-in framework, where you
explicitly tell Ant to record attributes from specific namespaces.
From the list, I think other people also use extra markup in their
builds for external tools, so in their case they don't need to
record those attributes for examples.

 What do you folks think?

I think it's a good idea. There are design considerations like, should
it be free form string=string recorded as-is, or should these
attributes be processed like ordinary attributes Ant deals with to do
property expansion and conversion to Java types (like boolean
accepting true/on/yes as a true). For example, imagine you group
your extra attributes into a DataType part of an AntLib bound to that
extra namespace, the DataType could be instantiated as usual by Ant
provided it looked at the UnknownElement specifically for a given
namespace, and then the DataType is bound somehow to the task or
type or target. That way everything is typed as usual, and could be
made to reuse a lot of the existing code/facilities. See what I mean?
--DD

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

Re: missing extension-point behaviour

[Dominique Devienne]

On Wed, Jun 23, 2010 at 5:34 AM, Stefan Bodewig bode...@apache.org wrote:
 I've taken your patch and modified it locally so the attribute is now
 named onMissingExtensionPoint (and the value error has been renamed to
 fail).  I've also added constants for the three possible attribute
 values to ProjectHelper.

 All of this is still open for debate.

I'm not sure I understand the problem at hand, and thus the need for
the proposed solution.

When a build file declares extensionOf=foo on a target, it is in
control and can easily make sure it imports the build file that does
declare the foo extension. I don't see why a build wouldn't in fact,
since it makes no sense IMHO to write extensionOf=foo if you don't.
What am I missing? I can't see the situation that would warrant such a
new feature, that a little refactoring of the builds couldn't solve by
splitting into separate common+build+deploy specific parts. Thanks,
--DD

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

Re: missing extension-point behaviour

[Dominique Devienne]

On Wed, Jun 23, 2010 at 2:17 PM, Danny Yates da...@codeaholics.org wrote:
 [...]
 In essence, you describe the build file which uses extensionOf
 importing/including the build file which has the extension-points, but we're
 trying to work the other way around and throwing two master build files
 into the mix!

 I hope that's a bit clearer?

That is clearer indeed, and the reason why I didn't get it, because
what you are trying to achieve is upside-down compared to my
thinking and I suspect the way extension-point where designed to be
used. I kinda understand your rational for doing it that way though,
even though I think I would have gone for a different design,
possibly:

1) merge build.xml and deploy.xml and be done with it. Somehow I
suspect the target sets are mostly orthogonal and the merge is
possible.
2) do exactly what you say you didn't want to do :) i.e. do it
right-side-up by having each service script import (now helper as
opposed to master) build(er).xml and deploy(er).xml. To build all
services, you'd subant into each service-specific script.

So I guess now I'm more +/-0 on this new feature, rather than plain -0.5. --DD

PS: You want fileset dir=service-descriptors
includes=*-descriptor.xml / to ensure you don't scan the whole of
${basedir}. Antoine's optimization probably recognize that case, but
it's always better to be as specific with the fileset's dir attribute
as you can.

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

Re: missing extension-point behaviour

[Dominique Devienne]

On Wed, Jun 23, 2010 at 4:27 PM, Danny Yates da...@codeaholics.org wrote:
 Thanks for the pointer ref fileset

 I'm not sure that merging the two builds is possible for various reasons.
 Technically, yes; but for security reasons, no.

 Also, I'd really like it so that I don't have to subant (or ant or
 antcall or whetever) into the service-specific scripts, because there are
 (will be) a large number of touch points, and I don't want to have to go and
 find each of them whenever a new service is added. As I have it now, adding
 a new service is as simple as dropping in a new service descriptor.

You already have these descriptor builds, so importing them all in 2
builds, or have them import 2 builds is not much different, and that's
the same number of touch points if you add a new service.

But I'll stop arguing, I don't know the specifics and you obviously
made these conscious choices for a reason. I'm still a bit on the
fence, but that doesn't matter, you already got buy in from Stefan, so
my guess is that you're mostly home free having this feature enabled
given that no other commiters chimed in ;) Cheers, --DD

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

Re: [VOTE] Remove commercial tasks from Ant

[Dominique Devienne]

On Sat, Jun 19, 2010 at 1:38 PM, Bruce Atherton br...@callenish.com wrote:

 1. Should the following commercial tasks be dropped from being distributed
 with the Ant release?

+1 to all.

 2. Should the commercial tasks that are voted for dropping from Ant core
 above be established in their own Antlibs in the sandbox?

+1.

--DD

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

Re: property file=... prefix=.../ what to expand?

[Dominique Devienne]

On Mon, Jun 21, 2010 at 2:18 AM, Stefan Bodewig bode...@apache.org wrote:
 loadproperties already can.
 [...]
 loadproperties
  filterchain
    prefixlines prefix=foo./
  /filterchain
 /loadproperties

 you get
 foo.y=${x}

Well filterchain likely applies on the property file text, not its
infoset, so will prefix comments and continuation lines as well,
leading to an possibly incorrect file or changed property values. So
it's not quite a general solution. My propsed ${.:x} allows the
property-file-writer to be in control, and if we separated the prefix
attribute for property writes and property reads, providing a read
search resolution path to allow either read local unprefixed first,
then local prefixed, then global, the build-file-writer is in control,
and the various permutations of those 3, that should cover all
possible situations. I'm not sure this is that high priority though.
Just my $0.02. --DD

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

Re: property file=... prefix=.../ what to expand?

[Dominique Devienne]

On Fri, Jun 18, 2010 at 2:47 AM, Stefan Bodewig bode...@apache.org wrote:
 On 06/17/2010 11:10 AM, Stefan Bodewig wrote:
 Assume

 x=x
 y=${x}

 and that there is no property x defined prior to

    property file=.../

 then ${y} will be x.  Using

    property file=... prefix=foo/

 ${foo.y} in Ant 1.8.0 is ${x} while it is x in 1.8.1 - the properties
 file was able to refer to its own properties without knowledge of the
 prefix.

This feels natural to me, and ${foo.y}'s value being ${x} surprising indeed.
But conversely, if property x is already defined, I'd expect that
value to prevail, according to classic immutability rules.
Yet as you point out we can't have both behaviors at the same time if
I understand correctly.

Can't property expansion in a property file be done entirely before
the prefix is applied?
It seems that this way both cases would work, and the prefix attribute
could be documented to be applied a-posteriori on the newly created
properties?
Hmmm, a caveat of this approach is that assigning to an already
defined property would have no effect, unless its name was already
prefixed... I think I've cornered myself in :)

 but breaking the established behavior of the widely used property
 task seems a bad idea.

 I tend to agree, but we are really talking about some sort of bordercase.

Another impractical idea quite likely, but what about a ${.:x}
notation, to force the expansion of propery x to point to the local
context, taking the prefix into account? It gives a way about of this
conundrum maybe, if it can be implemented that is, which I haven't
checked out course. Just throwing the idea around. --DD

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

Re: [Vote] Augment feature

[Dominique Devienne]

 1. Are you in favor of adding the augment feature to Ant?

 +1

 2. Are you in favor of an attribute that allows references to
be marked as final, to avoid augmentation?

+0

 3. If a final attribute is decided upon, do you think it
should default to false?

+1

--DD

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

Re: task that allows augmentation of previously declared references

[Dominique Devienne]

On Wed, Feb 24, 2010 at 10:39 PM, Matt Benson gudnabr...@gmail.com wrote:
 I'd like to direct the Ant developers' attention to
 https://issues.apache.org/bugzilla/show_bug.cgi?id=48798 for discussion.
  I'm hesitant to commit this outright because I anticipate this being
 somewhat controversial.  If noone responds I'll just assume it's not
 controversial and act accordingly.  ;)

You mean like adding path elements to a path, or nested selectors to
a selector? That would be useful indeed.

If attributes can be changed as well, that's not aumentation anymore,
but editing, no?
Can only top-level elements be augmented, or id'd nested elements as well?
Can one prevent augmentation while still having an id attribute?
(like final=true)

Stefan would like to see the code, but I'd like to see build snippets
from the user side of it ;) --DD

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

Re: task that allows augmentation of previously declared references

[Dominique Devienne]

On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart gscok...@gmail.com wrote:
 Did you have any example to demonstrates the benefits of such task ?

The benefits with conjunction with import could be important, in
that you can mix-in specialized pre-defined builds dealing with
specific concerns (like JAXB pre-compilation for example) and have
those builds implicitly augment the classpath or Javac source path
appropriately for example (as documented in those builds, and you do
explicitly import those, so are kinda in control). Sure, it does open
the door for some complexity, and Ant would enter some un-chartered
waters indeed, but when trying to design reusable builds in the
(distant now) past, I've often felt the need for such a feature. Yet
it doesn't necessarily mean that would have been the right solution
either. I'd be interesting to have the input of the EasyAnt people on
the matter in fact. Maybe an opt-in approach, explicitly adding
final=false on those datatype ids *designed* for extension, would be
a more conservative introduction of this feature, although that does
force to have perfect hindsight into what will be necessary to
extend/augment or not. --DD

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

Re: Ant picks class files from current directory rather than provided jar in classpath

[Dominique Devienne]

On Fri, Feb 19, 2010 at 4:42 PM, krats princekart...@gmail.com wrote:
 [...] directly use javac to compile , the behavior is what I would expect. So 
 for
 example in the case I mentioned, assuming source structure src\f1\f1.java
 and src\f2\f2.java, if I already create f1.jar and put it in lib, and
 assuming f2.java imports a class in f1.java, if I do

 javac -classpath lib\f1.jar f2\f2.java

 then, it doesnt create f1\f1.class. Instead it uses the import f1 class from
 the jar file.

In the pure Javac case, any dependent classes necessary to compile the
.java files explicitly on the command line must be available either on
the -classpath *or* a source file for that class be found relative to
one of the -sourcepath entry, in which case that dependent .java file,
despite not being on the Javac command line, will also be greedily
compiled by Javac. javac implicitly adds a sourcepath arg to Javac,
thus the difference in behavior in Ant and on the command line. You
can explicitly say javac sourcepath= ... to reset the sourcepath
to nothing, turning off Javac greedy behavior, That's a classic
technique compilewithwalls [1] uses to verify cross-package
dependency in a single source tree for example. Run Ant with -verbose
to see which arguments are actually passed to Javac, if you want to
understand how the use of javac attributes and nested elements
affect the command line for Javac. --DD

[1] http://ant-contrib.sourceforge.net/tasks/tasks/compilewithwalls.html

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

Re: [POLL] Rewriting Ant's self description

[Dominique Devienne]

On Mon, Feb 8, 2010 at 11:33 AM, Antoine Levy Lambert anto...@gmx.de wrote:
 Stefan Bodewig wrote:
 I agree its time to move away from make without make's wrinkles and
 prefer a description that says what Ant is rather than what it is not.
 Your draft does so pretty well.

 Thanks

+1 from me too, and your first draft is a good step forward.

 Personally I don't see any reason to compare Ant with any other tool
 from the same domain at all, YMMV.
 I would like to put the most famous or significant tools in perspective, 
 explaining how they differ in scope and in philosophy, rather than comparing 
 them in the sense of saying which tool is better, which each user/project can 
 decide for him/herself. Maybe this topic should go on its own separate page ?

I also don't think we should not delve too much into explaining the
other tools' differing philosophies. Adding a note that there exist
many alternative tools that reuse the tasks/types, Ant's primary asset
indeed, and mentioning those explicitly with hyper-linked names is
fine and useful, but lets stay out of controversial debate about those
tools vs Ant. --DD

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

Re: svn commit: r894462 - in /ant/core/trunk: WHATSNEW docs/manual/CoreTypes/filterchain.html src/main/org/apache/tools/ant/filters/AppendToLines.java src/main/org/apache/tools/ant/types/FilterChain

[Dominique Devienne]

On Thu, Jan 7, 2010 at 1:35 PM, Bruce Atherton br...@callenish.com wrote:
 While you are undeniably technically right that suffixlines is a better
 match with prefixlines, which of the three sounds better and is going to be
 clearer to users: appendtolines, suffixlines, or postfix lines.

header/footer lines?
prolog/epilog lines?

;) --DD

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

Re: svn commit: r894462 - in /ant/core/trunk: WHATSNEW docs/manual/CoreTypes/filterchain.html src/main/org/apache/tools/ant/filters/AppendToLines.java src/main/org/apache/tools/ant/types/FilterChain

[Dominique Devienne]

On Thu, Jan 7, 2010 at 1:57 PM, Dominique Devienne ddevie...@gmail.com wrote:
 On Thu, Jan 7, 2010 at 1:35 PM, Bruce Atherton br...@callenish.com wrote:
 While you are undeniably technically right that suffixlines is a better
 match with prefixlines, which of the three sounds better and is going to be
 clearer to users: appendtolines, suffixlines, or postfix lines.

 header/footer lines?
 prolog/epilog lines?

head/tail lines?

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

Re: [POLL] target-groups

[Dominique Devienne]

2009/12/16 Nicolas Lalevée nicolas.lale...@hibnet.org:
 [...] But targets are all public

Except for the tradition of having non-public targets' names start with a dash.

 So it seemed to me quite useless to try to restrict anything.

Restrict? More like caution, that's all. Lets not open Pandora's box
just yet on target dependencies, and provide a useful yet limited
extensible target (target-group), along with all the fixes Antoine
mentions. Lets see how it fairs in the wild and what users are
claiming for to make it more useful. This allows to release sooner
(1.7.1 is 18 months old), without rushing what is admittedly a more
radical change to Ant's target dependency handling.

Sorry to hijack your POLL thread Stefan ;) --DD

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

Re: deep-if/deep-unless

[Dominique Devienne]

On Wed, Dec 16, 2009 at 9:32 AM, Antoine Levy Lambert anto...@gmx.de wrote:
 is a sequence of tasks. If the process is highly configurable, there can be
 several blocks of tasks which are optionally executed.

Maybe a custom executor that blocks some targets would work for you?
Depends how these properties that prevent a target from executing
(including their dependencies) are set or computed, but from the
command line you could say

ant deploy /block:war

to launch the deploy target, completely forcing the removal of the war
target from the target dependency graph. I guess the issue with your
proposed deep if/unless is when that condition is evaluated. IMHO,
once the DAG has been resolved and targets start running, it's too
late. If you decide to block from the command line, that's OK, because
you in effect edit the script on the fly before it started, to
remove a dependency occurring anywhere in the DAG, overriding the
build author's intention on purpose. But once it's started, the effect
of removing a dependency in the middle could reorder the build in such
a way that it's now incompatible with the targets already executed so
far, and this to me makes it brittle and undesirable. My $0.02. --DD

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

Re: [POLL] target-groups

[Dominique Devienne]

On Mon, Dec 14, 2009 at 6:19 AM, Stefan Bodewig bode...@apache.org wrote:
  * have some special construct that has a depends list similar to
    target.  targets can depend on such a construct and add themselves
    to the depends list (the current code base).
+1, modulo the terminology.

  * allow targets to add themselves to the depends lists of targets that
    in some way mark themselves as being open for such extensions
+1, not much different from my other +1 above.

  * no target-group like construct at all
the functionality would have been useful to me in the past when
building reusable and extensible build scripts, so I do believe it has
value. Finding the right terminology is the only pb here IMHO. --DD

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

Re: Maybe we should open up depends for all targets [again]

[Dominique Devienne]

On Fri, Dec 11, 2009 at 6:32 AM, Xavier Hanin xavier.ha...@gmail.com wrote:
 2009/12/10 Stefan Bodewig bode...@apache.org
 and would do away with any notion of target composition people way
 expect from the name target-*group*.
 I also think the name target-group is confusing for something that doesn't
 provide any composition. [...] What do you think this:
 target name=foo dependencies=open/
 target name=bar join-depends=foo/

Like in a SQL join you mean? ;)

 But I'm not good at finding names, so maybe I should just go back to my work 
 :-)

Frankly I think the Maven terminology of a goal is appropriate here.
The fact that a goal is implemented as a target that has no tasks is
an impl detail. I think it easier that a goal is a higher level
abstraction that the target, and that target can choose to participate
into one and only one goal. Whether goals themselves should only
depend on goals might be a good idea. Goals would define the abstract
interface to the build system and logic, and targets become its
implementation. As I wrote, a target can belong to only a single goal,
but can depend on targets or goals, as long as the DAG is acyclic.

My $0.02, I just can't resist when the discussion turns to finding
good names! --DD

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

Re: if/unless Attributes

[Dominique Devienne]

On Fri, Sep 25, 2009 at 8:16 AM, Jesse Glick jesse.gl...@sun.com wrote:
 Refined proposal:

 1. Make target evaluate if/unless attributes (just before deciding whether
 or not to run the target).

 2. Introduce Project.isTrueOrSet(String val) which would return true if
 toBoolean(val) || getProperty(val) != null.

 3. Call iTOS from target, fail, etc. - anything with if/unless
 attributes with the standard meaning.

 Now target if=doSomething would behave as before, for better or worse.
 But you could also write target if=${doSomething} and it would work as
 most novice Ant users would expect: run the target if doSomething is defined
 but also set to 'true' (or 'on' or 'yes'). Similarly for fail and friends.

I like Jesse's proposal. It fits well with the principle of least
surprise, on both
the new user front, since ${foo} is correctly interpreted in boolean cases, and
for existing users too, since the existing behavior of testing
property existence
remains. So +1 from me. Anything more is not really needed IMHO. --DD

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

Re: if/unless Attributes

[Dominique Devienne]

On Thu, Sep 24, 2009 at 9:04 AM, Matt Benson gudnabr...@yahoo.com wrote:
 And a related question: we currently don't provide any
 PropertyEvaluator
 that would create Booleans.  Do we want to provide
 something like
 ${isTrue:foo} that created Boolean.TRUE if
 Project.toBoolean(${foo}) was
 true?  Or should something like this go into the props
 Antlib?

 Along these lines, I was just in the process of coding up a BooleanEvaluator 
 for the props antlib--I was just thinking e.g. ${boolean:on} and delegate to 
 Project.toBoolean(String).  If used in conjunction with the 
 NestedPropertyExpander, ${boolean:${foo}} should return true given property 
 name=foo value=[on|yes|true] /.  In fact I'd probably include that last 
 sentence verbatim in the documentation.  Note that this is mostly useful for 
 overloaded API areas as boolean task properties will still go through 
 InputHelper and be converted as usual.

 WDYT?

we have ${toString:foo}, we might as well call it ${toBoolean:foo} to
be consistent, and this also maps cleanly to the Project method that
implements the logic.

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

Re: if/unless Attributes

[Dominique Devienne]

On Thu, Sep 24, 2009 at 6:32 AM, Stefan Bodewig bode...@apache.org wrote:
 the if/unless attributes for target have changes slightly in that they
 now may use PropertyHelpers.  I.e.

 target if=${foo}

 will not be executed if ${foo} happens to expand to a Boolean instance
 with a booleanValue() of false and likewise

 target unless=${foo}

 will be executed in that case.  So far this hasn't been documented, but
 I'll do so shortly.

That's a pretty big change.

What's the exact semantic? Does it depend on the type returned, like
Boolean, Object, String. For String, does that fall back to assuming
it's a property name
that must be checked for existence?

What's the exact timing of the evaluation? Before or after depends' targets?

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

Re: if/unless Attributes

[Dominique Devienne]

On Thu, Sep 24, 2009 at 10:46 AM, Stefan Bodewig bode...@apache.org wrote:
 On 2009-09-24, Dominique Devienne ddevie...@gmail.com wrote:
 we have ${toString:foo}, we might as well call it ${toBoolean:foo} to
 be consistent,

 toString applies to project references, not properties, so they would
 not be as symmetric as they look.

True. Which makes me think ${toBoolean:ref} would / should evaluate to true or
false when the reference is defined or not. --DD

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

Re: svn commit: r812573 - in /ant/core/trunk/src: etc/testcases/taskdefs/manifestclasspath.xml main/org/apache/tools/ant/taskdefs/ManifestClassPath.java tests/junit/org/apache/tools/ant/taskdefs/Man

[Dominique Devienne]

On Tue, Sep 8, 2009 at 10:17 PM, Stefan Bodewig bode...@apache.org wrote:
 So I'm not sure the bug report is valid at all,

 The report talked about problems when staying on the same drive, this
 failed before I changed the code.

Thanks for the precisions. I get it now, and sorry for the noise. --DD

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

Re: svn commit: r812573 - in /ant/core/trunk/src: etc/testcases/taskdefs/manifestclasspath.xml main/org/apache/tools/ant/taskdefs/ManifestClassPath.java tests/junit/org/apache/tools/ant/taskdefs/Man

[Dominique Devienne]

On Tue, Sep 8, 2009 at 11:16 AM, bode...@apache.org wrote:
 Author: bodewig
 Date: Tue Sep  8 16:16:54 2009
 New Revision: 812573

 URL: http://svn.apache.org/viewvc?rev=812573view=rev
 Log: Use FileUtils.getRelativePath which knows how to deal with drive 
 letters.  PR 44499
 [...]
 +  target name=testDifferentDrive
 +    manifestclasspath jarfile=C:/Temp/e.jar
 +                       maxParentLevels=99 property=cp
 +      classpath
 +        pathelement location=D:/a/b/x.jar/
 +      /classpath
 +    /manifestclasspath
 +  /target
  /project

I don't get it Stefan. What is going to be in the manifest?

AFAIK, there's no way to change drive (letter) with a relative path/filename.
You can't cd .. when you're in D:\ or C:\ so how does one go from C: to D:
using a relative path??? cd /d allows changing drive letter, but takes an
absolute path, not a relative one.

IMHO, a manifest classpath should only ever contain true relative paths,
or absolute URLs (in which case one would need file:///D/a/b/x.jar and
D:/a/b/x.jar is not a valid entry for Class-Path: IMHO.)

So I'm not sure the bug report is valid at all, and why my original code didn't
allow changing drives, because AFAIK each drive is a root directory. --DD

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

Re: How about ${fromRefId:some-reference}?

[Dominique Devienne]

On Fri, Sep 4, 2009 at 6:25 AM, jan.mate...@rzf.fin-nrw.de wrote:
I suggest to add another core PropertyEvaluator that works like the one
for toString but doesn't invoke toString() on the reference (but leaves
that to IntrospectionHelper if necessary).

The ${ref:} and ${refid:} ideas look prettier but are more likely to
collide with existing property names.

 Because you referencing an id I would prefer ${refid:*}.

Tasks in the past had to explicitly support this by adding a separate
attribute which typically (by convention) uses a ref suffix (classpath=...,
classpathref=...), so having the following two notations
(classpathref=my_cp, classpath=${ref:my_cp} equivalent leans
towards using ref:.

OTOH, for addFoo() (i.e. nested elements), we use classpath refid=my_cp/,
so that points towards refid:.

Either way is fine with me. classpath=${refid:my_cp} reads well.

 There can be collisions as this is possible
  project
    property name=x:foo value=bar/
    echoproperties prefix=x/
  /project

  [echoproperties] x\:foo=bar

 but I think the ':' as seperation character is not a common use case.
 But in conclusion that would be a note in the could break existing
 builds section.

We could avoid ambiguity by not using a ${} notation...

I'm not sure I like the fact that ${} would start returning something
else than a String. Then there's classpath=foo${refid:my_cp}bar...
When you mix literals and a reference, what happens?

I've always considered that expanding references should be
something part of the core, especially when writing all those
xyzref attributes in my own tasks.

Since references are introduced by using an id=abc attribute,
and that such attributes in HTML are fragment which are accessed
using #abc in URLs, I'd prefer we introduce this notation to expand
references, rather than overloading ${}. #abc or #{abc}, the latter
being more consistent with our existing ${} and @{} notations.

BTW, we already have ${} and @{} which interact in interesting ways,
allowing to do ${...@{bar}} inside a macro. How would #{} (or ${refid:})
interact here?

Sorry to raise concerns again... I'm just trying to see whether
reference expansion shouldn't be something built-in rather than
tacked on via PropertyHelper. --DD

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

Re: PropertyHelper API

[Dominique Devienne]

On Tue, Sep 1, 2009 at 7:08 AM, Matt Bensongudnabr...@yahoo.com wrote:
 From: Stefan Bodewig bode...@apache.org
     wanted to allow nested properties ${${foo}} since the default
     PropertyExpander doesn't balance braces.

 Note that the props antlib does provide a NestedPropertyExpander, so you're 
 right on track.

protected PropertyHelper() {
add(TO_STRING);
add(SKIP_DOUBLE_DOLLAR);
add(DEFAULT_EXPANDER);
}

What I don't get is how NestedPropertyExpander can be enabled.
Given how DEFAULT_EXPANDER works, if one tries to add
NestedPropertyExpander after it, the first expander will not allow
the second to work.

So one's supposed to extend PropertyHelper and do different adds?
Given that the 3 default expanders are private, one can't reuse them.

On a side note, I find it a bit non-symetrical to have PropertyExpander
in oata.property, while PropertyEvaluator  PropertySetter has nested
interfaces in PropertyHelper.

Finally, I'm not sure I understand PropertyExpander and its
ParseNextProperty arg. The interface gives me the impression that to
do nested property parsing, one must mix the parsing and evaluation
phases since parsePropertyName has to return a property name; thus
${foo${bar}} must evaluate ${bar} during parsing to be able to return
foo1 if bar is 1.

I would have preferred the parsing to perform more akin to a compilation
phase, returning a little program (kinda like a little executable AST) which
is fully un-evaluated, and can be evaluated fully given a particular execution
context.

Maybe that's useless in the context of Ant, where almost everything
happens dynamically at runtime, but it somehow bothers me that we
don't clearly separate parsing from evaluation. Just my $0.02. --DD

PS: Note that it's entirely possible I missed something. I had a quick
look only.

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

Re: PropertyHelper API

[Dominique Devienne]

On Tue, Sep 1, 2009 at 9:42 AM, Stefan Bodewigbode...@apache.org wrote:
 On 2009-09-01, Dominique Devienne ddevie...@gmail.com wrote:

 What I don't get is how NestedPropertyExpander can be enabled.
 Given how DEFAULT_EXPANDER works, if one tries to add
 NestedPropertyExpander after it, the first expander will not allow
 the second to work.

 You missed the delegates get used in LIFO order bit.  add() adds to
 the front of the list.

Ah yes, thank you Stefan. --DD

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

Re: svn commit: r808018 - in /ant/core/trunk: ./ docs/manual/CoreTypes/ src/main/org/apache/tools/ant/ src/main/org/apache/tools/ant/filters/ src/tests/antunit/filters/ src/tests/antunit/filters/exp

[Dominique Devienne]

On Wed, Aug 26, 2009 at 1:35 PM, Matt Bensongudnabr...@yahoo.com wrote:
 Is uniq correct anywhere?

In *nix lingo only ;) --DD

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

Re: Scanning Resource Collections Several Times

[Dominique Devienne]

On Fri, Aug 21, 2009 at 9:46 AM, Dale Ansondan...@grafidog.com wrote:
 Part of the problem is the way delete is
 implemented in Java itself, that is, a non-empty directory cannot be deleted
 with java.io.File.delete(), so the delete task is required to traverse the
 tree and delete files from the bottom up.

Well, isn't that what the rm -r command does as well anyway?

It just happens to be implemented in a faster manner I think.

Deleting an entire directory w/o any pattern or selector could likely
be implemented in a lighter way by skipping all the extra processing
needed when more granular control over what's to be deleted. Sounds
like the deprecated deltree task to me. Don't know why it was
deprecated in fact. --DD

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

Re: 1.8.0 Bugzilla Milestone Reached

[Dominique Devienne]

On Thu, Aug 20, 2009 at 3:13 AM, Stefan Bodewigbode...@apache.org wrote:
 just noticed that one of my Bugzilla queries, the one which contains all
 issues marked as FIXED for 1.8.0, has hit the 250 items count.

Any significant change (new tasks, new behavior, etc...) that warrants 1.8.0
or should this be a 1.7.2 instead?

I don't care either way, I'm just asking. --DD

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

Re: 1.8.0 Bugzilla Milestone Reached

[Dominique Devienne]

On Thu, Aug 20, 2009 at 10:02 AM, Stefan Bodewigbode...@apache.org wrote:
 On 2009-08-20, Dominique Devienne ddevie...@gmail.com wrote:

 On Thu, Aug 20, 2009 at 3:13 AM, Stefan Bodewigbode...@apache.org wrote:
 just noticed that one of my Bugzilla queries, the one which contains all
 issues marked as FIXED for 1.8.0, has hit the 250 items count.

 Any significant change (new tasks, new behavior, etc...) that warrants
 1.8.0 or should this be a 1.7.2 instead?

 Most of the Bugzilla issues are bug fixes, but there is stuff in trunk
 (targetgroup and local properties spring to mind) that warrant 1.8.x
 IMHO.

makes sense.

 No, I really wouldn't want to go through the pain of merging the bug
 fixes into the 1.7 branch (I have been willing to do so about a year ago
 http://mail-archives.apache.org/mod_mbox/ant-dev/200810.mbox/%3cy1ud4hl5mht@v30161.1blu.de%3e
 but we have changed too much in trunk after that).

Ah yes, I forgot about the branch issue. 1.8.0 it is then. --DD

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

Re: conditional arg

[Dominique Devienne]

On Sat, Aug 15, 2009 at 10:23 AM, Blaine Simpsonblaine.simp...@admc.com wrote:
 Any chance that if I submitted a patch for if and unless attribute
 support for the arg sub-element, that it would make it into Ant
 distributions within a couple years?

What if we said yes? You'd write the code/test/doc for it then? :)

In case your itch is strong enough, I'd say something that works at the
UnknownElement level to disappear attributes and elements before
they are converted into set/add calls would be the most generic, as
task code doesn't need to change then. The trick is to make this code
dependent on the current context to access properties. Not sure it's
possible at all, but that's how I'd first try to do it.

As Stefan mentioned, you're still not quite explaining / showing why
you need conditional args. Even I who's been in favor of more conditional
processing in Ant would like to see some concrete examples which
would demonstrate your need. Often there are other ways to do it,
and again as Stefan mentions, one can always write one's own tasks.
I've done that a lot of that, and most of them were conditional, mostly
because I was dealing with native+java code on multiple platforms.

Anyways, not sure it applies, but just in case you are using Ant as a launcher,
this hack of mine which allows easier passing of command line args to java
and exec might be of interest:
https://issues.apache.org/bugzilla/show_bug.cgi?id=30651

--DD

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

Re: Ant XML Files precompilation

[Dominique Devienne]

On Thu, Aug 6, 2009 at 8:00 AM, Raja Nagendra
Kumarnagendra.r...@tejasoft.com wrote:
 However, due to imports and multiple times using of ant task with no
 inheritance, time taken per device is more than an minute..

On a one minute build, parsing the build file(s) is likely peanuts
compared to the build itself, unless you are doing some unusual stuff.
In any case, profile before you optimize.

 so for 100 devices.. it needs lot more time than tolerable..

Since it sounds like your 100 devices builds are orthogonal from each
other, maybe you could build them in parallel? (or enhance subant
to support parallel building?)

 In this context, is there a way Reduce the time of XML parsing/time of
 importing of xmls by way of any precompilation such as convert the xml file
 in .class files once and use the class files rest of the time etc..
 Some thing in lines to pre-compilation of jsp is there any thing for ant xml
 files pre-compilation.

There's no such thing in Ant. Given how Ant operates, the best you
could achieve would be a pre-parsing to UnknownElement, but since the
parsing stage is mixed up with Project and Target creation (and legacy
id handling I think), just doing that would be non-trivial and likely
not BC. Ant has no intermediate language that logically represents
the build files and build in general, and in fact doesn't have clear
static and dynamic contexts the way XSLT does for example, which is an
essential feature to allow having the equivalent of a pre-compiled
stylesheet.

But I'm sure there's probably room for improvement in your build times
still, even with stock Ant, by taking a step back from your current
build design and think it thru, internally or on list, if you don't
mind sharing more details about what's going on. --DD

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

Re: target call info, even when the if condition not met

[Dominique Devienne]

On Sat, Aug 1, 2009 at 9:55 AM, Raja Nagendra
Kumarnagendra.r...@tejasoft.com wrote:
 in such context, I was expecting it show on the console skipping the target
 call copyPrepocessingFiles etc.

There's two parts to a target: its body, and its dependencies.

A target's if/unless attributes are evaluated only after the
target's dependencies are met (they may or may not run depending
whether they have been run once already, as dependencies), and
if/unless enable/disable only the body of the target. So in a sense,
the target's banner you are complaining about does not precede the
target's body execution, but the evaluation of its dependencies, i.e.
the target's overall evaluation.

I think most people run with the NoBannerBuildLogger which suppresses
banners of targets that don't output anything, and thus don't mind.

I don't think Ant is likely to change in this regard. --DD

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

Re: Can we rename the compress sandbox Antlib?

[Dominique Devienne]

On Wed, Jul 1, 2009 at 4:52 AM, Stefan Bodewigbode...@apache.org wrote:
 I'm planning to create an Antlib based on commons-compress that would
 provide Ant tasks to create/extract cpio and ar archives as well as
 ArchiveFileset subclasses based on them.

 The natural name for the Antlib would be compress but that name is
 currently taken by the Antlib that runs Javascript compressors.

 Can we rename the existing Antlib? If yes, what would be a good name?

Could be simply jscompress?

But why not commons-compress AntLib for the new one?
That's makes it more obvious what it depends on, no? --DD

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

Re: Manifest Classpath ( programmatically generated but messedup).

[Dominique Devienne]

On Tue, Jun 23, 2009 at 12:40 PM, Garima Bathlagarima.bat...@gmail.com wrote:
 I am trying to set classpath for a standalone application and I am not able
 to figure out what exactly I am doing wrong. Below is the classpath that is
 being generated in the MANIFEST.MF And this isn't valid classpath , when I
 run java -jar mystandaloneapplication.jar, it cannot find any classes.

Well I can't see anything wrong with your classpath.

From: http://java.sun.com/docs/books/tutorial/deployment/jar/basicsindex.html :
To run an application packaged as a JAR file (requires the Main-class
manifest header): java -jar app.jar

Your snippet does not add a Main-Class attribute to the manifest. --DD

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

Re: Manifest Classpath ( programmatically generated but messedup).

[Dominique Devienne]

On Mon, Jun 22, 2009 at 12:33 AM, Garima Bathlagarima.bat...@gmail.com wrote:
 I am in the process of generating MANIFEST.MF file programmatically by
 Extending Jar Task; I am almost there, but the class-path that Jar task
 prints in the Manifest file isn't formatted correctly.

Have you looked at Ant's own Manifest and ManifestClassPath classes? --DD

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

Re: Manifest Classpath ( programmatically generated but messedup).

[Dominique Devienne]

On Mon, Jun 22, 2009 at 11:58 AM, Garima Bathlagarima.bat...@gmail.com wrote:
 That exactly is what  I am doing, using Ant's Manifest class. Problem
 happens to be that my classpath is too big and Manifest file has limit of 72
 characters per line, so even though it spits out my configured classpath ,
 it ain't set correctly (as I have listed in the orginial thread).

 Any help is highly appreciated, it must not be this tricky to set long
 classpaths programmatically?

Manifest can break a CP longer than 72 char on several lines correctly,
using the proper rules, and has been doing it correctly for years.

Very few bugs reported against it turned out to be real bugs in fact.
So I strongly suggest you take a second look, assuming it does the
correct thing. Note though that line breaks is only the beginning.

The Class-Path: attribute also needs to use the proper file and path separators,
be absolute or relative to the jar, and for this you should depend on
ManifestClasspath,
another Ant class that can take a Path and again format it correctly. --DD

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

Re: ant 1.7. Finding undefined variables

[Dominique Devienne]

On Wed, May 20, 2009 at 11:25 PM, Dave Pawson dave.paw...@gmail.com wrote:
 2009/5/20 Dominique Devienne ddevie...@gmail.com:

 I suggested postprocessing Ant's output as there are can hidden use of
 properties which is not easy to pick up by parsing the Ant XML file
 (they don't look like ${name} in attributes for example), and could
 thus possibly pick up info on more properties.


 An example please Dominique?

XML elements reading properties without the ${name} notation
target if/unless
fail if/unless
conditionisset property/condition
...

XML elements writing properties affecting the rest of the build:
condition property
exec (output|error)property
manifestclasspath property
...

In macros with params having default params (or lack thereof, what you
try to catch), it uses @{name} to differentiate it from property using
the ${name}. Of course the two can be combined ${...@{bar}} so
figuring out what property could be missing would replicate the
running behavior.

These are various reasons looking for ${name} may be insufficient for
some builds. Nonetheless I agree than looking for ${name} covers a lot
of ground.

You need to watch out for property helpers though, as
${toString:some-ref-id} is a fake property name converting the Java
object (Ant datatype typically like a path) with reference id
some-ref-id to a string on the fly. (undocumented feature, but
there's an official API to add custom property helpers for
${helper:rest} notation.

 But yes, for clarity, I am assuming ${name} form. ?Best practice?

Using ${name} is how you deref properties in the XML. All I'm saying
is that property derefs happen in the code as well, and that even
${name} can have a different meaning with macros and property helpers
(the latter is not very common, but the former more so).

But as I said, ${name} covers 90% of the ground, if not more. I just
wanted to make you aware of the 10% or 5% or 1% you could be missing.
90+ % is a good hit rate ;-) --DD

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

Re: ant 1.7. Finding undefined variables

[Dominique Devienne]

On Wed, May 20, 2009 at 1:38 PM, Dave Pawson dave.paw...@gmail.com wrote:
 I keep changing them which results in undefined variables which ant
 ignores, spreading odd filenames all over the place.

What I used to do was use fail with a nested condition asserting for
some properties to be defined were indeed defined. Aborts the builds
right away if they're missing. That addresses the Ant ignores
undefined properties part. As to your idea, I'm not sure I'm
following, sorry. --DD

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

Re: ant 1.7. Finding undefined variables

[Dominique Devienne]

On Wed, May 20, 2009 at 2:28 PM, Dave Pawson dave.paw...@gmail.com wrote:
 2009/5/20 Dominique Devienne ddevie...@gmail.com:
 Yes, that's what I generate. Except I run through the properties file
 and the build file to ensure I get all the (used) properties!
  As apposed to what I remembered to put in (and didn't change).
 That's the problem I was addressing, those changes and the
 odd properties I'd forgotten to test using fail/

Maybe running in verbose or debug mode and grepping for all property
related messages, especially those about not finding the property, and
convert that into a build similarly to what you did? --DD

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

Re: ant 1.7. Finding undefined variables

[Dominique Devienne]

On Wed, May 20, 2009 at 3:24 PM, Dave Pawson dave.paw...@gmail.com wrote:
 2009/5/20 Dominique Devienne ddevie...@gmail.com:

 Maybe running in verbose or debug mode and grepping for all property
 related messages, especially those about not finding the property, and
 convert that into a build similarly to what you did? --DD

 Yes
 Possibly.
 I chose Python and xslt.

I suggested postprocessing Ant's output as there are can hidden use of
properties which is not easy to pick up by parsing the Ant XML file
(they don't look like ${name} in attributes for example), and could
thus possibly pick up info on more properties.

 I gather you don't find it of use then?

Sorry, didn't mean to imply it wasn't useful. I'm not sure where to
put it though. Maybe the Ant wiki would be a good place? Cheers, --DD

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

Re: Target enablement via nested conditions?

[Dominique Devienne]

On Thu, Apr 23, 2009 at 8:13 AM, Jeffrey E Care ca...@us.ibm.com wrote:
 Off and on we've discussed more robust ways of determining target
 enablement, such as adding some type of EL syntax to if/unless.

 It dawned on me yesterday that we might already have the makings of a very
 robust system: why not use conditions nested in targets to determine if the
 target is enabled? I think effectively this is what people do already by
 having the real target depend on a decision target that sets (or
 doesn't) the controlling property used in the if attribute of the real
 target.

 We can quibble on the schema, but here's an example to illustrate the point:

 target name=doSomeWork
   target-enabled
     and
       istrue value=${controlling.property.1}/
      istrue value=${controlling.property.2}/
     /and
   /target-enabled

   !-- real work starts here --
 /target

 Thoughts?

Sounds like all we need is a return/ task then ;-)

ac:if ... ac:then return/ /ac:then /ac:if

More seriously, target-enabled sounds like a good idea, it's more
declarative, albeit a little heavy syntax wise (but then isn't Ant
heavy syntax wise ;-).

And advantage of doing it like this is that it's more obvious that
it's evaluated *after* the dependent targets, unlike the if/unless
attribute syntax (a common new user mistake is to assume if/unless are
evaluated before dependent targets are run).

As long as target-enabled is restricted as the first child of
target only. --DD

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

Re: Directory Sync

[Dominique Devienne]

On Mon, Mar 23, 2009 at 8:36 PM, Eger, Patrick pe...@automotive.com wrote:
 Hi, recently was working with some build scripts and found a deficiency in
 the “Sync” task, namely that it cannot actually compare file content and
 instead works strictly off file date. This was not usable for us and so I
 implemented the attached task, that will sync two directory trees based on
 file contents. I am submitting for inclusion in core or contrib, or if you’d
 like to refactor and integrate into the existing Sync task (I did not look
 at the code for Sync at all). LMK if any questions, I’m not on the list so
 please CC me.

If you need to read both files to compare them, you might as well
delete the destination and copy the source, quite often this will be
faster. Unless you have some preserve in target that is.

And as Stefan mentions, it would have been much better to enhance sync
with a plugeable strategy for file comparison than starting from
scratch. Especially since the pieces are already in place very likely,
like by reusing the different selector. --DD

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

Re: encoding in ZIP package

[Dominique Devienne]

On Thu, Feb 26, 2009 at 8:16 AM, Stefan Bodewig bode...@apache.org wrote:
 over the past two weeks commons-compress has been adding stuff for
 more advanced ZIP features and I've merged the changes over to our zip
 package.  The changes bring two new options with them and I'd like to
 get some feedback as to which defaults our tasks should use wrt these
 options.
 [...]
 zip:
 * setLanguageEncodingFlag - doesn't do anything if the encoding is not
  UTF-8.  Controls whether ZipOutputStream sets the flag.

  I'd make that default to true.

Sounds reasonable.

 * createUnicodeExtraFields
  Controls whether ZipOutputStream writes Unicode extra fields.

  I'd make that default to false.

 unzip:

Same.

 * parseUnicodeExtraFields
  Controls whether ZipFile searches for Unicode extra fields.

  I'm uncertain as to what the default should be.

Don't know.

Not very helpful I'm afraid. I've read your message with interest, and
you obviously have thought thru a lot of the involved issues, and what
you write makes sense. Regarding parseUnicodeExtraFields, I'd keep the
existing behavior not now, the fact that the attribute exists to
resolve corner cases is enough in my mind.

There's only so much you can do when a loosely defined format like
zip, and IMHO you've done plenty already. --DD

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

Re: svn commit: r743910 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/Javac.java

[Dominique Devienne]

On Thu, Feb 12, 2009 at 4:35 PM,  jgl...@apache.org wrote:
 +private static final byte[] PACKAGE_INFO_CLASS_HEADER = {
 +(byte) 0xca, (byte) 0xfe, (byte) 0xba, (byte) 0xbe, 0x00, 0x00, 0x00,
 +0x31, 0x00, 0x07, 0x07, 0x00, 0x05, 0x07, 0x00, 0x06, 0x01, 0x00, 
 0x0a,
 +0x53, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x46, 0x69, 0x6c, 0x65, 0x01, 
 0x00,
 +0x11, 0x70, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x2d, 0x69, 0x6e, 
 0x66,
 +0x6f, 0x2e, 0x6a, 0x61, 0x76, 0x61, 0x01
 +};
 +private static final byte[] PACKAGE_INFO_CLASS_FOOTER = {
 +0x2f, 0x70, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x2d, 0x69, 0x6e, 
 0x66,
 +0x6f, 0x01, 0x00, 0x10, 0x6a, 0x61, 0x76, 0x61, 0x2f, 0x6c, 0x61, 
 0x6e,
 +0x67, 0x2f, 0x4f, 0x62, 0x6a, 0x65, 0x63, 0x74, 0x02, 0x00, 0x00, 
 0x01,
 +0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 
 0x03,
 +0x00, 0x00, 0x00, 0x02, 0x00, 0x04
 +};

What Java version is this fake class in?

I suppose it doesn't matter much, as it's meant to be replaced, right?

Just curuous. --DD

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

Re: Developers log information needed

[Dominique Devienne]

On Fri, Jan 16, 2009 at 11:29 AM, Blaine Simpson
blaine.simp...@admc.com wrote:
 The code committers are still developers, so the two groups are
 definitely not exclusive.

 If you look at the Subversion logs, you will see that the comments are
 developer comments.

Have a look at the CONTRIBUTORS file in Ant's repo. --DD

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

Re: target-group committed

[Dominique Devienne]

On Wed, Nov 26, 2008 at 2:06 PM, Bruce Atherton [EMAIL PROTECTED] wrote:
 Or you could just live with the verbosity of the target list, like I did,
 and use naming conventions in EasyAnt. I'm sure there are many other ways to
 address the issue.

One possible way would be to provide an in-build-file hook to
intercept the -p switch, and this hook (I envision a target) would
then be responsible to display the help. Couple that with a new
configurable task to generate the -p output, and then it's up to the
user to select (via some kind of include/exclude) whatever targets are
going to be listed.

My builds used to all have a help target which java'd back into Ant
on the same build file with the -p switch added. It's the same idea,
but exposing a builtin task instead, and allowing to run that target
when -p is specified, if it's hooked via for example a project
help-target=help.

--DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: EasyAnt phases

[Dominique Devienne]

On Wed, Nov 19, 2008 at 11:19 PM, Stefan Bodewig [EMAIL PROTECTED] wrote:
 On 2008-11-19, Bruce Atherton [EMAIL PROTECTED] wrote:

 The only other topic I saw brought up on this thread was whether a
 target-group should be allowed to have tasks in it rather than
 requiring it to be empty.

 If we allwed them to e non-empty, we could do away with target-group
 completely and simply open up the depends list of all targets.

Sorry, I'm not getting this. Can you expand on what you mean please? --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maybe we should open up depends for all targets

[Dominique Devienne]

On Thu, Nov 20, 2008 at 9:32 AM, Stefan Bodewig [EMAIL PROTECTED] wrote:
 target name=a/
 target name=b target-group=a/

[OT] I recently was thinking that target ... target-group=... / is heavy.

I think using target ... group=... / is just as expressive.

 The *only* differences between target and target-group in trunk
 are:
 * target-groups must be empty

I like that.

 * you cannot use the target-group attribute to change the depends list
  of a plain target

Hmmm, you've lost me again ;) What's a plain target? If it's one w/o a
(target-)?group attribute, the above sentence has a logical
contradiction that throws me off.

 target name=b before=a [...]
 and we don't need target-group at all. [...]
 This is just an idea, not that I'm conviced of it myself.

Now that I've been introduced to the notion of target group, I prefer
it to the before/after we were discussing earlier.

Target groups allow to define to high level structure of a build, it's
flow in a way, and builds to cleanly hook up into this flow.

It's a cleaner abstraction than the before/after one, and which I feel
would encourage before build designs. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]