On Wed, Jul 20, 2016 at 7:24 AM, Amedee Van Gasse < amedee.vanga...@itextpdf.com> wrote:
> Hello Apache Commons devs, > > I work for iText Software. In our product iText, more specifically in the > module Xtra, we have a dependency on commons-imaging: > > https://github.com/itext/itextpdf/blob/develop/xtra/pom.xml > > <dependency> > <groupId>org.apache.commons</groupId> > <artifactId>commons-imaging</artifactId> > <version>1.0-SNAPSHOT</version> > </dependency> > > It's used only in this class: > > https://github.com/itext/itextpdf/blob/develop/xtra/src/main/java/com/itextpdf/text/pdf/pdfcleanup/PdfCleanUpRenderListener.java > > iText 5.x.x is targeted at Java 5, because that covers most of our > existing customer base. We also have an iText 7.x.x, targeted at Java 7, > but it's API is incompatible with iText 5. iText 5 won't be EOL until at > least 1.5 years from now. > > I am fully aware of the risks of having a dependency on a SNAPSHOT. There > are historical reasons why this was done anyway. That being said, our > customers who are still on Java 5 and who use our Xtra module, could run > into problems. > > We have a couple of options: > 1. Tell our affected customers to move to Java 7 > 2. Swich the dependency from commons-imaging to sanselan, and loose some > features > 3. Remove the functionality that depends on commons-imaging alltogether > 4. Depend on a 'release' of commons-imaging that is on Java 5. > > Regarding option 4, is there anything that Apache Commons can do? We would > really like to avoid forking commons-imaging and having to maintain it > ourselves. > > However, if the answer really is no, we will explore the other options. > We have not had too much luck getting 1.0 out the door. The component needs a review and whatever clean ups and completions an SME could provide on top of all the dotting of the i's and crossing of the t's a 1.0 requires. Just look at how much work has gotten into getting Commons Crypto close to its 1.0 release; and that was with a code based that was working well already. We have a lot of components in Commons compared to the amount of volunteers here. The 1.0 release will be based on Java 7 unless someone decides to do a branch, prepare a release, and so on. Since we have not managed to even get 1.0 out the door yet, I would say that the odds of someone here creating a branch and making the code Java 5 compatible is close to nil IMO. Making the code Java 5 compatible sounds like a pretty thankless task and I cannot imagine someone volunteering to do it. Gary > > Kind regards, > > -- > Amedee Van Gasse > QA Engineer | iText Software BVBA > amedee.vanga...@itextpdf.com > http://itextpdf.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
