> On Oct 1, 2017, at 2:48 AM, sebb <seb...@gmail.com> wrote: > > On 1 October 2017 at 10:08, Pascal Schumacher <pascalschumac...@gmx.net > <mailto:pascalschumac...@gmx.net>> wrote: >> Looks like commons-logging-api is used by some popular projects (Hibernate, >> Hadoop, Camel): >> >> http://www.mvnrepository.com/artifact/commons-logging/commons-logging-api/usages >> >> <http://www.mvnrepository.com/artifact/commons-logging/commons-logging-api/usages> >> >> but I guess they can easily switch to commons-logging. > > Not sure I agree with that. > > The purpose of the api jar is to define the API only without bringing > in the rest of the code. > Potentially having the implementation as well could cause issues. > >> Commons-logging-adatper seem to be very rarely used: >> >> http://www.mvnrepository.com/artifact/commons-logging/commons-logging-adapters/usages >> >> <http://www.mvnrepository.com/artifact/commons-logging/commons-logging-adapters/usages> >> >> As I understand it there is no other (realistic) choice than dropping the >> api and the adpater jars, so +1 from me. > > The split into API and implementation seems to me to be a > well-established pattern, so if Maven or Java 9 cannot support that > then it is Maven or Java 9 that needs to be fixed.
I would agree with you if commons-logging had done a proper job of splitting the api from the implementation. It did not. Everything is together in one source directory and the build picks and chooses what goes into each jar. Maven isn’t even in the picture here. If it was this probably would have been done properly. Java 9 isn’t going to be “fixed”. It simply does not allow classes in the same package to appear in more than one module. A proper separation of API from implementation would normally have put them in different packages. Ralph
