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 <[email protected]> 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 > > [email protected]> > > >> 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 > > >> [email protected] > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
