commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [IMAGING] Update from Java 5 to 7.
Date Thu, 21 Jul 2016 06:39:35 GMT
Hallo Amedee,

Amedee Van Gasse <amedee.vangasse@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.vangasse@itextpdf.com
> http://itextpdf.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message