Re: [SUBMIT] New task, a task to manage arbitrary dependencies between files

["Craeg K. Strong" <cs...@arielpartners.com>]

>
>
>Let's take a silly example - my <style> (using redirect extensions or
>something) generates two .html files - the name of one of them will be
>passed in as a parameter, something like
>
><style in="source.xml" 
>       out="output1.html"
>       style="style-with-redirect.xsl">
>  <param name="other-file"
>         value="${a-property-only-known-at-build-time}" />
></style>
>
<snip/>

>- maybe output1.html contains a
>link to the second file?  If any target file is out of date with
>respect to a given source, chances are high that all of them are IMHO.
>
I liked your example-- point taken.  I will modify the code and docs to 
delete ALL targetfiles
if ANY are out of date.

>But I see your point of using a fileset for target files as well,
>there are situations where you don't know all the names of the target
>files or it would be cumbersome to list them.
>
>Maybe we'd need a targetfileset and a targetfilelist or similar, where
>a missing file from the targetfilelist would be treated the same way
>as an out-of-date target file?
>
I see your point here as well.  If someone has gone to all the trouble 
to explicitly name target files as in

<targetfiles dir="mumble" includes="foo.html,bar.html,baz.html"/>

rather than simply

<targetfiles dir="mumble" includes="*.html"/>

Then if one of them does not exist, ALL should be removed in the 
interest of correctness.  I will try
to make a special note of this intricacy somehow in the docs...

>>A real issue is what to do when one or more SOURCES (not targets)
>>doesn't exist?  In the example above, that would mean that a
>>buildfile does not exist.  This is not so preposterous when you
>>realize that I might be generating my buildfile using XSLT or
>>whatnot.
>>
>Then place the dependset task after the one that generates the build
>file?
>
Yes in general I think you are right-- you would place the call to 
<dependset> in logical order
-after- the rule that generates the buildfile or common XSLT include or 
etc...  but see below.

>>Other times you might want this situation to be interpreted as if
>>the target files are NOT out of date.  For example, you might have a
>>boilerplate <dependset> rule that includes "*.dtd".  But one of your
>>projects does not yet happen to have any DTD files.  Setting
>>ignore=true means that this will not result in any target files
>>being removed.
>>
>Searching for sources that have an out-of-date target instead of
>targets that are out of date would eliminate this problem, you
>wouldn't even consider the *.dtd part.
>
I don't understand your argument here.  If <srcfiles> specifies "*.dtd" 
and there aren't any dtd files,
I wouldn't consider it either way.  The problem arises when <srcfiles> 
specifies an _explicit_
file like "foo.dtd" but "foo.dtd" does not exist.  (I should have used 
that for my earlier example...)

I still think that you may want to give the buildfile writer a choice in 
how to handle this situation.
n'est-ce pas?

--Craeg

Re: [SUBMIT] New task, a task to manage arbitrary dependencies between files

[Stefan Bodewig <bo...@apache.org>]

On Fri, 03 Aug 2001, Craeg K. Strong <cs...@arielpartners.com>
wrote:

> OK-- Just to confirm... your preference is for a new DataType rather
> than extending FileSets to support explicitly named files,

Correct.

> DependSet will support an arbitrary number of filesets and
> filelists, for both source and target files.

Sounds good.

Stefan

Re: [SUBMIT] New task, a task to manage arbitrary dependencies between files

["Craeg K. Strong" <cs...@arielpartners.com>]

Stefan Bodewig wrote:

>>- you could create a new DataType of ExplicitFileList or something
>>that accepted no wildcards
>>
>Yep.
>
OK-- Just to confirm... your preference is for a new DataType rather 
than extending FileSets to
support explicitly named files, something like:

<fileset dir="bar">
  <patternset includes="**/*.html" excludes="not-me.html">
   <namedfile file="blat.inc"/>
</fileset>

I understand now that FileSets are really filters, not lists of files. 
 I therefore propose to create
a new data type called FileList.  For now, FileList will simply support 
a comma-separated list of
files.  I will send a patch for both the FileSet and new FileList 
documentation to try to make the distinction
between the two more clear.

DependSet will support an arbitrary number of filesets and filelists, 
for both source and target files.

This means that an example usage of <dependset> would look something 
like the following:

<dependset>
   <srcfileset dir="buildfiles" includes="*.xml"/>
   <srcfilelist dir="dtdfiles" files="foo.dtd,bar.dtd"/>
   <targetfileset dir="${basedir}" includes="**/*.html"/>
   <targetfilelist dir="other-dir" files="one.html, two.html"/>
</dependset>

--Craeg

Re: [SUBMIT] New task, a task to manage arbitrary dependencies between files

[Stefan Bodewig <bo...@apache.org>]

On Thu, 02 Aug 2001, Craeg K. Strong <cs...@arielpartners.com>
wrote:

> This is why you mentioned the possibility of including both FileSets
> and FileLists, is it?   Now I get it.

Good ;-)

> - you could have some sort of option that would make
> DirectoryScanner return explicitly-named files even if they did not
> exist

Not DirectoryScanner's responsibilty IMHO, it is supposed to discover
files that follow certain patterns - not to list arbitrary files.

> - you could create a new DataType of ExplicitFileList or something
> that accepted no wildcards

Yep.

> - you could use FileSets, but have them behave a little differently
> in the case of <dependset>

I wouldn't like that too much either, but it is not without precedent,
see <zipfileset> and <tarfileset>, although they just "decorate" plain
filesets.

Stefan

Re: [SUBMIT] New task, a task to manage arbitrary dependencies between files

["Craeg K. Strong" <cs...@arielpartners.com>]

>
>
>> But I see your point of using a fileset for target files as well,
>> there are situations where you don't know all the names of the target
>> files or it would be cumbersome to list them.
>>
>> Maybe we'd need a targetfileset and a targetfilelist or similar, where
>> a missing file from the targetfilelist would be treated the same way
>> as an out-of-date target file?
>>
Oh-oh.  I just carefully read the source code for DirectoryScanner and 
noticed that
using this class in the usual way:

DirectoryScanner ds = sourceFileSet.getDirectoryScanner(project);
String[] sourceFiles = ds.getIncludedFiles();

will not return files that do not exist even if they were explicitly 
named like so:

<srcfiles dir="foo" includes="this-file-does-not-exist.xml"/>    

Holy incorrect assumptions, batman!

This is why you mentioned the possibility of including both FileSets and 
FileLists, is it?   Now I get it.
OK, this being the case, how to proceed?    There are several options I 
can imagine:

- you could have some sort of option that would make DirectoryScanner 
return explicitly-named
    files even if they did not exist

- you could create a new DataType of ExplicitFileList or something that 
accepted no wildcards

- you could use FileSets, but have them behave a little differently in 
the case of <dependset>

I guess I am leaning towards option "B," based on the principle of least 
surprise...

Something like:

<dependset missingSource="outofdate">
  <srcfile dir="bar" file="common.xsl"/>
   <srcfile dir="bar" file="tables.xsl"/>
  <srcfiles dir="foo" includes="*.xml"/>
   <targetfiles dir="mumble" includes="**/*.html"/>
    <targetfile dir="blat" file="generate-me.txt"/>
</dependset>

...thoughts?

--Craeg