Hmmm, so I did some experiments: If you want to ride along, the experiments are at:
https://github.com/stephenc/mng-6209 So basically I have a plugin that does three different tests: getLog().info("Injected by @Component:"); for (Lifecycle l : lifecycles) { if (l.getId().startsWith("mng-6209-")) { getLog().info(" " + l.getId().substring(9)); } } getLog().info(""); getLog().info("On Plugin Class Loader:"); try { ClassLoader tccl = ListMojo.class.getClassLoader(); for (URL url : Collections.list(tccl.getResources("META-INF/probe.txt"))) { InputStream is = url.openStream(); try { getLog().info(" " + IOUtil.toString(is).trim()); } finally { is.close(); } } } catch (IOException e) { throw new MojoExecutionException(e.getMessage(), e); } getLog().info(""); getLog().info("On Thread Context Class Loader:"); try { ClassLoader tccl = Thread.currentThread().getContextClassLoader(); for (URL url : Collections.list(tccl.getResources("META-INF/probe.txt"))) { InputStream is = url.openStream(); try { getLog().info(" " + IOUtil.toString(is).trim()); } finally { is.close(); } } } catch (IOException e) { throw new MojoExecutionException(e.getMessage(), e); } First off, I hijack the @Component injection with some fake "lifecycles" to see what "plexus" exposes to the plugins. Second, I look at the resources visible from the plugin's classloader. Finally, I look at the resources visible from the TCCL. Here's what 3.5.0 outputs: [INFO] ------------------------------------------------------------------------ [INFO] Building Both extensions. Order: plugin1, plugin2 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe1 --- [INFO] Injected by @Component: [INFO] plugin1 [INFO] [INFO] On Plugin Class Loader: [INFO] plugin1 [INFO] [INFO] On Thread Context Class Loader: [INFO] plugin1 [INFO] [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe1 --- [INFO] Injected by @Component: [INFO] plugin2 [INFO] [INFO] On Plugin Class Loader: [INFO] plugin2 [INFO] [INFO] On Thread Context Class Loader: [INFO] plugin2 [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Only plugin1 extensions. Order: plugin1, plugin2 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe2 --- [INFO] Injected by @Component: [INFO] plugin1 [INFO] [INFO] On Plugin Class Loader: [INFO] plugin1 [INFO] [INFO] On Thread Context Class Loader: [INFO] plugin1 [INFO] [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe2 --- [INFO] Injected by @Component: [INFO] plugin2 [INFO] plugin1 [INFO] extjar2 [INFO] extjar1 [INFO] [INFO] On Plugin Class Loader: [INFO] plugin2 [INFO] extjar2 [INFO] extjar1 [INFO] [INFO] On Thread Context Class Loader: [INFO] plugin2 [INFO] extjar2 [INFO] extjar1 [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Both extensions. Order: plugin2, plugin1 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe3 --- [INFO] Injected by @Component: [INFO] plugin2 [INFO] [INFO] On Plugin Class Loader: [INFO] plugin2 [INFO] [INFO] On Thread Context Class Loader: [INFO] plugin2 [INFO] [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe3 --- [INFO] Injected by @Component: [INFO] plugin1 [INFO] [INFO] On Plugin Class Loader: [INFO] plugin1 [INFO] [INFO] On Thread Context Class Loader: [INFO] plugin1 [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Both extensions. Order: plugin1, plugin2. Extra dependency in plugin1 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe4 --- [INFO] Injected by @Component: [INFO] extjar2 [INFO] plugin1 [INFO] [INFO] On Plugin Class Loader: [INFO] plugin1 [INFO] extjar2 [INFO] [INFO] On Thread Context Class Loader: [INFO] plugin1 [INFO] extjar2 [INFO] [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe4 --- [INFO] Injected by @Component: [INFO] plugin2 [INFO] [INFO] On Plugin Class Loader: [INFO] plugin2 [INFO] [INFO] On Thread Context Class Loader: [INFO] plugin2 [INFO] ------------------------------------------------------------------------ Now if we run with 3.5.1 (which contains the fix for MNG-6209) [INFO] ------------------------------------------------------------------------ [INFO] Building Both extensions. Order: plugin1, plugin2 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe1 --- [INFO] Injected by @Component: [INFO] plugin2 [INFO] plugin1 [INFO] extjar2 [INFO] extjar1 I would have expected the sequence to be: /build/extensions in pom order followed by /build/plugins/plugin[extensions=true] in pom order. This seems to be the reverse order. Is this a bug? [INFO] [INFO] On Plugin Class Loader: [INFO] plugin1 We haven't changed how the plugin classloader gets instantiated in MNG-6209. It seems strange to me that this excludes the /build/extensions... on the other hand this could be a side-effect of how the classloader gets instantiated (which would mean using the plugin's classloader is probably a bad idea, perhaps we need to provide the ability to inject the classloader as a @Component or something) [INFO] [INFO] On Thread Context Class Loader: [INFO] extjar1 [INFO] extjar2 OK, we see the change vs 3.5.0 as this is now the project realm... though I would have expected the project realm to also include the plugins that were marked as extensions... [INFO] [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe1 --- [INFO] Injected by @Component: [INFO] plugin2 [INFO] plugin1 [INFO] extjar2 [INFO] extjar1 [INFO] [INFO] On Plugin Class Loader: [INFO] plugin2 [INFO] [INFO] On Thread Context Class Loader: [INFO] extjar1 [INFO] extjar2 [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Only plugin1 extensions. Order: plugin1, plugin2 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe2 --- [INFO] Injected by @Component: [INFO] plugin1 [INFO] extjar2 [INFO] extjar1 As expected, given that plugin2 is not an extension here (apart from the order being reverse of what I expect) [INFO] [INFO] On Plugin Class Loader: [INFO] plugin1 [INFO] [INFO] On Thread Context Class Loader: [INFO] extjar2 [INFO] extjar1 [INFO] [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe2 --- [INFO] Injected by @Component: [INFO] plugin2 [INFO] plugin1 [INFO] extjar2 [INFO] extjar1 As expected (modulo order) because a plugin should see any self-defined extensions. I would expect the order to be plugin2, extjar1, extjar2, plugin1 (because the plugin is not an extension, it should have its extensions as priority over the project realms's) [INFO] [INFO] On Plugin Class Loader: [INFO] plugin2 [INFO] extjar2 [INFO] extjar1 WAT! ok, this I do not understand. Something is wrong somewhere, either plugin1's classloader should also include extjar2 and extjar1 or this one shouldn't. And since we have extjar1 and extjar2 where is plugin1? (if the inclusion is correct here I expect plugin2, extjar1, extjar2, plugin1 as a plugin that is not an extension plugin should have its own implementation first followed then by /build/extensions in pom order and then /build/plugins/plugin[extension==true] This is making no sense at all! [INFO] [INFO] On Thread Context Class Loader: [INFO] plugin2 [INFO] extjar2 [INFO] extjar1 So TCCL is the plugin classloader here as expected [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Both extensions. Order: plugin2, plugin1 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe3 --- [INFO] Injected by @Component: [INFO] plugin2 [INFO] plugin1 [INFO] extjar2 [INFO] extjar1 I note that the change in pom order has had no effect on the component sequence. This leads me to suspect that plexus has some rule that is defining the sequencing... it would be good if we could document that somewhere... [INFO] [INFO] On Plugin Class Loader: [INFO] plugin2 [INFO] [INFO] On Thread Context Class Loader: [INFO] extjar2 [INFO] extjar1 [INFO] [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe3 --- [INFO] Injected by @Component: [INFO] plugin2 [INFO] plugin1 [INFO] extjar2 [INFO] extjar1 [INFO] [INFO] On Plugin Class Loader: [INFO] plugin1 [INFO] [INFO] On Thread Context Class Loader: [INFO] extjar2 [INFO] extjar1 [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Both extensions. Order: plugin1, plugin2. Extra dependency in plugin1 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- plugin1:1.0-SNAPSHOT:list (default) @ probe4 --- [INFO] Injected by @Component: [INFO] plugin1 [INFO] extjar2 [INFO] plugin2 [INFO] extjar2 [INFO] extjar1 WAT! seems that @Component is somewhat in random order, in this case we have modified the dependencies if plugin1 to also include extjar2, the order I would expect is: extjar1, extjar2, plugin1, extjar2, plugin2 Given the previous executions and the fact that changing the sequence of plugin1 and plugin2 in the pom did not affect the previous executions, if plexus had a deterministic ordering then I would have been somewhat OK with: plugin2, plugin1, extjar2, extjar2, extjar1 But this seems to suggest that we have a completely non-deterministic ordering... that is not good for reproducible builds... [INFO] [INFO] On Plugin Class Loader: [INFO] plugin1 [INFO] extjar2 Now we see extjar2 but only because it has been explicitly added to the plugins dependencies, IMHO it should be here twice, e.g. extjar1, extjar2, plugin1, extjar2, plugin2 But it seems acceptable if this is instead plugin1, extjar2 (though it makes the plugin classloader useless for discovery) [INFO] [INFO] On Thread Context Class Loader: [INFO] extjar1 [INFO] extjar2 [INFO] [INFO] --- plugin2:1.0-SNAPSHOT:list (default) @ probe4 --- [INFO] Injected by @Component: [INFO] plugin1 [INFO] extjar2 [INFO] plugin2 [INFO] extjar2 [INFO] extjar1 [INFO] [INFO] On Plugin Class Loader: [INFO] plugin2 [INFO] [INFO] On Thread Context Class Loader: [INFO] extjar1 [INFO] extjar2 [INFO] ------------------------------------------------------------------------ Is this just a whole new set of bugs that I have found? Does this alter how we think things should work? Right now I am unclear as to whether we should go ahead with releasing 3.5.1 given the effects of MNG-6209... at least in terms of exposing some strangeness in the classloaders On 16 September 2017 at 03:51, Stephen Connolly < [email protected]> wrote: > > On Sat 16 Sep 2017 at 10:51, Stephen Connolly < > [email protected]> wrote: > >> On Sat 16 Sep 2017 at 04:07, Igor Fedorenko <[email protected]> wrote: >> >>> 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 behave differently (bad). On the other hand, I don't see >>> any better way to support ServiceLoader. For java 8 it may be possible >>> to use foreign-import of extensions classloader to fix MNG-6275, but >>> that classloader was removed in java 9, unless I am mistaken. >> >> >> Ok so I think the consensus is 6275 is probably a necessary fix for Java >> 8 interoperability, but may expose bugs in plugins that made incorrect >> assumptions, and is a breaking change from the PoV of the eclipse >> integration. Netbeans is fine and IntelliJ seems to do its own think (given >> I have an open bug that suggests IntelliJ is ignorant of the extensions >> type mapping) >> >> >>> >>> 2) I believe TCCL is already set to project realm for projects that have >>> extensions (and to plugin realm otherwise) during plugin execution. >> >> >> So my question is why should TCCL *ever* be anything other than project >> realm? >> >> The pom reference says: >> >> - *extensions*: true or false, whether or not to load extensions of >> this plugin. It is by default false. Extensions are covered later in this >> document. >> >> It does not say that this flag affects the classloader of the plugin, >> rather to me says when true the project realm shall include the plugin's >> extensions. >> >> My understanding was that a plugin would always see its own extensions, >> but if you set this flag then the project would be able to see them too... >> >> Now granted my understanding may be incorrect, but this change seems to >> be turning things in an entirely different direction >> > > Ok discussed this on #maven-dev > > I need to confirm my analysis, but if correct, then the fix for MNG-6209 > is correct... will need careful release noting > >> >> Problem is, neither project realm nor any of the plugin realms have >>> access to jvm extensions classloader, so ServiceLoader can't get classes >>> from there. >> >> >> That is another set of issues... but this should have been fixed by 6275 >> unless I am mistaken >> >> >>> >>> -- >>> Regards, >>> Igor >>> >>> On Fri, Sep 15, 2017, at 12:09 PM, Stephen Connolly wrote: >>> > 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, or whether the fix is invalid or >>> > even incomplete (I wonder if TCCL should always be >>> > project.getClassRealm() >>> > as extensions should be available to all plugins not just those that >>> > declare they are providing extensions - unless I misunderstand) >>> > >>> > Once I have the required information I will be better able to assess >>> > whether we should release 3.5.1 and follow up with a quick 3.5.2 or >>> just >>> > drop 3.5.1 and go straight to 3.5.2. >>> > >>> > -Stephen >>> > >>> > On 15 September 2017 at 05:45, Igor Fedorenko <[email protected]> >>> > wrote: >>> > >>> > > 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 classpath too much. >>> > > >>> > > -- >>> > > Regards, >>> > > Igor >>> > > >>> > > On Fri, Sep 15, 2017, at 08:32 AM, Mark Derricutt wrote: >>> > > > 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 <extensions>true</extensions> declared and doesn't >>> declare >>> > > > itself as being extensionSafe/extensionAware then we log a build >>> warning >>> > > > - >>> > > > it wouldn't solve anything, other than giving some feedback to >>> users some >>> > > > indication of WHY their build fails under 3.5.1 - and to either >>> remove >>> > > > <extensions> or fix/update their plugins. >>> > > > >>> > > > [1] Or even just infer the applicability of extensions by the >>> presence of >>> > > > custom lifecycles, or Mojos implementing the extension interfaces >>> ( it's >>> > > > midnight, and a hazy tired thought ). >>> > > > >>> > > > -- >>> > > > "Great artists are extremely selfish and arrogant things" — Steven >>> > > > Wilson, >>> > > > Porcupine Tree >>> > > > >>> > > > On Sat, Sep 16, 2017 at 12:22 AM, Anders Hammar <[email protected] >>> > >>> > > > wrote: >>> > > > >>> > > > > 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 < >>> [email protected]> >>> > > > > wrote: >>> > > > > >>> > > > > > 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 Hammar wrote: >>> > > > > > > On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar < >>> [email protected]> >>> > > > > > 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 >>> > > > > > reproduce. >>> > > > > > > > >>> > > > > > > >>> > > > > > > To follow up on this, my tests indicate that Maven 3.5.1 >>> causes >>> > > changed >>> > > > > > > class loading that could cause issues for plugins in m2e. >>> I've >>> > > asked >>> > > > > for >>> > > > > > > input from the m2e devs if it is possible to handle in m2e >>> but they >>> > > > > > > haven't >>> > > > > > > responded yet. >>> > > > > > > >>> > > > > > > /Anders >>> > > > > > > >>> > > > > > > >>> > > > > > > > >>> > > > > > > > So currently I'm 0 on the voting but I'll investigate some >>> more. >>> > > > > > > > >>> > > > > > > > /Anders >>> > > > > > > > >>> > > > > > > > On Wed, Sep 13, 2017 at 9:26 AM, Anders Hammar < >>> > > [email protected]> >>> > > > > > wrote: >>> > > > > > > > >>> > > > > > > >> >>> > > > > > > >> >>> > > > > > > >> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly < >>> > > > > > > >> [email protected]> wrote: >>> > > > > > > >> >>> > > > > > > >>> Have we got any feedback from the embedder integrations >>> yet? >>> > > > > > > >>> >>> > > > > > > >> >>> > > > > > > >> I haven't heard anything from the m2e people. Maybe we >>> need to >>> > > ping >>> > > > > > them >>> > > > > > > >> directly. I can contact Fred Bricon. >>> > > > > > > >> >>> > > > > > > >> /Anders >>> > > > > > > >> >>> > > > > > > >> >>> > > > > > > >>> >>> > > > > > > >>> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY < >>> > > [email protected]> >>> > > > > > > >>> wrote: >>> > > > > > > >>> >>> > > > > > > >>> > just for the records: it is Windows + Git Bash >>> (MINGW64) only >>> > > > > > > >>> > >>> > > > > > > >>> > and there is a chance that adding -Djansi.force=true >>> can >>> > > force >>> > > > > > JAnsi >>> > > > > > > >>> > activation (even if JAnsi fails to detect that it >>> should >>> > > > > > auto-activate) >>> > > > > > > >>> > >>> > > > > > > >>> > details on issue in https://issues.apache.org/ >>> > > > > jira/browse/MNG-6282 >>> > > > > > , >>> > > > > > > >>> and a >>> > > > > > > >>> > future JAnsi issue... >>> > > > > > > >>> > >>> > > > > > > >>> > Regards, >>> > > > > > > >>> > >>> > > > > > > >>> > Hervé >>> > > > > > > >>> > >>> > > > > > > >>> > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen >>> Connolly a >>> > > > > écrit >>> > > > > > : >>> > > > > > > >>> > > So that is windows only, or were they lost on other >>> OSes >>> > > for >>> > > > > you. >>> > > > > > > >>> > > >>> > > > > > > >>> > > I have colours on linux (via docker) and os-x >>> > > > > > > >>> > > >>> > > > > > > >>> > > On 11 September 2017 at 12:35, [email protected] < >>> > > > > > > >>> [email protected]> >>> > > > > > > >>> > > >>> > > > > > > >>> > > wrote: >>> > > > > > > >>> > > > +1 (conditionally). >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > Tested via project that includes dozen of plugins: >>> 1st >>> > > tier, >>> > > > > > > >>> MojoHaus >>> > > > > > > >>> > and >>> > > > > > > >>> > > > few 3rd party plugins (so to say). >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > Everything looks good with one notable regression: >>> > > > > > > >>> > > > https://issues.apache.org/jira/browse/MNG-6282 >>> Console >>> > > > > output >>> > > > > > has >>> > > > > > > >>> no >>> > > > > > > >>> > > > colors (regression in Maven 3.5.1) >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > Regards, >>> > > > > > > >>> > > > Dejan >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > On 2017-09-10 17:39, Stephen Connolly < >>> > > > > > > >>> [email protected] >>> > > > > > > >>> > > >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > wrote: >>> > > > > > > >>> > > > > Hi, >>> > > > > > > >>> > > > > >>> > > > > > > >>> > > > > We solved 25 issues: >>> > > > > > > >>> > > > > https://issues.apache.org/ >>> jira/secure/ReleaseNote.jspa >>> > > ? >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > version=12338964&styleName=Text&projectId=12316922 >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > > There are 350 issues left in JIRA for Maven core: >>> > > > > > > >>> > > > > https://issues.apache.org/ >>> jira/issues/?jql=project%20% >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > 3D%20MNG%20AND%20resolution% >>> 20%3D%20Unresolved%20ORDER% >>> > > > > > > >>> > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C% >>> 20created%20ASC >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > > Staging repo: >>> > > > > > > >>> > > > > https://repository.apache.org/ >>> > > content/repositories/maven- >>> > > > > > 1364/ >>> > > > > > > >>> > > > > >>> > > > > > > >>> > > > > The distributable binaries and sources can be >>> found >>> > > here: >>> > > > > > > >>> > > > > https://repository.apache.org/ >>> > > content/repositories/maven-> >>> > > > > > >>> > > > > > > >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/ >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > > Specifically the zip, tarball and source >>> archives can >>> > > be >>> > > > > > found >>> > > > > > > >>> here: >>> > > > > > > >>> > > > > https://repository.apache.org/ >>> > > content/repositories/maven-> >>> > > > > > >>> > > > > > > >>> > > > 1364/org/apache/maven/apache- >>> > > maven/3.5.1/apache-maven-3.5.1- >>> > > > > > > >>> bin.zip >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > > https://repository.apache.org/ >>> > > content/repositories/maven-> >>> > > > > > >>> > > > > > > >>> > > > 1364/org/apache/maven/apache- >>> > > maven/3.5.1/apache-maven-3.5.1- >>> > > > > > > >>> bin.tar.gz >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > > https://repository.apache.org/ >>> > > content/repositories/maven-> >>> > > > > > >>> > > > > > > >>> > > > 1364/org/apache/maven/apache- >>> > > maven/3.5.1/apache-maven-3.5.1- >>> > > > > > > >>> src.zip >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > > https://repository.apache.org/ >>> > > content/repositories/maven-> >>> > > > > > >>> > > > > > > >>> > > > 1364/org/apache/maven/apache- >>> > > maven/3.5.1/apache-maven-3.5.1- >>> > > > > > > >>> src.tar.gz >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > > Source release checksum(s): >>> > > > > > > >>> > > > > apache-maven-3.5.1-src.tar.gz sha1: >>> > > > > > > >>> 9eb821f153c7667194aa11ccd099b7 >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > bd2059560d >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > > apache-maven-3.5.1-src.zip: sha1: >>> > > > > > 121d54b045380a8a4895eb137970ab >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > 69e698eb0e >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > > Git tag: >>> > > > > > > >>> > > > > https://git-wip-us.apache.org/ >>> repos/asf?p=maven.git;a= >>> > > > > > commit;h= >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > 094e4e31a5af55bb17be87675da41d9aeca062f3 >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > > Staging site: >>> > > > > > > >>> > > > > https://maven.apache.org/ >>> components/ref/3-LATEST/ >>> > > > > > > >>> > > > > >>> > > > > > > >>> > > > > Vote open for 72 hours. >>> > > > > > > >>> > > > > >>> > > > > > > >>> > > > > [ ] +1 >>> > > > > > > >>> > > > > [ ] +0 >>> > > > > > > >>> > > > > [ ] -1 >>> > > > > > > >>> > > > > >>> > > > > > > >>> > > > > Thanks, >>> > > > > > > >>> > > > > >>> > > > > > > >>> > > > > Stephen. >>> > > > > > > >>> > > > >>> > > > > > > >>> > > > ------------------------------ >>> > > ------------------------------ >>> > > > > > > >>> --------- >>> > > > > > > >>> > > > To unsubscribe, e-mail: >>> [email protected] >>> > > > > > > >>> > > > For additional commands, e-mail: >>> > > [email protected] >>> > > > > > > >>> > >>> > > > > > > >>> > >>> > > > > > > >>> > >>> > > > > > > >>> > ------------------------------ >>> ------------------------------ >>> > > > > > --------- >>> > > > > > > >>> > To unsubscribe, e-mail: [email protected]. >>> org >>> > > > > > > >>> > For additional commands, e-mail: >>> [email protected] >>> > > > > > > >>> > >>> > > > > > > >>> > -- >>> > > > > > > >>> Sent from my phone >>> > > > > > > >>> >>> > > > > > > >> >>> > > > > > > >> >>> > > > > > > > >>> > > > > > >>> > > > > > ------------------------------------------------------------ >>> > > --------- >>> > > > > > To unsubscribe, e-mail: [email protected] >>> > > > > > For additional commands, e-mail: [email protected] >>> > > > > > >>> > > > > > >>> > > > > >>> > > >>> > > ------------------------------------------------------------ >>> --------- >>> > > To unsubscribe, e-mail: [email protected] >>> > > For additional commands, e-mail: [email protected] >>> > > >>> > > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> -- >> Sent from my phone >> > -- > Sent from my phone >
