Re: Using Apache Commons IO
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" <dominik.stad...@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. <talli...@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:apa...@gagravarr.org] > > Sent: Tuesday, January 17, 2017 3:35 PM > > To: POI Developers List <dev@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-unsubscr...@poi.apache.org For additional > > commands, e-mail: dev-h...@poi.apache.org > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > >
Re: Using Apache Commons IO
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. <talli...@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:apa...@gagravarr.org] > Sent: Tuesday, January 17, 2017 3:35 PM > To: POI Developers List <dev@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-unsubscr...@poi.apache.org For additional > commands, e-mail: dev-h...@poi.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
RE: Using Apache Commons IO
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:apa...@gagravarr.org] Sent: Tuesday, January 17, 2017 3:35 PM To: POI Developers List <dev@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-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: Using Apache Commons IO
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-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
RE: Using Apache Commons IO
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:apa...@gagravarr.org] Sent: Tuesday, January 17, 2017 3:35 PM To: POI Developers List <dev@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-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
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-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org