You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Javen O'Neal <on...@apache.org> on 2017/01/17 20:23:25 UTC
Using Apache Commons IO
In the spirit of "the best code is no code", how would you feel about
replacing our endian classes and IOUtils with Apache Commons IO?
The downside is that it adds a dependency.
https://poi.apache.org/overview.html#components
https://commons.apache.org/proper/commons-io/javadocs/api-release/index.html?org/apache/commons/io/package-summary.html
Re: Using Apache Commons IO
Posted by Andreas Beeker <ki...@apache.org>.
I always wonder why a lot of these oldies stick with POI 3.9 and based on your explanation there wouldn't be much reason not to use 3.10 as there weren't much breaking changes ... if any.
So it must be something else ... I start to believe - especially when dealing with a few stackoverflow issues lately - it's a delusions of adequacy and because 3.9 is lexically bigger than 3.1x,
e.g. if you look at search.maven.org, they pick 3.9 ...
... enough ranting ... I'm ok with semantic versioning, but I welcome even more the constant changes introduced with the 2-release-rule.
There are so many places where we use some shorts/integers instead of enums or the ooxml and biff apis differ even for *SSF.
So I prefer a clean(er) API vs. a backward-compatible and maybe ambiguous one.
But how would you deal with versioning in the different modules?
I guess, the answer will be, to have the same version for all modules - if there's a breaking change in one of the modules, we would raise the major version,
but this wouldn't reflect the unchanged API in the other modules.
And if we would do per-module versioning, things get even more confusing.
If this assumption is correct, I think this hasn't much effect on user to use the correct dependencies.
Either they use maven/gradle and get the dependencies on the fly or they copy the jars once into the project and don't care anymore about them.
So coming back to the original topic, I'm ok with adding commons io to the project.
I only had a quick look into commons io, but LittleEndian could be replaced via EndianUtils and the streams with SwappedDataInputStream.
There are a few other stream classes which we've copy and pasted like BoundedInputStream.
Andi.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
RE: Using Apache Commons IO
Posted by "Murphy, Mark" <mu...@metalexmfg.com>.
I believe that one of the reasons people get stuck on really old versions of POI is that inevitably there are breaking changes in nearly every release. So folks pick a version, and it remains the one they use. If we were to shift to a semantic versioning scheme where we only introduced breaking fixes for major releases, we would probably have a better upgrade record, and we could say something like "We only support the last two major releases. You are going to have to upgrade." As it is, we have had two releases in the last year that contained breaking fixes. It would take some discipline on our part to do that, and we could specify which API's were subject to the Semantic versioning rules. For example HSSF and XSSF, but not those API's that we deem are still subject to change (everything else). Once an API is ready to be called stable, it ould fall under the semantic versioning rules. I think this would help the user community, and even projects with dependencies to POI.
-----Original Message-----
From: Nick Burch [mailto:apache@gagravarr.org]
Sent: Tuesday, January 17, 2017 3:35 PM
To: POI Developers List <de...@poi.apache.org>
Subject: Re: Using Apache Commons IO
On Tue, 17 Jan 2017, Javen O'Neal wrote:
> In the spirit of "the best code is no code", how would you feel about
> replacing our endian classes and IOUtils with Apache Commons IO?
>
> The downside is that it adds a dependency.
> https://poi.apache.org/overview.html#components
How many classes do we need? Do those classes include all the methods we need, or are there gaps?
(Having dealt with yet another StackOverflow question today from someone stuck on a really old POI version, and knowing that the ones who make it to StackOverflow are actually the better ones, I'd rather inline a few classes / do nothing instead of adding a dependency that people can get
wrong....)
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org For additional commands, e-mail: dev-help@poi.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Using Apache Commons IO
Posted by Javen O'Neal <on...@apache.org>.
If having dependencies is seen as a negative, we could use Gradle to shadow
our dependencies (we could start with Apache Commons IO, for which we
currently use very little, but makes our code better where used).
If we shadow import just the classes that we need, this would be a decent
compromise between jar/class load time and consumed perm gen space, and
reducing our maintained code base.
On Jan 18, 2017 11:12, "Dominik Stadler" <do...@gmx.at> wrote:
> Hi,
>
> I don't see the logic of "we should not add new dependencies because our
> user do not upgrade", the ones that do upgrade would probably easily manage
> as we already have a few of them. The ones that do not upgrade are not
> interested in new stuff anyway, but are not affected even if we do add new
> ones.
>
> And did people complain about breaking changes as long as we listed them
> properly via @Deprecated and in release notes? I mostly remember some
> discussions when we did not properly document them and thus caught people
> off guard.
>
> If you want to look at some facts about version-usage and upgrade-speed you
> can take a look at https://centic9.github.io/github-version-statistics/ it
> has both the current version-distribution and timeseries since around
> October last year. According to this, open-source projects on Github (only
> the ones using Gradle or Maven) use version 3.14 most often, with the
> following top 5 as of today:
>
> 3.14: 343
> 3.9: 276
> 3.13: 188
> 3.15: 167
> 3.12: 166
>
> Please note that these are not full numbers, but only the first ~2000
> entries found as Github has a 1000-result-limit when searching for the two
> buildsystems.
> Back in October the numbers were 3.14: 353, 3.9: 310, 3.13: 209, so older
> versions do slowly fade out and newer ones actually get used by a fair
> share of the projects after some time.
>
> So 3.9 really is still very popular for some reason despite
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.
> apache.poi%22%20AND%20a%3A%22poi%22
> and http://mvnrepository.com/artifact/org.apache.poi/poi sorting the
> versions properly!
>
> Dominik.
>
> On Wed, Jan 18, 2017 at 3:45 AM, Allison, Timothy B. <ta...@mitre.org>
> wrote:
>
> > Y, I agree with Nick. I'm slightly inclined to not using Commons IO to
> > avoid potential conflicts, but I defer to the more active devs :).
> >
> > We can't do the equivalent of a maven-shade-plugin in Ant, can we? Looks
> > like maybe in gradle...but...
> >
> >
> > -----Original Message-----
> > From: Nick Burch [mailto:apache@gagravarr.org]
> > Sent: Tuesday, January 17, 2017 3:35 PM
> > To: POI Developers List <de...@poi.apache.org>
> > Subject: Re: Using Apache Commons IO
> >
> > On Tue, 17 Jan 2017, Javen O'Neal wrote:
> > > In the spirit of "the best code is no code", how would you feel about
> > > replacing our endian classes and IOUtils with Apache Commons IO?
> > >
> > > The downside is that it adds a dependency.
> > > https://poi.apache.org/overview.html#components
> >
> > How many classes do we need? Do those classes include all the methods we
> > need, or are there gaps?
> >
> > (Having dealt with yet another StackOverflow question today from someone
> > stuck on a really old POI version, and knowing that the ones who make it
> to
> > StackOverflow are actually the better ones, I'd rather inline a few
> classes
> > / do nothing instead of adding a dependency that people can get
> > wrong....)
> >
> > Nick
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org For additional
> > commands, e-mail: dev-help@poi.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> > For additional commands, e-mail: dev-help@poi.apache.org
> >
> >
>
Re: Using Apache Commons IO
Posted by Dominik Stadler <do...@gmx.at>.
Hi,
I don't see the logic of "we should not add new dependencies because our
user do not upgrade", the ones that do upgrade would probably easily manage
as we already have a few of them. The ones that do not upgrade are not
interested in new stuff anyway, but are not affected even if we do add new
ones.
And did people complain about breaking changes as long as we listed them
properly via @Deprecated and in release notes? I mostly remember some
discussions when we did not properly document them and thus caught people
off guard.
If you want to look at some facts about version-usage and upgrade-speed you
can take a look at https://centic9.github.io/github-version-statistics/ it
has both the current version-distribution and timeseries since around
October last year. According to this, open-source projects on Github (only
the ones using Gradle or Maven) use version 3.14 most often, with the
following top 5 as of today:
3.14: 343
3.9: 276
3.13: 188
3.15: 167
3.12: 166
Please note that these are not full numbers, but only the first ~2000
entries found as Github has a 1000-result-limit when searching for the two
buildsystems.
Back in October the numbers were 3.14: 353, 3.9: 310, 3.13: 209, so older
versions do slowly fade out and newer ones actually get used by a fair
share of the projects after some time.
So 3.9 really is still very popular for some reason despite
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.poi%22%20AND%20a%3A%22poi%22
and http://mvnrepository.com/artifact/org.apache.poi/poi sorting the
versions properly!
Dominik.
On Wed, Jan 18, 2017 at 3:45 AM, Allison, Timothy B. <ta...@mitre.org>
wrote:
> Y, I agree with Nick. I'm slightly inclined to not using Commons IO to
> avoid potential conflicts, but I defer to the more active devs :).
>
> We can't do the equivalent of a maven-shade-plugin in Ant, can we? Looks
> like maybe in gradle...but...
>
>
> -----Original Message-----
> From: Nick Burch [mailto:apache@gagravarr.org]
> Sent: Tuesday, January 17, 2017 3:35 PM
> To: POI Developers List <de...@poi.apache.org>
> Subject: Re: Using Apache Commons IO
>
> On Tue, 17 Jan 2017, Javen O'Neal wrote:
> > In the spirit of "the best code is no code", how would you feel about
> > replacing our endian classes and IOUtils with Apache Commons IO?
> >
> > The downside is that it adds a dependency.
> > https://poi.apache.org/overview.html#components
>
> How many classes do we need? Do those classes include all the methods we
> need, or are there gaps?
>
> (Having dealt with yet another StackOverflow question today from someone
> stuck on a really old POI version, and knowing that the ones who make it to
> StackOverflow are actually the better ones, I'd rather inline a few classes
> / do nothing instead of adding a dependency that people can get
> wrong....)
>
> Nick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org For additional
> commands, e-mail: dev-help@poi.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>
RE: Using Apache Commons IO
Posted by "Allison, Timothy B." <ta...@mitre.org>.
Y, I agree with Nick. I'm slightly inclined to not using Commons IO to avoid potential conflicts, but I defer to the more active devs :).
We can't do the equivalent of a maven-shade-plugin in Ant, can we? Looks like maybe in gradle...but...
-----Original Message-----
From: Nick Burch [mailto:apache@gagravarr.org]
Sent: Tuesday, January 17, 2017 3:35 PM
To: POI Developers List <de...@poi.apache.org>
Subject: Re: Using Apache Commons IO
On Tue, 17 Jan 2017, Javen O'Neal wrote:
> In the spirit of "the best code is no code", how would you feel about
> replacing our endian classes and IOUtils with Apache Commons IO?
>
> The downside is that it adds a dependency.
> https://poi.apache.org/overview.html#components
How many classes do we need? Do those classes include all the methods we need, or are there gaps?
(Having dealt with yet another StackOverflow question today from someone stuck on a really old POI version, and knowing that the ones who make it to StackOverflow are actually the better ones, I'd rather inline a few classes / do nothing instead of adding a dependency that people can get
wrong....)
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org For additional commands, e-mail: dev-help@poi.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Using Apache Commons IO
Posted by Nick Burch <ap...@gagravarr.org>.
On Tue, 17 Jan 2017, Javen O'Neal wrote:
> In the spirit of "the best code is no code", how would you feel about
> replacing our endian classes and IOUtils with Apache Commons IO?
>
> The downside is that it adds a dependency.
> https://poi.apache.org/overview.html#components
How many classes do we need? Do those classes include all the methods we
need, or are there gaps?
(Having dealt with yet another StackOverflow question today from someone
stuck on a really old POI version, and knowing that the ones who make it
to StackOverflow are actually the better ones, I'd rather inline a few
classes / do nothing instead of adding a dependency that people can get
wrong....)
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org