gnodet commented on pull request #690:
URL: https://github.com/apache/maven/pull/690#issuecomment-1064151253
> @gnodet Does this apply to 3.8.x? I guess we need a new JIRA issue to
clearly document this problem/regression.
@michael-o It does apply to 3.8.x, and yes, I'll create a JIRA.
> But this does actually shows that an project classlaoder is leaked. I
don't see how reverting this makes the situation better (beside that 'it has
worked before') as obviously here we have a gap where a **random** project
classloader is used.
It *was* leaking : the current PR still reverts at the end of the build.
And yes, I agree that specifying build extensions at various level of a reactor
may lead o unpredictable results. However,
* I think the current behavior (i.e. an extension defined at the top should
be effective throughout the build) should be preserved
* while defining extensions inside the reactor is theoretically possible, I
don't think any used that and I don't think we need to support those use cases
This leads me to think that reverting to the previous behavior is the way
to do, while still avoiding the leak at the end of the build.
> > Also, about the _last project_ point, I think in most cases, only the
top level project has a specific classloader.
>
> If it is not the last then "the last one that has a specific classloader",
and working of such extensions then was jsut a side-effect and if thats true
what you wrote why then all these "attach to thread" for each project? As far
as i understand the "top level" is the pom actually executed and assume that
that is the only valid one to have extensions seems a bit strange.
Defining extensions not at the top level was broken, as you said, the last
project defining extensions was used for the whole build. So I assume that's
actually not a use case and we don't need to fix it. It would be easier to
forbid them at the moment if we really want to fix the possible problem.
> Do you refer to
https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/CacheLifecycleParticipant.java
? Why do you make this a session scoped `@Named` and not a plain
`@Component(role = AbstractMavenLifecycleParticipant.class, hint = "cache")`?
Thats how tycho works and maven sets the appropriate classlaoder when calling
the methods.
Actually, the one that cause problems is the
[BuildCacheMojosExecutionStrategy](https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java),
and yes, it's session scoped because I'm aiming at integrating this extension
in `mvnd` which reuses maven plexus realms and thus makes a much bigger
difference between `@Singleton` and `@SessionScoped` components.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
