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