Ant task status update, take 2

[Stefan Bodewig]

Forget what I said in my previous post - if that is ever going to show
up. In the hours between typing the former post and now I understood I
was tackling things from the wrong end, the report engine wants to pull
the information, not get it pushed into it.

I've made a few methods in the elements package protected, added a few
constructors and wrapped my Ant ResourceCollection in a subclass of
Directory which implements its own traversal logic.

A functional version of the task is in SVN now, including an example
build file with three targets

$ ant -f ant-task-examples.xml -projecthelp
Buildfile: ant-task-examples.xml

A few examples of using the Ant task

Main targets:

jar runs the task over rat-0.3.jar
javasources runs the tasks over src/java excluding the license
directory
tarball creates a tarball of rat's source tree and runs the task
over the tarball
Default target: javasources

the jar and tarball targets demonstrate the task running on files
inside an archive.

Right now I don't see the directories in the report which is only a
problem in the filesystem case. Should be easy to fix.

[robertbur...@gmail.com]

Stefan Bodewig wrote:
> Forget what I said in my previous post - if that is ever going to show
> up.

sorry - i have to moderate the first post

(i've added everyone whose email address i recognize from apache as a
manager now)

> In the hours between typing the former post and now I understood I
> was tackling things from the wrong end, the report engine wants to pull
> the information, not get it pushed into it.

yeh

the pull design made it easy to develop quick initially but i think
refactoring's needed now

> I've made a few methods in the elements package protected, added a few
> constructors and wrapped my Ant ResourceCollection in a subclass of
> Directory which implements its own traversal logic.

cool

> A functional version of the task is in SVN now, including an example
> build file with three targets
>
> $ ant -f ant-task-examples.xml -projecthelp
> Buildfile: ant-task-examples.xml
>
> A few examples of using the Ant task
>
> Main targets:
>
> jar runs the task over rat-0.3.jar
> javasources runs the tasks over src/java excluding the license
> directory
> tarball creates a tarball of rat's source tree and runs the task
> over the tarball
> Default target: javasources
>
> the jar and tarball targets demonstrate the task running on files
> inside an archive.

i look forward to giving these a run (but i'm cutting a release tonight
so it'll be at the weekend)

> Right now I don't see the directories in the report which is only a
> problem in the filesystem case. Should be easy to fix.

yep

- robert

[Stefan Bodewig]

The pull designs is part of the reason that RAT is a memory hog, so
yes, we should rethink that. And while we do that we should find a
common abstraction for the report engines.

The directory issue is a bit more complex. You don't see any
directories since a fileset doesn't return them (it's a fileset and not
a dirset after all).

The current reporting engine assumes that information about the parent
directory of every file has been emitted prior to information about the
file and thus only emits the file name - which causes the Ant version
of the report to look wierd. I think I'll modify the code so that
we'll see a longer piece of the path when the report is run by Ant
(like the path you see when running the task on an archive).

[robertbur...@gmail.com]

Stefan Bodewig wrote:
> The pull designs is part of the reason that RAT is a memory hog, so
> yes, we should rethink that.

my machine has lots and lots of RAM so whilst it was a tool just for
me, what didn't matter :-)

> And while we do that we should find a
> common abstraction for the report engines.

i'm currently in the process of removing the older engine

however, i also think that the xml report is going to be a transitory
phase. i'm probably going to move to an RDF writer that will output xml
amongst other formats.

> The directory issue is a bit more complex. You don't see any
> directories since a fileset doesn't return them (it's a fileset and not
> a dirset after all).

yeh

> The current reporting engine assumes that information about the parent
> directory of every file has been emitted prior to information about the
> file and thus only emits the file name - which causes the Ant version
> of the report to look wierd. I think I'll modify the code so that
> we'll see a longer piece of the path when the report is run by Ant
> (like the path you see when running the task on an archive).

i understand the problem domain better know. there were reasons behind
the original design which i now think are better solve by layering. the
design needs to become resource-centric. so this means relative urls
rather than directory containment.

- robert

[robertbur...@gmail.com]

robertbur...@gmail.com wrote:
> Stefan Bodewig wrote:

<snip>

> > The directory issue is a bit more complex. You don't see any
> > directories since a fileset doesn't return them (it's a fileset and not
> > a dirset after all).
>
> yeh
>
> > The current reporting engine assumes that information about the parent
> > directory of every file has been emitted prior to information about the
> > file and thus only emits the file name - which causes the Ant version
> > of the report to look wierd. I think I'll modify the code so that
> > we'll see a longer piece of the path when the report is run by Ant
> > (like the path you see when running the task on an archive).
>
> i understand the problem domain better know. there were reasons behind
> the original design which i now think are better solve by layering. the
> design needs to become resource-centric. so this means relative urls
> rather than directory containment.

i'm starting to alter the report format to be resource centric

- robert