Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Jon Moore]

On Sat, Nov 21, 2015 at 1:56 PM, Michael Osipov  wrote:

> Am 2015-11-21 um 19:52 schrieb Gary Gregory:
>
>> +1.
>>
>> I would not mind using Java 8 too.
>>
>
> Believe that is too early. We are using a company-wide, Eclipse RCP-based
> product which is on Eclipse 3.4/3.6 and still HttpClient 3.x. I highly
> doubt that the dev team will jump on e4 and Java 8 features.
> Java 7 is a good base line.


Java 7 is already end-of-life, as of April 2015. Given that part of the
idea of starting version 5.0 is to be able to remove deprecated items and
general cleanup, it would seem prudent to me to at least *start* HC 5.0
with a non-EOL Java version. In addition, the Streams API that were added
to in java.util.streams might be very useful especially in an HTTP/2.0
implementation, although that might be a separate discussion.

I will also note that you should weigh my opinion against the fact that I
haven't had a lot of time for contributing recently...

Jon

Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Gary Gregory]

On Sun, Nov 22, 2015 at 3:10 PM, Jon Moore  wrote:

> On Sat, Nov 21, 2015 at 1:56 PM, Michael Osipov 
> wrote:
>
> > Am 2015-11-21 um 19:52 schrieb Gary Gregory:
> >
> >> +1.
> >>
> >> I would not mind using Java 8 too.
> >>
> >
> > Believe that is too early. We are using a company-wide, Eclipse RCP-based
> > product which is on Eclipse 3.4/3.6 and still HttpClient 3.x. I highly
> > doubt that the dev team will jump on e4 and Java 8 features.
> > Java 7 is a good base line.
>

By the time, HC5 comes out, Java 9 might be out ;-)

I think it is time to move to Java 8, which might also attract fresh blood
to the project.

My 2c,
Gary


>
>
> Java 7 is already end-of-life, as of April 2015. Given that part of the
> idea of starting version 5.0 is to be able to remove deprecated items and
> general cleanup, it would seem prudent to me to at least *start* HC 5.0
> with a non-EOL Java version. In addition, the Streams API that were added
> to in java.util.streams might be very useful especially in an HTTP/2.0
> implementation, although that might be a separate discussion.
>
> I will also note that you should weigh my opinion against the fact that I
> haven't had a lot of time for contributing recently...
>
> Jon
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

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.

Michael

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

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

Cheers

Oleg



-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org