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 <[email protected]> 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 <[email protected]> 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 <[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] >> > > >> > > >> > >> >
