Hallo Amedee, Amedee Van Gasse <amedee.vanga...@itextpdf.com> schrieb am Mi., 20. Juli 2016 um 16:24 Uhr:
> 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. > now that we have BCEL 6.0 out of the door, I plan to start working on Imaging again. The main problem of the current API is that it exposes internal state (e.g. byte arrays) to the outside. I currently don't know how to fix this. > > However, if the answer really is no, we will explore the other options. > I'm not really happy with what your saying here. You're basically saying: please invest your (spare time) to maintain Java 5 code, so we can ship our product to our customers. This simply isn't how open source works. Open source is you get something, and you give something back. You could have joined the development years ago and help push it in a direction that fits everybody's need - Java 5 and a stable API. But you decided to rely on a unreleased SNAPSHOT and now you're "threaten" us that you'll fork the project. So if this really is how you'd like to handle this situation, then the answer is: no, I will definitely not maintain Java 5 code for you. I'm open for discussion how we can get to a 1.0 release that is 5.0 compatible *together* or how we can backport some of the fixes and features to sanselan and release it as 0.98. Regards, Benedikt > > 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 > >
