Reusing with a subset?

[Bill Burton <bi...@progress.com>]

Hello,

I have a <patternset> like the following.  Since the src.dir has many more
packages, I'm explicitly specifying each package I want to be included in
the compile and jar targets:

  <patternset id="server">
    <include name="com.myco.server/*" />
    <include name="com.myco.server.config/*" />
    <include name="com.myco.server.connector/*" />
  </patternset>

As I'm building each of my jars with just the CLASSPATH it needs, I'm also
limiting the files passed to my <javac> this way as follows:

  <target name="compile" depends="vssget" description="Compiles source
code">
    <mkdir dir="${classes.dir}" />
    <javac srcdir="${src.dir}"
           destdir="${classes.dir}"
      <classpath refid="classpath" />
      <patternset refid="server" />
    </javac>

The patternset seems to work fine here.  But now, I want to copy any
.properties files from the same directories using the copy task.  What I'd
like to be able to do is reuse this patternset in a fileset but further
qualify it to find just **/*.properties files.  It would be nice if
something like the following worked:

    <copy todir="${classes.dir}">
      <fileset dir="${src.dir}">
        <patternset refid="server">
          <!-- only include files found in the patternset -->
          <include name="**/*.properties" />
        </patternset>
      </fileset>
    </copy>

Is there any way to do the above?  

  <patternset id="server.properties" refid="server">
    <include name="**/*.properties" />
  </patternset>

Or maybe this, so you can create a new patternset as a subset of an
existing one?

Thanks,
-Bill Burton

Re: Reusing with a subset?

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

Bill Burton <bi...@progress.com> wrote:

> Stefan Bodewig wrote:
>
>> This issue has come up before and we've not found a good solution
>> for it, maybe a new <restrict> pattern type or something similar?
> 
> Yes, that sounds good.  I was thinking of something similar like
> <excludeunless> but <restrict> looks better.  Spent some time
> looking at the code to see how hard it would be to add.  Looks like
> it would touch a number of classes just to add to <fileset> and
> <patternset>.  Then to be consistent, a "restricts" attribute should
> probably be added to all the tasks that support includes and
> excludes.

Adding nested <restrict> elements everywhere where an <include> or
<exclude> can appear is not much of a problem, you'd have to change
DirectoryScanner significantly to make them do anything.

> In the meantime, is there any way to access a fileset object and
> manipulate it from a <script> or custom task?

Actually FileSet itself is a dumb class that doesn't do and doesn't
know anything - well almost. The work is done in DirectoryScanner and
you don't have easy access to this via <script>.

> In any case, it looks like a work around is to copy all the
> .properties files to a temporary directory and then use the
> patternset to copy from there to the desired location.

Yep. Another - extremely hacky - workaround for current CVS sources
would be:

<copy ...>
  <fileset ...>
    <patternset refid="selects.the.packages" />
  </fileset>
  <mapper type="glob" from="*.properties" to="*.properties" />
</copy>

which abuses the side effect of the mapper that all files that don't
match the from pattern will be dropped.

Stefan

Re: Reusing with a subset?

[Bill Burton <bi...@progress.com>]

Hi Stefan,

Stefan Bodewig wrote:
> 
> Bill Burton <bi...@progress.com> wrote:
> 
> >     <copy todir="${classes.dir}">
> >       <fileset dir="${src.dir}">
> >         <patternset refid="server">
> >           <!-- only include files found in the patternset -->
> >           <include name="**/*.properties" />
> >         </patternset>
> >       </fileset>
> >     </copy>
> >
> > Is there any way to do the above?
> >
> 
> Unfortunately no. The includes as well as the excludes are additive
> and I file matches a patternset if it matches at least one include
> pattern and no exclude pattern.
> 
> This issue has come up before and we've not found a good solution for
> it, maybe a new <restrict> pattern type or something similar?

Yes, that sounds good.  I was thinking of something similar like
<excludeunless> but <restrict> looks better.  Spent some time looking at
the code to see how hard it would be to add.  Looks like it would touch a
number of classes just to add to <fileset> and <patternset>.  Then to be
consistent, a "restricts" attribute should probably be added to all the
tasks that support includes and excludes.

> Currently we only support set unions (this applies to filesets or
> pathelements as well) by simply specifying more than one element -
> maybe we need a general set intersection mechanism, I'm not sure.

That would be something to consider.  

In the meantime, is there any way to access a fileset object and
manipulate it from a <script> or custom task?

In any case, it looks like a work around is to copy all the .properties
files to a temporary directory and then use the patternset to copy from
there to the desired location.  The other option I like a little better is
to have the master build.xml copy all the .properties files to a known
location.  Then each sub-build.xml would only copy what it needs based on
its patternset.

> Stefan

Thanks,
-Bill Burton

Re: Reusing with a subset?

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

Bill Burton <bi...@progress.com> wrote:

>     <copy todir="${classes.dir}">
>       <fileset dir="${src.dir}">
>         <patternset refid="server">
>           <!-- only include files found in the patternset -->
>           <include name="**/*.properties" />
>         </patternset>
>       </fileset>
>     </copy>
> 
> Is there any way to do the above?  
> 

Unfortunately no. The includes as well as the excludes are additive
and I file matches a patternset if it matches at least one include
pattern and no exclude pattern.

This issue has come up before and we've not found a good solution for
it, maybe a new <restrict> pattern type or something similar?

Currently we only support set unions (this applies to filesets or
pathelements as well) by simply specifying more than one element -
maybe we need a general set intersection mechanism, I'm not sure.

Stefan