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 > > >
