For clarity, I was testing against 3.3.9. I tried with 3.5.4 today without a change in results. However, I did discover something interesting that I confirmed in both versions...
Given my setup: *) Utility jar has several plexus components and non-components *) Utility jar has an AbstractMavenLifecycleParticipant component *) Plugin has a dependency on the utility jar *) In target project, utility jar is an <extension> and <plugin> is used Findings: 1) For the plugin, if the dependent utility jar is set to scope "compile|test|runtime", I get class duplication. This is the case that generates the "class X cannot be cast to class X" error. My debugging shows the extension class loader and the plugin class loader are both using different Class<X> instantiations. 2) For the plugin, if the dependent utility jar is set to scope "provided", the COMPONENTS are nicely accessible to both .... but none of the non-component classes are. I am still looking for an escape hatch. Each case gives me some progress but not enough to meet my requirements. So is this the way Maven or MNG-6209 is meant to work? Is any of this unexpected to you all? Cheers and God bless, Paul On Tue, Oct 9, 2018 at 1:22 PM Robert Scholte <[email protected]> wrote: > MNG-6209 is indeed the first issue that comes to my mind and I wonder if > this is fixed. I thought it was reverted after issues with the 3.5.1 > release. > > Together with Stephen we've tried to define how this should work. > He wrote some tests[1] to demonstrate the issue. > I've tried to show the difference in behavior between 3.5.0 and the > (cancelled) 3.5.1 Maven releases. > > Have a look at it, try to run it and share your experience. > I consider this as a critical bug, but it is in the heart of Maven, not > many dare to touch this part but I think we should once we agree on the > expected behavior. > > thanks, > Robert > > [1] https://github.com/stephenc/mng-6209 > [2] > > https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2 > > > On Tue, 09 Oct 2018 17:45:45 +0200, Paul Benedict <[email protected]> > wrote: > > > Good day. I hope this post is acceptable. I don't mean to "cross post" > > but > > I think my problem may be too difficult for the common question on the > > user@ > > list. > > > > I scoured all the MNG tickets regarding extensions and class loading > > documentation on the Maven site (and elsewhere), but cannot find a clear > > answer to my problem. This problem is a roadblock for my work. I can't > > seem > > to make any headway; so any expedient response would be overwhelmingly > > appreciated. This may or may not be related to MNG-6209. > > > > TL;DR link to my user@ list post [1]. > > > > The quick summary: > > *) Project A (library of @Components and other utility classes) > > *) Project B (build plugin) > > *) Project C (uses build <extension> of Project A and build <plugin> of > > Project B) > > > > The quick problem: > > In Project A, there is a lifecycle callback that takes an injected > > component from A, and stores it in the plugin context of B. When B > > retrieves the object, I receive a "type X cannot be case to type X" > > error. > > > > Is this intended? I am getting conflicted documentation. > > Curiously, the older documentation in SVN is much more descriptive. I > > wish > > this was the one on the site -- if it is still valid. Is it still valid > > information? Should this be really what the official mini guide should > > be? > > *) Published 2018-10-15: This is the #1 google hit for "maven class > > loader" > > search [1]. This is on the Maven site itself... There is no mention > here > > a > > restriction on extensions and plugins unable to share classes. > > *) Published 2018-04-30: This is the #3 google hit for "maven class > > loader" > > search [1]. This is from SVN... There is mention here that "it is not > > possible" for extensions and plugins to share classes. > > > > Lastly, if the last documentation is the truth, is there any escape > > hatch? > > IMO, it is very valuable when a build extension is able to setup one-time > > data that plugins can later use. In my use case, I had to retrieve some > > complex information, which then allowed me to dynamically add a > > dependency > > to the build -- but I don't want to lose the ancillary information that > > went with the retrieval. I want that available to the plugin for further > > logic. Thoughts, please? > > > > References: > > [1] > > > https://lists.apache.org/thread.html/341a92e7b9b4dab328077d32a8490df3bc9866c544bfcc03b5e4c6d9@%3Cusers.maven.apache.org%3E > > [2] https://maven.apache.org/guides/mini/guide-maven-classloading.html > > [3] > > > https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html > > > > Cheers and God bless, > > Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
