You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Amedee Van Gasse <am...@itextpdf.com> on 2016/07/20 14:24:14 UTC
Re: [IMAGING] Update from Java 5 to 7.
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.
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
Re: [IMAGING] Update from Java 5 to 7.
Posted by Emmanuel Bourg <eb...@apache.org>.
Hi Amedee,
Le 20/07/2016 � 16:24, Amedee Van Gasse a �crit :
> We have a couple of options:
> 1. Tell our affected customers to move to Java 7
This is probably the best solution. Do you have that many customers
still using Java 5 in 2016? Oracle stopped it's extended support one
year ago (the public updates stopped 7 years ago).
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Update from Java 5 to 7.
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Jul 20, 2016 at 7:24 AM, Amedee Van Gasse <
amedee.vangasse@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.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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [IMAGING] issue tracker?
Posted by Benedikt Ritter <br...@apache.org>.
Hello Amedee,
Amedee Van Gasse <am...@itextpdf.com> schrieb am Do., 18. Aug.
2016 um 15:30 Uhr:
> Where can I find a single issue tracker with all issues that block a
> release of commons-imaging? And, if available, estimated time / story
> points / other metric for those blocking issues?
>
> Based on that input, we at iText Software can decide how we can work with
> Apache Commons to get to a release of Commons-imaging.
>
I'm happy to hear that iText Software is still considering joining the
development of Commons Imaging after we had kind of a tough start - sorry
for that.
The issue tracker is here [1]. We don't estimate issues. I don't think that
this would work for a community like Commons. What we do have are special
versions for Issues that need more discussion, issues that need a patch and
issues that have a patch the needs to be reviewed.
TBH I think we need to go through all issues reevaluate whether we want
them in 1.0 or not and then set the version according to that.
From my PoV what is blocking the release is finalizing the public API. As a
library vendor, you probably know that it is important to come up with a
stable API for the first release. Currently we have a lot of FindBugs
errors indicating that Imaging is leaking internal representation of data
[2]. I think we have to discuss whether we can fix this by changing the API
or not. Since we're talking about the byte array representations of the
image date being processed, I don't see a way to fix this without
excessively copying data around in memory. This what certainly degrade
performance.
Another interesting aspect would be your feedback as a user. Does the API
work well from a user perspective or do we need to change stuff? Now is the
time to introduce those changes as it will be harder to evolve the API
after release 1.0.
Regards,
Benedikt
[1] https://issues.apache.org/jira/browse/IMAGING
[2] http://commons.apache.org/proper/commons-imaging/findbugs.html
>
> Best regards,
> Amedee Van Gasse
> QA Engineer
> iText Software
> ________________________________
> From: Benedikt Ritter <br...@apache.org>
> Sent: Wednesday, July 27, 2016 8:18:21 PM
> To: Commons Developers List
> Subject: Re: [IMAGING] Update from Java 5 to 7.
>
> Hello Amedee,
>
> Amedee Van Gasse <am...@itextpdf.com> schrieb am Di., 26. Juli
> 2016 um 18:00 Uhr:
>
> > Hello Benedikt,
> >
> > Op 21-07-16 om 08:39 schreef Benedikt Ritter:
> > > Hallo Amedee,
> >
> > *snip*
> >
> > >> 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,
> >
> > I'm afraid you misinterpreted my email.
> >
> > I asked a question, and I said beforehand that I would accept "no" as an
> > answer.
> >
> > > now you're "threaten" us that you'll fork the project.
> >
> > I'm afraid there is again a misinterpretation. Hey, I *know* how
> > sensitive the "fork" topic is in Open Source. Really. We've had our own
> > share of forks too, and they weren't as nice (because they intentionally
> > tried to circumvent an AGPL license).
> >
> > I gave 4 options that we are choosing from, and only those 4 options. I
> > will repeat them again:
> >
> > 1. Tell our affected customers to move to Java 7
> > 2. Switch 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.
> >
> > Below that, I mentioned something that was not numbered, forking. It
> > came up in an internal brainstorm in a meeting, and I personally gave
> > lots of arguments why we should really really REALLY avoid to fork. I
> > repeat: forking was briefly considered, and rejected.
> >
> > > 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.
> >
> > Emmanuel Bourg and Gary Gregory already answered the question. I read
> > between the lines of Gary Gregory's email that a contribution would be
> > welcomed. I would like to thank Emmanuel and Gary for their replies.
> > When there is a 1.0 release, and if at that time our Java 5 product
> > isn't EOL yet, then a contribution will most definitely be considered,
> > obviously. After all, we're an Open Source company ourselves, and we
> > know very well how Open Source works.
> >
>
> Thank you for this clarification. Sorry, if I came along harshly. We're
> looking forward to collaborating with you.
>
> Regards,
> Benedikt
>
>
> >
> >
> > --
> > 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
> >
> >
>
Re: [IMAGING] issue tracker?
Posted by Amedee Van Gasse <am...@itextpdf.com>.
Where can I find a single issue tracker with all issues that block a release of commons-imaging? And, if available, estimated time / story points / other metric for those blocking issues?
Based on that input, we at iText Software can decide how we can work with Apache Commons to get to a release of Commons-imaging.
Best regards,
Amedee Van Gasse
QA Engineer
iText Software
________________________________
From: Benedikt Ritter <br...@apache.org>
Sent: Wednesday, July 27, 2016 8:18:21 PM
To: Commons Developers List
Subject: Re: [IMAGING] Update from Java 5 to 7.
Hello Amedee,
Amedee Van Gasse <am...@itextpdf.com> schrieb am Di., 26. Juli
2016 um 18:00 Uhr:
> Hello Benedikt,
>
> Op 21-07-16 om 08:39 schreef Benedikt Ritter:
> > Hallo Amedee,
>
> *snip*
>
> >> 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,
>
> I'm afraid you misinterpreted my email.
>
> I asked a question, and I said beforehand that I would accept "no" as an
> answer.
>
> > now you're "threaten" us that you'll fork the project.
>
> I'm afraid there is again a misinterpretation. Hey, I *know* how
> sensitive the "fork" topic is in Open Source. Really. We've had our own
> share of forks too, and they weren't as nice (because they intentionally
> tried to circumvent an AGPL license).
>
> I gave 4 options that we are choosing from, and only those 4 options. I
> will repeat them again:
>
> 1. Tell our affected customers to move to Java 7
> 2. Switch 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.
>
> Below that, I mentioned something that was not numbered, forking. It
> came up in an internal brainstorm in a meeting, and I personally gave
> lots of arguments why we should really really REALLY avoid to fork. I
> repeat: forking was briefly considered, and rejected.
>
> > 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.
>
> Emmanuel Bourg and Gary Gregory already answered the question. I read
> between the lines of Gary Gregory's email that a contribution would be
> welcomed. I would like to thank Emmanuel and Gary for their replies.
> When there is a 1.0 release, and if at that time our Java 5 product
> isn't EOL yet, then a contribution will most definitely be considered,
> obviously. After all, we're an Open Source company ourselves, and we
> know very well how Open Source works.
>
Thank you for this clarification. Sorry, if I came along harshly. We're
looking forward to collaborating with you.
Regards,
Benedikt
>
>
> --
> 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
>
>
Re: [IMAGING] Update from Java 5 to 7.
Posted by Benedikt Ritter <br...@apache.org>.
Hello Amedee,
Amedee Van Gasse <am...@itextpdf.com> schrieb am Di., 26. Juli
2016 um 18:00 Uhr:
> Hello Benedikt,
>
> Op 21-07-16 om 08:39 schreef Benedikt Ritter:
> > Hallo Amedee,
>
> *snip*
>
> >> 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,
>
> I'm afraid you misinterpreted my email.
>
> I asked a question, and I said beforehand that I would accept "no" as an
> answer.
>
> > now you're "threaten" us that you'll fork the project.
>
> I'm afraid there is again a misinterpretation. Hey, I *know* how
> sensitive the "fork" topic is in Open Source. Really. We've had our own
> share of forks too, and they weren't as nice (because they intentionally
> tried to circumvent an AGPL license).
>
> I gave 4 options that we are choosing from, and only those 4 options. I
> will repeat them again:
>
> 1. Tell our affected customers to move to Java 7
> 2. Switch 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.
>
> Below that, I mentioned something that was not numbered, forking. It
> came up in an internal brainstorm in a meeting, and I personally gave
> lots of arguments why we should really really REALLY avoid to fork. I
> repeat: forking was briefly considered, and rejected.
>
> > 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.
>
> Emmanuel Bourg and Gary Gregory already answered the question. I read
> between the lines of Gary Gregory's email that a contribution would be
> welcomed. I would like to thank Emmanuel and Gary for their replies.
> When there is a 1.0 release, and if at that time our Java 5 product
> isn't EOL yet, then a contribution will most definitely be considered,
> obviously. After all, we're an Open Source company ourselves, and we
> know very well how Open Source works.
>
Thank you for this clarification. Sorry, if I came along harshly. We're
looking forward to collaborating with you.
Regards,
Benedikt
>
>
> --
> 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
>
>
Re: [IMAGING] Update from Java 5 to 7.
Posted by Amedee Van Gasse <am...@itextpdf.com>.
Hello Benedikt,
Op 21-07-16 om 08:39 schreef Benedikt Ritter:
> Hallo Amedee,
*snip*
>> 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,
I'm afraid you misinterpreted my email.
I asked a question, and I said beforehand that I would accept "no" as an
answer.
> now you're "threaten" us that you'll fork the project.
I'm afraid there is again a misinterpretation. Hey, I *know* how
sensitive the "fork" topic is in Open Source. Really. We've had our own
share of forks too, and they weren't as nice (because they intentionally
tried to circumvent an AGPL license).
I gave 4 options that we are choosing from, and only those 4 options. I
will repeat them again:
1. Tell our affected customers to move to Java 7
2. Switch 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.
Below that, I mentioned something that was not numbered, forking. It
came up in an internal brainstorm in a meeting, and I personally gave
lots of arguments why we should really really REALLY avoid to fork. I
repeat: forking was briefly considered, and rejected.
> 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.
Emmanuel Bourg and Gary Gregory already answered the question. I read
between the lines of Gary Gregory's email that a contribution would be
welcomed. I would like to thank Emmanuel and Gary for their replies.
When there is a 1.0 release, and if at that time our Java 5 product
isn't EOL yet, then a contribution will most definitely be considered,
obviously. After all, we're an Open Source company ourselves, and we
know very well how Open Source works.
--
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
Re: [IMAGING] Update from Java 5 to 7.
Posted by Benedikt Ritter <br...@apache.org>.
Hallo Amedee,
Amedee Van Gasse <am...@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
>
>