> On Mon, 2015-11-23 at 10:51 +0100, Michael Osipov wrote: > > > On Sun, 2015-11-22 at 20:42 +0100, Michael Osipov wrote: > > > > Am 2015-11-22 um 20:11 schrieb Oleg Kalnichevski: > > > > > On Sat, 2015-11-21 at 19:48 +0100, Michael Osipov wrote: > > > > >> Am 2015-11-21 um 18:01 schrieb Oleg Kalnichevski: > > > > >>> Folks > > > > >>> > > > > >>> I moved code to org.apache.hc.core5 namespace as the first step. > > > > >>> > > > > >>> Now I would like to move things around in order to make the package > > > > >>> structure more consistent, reduce circular dependencies between > > > > >>> packages > > > > >>> and prepare for messaging code separation into HTTP/1.1 and HTTP/2 > > > > >>> compliant implementations. > > > > >>> > > > > >>> However, more importantly I would like to fold httpcore-nio into > > > > >>> httpcore. Separation into two modules made sense in 2005 but hardly > > > > >>> makes any sense today in 2015. > > > > >>> > > > > >>> Please let me know if you have any objections to that. > > > > >> > > > > >> I am quite happy with that. The rename is the very first step to get > > > > >> the > > > > >> module in shape. > > > > >> > > > > >> We should immediately drop deprecated stuff and stuff which is > > > > >> already > > > > >> in Java 7 by default. Moreover stuff which is in other Commons > > > > >> projects > > > > >> which we could either verbatim copy into util or simply depend on it, > > > > >> e.g., Commons Lang StringUtils/Validate. > > > > >> > > > > >> Have you thought about adapting group ids and artifact ids as well? > > > > >> Currently, they seem counter-intuitive to me. Not the way I would > > > > >> expect > > > > >> proper artifact id names. At least not sturctured the way I am used > > > > >> from > > > > >> maven.a.o. > > > > >> > > > > >> Additionally, the parent POM has a stupid artifact id, as well as > > > > >> configurations which are by now obsolete or already set by default > > > > >> by now. > > > > >> I'd like to work on the parent POM to take it to a new level which > > > > >> would > > > > >> introduce a new artifact id. It could co-exist with 4.x until it goes > > > > >> out of life. > > > > >> > > > > > > > > > > Are you referring to this one? > > > > > > > > > > http://svn.apache.org/repos/asf/httpcomponents/project/trunk/pom.xml > > > > > > > > > > If so, by all of means do feel free to improve it. > > > > > > > > Yes, that one. I would prefer to create a new one under > > > > http://svn.apache.org/repos/asf/httpcomponents/pom/trunk/pom.xml to > > > > avoid disruptive changes with a new artifact id. The POM is so old that > > > > is hasn't been improved structurally for years. There have been so many > > > > changes to Apache Parent and Maven Parent from which we can benefit > > > > from. > > > > > > > > If you are fine with that, I will copy and start my work next week. > > > > > > > > > > Feel free to completely wipe out the existing pom.xml and start from > > > scratch. Do we really need a new project location though? > > > > That is a deliberate choice. Given tha the user base is big, I don't want > > anyone > > to open up the "old" URL and see a competely different POM with a different > > artifact > > id. My primary goal is stability and predictability. Otherwise I would wipe > > 8-SNAPSHOT > > and begin it anew. > > > > Who would that be? Archaeologists?
I can't tell, that is why I am cautious. > There are tags for previous releases for anyone still interested. See no > reason of what so ever to keep the old branch. If that is OK for you. I do not mind to re-start inline. What do others say? Michael --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
