We have developed a maven EventSpy to report progress of maven phases and mojos.
when running from command line with -Dmaven.ext.class.path=PATH-TO-JAR it works fine as expected.
when running under jenkins in a maven project , the jenkins maven-plugin ignores
-Dmaven.ext.class.path and does not add our EventSpy jar to the classpath.
this forces us to place the jar in maven ext folder which is not a good idea when managing many slaves and especially if we want jenkins to auto install maven.
this also complicates our code because we don't want this spy for all our maven builds, but when the jar is in maven ext folder it will always be there and we have to set the plugin active or not by setting another system property from the jenkins job.
So we placed our spy jar in maven's lib/ext folder.
But when placing the jar in maven ext folder our EventSpy is added twice to maven's EventSpyDispatcher. the problem is in Maven32Launcher from the artifact maven32-interceptor:1.6,
Maven32Launcher executes this line in it's main method:
this causes plexus container to initialize EventSpyDispatcher as its a @Requirement of DefaulrMaven, and then also our EventSpy is injected to the EventSpyDispatcher instance.
then Maven32Launcher executes this code:
this will find our EventSpy again and will add it again to the list of spies resulting in doubling the events we get from maven.
to solve it currently we added our own EventSpyDIspatcher class that removes duplicate EventSpy from the event spies list. we annotated the class with @Component( role = EventSpyDispatcher.class ) and plexus is using our class instead of the default EventSpyDispatcher but I feel I can't trust this solution.
another issue is while running from jenkins some events are received before the spy's init is called, for example DefaultSettingsBuildingRequest event.
I feel that jenkins maven plugin should not break maven's command line interface even if some features are rarely used. and thus maven.ext.class.path should not be ignored when running in a maven project.