Consolidated delete task (Re: make clean equivalent)

[Stefan Bodewig <bo...@bost.de>]

>>>>> "CC" == Craig Cottingham <cc...@euronetservices.com> writes:

 CC> Is "deltree" the appropriate task? By its name, it seems
 CC> "deltree" should delete a directory tree -- meaning all files and
 CC> subdirectories.

Arnout has started a thread about consolidating tasks some days
ago. One of his proposals (and I'm all for it) was to merge delete and
deltree into a single delete task.

I've chosen to modify deltree for now as this one already implied
recursion while delete say "deletes on file".

I'm not sure whether we had come to an agreement about the names of
the attributes that were needed.

Do we keep different attributes for deleting files and dirs, i.e.
<delete file="name" /> with no includes or excludes allowed and
<delete dir="name" /> with all the MatchingTask stuff in place? I
think we should do so to avoid accidents.

Should we set defaultexcludes to false by default when deleting a
directory tree - my opinion is yes.

Do we need a recurse attribute (don't think so, if you specify a dir,
you obviously want to delete it)?

Do we need a purge attribute to delete empty dirs - I'm not decided on
this?

Stefan

Re: Consolidated delete task (Re: make clean equivalent)

[John Pappin <jo...@jmonkey.com>]

> Should we set defaultexcludes to false by default when deleting a
> directory tree - my opinion is yes.

+1

> Do we need a recurse attribute (don't think so, if you specify a dir,
> you obviously want to delete it)?

Hmm... this one needs to be thought out... but I suspect it will be needed
so you can target a particular directory... this of course could be done
with an exclude/include instead, but using an explicit recurse attribute
would make the task much clearer to read, and avoid mistakes.

> Do we need a purge attribute to delete empty dirs - I'm not decided on
> this?

Yes, use a rule in the standard delete task... i.e. delete if empty, etc. I
would like control over empty dirs. They may not be part of the source tree,
but be placeholders for my working environment or some other workspace
addition that I want ignored by the build system...

- Brill Pappin

Re: How to tell what Javac did?

[Ernst de Haan <er...@c187104187.telekabel.chello.nl>]

Stefan wrote:
>  JS> I have some class post-processing and some reflection/source code
>  JS> generation after the compile step, it would be ideal if it only
>  JS> invoked this step if javac actually did anything.
> 
> Wouldn't it be better to code your post processing so that it can
> determine whether it has some work to do itself? Maybe you could just
> compare the creation dates of the class files with the dates of your
> generated output?

+1


Ernst

RE: How to tell what Javac did?

[Jason Sando <js...@think1up.com>]

> From: Stefan Bodewig [mailto:bodewig@bost.de]
>
> >>>>> "JS" == Jason Sando <js...@think1up.com> writes:
>
>  JS> I have some class post-processing and some reflection/source code
>  JS> generation after the compile step, it would be ideal if it only
>  JS> invoked this step if javac actually did anything.
>
> Wouldn't it be better to code your post processing so that it can
> determine whether it has some work to do itself? Maybe you could just
> compare the creation dates of the class files with the dates of your
> generated output?
>

You are correct, its the only option.  I'm generating source and exec'ing
javac/jikes, so the "targets" may not even be present in the file system.
Knowing what the javac task did incrementally doesn't ensure that all my
generated classes are up to date.

thanks,

-j

Re: How to tell what Javac did?

[Stefan Bodewig <bo...@bost.de>]

>>>>> "JS" == Jason Sando <js...@think1up.com> writes:

 JS> I have some class post-processing and some reflection/source code
 JS> generation after the compile step, it would be ideal if it only
 JS> invoked this step if javac actually did anything.

Wouldn't it be better to code your post processing so that it can
determine whether it has some work to do itself? Maybe you could just
compare the creation dates of the class files with the dates of your
generated output?

Stefan

How to tell what Javac did?

[Jason Sando <js...@think1up.com>]

Is there any way/plans to conditionally do tasks depending on whether javac
did anything or not?

I have some class post-processing and some reflection/source code generation
after the compile step, it would be ideal if it only invoked this step if
javac actually did anything.

Thanks,

-j

Re: Consolidated delete task (Re: make clean equivalent)

[John Pappin <jo...@jmonkey.com>]

> Should we set defaultexcludes to false by default when deleting a
> directory tree - my opinion is yes.

+1

> Do we need a recurse attribute (don't think so, if you specify a dir,
> you obviously want to delete it)?

I think your correct... you can tell by what you have asked delete to do,
what should be done... if you only specify a diretory then recurse, if its a
directory and has filters then recurse but don't delete the actual dir
unless all rules are passed, etc.

> Do we need a purge attribute to delete empty dirs - I'm not decided on
> this?

I don't think we need that... the same thing could be done with a rule in
the standard delete task... i.e. delete if empty, etc.

- Brill Pappin

Re: Consolidated delete task (Re: make clean equivalent)

[Stefan Bodewig <bo...@bost.de>]

>>>>> "JS" == Jason Sando <js...@think1up.com> writes:

 >> Do we need a purge attribute to delete empty dirs - I'm not
 >> decided on this?
 >> 

 JS> I don't understand, the delete dir="blah" would remove it whether
 JS> it is empty or not, right?

Uhm yes, maybe.

If you use include/exclude patterns some files might be left over so
some directories are empty and others are not. Consider

<delete dir="build/classes">
    <include name="**/*.class" />
</delete>

on Ant's own build directory. This will delete everything in
build/classes/org/apache/tools/tar but in
build/classes/org/apache/tools/ant the file defaultManifest.mf is
left.

The purge attribute is thought to control whether the tar dir is to be
deleted or not.

Stefan

RE: Consolidated delete task (Re: make clean equivalent)

[Jason Sando <js...@think1up.com>]

>
> Arnout has started a thread about consolidating tasks some days
> ago. One of his proposals (and I'm all for it) was to merge delete and
> deltree into a single delete task.
>
> I've chosen to modify deltree for now as this one already implied
> recursion while delete say "deletes on file".
>
> I'm not sure whether we had come to an agreement about the names of
> the attributes that were needed.
>
> Do we keep different attributes for deleting files and dirs, i.e.
> <delete file="name" /> with no includes or excludes allowed and
> <delete dir="name" /> with all the MatchingTask stuff in place? I
> think we should do so to avoid accidents.
>

I was the proponent of using just "src" instead of "file" or "dir", but it
seems everyone feels safer the way your proposing.  I'll go along with that
...

> Should we set defaultexcludes to false by default when deleting a
> directory tree - my opinion is yes.
>

Yes.

> Do we need a recurse attribute (don't think so, if you specify a dir,
> you obviously want to delete it)?
>

No.

> Do we need a purge attribute to delete empty dirs - I'm not decided on
> this?
>

I don't understand, the delete dir="blah" would remove it whether it is
empty or not, right?

-j