Perhaps then it could be a parallel package to start, marked @Beta,
independent of the two existing packages, aside from reusing things like
enums perhaps.  Projects could then explore it and use it as a common
alternative.  Once it is deemed stable enough to leave beat status we could
then mark the existing packages @Deprecated and start planning for
removal.  Sounds like that could be a POI 4 type of move?

If we have it alongside the existing ones to start it may be easier to
gather feedback on the design and find ways to ease consumer code migration
before freezing the API.

I'll point you to the vaadin code on GitHub in my AM, too much work on my
phone in bed.  That's when everyone catches up on tech mailing lists, right?

On Sat, Aug 12, 2017, 22:21 Alain FAGOT BÉAREZ <abea...@for-scala.it> wrote:

> Hi,
>
> @pjfanning: In the current state, delegating to the XDDF from the legacy
> SS and XSSF implementation would not be feasible. Some constants were
> defined in Enum types and I don’t know how to “redirect” an Enum value to
> the new implementation of it.
>
> @Greg: I don’t know how deep your code goes throughout the CT* side. For
> the user model, I tried to put as much as possible of the common code in
> the abstract XDDFChartData, XDDFChartData.Series and XDDFChartAxis, with
> concrete implementations in the subclasses. If you could point me to some
> repository where I could take a look at your current uses of chart related
> CT* internals, I could focus on preparing a user model API for these uses.
>
> @Andi: I did not put any @Removal on the @Deprecated elements. Maybe all
> the classes in the XDDF package should be marked as @Beta as well.
>
> Best regards,
> Alain
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Reply via email to