maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <>
Subject Problem sharing objects between extension and plugin
Date Tue, 09 Oct 2018 15:45:45 GMT
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@

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?


Cheers and God bless,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message