You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Hobson <ma...@gmail.com> on 2007/06/12 11:33:16 UTC
Adding wildcards to IncludesArtifactFilter
Hi,
I need an ArtifactFilter that supports wildcards and have patched
IncludesArtifactFilter accordingly, but then saw MNG-2621. I
implemented wildcards slightly stricter than allowing arbitrary
regular expressions - from the Javadoc:
> The artifact pattern syntax is of the form:
>
> [groupId]:[artifactId]:[type]:[version]
>
> Where each pattern segment is optional and supports full and partial * wildcards.
> An empty pattern segment is treated as an implicit wildcard.
>
> For example, org.apache.* would match all artifacts whose group id started with
> org.apache., and :::*-SNAPSHOT would match all snapshot artifacts.
Would this be acceptable? If not, we could either add a flag in the
constructor to signify whether wildcards are to be supported, or
subclass IncludesArtifactFilter to add wildcard support. Let me know
what's preferable and I'll submit a patch.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Adding wildcards to IncludesArtifactFilter
Posted by Mark Hobson <ma...@gmail.com>.
I've added the new filters to maven-common-artifact-filters as per
John's suggestion in MNG-2621. Let me know if there's any probs.
Mark
On 18/06/07, Mark Hobson <ma...@gmail.com> wrote:
> Hi John,
>
> On 16/06/07, John Casey <jd...@commonjava.org> wrote:
> > Just another pointer to add. I've put together some wildcard
> > filtering support for the assembly plugin, and factored it into a
> > separate library so I could share it with the maven-repository-
> > builder project. These wildcard-enabled filters are by no means
> > perfect, but if you're interested in taking a look, they're in maven-
> > common-artifact-filters under maven/shared. I put them here so we
> > could re-release them independently of Maven, should the need arise.
>
> Ah ha, this looks more like what I'm after. I dropped these
> alternative implementations into my dependency tree changes and they
> seem to work okay. They're a little less strict that the version I
> attached to MNG-2621 - in my implementation wildcards can't span id
> segments (groupId, artifactId, etc), and individual segments can be
> referred to explicity (e.g. ::jar for type). Have a look at the
> testcase in the patch and see if you think it's worth merging into
> your filters:
>
> http://jira.codehaus.org/secure/attachment/27995/MNG-2621.patch
>
> I'll move to using maven-common-artifact-filters for the time being so
> we can concentrate the work there.
>
> Cheers,
>
> Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Adding wildcards to IncludesArtifactFilter
Posted by Mark Hobson <ma...@gmail.com>.
Hi John,
On 16/06/07, John Casey <jd...@commonjava.org> wrote:
> Just another pointer to add. I've put together some wildcard
> filtering support for the assembly plugin, and factored it into a
> separate library so I could share it with the maven-repository-
> builder project. These wildcard-enabled filters are by no means
> perfect, but if you're interested in taking a look, they're in maven-
> common-artifact-filters under maven/shared. I put them here so we
> could re-release them independently of Maven, should the need arise.
Ah ha, this looks more like what I'm after. I dropped these
alternative implementations into my dependency tree changes and they
seem to work okay. They're a little less strict that the version I
attached to MNG-2621 - in my implementation wildcards can't span id
segments (groupId, artifactId, etc), and individual segments can be
referred to explicity (e.g. ::jar for type). Have a look at the
testcase in the patch and see if you think it's worth merging into
your filters:
http://jira.codehaus.org/secure/attachment/27995/MNG-2621.patch
I'll move to using maven-common-artifact-filters for the time being so
we can concentrate the work there.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Adding wildcards to IncludesArtifactFilter
Posted by John Casey <jd...@commonjava.org>.
Just another pointer to add. I've put together some wildcard
filtering support for the assembly plugin, and factored it into a
separate library so I could share it with the maven-repository-
builder project. These wildcard-enabled filters are by no means
perfect, but if you're interested in taking a look, they're in maven-
common-artifact-filters under maven/shared. I put them here so we
could re-release them independently of Maven, should the need arise.
-john
On Jun 15, 2007, at 5:57 PM, Brian E. Fox wrote:
> Mark,
> There are already a bunch of filters defined within dependency for
> a lot
> of this. None of them work for you or is it that you need to access
> them
> from the shared component?
>
> -----Original Message-----
> From: Mark Hobson [mailto:markhobson@gmail.com]
> Sent: Friday, June 15, 2007 9:46 AM
> To: Maven Developers List
> Subject: Re: Adding wildcards to IncludesArtifactFilter
>
> On 15/06/07, Jason van Zyl <ja...@maven.org> wrote:
>> I think you have two different things here. The first visualizing the
>> tree removing certain aspects and this implies the resolution is
>> complete and you're looking at a reduction. The second is actually
>> changing how the resolution happened in the first place. I don't
>> think filtering has anything to do with visualization. The filtering
>> obviously affects what shows up to be viewed, but I don't think the
>> filter is what you want when you're looking at a dependency tree.
>
> Sure, you wouldn't typically filter with wildcards during resolution,
> although it is feasible. The filtering during serialisation is
> performed by a DependencyNodeFilter, where one of the implementations
> provides a bridge to ArtifactFilter. This allows us to reuse these
> filters, hence me adding wildcard functionality to
> IncludesArtifactFilter.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
Re: Adding wildcards to IncludesArtifactFilter
Posted by Mark Hobson <ma...@gmail.com>.
Hi Brian,
On 18/06/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> I'm pretty sure I just wrapped the core artifactsFilter impl so that I
> could deal with the collection. In any case that I can, I try to use the
> core functionality but sometimes I wrap it to do any additional work
> needed. This was done mainly because mdep started out at Mojo and I
> didn't have Karma to influence core.
Looking at o.a.m.plugin.dependency.utils.filters, only ScopeFilter
delegates to ScopeArtifactFilter from maven-artifact. It's not a
problem, it's just that I needed to delegate to an arbitrary
ArtifactFilter. Maybe it'd be worth refactoring these filters into
ArtifactFilters and moving them into maven-common-artifact-filters in
future.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Adding wildcards to IncludesArtifactFilter
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I'm pretty sure I just wrapped the core artifactsFilter impl so that I
could deal with the collection. In any case that I can, I try to use the
core functionality but sometimes I wrap it to do any additional work
needed. This was done mainly because mdep started out at Mojo and I
didn't have Karma to influence core.
-----Original Message-----
From: Mark Hobson [mailto:markhobson@gmail.com]
Sent: Monday, June 18, 2007 8:53 AM
To: Maven Developers List
Subject: Re: Adding wildcards to IncludesArtifactFilter
Hi Brian,
On 15/06/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> Mark,
> There are already a bunch of filters defined within dependency for a
lot
> of this. None of them work for you or is it that you need to access
them
> from the shared component?
I did see them, although they weren't really what I was looking for.
How come you needed to introduce a new interface ArtifactsFilter
rather than reuse the existing ArtifactFilter API? I need a filter
that supports wildcards on groupId, artifactId, type and version
together, whereas the ArtifactsFilter implementations look for
equality or startsWith on only one part. I also deal with an artifact
at a time, whereas the ArtifactsFilter API looks more suitable for
dealing with collections of artifacts.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Adding wildcards to IncludesArtifactFilter
Posted by Mark Hobson <ma...@gmail.com>.
Hi Brian,
On 15/06/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> Mark,
> There are already a bunch of filters defined within dependency for a lot
> of this. None of them work for you or is it that you need to access them
> from the shared component?
I did see them, although they weren't really what I was looking for.
How come you needed to introduce a new interface ArtifactsFilter
rather than reuse the existing ArtifactFilter API? I need a filter
that supports wildcards on groupId, artifactId, type and version
together, whereas the ArtifactsFilter implementations look for
equality or startsWith on only one part. I also deal with an artifact
at a time, whereas the ArtifactsFilter API looks more suitable for
dealing with collections of artifacts.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Adding wildcards to IncludesArtifactFilter
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Mark,
There are already a bunch of filters defined within dependency for a lot
of this. None of them work for you or is it that you need to access them
from the shared component?
-----Original Message-----
From: Mark Hobson [mailto:markhobson@gmail.com]
Sent: Friday, June 15, 2007 9:46 AM
To: Maven Developers List
Subject: Re: Adding wildcards to IncludesArtifactFilter
On 15/06/07, Jason van Zyl <ja...@maven.org> wrote:
> I think you have two different things here. The first visualizing the
> tree removing certain aspects and this implies the resolution is
> complete and you're looking at a reduction. The second is actually
> changing how the resolution happened in the first place. I don't
> think filtering has anything to do with visualization. The filtering
> obviously affects what shows up to be viewed, but I don't think the
> filter is what you want when you're looking at a dependency tree.
Sure, you wouldn't typically filter with wildcards during resolution,
although it is feasible. The filtering during serialisation is
performed by a DependencyNodeFilter, where one of the implementations
provides a bridge to ArtifactFilter. This allows us to reuse these
filters, hence me adding wildcard functionality to
IncludesArtifactFilter.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Adding wildcards to IncludesArtifactFilter
Posted by Mark Hobson <ma...@gmail.com>.
On 15/06/07, Jason van Zyl <ja...@maven.org> wrote:
> I think you have two different things here. The first visualizing the
> tree removing certain aspects and this implies the resolution is
> complete and you're looking at a reduction. The second is actually
> changing how the resolution happened in the first place. I don't
> think filtering has anything to do with visualization. The filtering
> obviously affects what shows up to be viewed, but I don't think the
> filter is what you want when you're looking at a dependency tree.
Sure, you wouldn't typically filter with wildcards during resolution,
although it is feasible. The filtering during serialisation is
performed by a DependencyNodeFilter, where one of the implementations
provides a bridge to ArtifactFilter. This allows us to reuse these
filters, hence me adding wildcard functionality to
IncludesArtifactFilter.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Adding wildcards to IncludesArtifactFilter
Posted by Jason van Zyl <ja...@maven.org>.
On 15 Jun 07, at 6:29 AM 15 Jun 07, Mark Hobson wrote:
> Hi Jason,
>
> On 15/06/07, Jason van Zyl <ja...@maven.org> wrote:
>> That one small typo will render a system useless. What's the usecase
>> for not having to select individual artifacts to filter?
>>
>> The filters are looking like something that will be used to exclude
>> dependencies and things of that nature where you have the exact
>> artifact you want to filter.
>>
>> The filters as we are using them to knock out core libraries will
>> probably be replaced with the import mechanism that we've started
>> using in the branch and the trunk and that master filter list for our
>> internals will go away. A filter that does not have specific intent
>> of eliminating a single artifact will cause more hassles then the
>> perceived benefit of not having to write them out individually.
>
> The use case for this filter is within the dependency:tree goal. It
> would be used to include and exclude artifacts from the displayed
> tree; e.g. org.apache.maven.* for all maven groupIds, :::*-SNAPSHOT
> for all snapshot artifacts. Listing explicit artifacts in this
> situation obviously negates the usefulness of diagnostic tools such as
> this.
>
I think you have two different things here. The first visualizing the
tree removing certain aspects and this implies the resolution is
complete and you're looking at a reduction. The second is actually
changing how the resolution happened in the first place. I don't
think filtering has anything to do with visualization. The filtering
obviously affects what shows up to be viewed, but I don't think the
filter is what you want when you're looking at a dependency tree.
> I'm happy to move the wildcard functionality to a different
> implementation, I just figured it'd make sense to consolidate them
> within maven-artifact.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Adding wildcards to IncludesArtifactFilter
Posted by Mark Hobson <ma...@gmail.com>.
Hi Jason,
On 15/06/07, Jason van Zyl <ja...@maven.org> wrote:
> That one small typo will render a system useless. What's the usecase
> for not having to select individual artifacts to filter?
>
> The filters are looking like something that will be used to exclude
> dependencies and things of that nature where you have the exact
> artifact you want to filter.
>
> The filters as we are using them to knock out core libraries will
> probably be replaced with the import mechanism that we've started
> using in the branch and the trunk and that master filter list for our
> internals will go away. A filter that does not have specific intent
> of eliminating a single artifact will cause more hassles then the
> perceived benefit of not having to write them out individually.
The use case for this filter is within the dependency:tree goal. It
would be used to include and exclude artifacts from the displayed
tree; e.g. org.apache.maven.* for all maven groupIds, :::*-SNAPSHOT
for all snapshot artifacts. Listing explicit artifacts in this
situation obviously negates the usefulness of diagnostic tools such as
this.
I'm happy to move the wildcard functionality to a different
implementation, I just figured it'd make sense to consolidate them
within maven-artifact.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Adding wildcards to IncludesArtifactFilter
Posted by Jason van Zyl <ja...@maven.org>.
On 15 Jun 07, at 4:38 AM 15 Jun 07, Kenney Westerhof wrote:
>
>
> Mark Hobson wrote:
>> Hi,
>> I need an ArtifactFilter that supports wildcards and have patched
>> IncludesArtifactFilter accordingly, but then saw MNG-2621. I
>> implemented wildcards slightly stricter than allowing arbitrary
>> regular expressions - from the Javadoc:
>>> The artifact pattern syntax is of the form:
>>>
>>> [groupId]:[artifactId]:[type]:[version]
>>>
>>> Where each pattern segment is optional and supports full and
>>> partial * wildcards.
>>> An empty pattern segment is treated as an implicit wildcard.
>>>
>>> For example, org.apache.* would match all artifacts whose group
>>> id started with
>>> org.apache., and :::*-SNAPSHOT would match all snapshot artifacts.
>> Would this be acceptable? If not, we could either add a flag in the
>> constructor to signify whether wildcards are to be supported, or
>> subclass IncludesArtifactFilter to add wildcard support. Let me know
>> what's preferable and I'll submit a patch.
>
> I think it's safest to assume no regexps at all, so your solution
> looks fine.
>
> Jason, you said in MNG-2621 it could wreak havoc - how so? I think
> it's safer to not
> allow * for partial matches too, but we have no choice in the version
> tag, or we should write a more complex ArtifactMatcher system...
>
That one small typo will render a system useless. What's the usecase
for not having to select individual artifacts to filter?
The filters are looking like something that will be used to exclude
dependencies and things of that nature where you have the exact
artifact you want to filter.
The filters as we are using them to knock out core libraries will
probably be replaced with the import mechanism that we've started
using in the branch and the trunk and that master filter list for our
internals will go away. A filter that does not have specific intent
of eliminating a single artifact will cause more hassles then the
perceived benefit of not having to write them out individually.
> Cheers,
>
> Kenney
>
>> Cheers,
>> Mark
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Adding wildcards to IncludesArtifactFilter
Posted by Mark Hobson <ma...@gmail.com>.
On 15/06/07, Kenney Westerhof <ke...@apache.org> wrote:
> I think it's safest to assume no regexps at all, so your solution looks fine.
>
> Jason, you said in MNG-2621 it could wreak havoc - how so? I think it's safer to not
> allow * for partial matches too, but we have no choice in the version
> tag, or we should write a more complex ArtifactMatcher system...
I've attached my patch to the issue if you'd like to have a look.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Adding wildcards to IncludesArtifactFilter
Posted by Kenney Westerhof <ke...@apache.org>.
Mark Hobson wrote:
> Hi,
>
> I need an ArtifactFilter that supports wildcards and have patched
> IncludesArtifactFilter accordingly, but then saw MNG-2621. I
> implemented wildcards slightly stricter than allowing arbitrary
> regular expressions - from the Javadoc:
>
>> The artifact pattern syntax is of the form:
>>
>> [groupId]:[artifactId]:[type]:[version]
>>
>> Where each pattern segment is optional and supports full and partial *
>> wildcards.
>> An empty pattern segment is treated as an implicit wildcard.
>>
>> For example, org.apache.* would match all artifacts whose group id
>> started with
>> org.apache., and :::*-SNAPSHOT would match all snapshot artifacts.
>
> Would this be acceptable? If not, we could either add a flag in the
> constructor to signify whether wildcards are to be supported, or
> subclass IncludesArtifactFilter to add wildcard support. Let me know
> what's preferable and I'll submit a patch.
I think it's safest to assume no regexps at all, so your solution looks fine.
Jason, you said in MNG-2621 it could wreak havoc - how so? I think it's safer to not
allow * for partial matches too, but we have no choice in the version
tag, or we should write a more complex ArtifactMatcher system...
Cheers,
Kenney
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org