Hi Roberto, I'd drop it:
1. the default should stay the same as in G-config to have a consistent behavior for end user I think and you should be able to have live updates normally 2. I was not thinking to the webapp enrichment prefix but more to make https://github.com/apache/tomee/blob/8fc8d8011c5155e7f47ebc162cb88124bf4ca06e/container/openejb-core/src/main/java/org/apache/openejb/config/DeploymentLoader.java#L1099 active by default and configurable. Concretely applyBuiltinExcludes takes an include/exclude pair we should make configurable as in https://github.com/apache/tomee/blob/8fc8d8011c5155e7f47ebc162cb88124bf4ca06e/container/openejb-core/src/main/java/org/apache/openejb/config/NewLoaderLogic.java#L445 or https://github.com/apache/tomee/blob/8fc8d8011c5155e7f47ebc162cb88124bf4ca06e/container/openejb-core/src/main/java/org/apache/openejb/config/TldScanner.java#L337 but with other key names for jar name prefixes ( openejb.scan.webapp.container.includes and openejb.scan.webapp.container.excludes?). Default can use geronimo-* if we ensure all default g-* are excluded except mp ones (what you started in exclusions.list). Hope it makes sense Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> 2018-03-06 11:32 GMT+01:00 Roberto Cortez <radcor...@yahoo.com.invalid>: > > 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 > >>>> > >>>> > >> > >> > >
