I actually already tried that. It seems to exclude everything even
though it was specified later on.
<!-- Nothing is copied even if <configfiles/> is defined -->
<copy todir="${config.dir}">
<fileset dir="${basedir}/@{module}">
<exclude name="**/*"/>
<configfiles/>
</fileset>
</copy>
I am now handling it by putting a fake <include> in the line. Since
there is one include, it won't include the whole directory:
<!-- This does seem to work -->
<copy todir="${config.dir}">
<fileset dir="${basedir}/@{module}">
<include name="fakedir/*.foo"/>
<configfiles/>
</fileset>
</copy>
I am not too happy with this solution. What if someone actually has a
directory called "fakedir" and want to copy all the files named *.foo
from it?
On 9/4/07, Matt Benson <[EMAIL PROTECTED]> wrote:
>
> --- David Weintraub <[EMAIL PROTECTED]> wrote:
>
> > I am using the <macrodef> task to define a macro
> > that will help
> > standardize our building tasks. This is suppose to
> > work better than
> > <antcall>, and I find some features very nice.
> > However, I have a
> > question:
> >
> > I have something like this:
> >
> > <macrodef name=build.module>
> > <attribute name="module"/>
> > <attribute jarname="@{module}.jar>
> > <element name="configfiles" optional="true"/>
> > <sequential>
> >
> > <copy todir="${config.dir}">
> > <fileset dir="${basedir}/@{module}">
> > <configfiles/>
> > </fileset>
> > </copy>
> > <sequential>
> > </macrodef>
> >
> >
> > This works fine as long as <configfiles/> is defined
> > by the calling routine:
> >
> > <build.module
> > module="foo">
> > <configfiles>
> > <include name="config/**"/>
> > </configfiles>
> > </build.module>
> >
> > However, if the user doesn't define <configfiles/>,
> > all files are
> > copied over which is what I don't want. How can I
> > prevent this from
> > happening? Is there a way to see if <configfiles/>
> > is defined?
>
> Hi David,
>
> The first thing you should try, IMHO, is specifying
> excludes="**/*" on your fileset going on the theory
> that any include pattern other than **/* should be
> more specific than the exclude pattern and thus
> override it. I don't 100% guarantee this to work and
> don't have even the paltry amount of time it would
> take to test it before suggesting it, but I urge you
> to give it a try.
>
> HTH,
> Matt
>
> > --
> > David Weintraub
> > [EMAIL PROTECTED]
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
> >
>
>
>
>
> ____________________________________________________________________________________
> Pinpoint customers who are looking for what you sell.
> http://searchmarketing.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
--
David Weintraub
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
