I don't really have much to add, but let me answer anyways :-)
1) I am reasonably confident we can compensate for the new classloader
arrangement in m2e without much problems. The new setup does make plugin
runtime classpath less stable, so there are likely other scenarios where
plugins will
I'm going to hold off closing the vote over the weekend to give Igor a
chance to:
1. comment on whether we need an alternative fix for MNG-6275 (and indeed
ideally provide one ;- );
2. comment on whether the fix for MNG-6209 is exposing bugs in plugins that
made incorrect assumptions about TCCL,
The Apache Maven team is pleased to announce the release of the Apache
Maven Surefire Plugin, version 2.20.1
The release contains 24 bug fixes.
Again we received contributions from the community in form of bug reports
and bug fixes.
Thank you and keep them coming!
Has anyone tried wiring jvm extensions ClassLoader as foreign import to
plugin/extensions realms? Jvm extensions classloader is little tricky to
get to (see how this is done in java.util.ServiceLoader.loadInstalled),
but I think this will solve ServiceLoader/MNG-6275 without polluting
plugin
Would it be possible to handle this in a somewhat similar way to threadSafe
mojos - some form of plugin flag that says "extensionSafe" [1], that if the
plugin has true declared and doesn't declare
itself as being extensionSafe/extensionAware then we log a build warning -
it wouldn't solve
Based on Igor's feedback I'm changing my vote to +1.
Having this class loader change in a bug fix release is probably not
(semver) ideal though.
/Anders
On Fri, Sep 15, 2017 at 2:12 PM, Igor Fedorenko wrote:
> I answered in more details on m2e-dev, but I believe we can
I answered in more details on m2e-dev, but I believe we can compensate
for the change from m2e end. In the worst case we'll bundle hacked
version of DefaultClassRealmManager with m2e, not ideal, but not the end
of the world either.
--
Regards,
Igor
On Fri, Sep 15, 2017, at 07:21 AM, Anders
On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar wrote:
> Reporting back from tests of m2e with embedded Maven 3.5.1, we see problem
> with the jaxws-maven-plugin mojo. We're two people seeing the issue
> independently, but unfortunately Fred Bricon hasn't been able to
Just to reply to my self and to add +1 (non-binding).
My two cents on regression (https://issues.apache.org/jira/browse/MNG-6282):
ticket is still open and we (that is: Hervé Boutemy and me) are narrowing the
gap (no ETA at the moment).
IMHO this issue is not a show-stopper; I volunteer to
Hi,
The vote has passed with the following result:
+1 : Enrico Olivelli (non-binding), Dan Tran (binding), Thomas Collignon
(non-binding), jieryn (non-binding), Michael Osipov (binding), Petr Široký
(non-binding), Tibor Digaňa (binding)
PMC quorum: Dan Tran, Michael Osipov, Tibor Digaňa
I will
On 14 September 2017 at 23:55, Michael Osipov wrote:
> Am 2017-09-15 um 00:50 schrieb Petr Široký:
>
>> I was able to easily fix our plugin by e.g. replacing
>> "Thread.currentThread().getContextClassLoader()" with
>> "this.getClass().getClassLoader()" (in the Mojo class) to
Am 2017-09-15 um 00:50 schrieb Petr Široký:
I was able to easily fix our plugin by e.g. replacing
"Thread.currentThread().getContextClassLoader()" with
"this.getClass().getClassLoader()" (in the Mojo class) to get the plugin
classloader.
I don't know though if the
Reporting back from tests of m2e with embedded Maven 3.5.1, we see problem
with the jaxws-maven-plugin mojo. We're two people seeing the issue
independently, but unfortunately Fred Bricon hasn't been able to reproduce.
So currently I'm 0 on the voting but I'll investigate some more.
/Anders
On
13 matches
Mail list logo