I like that feature. But I don't like to pollute our pretty clean API with it ;)
At the end it's an impl detail whether you duplicate it, write it your own, or reuse the class from ds-core-impl. (Assuming we make necessary parts public). Ofc we give clearly less guarantees for stability than our API classes. But it should remain considerably stable in the foreseeable future I think. LieGrue, Strub > Am 21.08.2016 um 17:12 schrieb Romain Manni-Bucau <[email protected]>: > > Mark/Gerhard: are you against the feature or packaging? > > Le 21 août 2016 16:37, "Gerhard Petracek" <[email protected]> a > écrit : > >> @mark: +1 >> >> regards, >> gerhard >> >> >> >> 2016-08-21 16:08 GMT+02:00 Mark Struberg <[email protected]>: >> >>> 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. >>> >>> >>> 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. >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> >>>> On Sunday, 21 August 2016, 15:28, John D. Ament <[email protected] >>> >>> 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 >>
