Le 21 août 2016 20:44, "Mark Struberg" <strub...@yahoo.de.invalid> a écrit : > > Oh if it's not public then we should really make it! > > You are right with 'production code'. Of course it's in production. > But it's more like infrastructure glue code and not business related, right? > Means your colleagues tinkering on UI and business should typically not even get it as compile scoped dependency but really only as runtime dep. > John, romain, do you agree on this point?
So not what we are talking about and my point ;). If we care then you dev against config source api. Sounds like we can need a config-support module for such a case if you case of visibility > Just trying to make a few steps back to look at the problem from a distance... > > LieGrue, > Strub > > > Am 21.08.2016 um 16:11 schrieb Romain Manni-Bucau <rmannibu...@gmail.com >: > > > > 2016-08-21 16:08 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>: > > > >> EnvironmentPropertyConfigSourceProvider is effectively an internal class. > >> And thus I'd not move it to the API. Just look how much we would need to > >> add to the api package. > >> > >> I understand that you don't like to duplicate code. > >> > >> Usually things like ConfigSources are totally orthogonal to your > >> production code. So you need those only as runtime dependency. > > I get the idea but this is likely not what you wanted to say. Typically > > sources are production code (but not business code). > > > > > >> > >> In that case just make a tool module which has ds-core-impl as compile > >> time dependency and then you can simply re-use and even extend the internal > >> class. > >> But that class is clearly NOT an API class imo. > > Question is: how stable do we consider -impl is? If the solution to that > > issue is 1. make the class (whichever it is) public 2. say to the user to > > import -impl in his pom, then we need to show that the API is stable and > > not just an internal we can break when we want. @Stable would be an option > > but moving it to -api is another one. Don't care of the solution while we > > prevent the user to duplicate our -impl code. > > > > > >> LieGrue, > >> strub > >> > >> > >> > >> > >> > >>> On Sunday, 21 August 2016, 15:28, John D. Ament <johndam...@apache.org > > >> wrote: > >>>> Hi, > >>> > >>> I have a use case for leveraging something > >>> like EnvironmentPropertyConfigSourceProvider to load multiple property > >>> files, outside of apache-deltaspike.properties. Right now its package > >>> local and in the impl JAR. I'd rather not duplicate the logic since > >> whats > >>> being done is exactly what is needed. I was wondering if anyone had any > >>> concerns with making this an API class instead of an impl class? > >>> > >>> John > >> >
