You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2020/06/09 07:54:42 UTC
DirectoryScanner, exclusions wins or loose over inclusions?
Hi everyone,
As you know, DirectoryScanner is used a lot in plugins.
Today I realized that plexus impl does not respect exclusions in the visit
but only in the result, it means if you exclude **/target/** and include
**/*.java, it will visit target to see if there is any java (cause ** means
java can be in target).
I did a quick fix for license-maven-plugin (
https://github.com/mycila/license-maven-plugin/pull/172) but discussion on
the PR we wonder if it is something to consider in maven shared utils.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Re: DirectoryScanner, exclusions wins or loose over inclusions?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Here is a PR for discussion:
https://github.com/apache/maven-shared-utils/pull/54
Side note being: hopefully we keep our abstraction and don't let the dev
across mojo do it themselves :D
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 10 juin 2020 à 08:59, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> Ok,
>
> Will give a try to a first draft/pr this week.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mer. 10 juin 2020 à 08:56, Robert Scholte <rf...@apache.org> a
> écrit :
>
>> The stream wasn't intended as discussion, just to mention this piece of
>> code must be touched anyway, it is far from dead.
>>
>>
>> I think we can do both.
>>
>> Robert
>> On 9-6-2020 20:48:02, Romain Manni-Bucau <rm...@gmail.com> wrote:
>> Well, have to admit I didn't expect the stream discussion there (not
>> saying
>> it is bad, just highly unexpected).
>> So think we have multiple topics:
>>
>> 1. Do we do a stream based *impl* with a flatmap enabling to bypass
>> children - reusing ScanCondutor maybe?
>> 2. Do we fix maven shared impl providing some default ScanConductors (at
>> least one enforcing exclusions)?
>>
>> Guess both can be tackled in parallel or at different speed.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau | Blog
>> | Old Blog
>> | Github |
>> LinkedIn | Book
>>
>>
>>
>> Le mar. 9 juin 2020 à 20:39, Robert Scholte a écrit :
>>
>> > bq. Today I realized that plexus impl does not respect exclusions in the
>> > visit but only in the result, it means if you exclude **/target/** and
>> > include **/*.java, it will visit target to see if there is any java
>> (cause
>> > ** means java can be in target).
>> >
>> > I recall noticing that as well. I had the plan to have a Stream based
>> > directory scanner, and to see if the Ant pattern resolution could be
>> > improved.
>> >
>> > Robert
>> > On 9-6-2020 15:11:11, Romain Manni-Bucau wrote:
>> > Strictly speaking it is slower but I don't think we would notice it in a
>> > build (same as Path is slower than File).
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau | Blog
>> > | Old Blog
>> > | Github |
>> > LinkedIn | Book
>> >
>> >
>> >
>> > Le mar. 9 juin 2020 à 14:59, Mark Struberg a
>> > écrit :
>> >
>> > > Don't we configure those patterns mostly directly in the poms?
>> > > Ditching our own DirectoryScanner would likely require a huge amount
>> of
>> > > existing projects to rewrite their config when they update some
>> plugins.
>> > > Don't think this is really worth it. Plus the Java7 directoryScanner
>> is
>> > > not really faster than our own impl, isn't?
>> > >
>> > > LieGrue,
>> > > strub
>> > >
>> > >
>> > > > Am 09.06.2020 um 14:54 schrieb Romain Manni-Bucau
>> > > >:
>> > > >
>> > > > Do you suggest to use java regex?
>> > > > Think it is very rare that mojo use that (even outside
>> > > > org.apache.maven.plugins) and each time it kind of hurts users so I
>> > hope
>> > > we
>> > > > don't go that path. On the other side, never saw anyone complaining
>> of
>> > > ant
>> > > > regexes.
>> > > > Ant like syntax is way more friendly and natural IMHO and does not
>> > assume
>> > > > maven user is a Java expert nor a regex expert (this is actually
>> rare
>> > you
>> > > > use them properly at this location, you likely don't escape it
>> properly
>> > > or
>> > > > have some headache with xml in some cases).
>> > > > I also don't think we can break all plugins out there using this
>> piece
>> > of
>> > > > code so rewriting the impl with whatever newer API is ok if as fast
>> but
>> > > > changing the config requires a wider discussion IMHO.
>> > > >
>> > > > Romain Manni-Bucau
>> > > > @rmannibucau | Blog
>> > > > | Old Blog
>> > > > | Github
>> > > https://github.com/rmannibucau> |
>> > > > LinkedIn | Book
>> > > >
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > >
>> > > >
>> > > >
>> > > > Le mar. 9 juin 2020 à 14:46, Elliotte Rusty Harold
>> > > a
>> > > > écrit :
>> > > >
>> > > >> On Tue, Jun 9, 2020 at 8:30 AM Romain Manni-Bucau
>> > > rmannibucau@gmail.com>
>> > > >> wrote:
>> > > >>>
>> > > >>> Wildcard support which is more user friendly (who would like to
>> use
>> > > java
>> > > >>> regex to configure that ;)).
>> > > >>
>> > > >> Familiarity is user friendly. Standard Java regex that developers
>> > > >> already know and use beats a marginally simpler syntax they don't.
>> I'd
>> > > >> rather stick to one well-documented wildcard syntax across multiple
>> > > >> projects than learn a new and slightly different one for each
>> project.
>> > > >> Relying on developers to read and understand the details of a new
>> > > >> syntax is dangerous. That's even assuming it's fully and correctly
>> > > >> documented and implemented in the first place, which might not be
>> the
>> > > >> case here.
>> > > >>
>> > > >>
>> > > >>
>> > > >> --
>> > > >> Elliotte Rusty Harold
>> > > >> elharo@ibiblio.org
>> > > >>
>> > > >>
>> ---------------------------------------------------------------------
>> > > >> 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: DirectoryScanner, exclusions wins or loose over inclusions?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ok,
Will give a try to a first draft/pr this week.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 10 juin 2020 à 08:56, Robert Scholte <rf...@apache.org> a
écrit :
> The stream wasn't intended as discussion, just to mention this piece of
> code must be touched anyway, it is far from dead.
>
>
> I think we can do both.
>
> Robert
> On 9-6-2020 20:48:02, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Well, have to admit I didn't expect the stream discussion there (not saying
> it is bad, just highly unexpected).
> So think we have multiple topics:
>
> 1. Do we do a stream based *impl* with a flatmap enabling to bypass
> children - reusing ScanCondutor maybe?
> 2. Do we fix maven shared impl providing some default ScanConductors (at
> least one enforcing exclusions)?
>
> Guess both can be tackled in parallel or at different speed.
>
>
> Romain Manni-Bucau
> @rmannibucau | Blog
> | Old Blog
> | Github |
> LinkedIn | Book
>
>
>
> Le mar. 9 juin 2020 à 20:39, Robert Scholte a écrit :
>
> > bq. Today I realized that plexus impl does not respect exclusions in the
> > visit but only in the result, it means if you exclude **/target/** and
> > include **/*.java, it will visit target to see if there is any java
> (cause
> > ** means java can be in target).
> >
> > I recall noticing that as well. I had the plan to have a Stream based
> > directory scanner, and to see if the Ant pattern resolution could be
> > improved.
> >
> > Robert
> > On 9-6-2020 15:11:11, Romain Manni-Bucau wrote:
> > Strictly speaking it is slower but I don't think we would notice it in a
> > build (same as Path is slower than File).
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog
> > | Old Blog
> > | Github |
> > LinkedIn | Book
> >
> >
> >
> > Le mar. 9 juin 2020 à 14:59, Mark Struberg a
> > écrit :
> >
> > > Don't we configure those patterns mostly directly in the poms?
> > > Ditching our own DirectoryScanner would likely require a huge amount of
> > > existing projects to rewrite their config when they update some
> plugins.
> > > Don't think this is really worth it. Plus the Java7 directoryScanner is
> > > not really faster than our own impl, isn't?
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > > > Am 09.06.2020 um 14:54 schrieb Romain Manni-Bucau
> > > >:
> > > >
> > > > Do you suggest to use java regex?
> > > > Think it is very rare that mojo use that (even outside
> > > > org.apache.maven.plugins) and each time it kind of hurts users so I
> > hope
> > > we
> > > > don't go that path. On the other side, never saw anyone complaining
> of
> > > ant
> > > > regexes.
> > > > Ant like syntax is way more friendly and natural IMHO and does not
> > assume
> > > > maven user is a Java expert nor a regex expert (this is actually rare
> > you
> > > > use them properly at this location, you likely don't escape it
> properly
> > > or
> > > > have some headache with xml in some cases).
> > > > I also don't think we can break all plugins out there using this
> piece
> > of
> > > > code so rewriting the impl with whatever newer API is ok if as fast
> but
> > > > changing the config requires a wider discussion IMHO.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau | Blog
> > > > | Old Blog
> > > > | Github
> > > https://github.com/rmannibucau> |
> > > > LinkedIn | Book
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > > >
> > > >
> > > > Le mar. 9 juin 2020 à 14:46, Elliotte Rusty Harold
> > > a
> > > > écrit :
> > > >
> > > >> On Tue, Jun 9, 2020 at 8:30 AM Romain Manni-Bucau
> > > rmannibucau@gmail.com>
> > > >> wrote:
> > > >>>
> > > >>> Wildcard support which is more user friendly (who would like to use
> > > java
> > > >>> regex to configure that ;)).
> > > >>
> > > >> Familiarity is user friendly. Standard Java regex that developers
> > > >> already know and use beats a marginally simpler syntax they don't.
> I'd
> > > >> rather stick to one well-documented wildcard syntax across multiple
> > > >> projects than learn a new and slightly different one for each
> project.
> > > >> Relying on developers to read and understand the details of a new
> > > >> syntax is dangerous. That's even assuming it's fully and correctly
> > > >> documented and implemented in the first place, which might not be
> the
> > > >> case here.
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Elliotte Rusty Harold
> > > >> elharo@ibiblio.org
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> 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: DirectoryScanner, exclusions wins or loose over inclusions?
Posted by Robert Scholte <rf...@apache.org>.
The stream wasn't intended as discussion, just to mention this piece of code must be touched anyway, it is far from dead.
I think we can do both.
Robert
On 9-6-2020 20:48:02, Romain Manni-Bucau <rm...@gmail.com> wrote:
Well, have to admit I didn't expect the stream discussion there (not saying
it is bad, just highly unexpected).
So think we have multiple topics:
1. Do we do a stream based *impl* with a flatmap enabling to bypass
children - reusing ScanCondutor maybe?
2. Do we fix maven shared impl providing some default ScanConductors (at
least one enforcing exclusions)?
Guess both can be tackled in parallel or at different speed.
Romain Manni-Bucau
@rmannibucau | Blog
| Old Blog
| Github |
LinkedIn | Book
Le mar. 9 juin 2020 à 20:39, Robert Scholte a écrit :
> bq. Today I realized that plexus impl does not respect exclusions in the
> visit but only in the result, it means if you exclude **/target/** and
> include **/*.java, it will visit target to see if there is any java (cause
> ** means java can be in target).
>
> I recall noticing that as well. I had the plan to have a Stream based
> directory scanner, and to see if the Ant pattern resolution could be
> improved.
>
> Robert
> On 9-6-2020 15:11:11, Romain Manni-Bucau wrote:
> Strictly speaking it is slower but I don't think we would notice it in a
> build (same as Path is slower than File).
>
> Romain Manni-Bucau
> @rmannibucau | Blog
> | Old Blog
> | Github |
> LinkedIn | Book
>
>
>
> Le mar. 9 juin 2020 à 14:59, Mark Struberg a
> écrit :
>
> > Don't we configure those patterns mostly directly in the poms?
> > Ditching our own DirectoryScanner would likely require a huge amount of
> > existing projects to rewrite their config when they update some plugins.
> > Don't think this is really worth it. Plus the Java7 directoryScanner is
> > not really faster than our own impl, isn't?
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 09.06.2020 um 14:54 schrieb Romain Manni-Bucau
> > >:
> > >
> > > Do you suggest to use java regex?
> > > Think it is very rare that mojo use that (even outside
> > > org.apache.maven.plugins) and each time it kind of hurts users so I
> hope
> > we
> > > don't go that path. On the other side, never saw anyone complaining of
> > ant
> > > regexes.
> > > Ant like syntax is way more friendly and natural IMHO and does not
> assume
> > > maven user is a Java expert nor a regex expert (this is actually rare
> you
> > > use them properly at this location, you likely don't escape it properly
> > or
> > > have some headache with xml in some cases).
> > > I also don't think we can break all plugins out there using this piece
> of
> > > code so rewriting the impl with whatever newer API is ok if as fast but
> > > changing the config requires a wider discussion IMHO.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau | Blog
> > > | Old Blog
> > > | Github
> > https://github.com/rmannibucau> |
> > > LinkedIn | Book
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le mar. 9 juin 2020 à 14:46, Elliotte Rusty Harold
> > a
> > > écrit :
> > >
> > >> On Tue, Jun 9, 2020 at 8:30 AM Romain Manni-Bucau
> > rmannibucau@gmail.com>
> > >> wrote:
> > >>>
> > >>> Wildcard support which is more user friendly (who would like to use
> > java
> > >>> regex to configure that ;)).
> > >>
> > >> Familiarity is user friendly. Standard Java regex that developers
> > >> already know and use beats a marginally simpler syntax they don't. I'd
> > >> rather stick to one well-documented wildcard syntax across multiple
> > >> projects than learn a new and slightly different one for each project.
> > >> Relying on developers to read and understand the details of a new
> > >> syntax is dangerous. That's even assuming it's fully and correctly
> > >> documented and implemented in the first place, which might not be the
> > >> case here.
> > >>
> > >>
> > >>
> > >> --
> > >> Elliotte Rusty Harold
> > >> elharo@ibiblio.org
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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: DirectoryScanner, exclusions wins or loose over inclusions?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Well, have to admit I didn't expect the stream discussion there (not saying
it is bad, just highly unexpected).
So think we have multiple topics:
1. Do we do a stream based *impl* with a flatmap enabling to bypass
children - reusing ScanCondutor maybe?
2. Do we fix maven shared impl providing some default ScanConductors (at
least one enforcing exclusions)?
Guess both can be tackled in parallel or at different speed.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 9 juin 2020 à 20:39, Robert Scholte <rf...@apache.org> a écrit :
> bq. Today I realized that plexus impl does not respect exclusions in the
> visit but only in the result, it means if you exclude **/target/** and
> include **/*.java, it will visit target to see if there is any java (cause
> ** means java can be in target).
>
> I recall noticing that as well. I had the plan to have a Stream based
> directory scanner, and to see if the Ant pattern resolution could be
> improved.
>
> Robert
> On 9-6-2020 15:11:11, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Strictly speaking it is slower but I don't think we would notice it in a
> build (same as Path is slower than File).
>
> Romain Manni-Bucau
> @rmannibucau | Blog
> | Old Blog
> | Github |
> LinkedIn | Book
>
>
>
> Le mar. 9 juin 2020 à 14:59, Mark Struberg a
> écrit :
>
> > Don't we configure those patterns mostly directly in the poms?
> > Ditching our own DirectoryScanner would likely require a huge amount of
> > existing projects to rewrite their config when they update some plugins.
> > Don't think this is really worth it. Plus the Java7 directoryScanner is
> > not really faster than our own impl, isn't?
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 09.06.2020 um 14:54 schrieb Romain Manni-Bucau
> > >:
> > >
> > > Do you suggest to use java regex?
> > > Think it is very rare that mojo use that (even outside
> > > org.apache.maven.plugins) and each time it kind of hurts users so I
> hope
> > we
> > > don't go that path. On the other side, never saw anyone complaining of
> > ant
> > > regexes.
> > > Ant like syntax is way more friendly and natural IMHO and does not
> assume
> > > maven user is a Java expert nor a regex expert (this is actually rare
> you
> > > use them properly at this location, you likely don't escape it properly
> > or
> > > have some headache with xml in some cases).
> > > I also don't think we can break all plugins out there using this piece
> of
> > > code so rewriting the impl with whatever newer API is ok if as fast but
> > > changing the config requires a wider discussion IMHO.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau | Blog
> > > | Old Blog
> > > | Github
> > https://github.com/rmannibucau> |
> > > LinkedIn | Book
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le mar. 9 juin 2020 à 14:46, Elliotte Rusty Harold
> > a
> > > écrit :
> > >
> > >> On Tue, Jun 9, 2020 at 8:30 AM Romain Manni-Bucau
> > rmannibucau@gmail.com>
> > >> wrote:
> > >>>
> > >>> Wildcard support which is more user friendly (who would like to use
> > java
> > >>> regex to configure that ;)).
> > >>
> > >> Familiarity is user friendly. Standard Java regex that developers
> > >> already know and use beats a marginally simpler syntax they don't. I'd
> > >> rather stick to one well-documented wildcard syntax across multiple
> > >> projects than learn a new and slightly different one for each project.
> > >> Relying on developers to read and understand the details of a new
> > >> syntax is dangerous. That's even assuming it's fully and correctly
> > >> documented and implemented in the first place, which might not be the
> > >> case here.
> > >>
> > >>
> > >>
> > >> --
> > >> Elliotte Rusty Harold
> > >> elharo@ibiblio.org
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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: DirectoryScanner, exclusions wins or loose over inclusions?
Posted by Robert Scholte <rf...@apache.org>.
bq. Today I realized that plexus impl does not respect exclusions in the visit but only in the result, it means if you exclude **/target/** and include **/*.java, it will visit target to see if there is any java (cause ** means java can be in target).
I recall noticing that as well. I had the plan to have a Stream based directory scanner, and to see if the Ant pattern resolution could be improved.
Robert
On 9-6-2020 15:11:11, Romain Manni-Bucau <rm...@gmail.com> wrote:
Strictly speaking it is slower but I don't think we would notice it in a
build (same as Path is slower than File).
Romain Manni-Bucau
@rmannibucau | Blog
| Old Blog
| Github |
LinkedIn | Book
Le mar. 9 juin 2020 à 14:59, Mark Struberg a
écrit :
> Don't we configure those patterns mostly directly in the poms?
> Ditching our own DirectoryScanner would likely require a huge amount of
> existing projects to rewrite their config when they update some plugins.
> Don't think this is really worth it. Plus the Java7 directoryScanner is
> not really faster than our own impl, isn't?
>
> LieGrue,
> strub
>
>
> > Am 09.06.2020 um 14:54 schrieb Romain Manni-Bucau
> >:
> >
> > Do you suggest to use java regex?
> > Think it is very rare that mojo use that (even outside
> > org.apache.maven.plugins) and each time it kind of hurts users so I hope
> we
> > don't go that path. On the other side, never saw anyone complaining of
> ant
> > regexes.
> > Ant like syntax is way more friendly and natural IMHO and does not assume
> > maven user is a Java expert nor a regex expert (this is actually rare you
> > use them properly at this location, you likely don't escape it properly
> or
> > have some headache with xml in some cases).
> > I also don't think we can break all plugins out there using this piece of
> > code so rewriting the impl with whatever newer API is ok if as fast but
> > changing the config requires a wider discussion IMHO.
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog
> > | Old Blog
> > | Github
> https://github.com/rmannibucau> |
> > LinkedIn | Book
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 9 juin 2020 à 14:46, Elliotte Rusty Harold
> a
> > écrit :
> >
> >> On Tue, Jun 9, 2020 at 8:30 AM Romain Manni-Bucau
> rmannibucau@gmail.com>
> >> wrote:
> >>>
> >>> Wildcard support which is more user friendly (who would like to use
> java
> >>> regex to configure that ;)).
> >>
> >> Familiarity is user friendly. Standard Java regex that developers
> >> already know and use beats a marginally simpler syntax they don't. I'd
> >> rather stick to one well-documented wildcard syntax across multiple
> >> projects than learn a new and slightly different one for each project.
> >> Relying on developers to read and understand the details of a new
> >> syntax is dangerous. That's even assuming it's fully and correctly
> >> documented and implemented in the first place, which might not be the
> >> case here.
> >>
> >>
> >>
> >> --
> >> Elliotte Rusty Harold
> >> elharo@ibiblio.org
> >>
> >> ---------------------------------------------------------------------
> >> 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: DirectoryScanner, exclusions wins or loose over inclusions?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Strictly speaking it is slower but I don't think we would notice it in a
build (same as Path is slower than File).
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 9 juin 2020 à 14:59, Mark Struberg <st...@yahoo.de.invalid> a
écrit :
> Don't we configure those patterns mostly directly in the poms?
> Ditching our own DirectoryScanner would likely require a huge amount of
> existing projects to rewrite their config when they update some plugins.
> Don't think this is really worth it. Plus the Java7 directoryScanner is
> not really faster than our own impl, isn't?
>
> LieGrue,
> strub
>
>
> > Am 09.06.2020 um 14:54 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Do you suggest to use java regex?
> > Think it is very rare that mojo use that (even outside
> > org.apache.maven.plugins) and each time it kind of hurts users so I hope
> we
> > don't go that path. On the other side, never saw anyone complaining of
> ant
> > regexes.
> > Ant like syntax is way more friendly and natural IMHO and does not assume
> > maven user is a Java expert nor a regex expert (this is actually rare you
> > use them properly at this location, you likely don't escape it properly
> or
> > have some headache with xml in some cases).
> > I also don't think we can break all plugins out there using this piece of
> > code so rewriting the impl with whatever newer API is ok if as fast but
> > changing the config requires a wider discussion IMHO.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 9 juin 2020 à 14:46, Elliotte Rusty Harold <el...@ibiblio.org>
> a
> > écrit :
> >
> >> On Tue, Jun 9, 2020 at 8:30 AM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> >> wrote:
> >>>
> >>> Wildcard support which is more user friendly (who would like to use
> java
> >>> regex to configure that ;)).
> >>
> >> Familiarity is user friendly. Standard Java regex that developers
> >> already know and use beats a marginally simpler syntax they don't. I'd
> >> rather stick to one well-documented wildcard syntax across multiple
> >> projects than learn a new and slightly different one for each project.
> >> Relying on developers to read and understand the details of a new
> >> syntax is dangerous. That's even assuming it's fully and correctly
> >> documented and implemented in the first place, which might not be the
> >> case here.
> >>
> >>
> >>
> >> --
> >> Elliotte Rusty Harold
> >> elharo@ibiblio.org
> >>
> >> ---------------------------------------------------------------------
> >> 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: DirectoryScanner, exclusions wins or loose over inclusions?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Don't we configure those patterns mostly directly in the poms?
Ditching our own DirectoryScanner would likely require a huge amount of existing projects to rewrite their config when they update some plugins.
Don't think this is really worth it. Plus the Java7 directoryScanner is not really faster than our own impl, isn't?
LieGrue,
strub
> Am 09.06.2020 um 14:54 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Do you suggest to use java regex?
> Think it is very rare that mojo use that (even outside
> org.apache.maven.plugins) and each time it kind of hurts users so I hope we
> don't go that path. On the other side, never saw anyone complaining of ant
> regexes.
> Ant like syntax is way more friendly and natural IMHO and does not assume
> maven user is a Java expert nor a regex expert (this is actually rare you
> use them properly at this location, you likely don't escape it properly or
> have some headache with xml in some cases).
> I also don't think we can break all plugins out there using this piece of
> code so rewriting the impl with whatever newer API is ok if as fast but
> changing the config requires a wider discussion IMHO.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mar. 9 juin 2020 à 14:46, Elliotte Rusty Harold <el...@ibiblio.org> a
> écrit :
>
>> On Tue, Jun 9, 2020 at 8:30 AM Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>>
>>> Wildcard support which is more user friendly (who would like to use java
>>> regex to configure that ;)).
>>
>> Familiarity is user friendly. Standard Java regex that developers
>> already know and use beats a marginally simpler syntax they don't. I'd
>> rather stick to one well-documented wildcard syntax across multiple
>> projects than learn a new and slightly different one for each project.
>> Relying on developers to read and understand the details of a new
>> syntax is dangerous. That's even assuming it's fully and correctly
>> documented and implemented in the first place, which might not be the
>> case here.
>>
>>
>>
>> --
>> Elliotte Rusty Harold
>> elharo@ibiblio.org
>>
>> ---------------------------------------------------------------------
>> 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: DirectoryScanner, exclusions wins or loose over inclusions?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Do you suggest to use java regex?
Think it is very rare that mojo use that (even outside
org.apache.maven.plugins) and each time it kind of hurts users so I hope we
don't go that path. On the other side, never saw anyone complaining of ant
regexes.
Ant like syntax is way more friendly and natural IMHO and does not assume
maven user is a Java expert nor a regex expert (this is actually rare you
use them properly at this location, you likely don't escape it properly or
have some headache with xml in some cases).
I also don't think we can break all plugins out there using this piece of
code so rewriting the impl with whatever newer API is ok if as fast but
changing the config requires a wider discussion IMHO.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 9 juin 2020 à 14:46, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
> On Tue, Jun 9, 2020 at 8:30 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > Wildcard support which is more user friendly (who would like to use java
> > regex to configure that ;)).
>
> Familiarity is user friendly. Standard Java regex that developers
> already know and use beats a marginally simpler syntax they don't. I'd
> rather stick to one well-documented wildcard syntax across multiple
> projects than learn a new and slightly different one for each project.
> Relying on developers to read and understand the details of a new
> syntax is dangerous. That's even assuming it's fully and correctly
> documented and implemented in the first place, which might not be the
> case here.
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: DirectoryScanner, exclusions wins or loose over inclusions?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Tue, Jun 9, 2020 at 8:30 AM Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Wildcard support which is more user friendly (who would like to use java
> regex to configure that ;)).
Familiarity is user friendly. Standard Java regex that developers
already know and use beats a marginally simpler syntax they don't. I'd
rather stick to one well-documented wildcard syntax across multiple
projects than learn a new and slightly different one for each project.
Relying on developers to read and understand the details of a new
syntax is dangerous. That's even assuming it's fully and correctly
documented and implemented in the first place, which might not be the
case here.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DirectoryScanner, exclusions wins or loose over inclusions?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Wildcard support which is more user friendly (who would like to use java
regex to configure that ;)).
In other words you can redo the impl but you will less likely redo the
associated configuration so the class is still needed since DirectoryStream
does not bring any of that AFAIK.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 9 juin 2020 à 14:23, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
> Is there a strong reason anymore to have this class? It is heavily
> used so we're stuck with it for a while, but for new code
> DirectoryStream is in the JDK 7+ and is likely to be better supported,
> less buggy, and more familiar to new developers.
>
> If there's an actual bug or missing documentation in DirectoryScanner,
> then we can fix it. Otherwise I'm inclined to leave it alone.
>
>
> https://docs.oracle.com/javase/7/docs/api/java/nio/file/DirectoryStream.html
>
> On Tue, Jun 9, 2020 at 3:54 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > Hi everyone,
> >
> > As you know, DirectoryScanner is used a lot in plugins.
> > Today I realized that plexus impl does not respect exclusions in the
> visit
> > but only in the result, it means if you exclude **/target/** and include
> > **/*.java, it will visit target to see if there is any java (cause **
> means
> > java can be in target).
> > I did a quick fix for license-maven-plugin (
> > https://github.com/mycila/license-maven-plugin/pull/172) but discussion
> on
> > the PR we wonder if it is something to consider in maven shared utils.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: DirectoryScanner, exclusions wins or loose over inclusions?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
Is there a strong reason anymore to have this class? It is heavily
used so we're stuck with it for a while, but for new code
DirectoryStream is in the JDK 7+ and is likely to be better supported,
less buggy, and more familiar to new developers.
If there's an actual bug or missing documentation in DirectoryScanner,
then we can fix it. Otherwise I'm inclined to leave it alone.
https://docs.oracle.com/javase/7/docs/api/java/nio/file/DirectoryStream.html
On Tue, Jun 9, 2020 at 3:54 AM Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Hi everyone,
>
> As you know, DirectoryScanner is used a lot in plugins.
> Today I realized that plexus impl does not respect exclusions in the visit
> but only in the result, it means if you exclude **/target/** and include
> **/*.java, it will visit target to see if there is any java (cause ** means
> java can be in target).
> I did a quick fix for license-maven-plugin (
> https://github.com/mycila/license-maven-plugin/pull/172) but discussion on
> the PR we wonder if it is something to consider in maven shared utils.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org