Thanks Robert. Congratulations on the outstanding research. Personally I am surprised that the Maven Plugin Plugin was scanning *all* my dependencies. I have nothing to offer it. :-) My project source is where my Mojo annotations are and not in any dependencies. So when I reported a suspected ASM leak, I was reading the error wrong -- the mojo scanner was scanning my version of ASM instead. I appreciate you going to create new ticket to customize the scanning behavior. I fully agree with you that (1) special classes like module/package-info.class should not be scanned and (2) scanning should be configurable to be finer tuned.
Again, thanks! Cheers, Paul On Tue, Jul 19, 2016 at 1:10 PM, Robert Scholte <[email protected]> wrote: > Hi, > > after some investigation Paul and I have good news: *none* of the classes > is leaking into the plugin. > > Some details: the Annotation scanners doesn't only scan the compiled > classes in the outputDirectory, but also in all the dependencies in search > for other (Abstract)Mojo's. > One of the files which the scanner found was > asm-6.0_ALPHA.jar!/module-info.class > maven-plugin-plugin:3.2 will throw a NullPointerException on this file, > more recent versions throw an IllegalArgumentException. > The plugin can't handle this Java9 file, yet. > > I will create some Jira issues regarding this: > - ensure that special classes are never scanned > - better control over the dependencies to scan, where I would prefer a > solution where the plugin knows if additional scanning of dependencies is > required based on the superclass(es) of the mojo's. > > thanks, > Robert > > > On Mon, 18 Jul 2016 22:20:41 +0200, Robert Scholte <[email protected]> > wrote: > > sure >> >> On Mon, 18 Jul 2016 22:13:46 +0200, Paul Benedict <[email protected]> >> wrote: >> >> Sure, I'll just have to produce a dummy example from my current project. >>> Can I mail you a zip personally? >>> >>> Cheers, >>> Paul >>> >>> On Mon, Jul 18, 2016 at 3:10 PM, Robert Scholte <[email protected]> >>> wrote: >>> >>> Do you have the code somewhere so we can have a look at what's happening? >>>> I did a quick look at the scanner code but can't find a reason why ASM >>>> should be leaking. >>>> >>>> Robert >>>> >>>> >>>> On Mon, 18 Jul 2016 22:03:23 +0200, Paul Benedict <[email protected] >>>> > >>>> wrote: >>>> >>>> If I may expand this thread to the subject of class loaders, how is it >>>> >>>>> possible that a plugin's own dependencies can ever leak into mine? I >>>>> know >>>>> shading is a common solution, but I am curious why this particular >>>>> situation can occur at all. Got any insight on the matter? I read the >>>>> stock >>>>> documentation on this subject [1], but I think more information is >>>>> needed. >>>>> >>>>> [1] http://maven.apache.org/guides/mini/guide-maven-classloading.html >>>>> >>>>> Cheers, >>>>> Paul >>>>> >>>>> On Mon, Jul 18, 2016 at 2:39 PM, Robert Scholte <[email protected]> >>>>> wrote: >>>>> >>>>> On Mon, 18 Jul 2016 19:18:36 +0200, Paul Benedict < >>>>> [email protected]> >>>>> >>>>>> wrote: >>>>>> >>>>>> Hi. It seems when I build my maven plugin, ASM is being used to scan >>>>>> for >>>>>> my >>>>>> >>>>>> Mojo annotations. I use ASM internally for my own code. My ASM is the >>>>>>> latest 6.0_ALPHA and it's causing an NPE when the Maven Plugin Plugin >>>>>>> executes. If I downgrade to something less, then there is no >>>>>>> interference >>>>>>> with the build. >>>>>>> >>>>>>> I am surprised to see ASM leak into my plugin like this. Whatever >>>>>>> version >>>>>>> I >>>>>>> am using is clearly affecting the Plugin Plugin. I would classify >>>>>>> this >>>>>>> behavior as a bug -- no need for ASM to leak into my project. >>>>>>> Thoughts? >>>>>>> >>>>>>> Cheers, >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> Hard to tell, you might be right. Unless it is something like >>>>>> surefire, >>>>>> which also needs surefire to execute the unittests. This causes class >>>>>> collisions, so surefire uses a shaded version of the >>>>>> maven-surefire-plugin >>>>>> to handle this. >>>>>> If we can't isolate ASM, we might need to shade or have a second >>>>>> implementation. >>>>>> >>>>>> Robert >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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] >>>> >>>> >> --------------------------------------------------------------------- >> 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] > >
