Hi Petr,
> On 13 Nov 2014, at 03:57, Petr Slabý <sl...@kadel.cz> wrote:
>
> Hi,
>
> as so many other users, I would appreciate a pdfbox version 2.0 release as
> soon as possible. Or at least a plan for it.
When this question was asked on the mailing list about a month ago, I gave the
following list of features for 2.0:
Improvements and fixes which still need breaking API changes include:
- Pattern rendering [In Progress]
- Pages resource caching [In Progress]
- Font embedding [Todo]
- Parsing [In Progress]
- Page Tree [In Progress]
- Text extraction on Java 8 [Done?]
We’re now making good progress on all of these.
> In our project, we suffer from the same problems as described by Simon. In
> our release plan, we had the move to pdfbox 2.0 planned for this year. But
> the APIs are changing too often and too much so far. Also, I need to review
> the redesigned font handling to see whether it can be used in our J2EE
> environment where configurations change at runtime - anything statically
> accessed and statically cached is evil for us. I had to abandon the work on
> this until there is at least a half way guarantee that the APIs will not be
> completely different the next day.
We’ve always resisted agreeing to any sort of release date for 2.0, because the
code is developed by volunteers in their spare time, whose priorities are their
day jobs. There’s just no way for us to keep any kind of schedule when the time
we get to spend of PDFBox is controlled by external factors.
Having said that, in the past the list of features for 2.0 was open-ended, but
we’ve now got that under control, we’re now using the blocker and critical
priorities in JIRA to keep track of the issues one which the release of 2.0
truly depends, see:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20PDFBOX%20AND%20priority%20in%20(Blocker%2C%20Critical)%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.0.0%20ORDER%20BY%20priority%20DESC
> So, as many users before, I have to ask, too - could you make up a release
> plan for 2.0? Or at least a milestone plan for the final version of APIs and
> publicly accessible classes? Such a milestone would be good to be able to
> discuss breaking API changes before the final release. It would give me a
> chance to complain soon enough about APIs I was using and which are gone the
> other day.
The list above and the issues on JIRA essentially constitute our release plan,
in terns of features. Classes not related to those aspects of the code are
unlikely to change, but the scope for changes is still sizeable as there’s some
fairly core functionality (e.g resource caching) being worked on. Ultimately,
the APIs won’t be stable until the code is stable, and that won’t happen until
the work on those big blocker issues is complete.
Thanks
— John
