Hi again, I've pushed an update to the PR. Updated the LICENSE and NOTICE.Got rid of the MPClassLoaderEnricher. I still kept MPService, but it only reading and setting system properties to configure the environment. This is to prevent changes in system.properties that could mess the configuration. Still, if we prefer to just have these in there, I'm fine dropping the Service and place everything in system.properties. Cheers,Roberto On Tuesday, March 6, 2018, 8:39:20 AM GMT, Mark Struberg <strub...@yahoo.de.INVALID> wrote: Well, we did our best to not use types whose coercion lead to java8 method calls which are not available in a java7 rt.jar.
But the ONLY way you can _guarantee_ Java7 compatibility is to use a java7 rt.jar during the release build. Everything else ended up being broken in some cases. You basically switch to 'JavaScript mode' where you will only blow up at runtime... LieGrue, strub > Am 06.03.2018 um 09:28 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > 2018-03-06 9:11 GMT+01:00 Mark Struberg <strub...@yahoo.de.invalid>: > >> The point is: you cannot pass the mp TCKs with Java7 but only with Java8. >> >> But if you run the release with Java8 then there is a high chance that the >> generated bytecode will not run on Java7 anymore. >> So until we drop Java7 officially (and move to a TomEE-7.1.0 version) we >> have to run the release build on Java7. >> > > That is no more true today since we worked to make it possible cleaning up > bad typings but the point is highly valid. > > >> >> That's why I suggested to only ship MP with TomEE8. >> > > +1 > > >> >> LieGrue, >> strub >> >> >> >>> Am 06.03.2018 um 08:30 schrieb Romain Manni-Bucau <rmannibu...@gmail.com >>> : >>> >>> 2018-03-06 8:22 GMT+01:00 Mark Struberg <strub...@yahoo.de.invalid>: >>> >>>> Did we already solve the Java8 question? >>>> >>> >>> Nop but not a blocker for java 8 >>> >>> >>>> Because if we add MP then you cannot build with Java7 anymore. >>>> >>> >>> We fixed all the java8/7 build time incompatibilities so we can (now, >> agree >>> we need to ensure it is still the case but ATM we dont need buildchain to >>> do it). >>> >>> >>>> >>>> Lg strub >>>> >>>> Mit autocorrect gesendet >>>> >>>>> Am 05.03.2018 um 22:31 schrieb Romain Manni-Bucau < >> rmannibu...@gmail.com >>>>> : >>>>> >>>>> Le 5 mars 2018 22:07, "Jonathan Gallimore" < >> jonathan.gallim...@gmail.com> >>>> a >>>>> écrit : >>>>> >>>>> On Mon, Mar 5, 2018 at 9:03 PM, Romain Manni-Bucau < >>>> rmannibu...@gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> Le 5 mars 2018 21:35, "Jonathan Gallimore" < >>>> jonathan.gallim...@gmail.com> >>>>>> a écrit : >>>>>> >>>>>> The name "MicroProfile" suggests an element of being small, so I'm not >>>>>> sure why we'd only add this to our biggest distribution and no where >>>> else. >>>>>> I've built the change (thanks for the help Roberto), and it adds >> <100KB >>>> to >>>>>> the binary. I'd definitely add it to Plus and Plume, but I think we >>>> should >>>>>> either add it web profile, or if we really don't want it in >> WebProfile, >>>> I >>>>>> see no harm in an extra flavour that is webprofile + microprofile. >>>>>> >>>>>> >>>>>> Ok for plume and plus for me, please not to WP. >>>>>> >>>>> >>>>> Would you be ok with the MP profile then? Seems like reasonable middle >>>>> ground. Without that, folks who want "Micro"Profile features would be >>>>> forced to use the biggest flavours. >>>>> >>>>> >>>>> Yep, as mentionned no issue to have a new distro ;). >>>>> >>>>> >>>>> >>>>>> >>>>>> Open point: should it be switchable to off even if provided in case it >>>>>> breaks apps? >>>>>> >>>>> >>>>> I'm ok with that. >>>>> >>>>> Jon >>>> >>>> >> >>
