Ivy
  1. Ivy
  2. IVY-439

Add more filters to the Ant tasks

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.4.1
    • Fix Version/s: None
    • Component/s: Ant
    • Labels:
      None

      Description

      At the moment, it is only possible to specify 1 filter which filters out the artifacts based on their type. This is done with the "type" attribute.
      It would be useful to use more filters here, e.g.:

      • a filter based on the status
      • a filter based on the organization
      • a filter based on the branch
      • a combination of the filters above
      • a custom-made filter
      • ...

      Perhaps we could add a "filter" element, somthing like this (something similar like the "selector"-type in Ant)

      <resolve ...>
      <type-filter types="jar,zip" />
      <organisation-filter orgs="apache" />
      <filter class="com.mycompany.MyCustomFilter" />
      </resolve>

        Issue Links

          Activity

          Hide
          Xavier Hanin added a comment -

          This is a good idea, and this shouldn't too difficult to implement since the API already use a Filter, we only have to modify the ant task.

          I think the implementation should try to be reusable for other cases, like the conditional patterns (IVY-324). Indeed I think it could be a nice solution to have a uniform way of addressing the two.

          Show
          Xavier Hanin added a comment - This is a good idea, and this shouldn't too difficult to implement since the API already use a Filter, we only have to modify the ant task. I think the implementation should try to be reusable for other cases, like the conditional patterns ( IVY-324 ). Indeed I think it could be a nice solution to have a uniform way of addressing the two.
          Hide
          Scott Goldstein added a comment -

          This issue came up in the mailing list. Here's the content of the discussion:

          > In my common build file, for organization purposes, I retrieve files by
          > type and place them in particular directories. For example:
          >
          > .../lib Contains win32 dlls
          > .../jlib Containes jar files
          > .../obl Contains Installscript libraries
          >
          > This works, but I don't want to list out all of them. In other words, I
          > want to choose a few well known types for their own directories and the rest
          > I want to place in a directory called "misc".
          >
          > One way to do this, is to have a type filter with negation
          > capabilities. So, for the type attribute, you could specify, "!jar, !dll,
          > !obl". I've done this will a small change in FitlerHelper:
          >
          > public static Filter getArtifactTypeFilter(String types) {
          > if (types == null || types.trim().equals("*"))

          { > return NO_FILTER; > }

          > String[] t = types.split(",");
          > List acceptedTypes = new ArrayList(types.length());
          > List negatedTypes = new ArrayList(types.length());
          > for (int i = 0; i < t.length; i++) {
          > String type = t[i].trim();
          > if (type.startsWith("!"))

          { > negatedTypes.add(type.substring(1)); > }

          else

          { > acceptedTypes.add(type); > }

          > }
          > Filter acceptedTypesFilter = new ArtifactTypeFilter(acceptedTypes);
          > Filter negatedTypesFilter = new NotFilter(new
          > ArtifactTypeFilter(negatedTypes));
          > return new OrFilter(acceptedTypesFilter, negatedTypesFilter);
          > }
          >
          > This works for my situation, but I don't know if it's the best long term
          > approach. I would imagine a mechanism of providing filters in the same way
          > that the ant fileset tag works. In other words, providing include and
          > exclude tags. This would be extremely flexible, allowing the developer to
          > perform any type of filtering desired.
          >
          > I haven't thought through all of the implications, but I thought I would
          > post the idea for discussion.

          Thanks for sharing this, the idea is indeed interesting. About having more
          flexible filters, there is already an open issue for that:
          https://issues.apache.org/jira/browse/IVY-439

          I suggest to vote for it, and add a comment about your opinion on the
          subject.

          Your include/exclude suggestion is interesting, it could be pretty easy to
          have something like:

          <resolve ...>

          <include attribute="type" value="jar,zip" />

          <exclude attribute="module" value="foo*" matcher="glob"/>

          </resolve>
          This would be very flexible, and should match your use case. What do you
          think?

          Xavier

          Show
          Scott Goldstein added a comment - This issue came up in the mailing list. Here's the content of the discussion: > In my common build file, for organization purposes, I retrieve files by > type and place them in particular directories. For example: > > .../lib Contains win32 dlls > .../jlib Containes jar files > .../obl Contains Installscript libraries > > This works, but I don't want to list out all of them. In other words, I > want to choose a few well known types for their own directories and the rest > I want to place in a directory called "misc". > > One way to do this, is to have a type filter with negation > capabilities. So, for the type attribute, you could specify, "!jar, !dll, > !obl". I've done this will a small change in FitlerHelper: > > public static Filter getArtifactTypeFilter(String types) { > if (types == null || types.trim().equals("*")) { > return NO_FILTER; > } > String[] t = types.split(","); > List acceptedTypes = new ArrayList(types.length()); > List negatedTypes = new ArrayList(types.length()); > for (int i = 0; i < t.length; i++) { > String type = t [i] .trim(); > if (type.startsWith("!")) { > negatedTypes.add(type.substring(1)); > } else { > acceptedTypes.add(type); > } > } > Filter acceptedTypesFilter = new ArtifactTypeFilter(acceptedTypes); > Filter negatedTypesFilter = new NotFilter(new > ArtifactTypeFilter(negatedTypes)); > return new OrFilter(acceptedTypesFilter, negatedTypesFilter); > } > > This works for my situation, but I don't know if it's the best long term > approach. I would imagine a mechanism of providing filters in the same way > that the ant fileset tag works. In other words, providing include and > exclude tags. This would be extremely flexible, allowing the developer to > perform any type of filtering desired. > > I haven't thought through all of the implications, but I thought I would > post the idea for discussion. Thanks for sharing this, the idea is indeed interesting. About having more flexible filters, there is already an open issue for that: https://issues.apache.org/jira/browse/IVY-439 I suggest to vote for it, and add a comment about your opinion on the subject. Your include/exclude suggestion is interesting, it could be pretty easy to have something like: <resolve ...> <include attribute="type" value="jar,zip" /> <exclude attribute="module" value="foo*" matcher="glob"/> </resolve> This would be very flexible, and should match your use case. What do you think? Xavier
          Hide
          Scott Goldstein added a comment -

          I think Xavier's approach is perfect here. Very flexible and powerful.

          Show
          Scott Goldstein added a comment - I think Xavier's approach is perfect here. Very flexible and powerful.

            People

            • Assignee:
              Unassigned
              Reporter:
              Maarten Coene
            • Votes:
              3 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development