> Am 01.10.2017 um 11:48 schrieb sebb <seb...@gmail.com>: > > On 1 October 2017 at 10:08, Pascal Schumacher <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 >> >> 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 >> >> 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 don’t think that is going to happen :-) So what options are we left with? - Do nothing -> logging can’t be used as a Java 9 module - Drop api and adapters -> users have to change their dependencies and get more code than they want Anything else? Benedikt > >> Cheers, >> Pascal >> >> >> Am 01.10.2017 um 10:25 schrieb Benedikt Ritter: >>> >>> Okay, so we agree to drop the api and adapters jars from the build and the >>> distribution? If that is the case, I think we are ready to release this. >>> >>> Benedikt >>> >>> Gary Gregory <garydgreg...@gmail.com> schrieb am So. 1. Okt. 2017 um >>> 03:39: >>> >>>> On Sep 30, 2017 11:24, "Ralph Goers" <ralph.go...@dslextreme.com> wrote: >>>> >>>> Looking at the build script it appears that both the api and adapters >>>> modules contain a subset of what is in commons-logging.jar. I have no >>>> idea >>>> why this is but all three of them cannot be modularized. I would suggest >>>> only modularizing commons-logging.jar and ignoring the other two. >>>> >>>> >>>> Makes sense to me. >>>> >>>> Gary >>>> >>>> >>>> Ralph >>>> >>>>> On Sep 30, 2017, at 1:28 AM, Benedikt Ritter <brit...@apache.org> wrote: >>>>> >>>>> >>>>>> Am 26.09.2017 um 23:34 schrieb Stephen Colebourne <scolebou...@joda.org >>>>> >>>>> : >>>>>> >>>>>> The contents of pom.xml look OK. I can't seem to browse to see if you >>>>>> changed anything else in that commit. >>>>>> >>>>>> I would suggest being extra cautious when releasing, as a newer >>>>>> version of maven may have changed some of the config, and you don't >>>>>> want to release the two extra jars to maven central. (In fact, why not >>>>>> just delete their creation in pom.xml ?) >>>>> >>>>> They are part of our standard distribution (I don’t know why) [1]. In >>>> >>>> fact I saw commons-logging-api.jar fly by last time I build my Spring >>>> Boot >>>> project. So it seems that those additional artifacts are still in use. >>>>> >>>>> I don’t know how well this plays with Automatic-Module-Name. If I >>>> >>>> understand correctly only one jar can have org.apache.common.logging. >>>>> >>>>> Benedikt >>>>> >>>>> [1] http://commons.apache.org/proper/commons-logging/guide. >>>> >>>> html#Jars_Included_in_the_Standard_Distribution >>>>>> >>>>>> Stephen >>>>>> >>>>>> On 26 September 2017 at 22:05, Benedikt Ritter <brit...@apache.org> >>>> >>>> wrote: >>>>>>>> >>>>>>>> Am 26.09.2017 um 22:54 schrieb Stephen Colebourne < >>>> >>>> scolebou...@joda.org >>>>> >>>>> : >>>>>>>> >>>>>>>> On 26 September 2017 at 18:48, Jörg Schaible <joerg.schai...@gmx.de> >>>> >>>> wrote: >>>>>>>>> >>>>>>>>> AFAICS we have only commons-logging. The other artifacts have not >>>> >>>> been part >>>>>>>>> >>>>>>>>> of any release in the last decade. >>>>>>>> >>>>>>>> Simple then! >>>>>>> >>>>>>> Please review revision 1809785. The build still creates all those >>>>>>> jars, >>>> >>>> the Automatic-Module-Name header is added to commons-logging.jar >>>> MANIFEST.MF with value org.apache.commons.logging. >>>>>>> >>>>>>> Regards, >>>>>>> Benedikt >>>>>>> >>>>>>>> Stephen >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
