You will also need to trace through the code to find the methods and
properties referenced indirectly, via reflection, unfortunately. To avoid
code duplication, Vaadin chose to access some properties of chart types via
reflection where the properties are common to all charts, but not defined
in a
Hi,
@Greg: It was Brazilian Father’s Day today, so that I did not pick up tech
lists from bed… but only after my daughter was sleeping.
I cloned and searched through the following code base:
https://github.com/WoozyG/spreadsheet/tree/ConditionalFormatting
There I found no single reference to an
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 th
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
Vaadin7 requires Java 7, Vaadin 8 requires Java 8, so they are OK there.
POI 3.17 already has breaking changes, so they have to put off
incorporating my work until a larger release anyway, due to possible
customer dependencies. Their next release will at least be using 3.16, so
users like me can d
> I would prefer this wait until 3.18, for purely selfish reasons, as we've
> already released a beta for 3.17.
The postponing is ok for me ... but afterwards you have the breaking changes
anyways
and the Vaadin guys (or you?) have to do the chart modifications twice ... or
Vaadin
might be stuck
quot;pj.fanning" wrote:
>
> > Would it be feasible to keep the existing classes and APIs and have them
> > delegate to the XDDF impl?
> > We could immediately deprecate any of these legacy APIs.
> >
> >
> >
> > --
> > View this message in
View this message in context: http://apache-poi.1045710.n5.
> nabble.com/XDDF-implementation-shared-between-XSSFChart-and-XSLFChart-
> tp5728473p5728476.html
> Sent from the POI - Dev mailing list archive at Nabble.com.
>
> ---
Would it be feasible to keep the existing classes and APIs and have them
delegate to the XDDF impl?
We could immediately deprecate any of these legacy APIs.
--
View this message in context:
http://apache-poi.1045710.n5.nabble.com/XDDF-implementation-shared-between-XSSFChart-and-XSLFChart
7 final/4.0 - so I
> think, we'll get that one in before.
>
> Best wishes,
> Andi
>
>
>
> --
> View this message in context:
> http://apache-poi.1045710.n5.nabble.com/XDDF-implementation-shared-between-XSSFChart-and-XS
this message in context:
http://apache-poi.1045710.n5.nabble.com/XDDF-implementation-shared-between-XSSFChart-and-XSLFChart-tp5728473p5728474.html
Sent from the POI - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mai
Dear all,
Since June, this is the third pull request I open about the same theme.
After the first review, mentioning a conversation I had missed
(https://lists.apache.org/thread.html/ff5470bc413d298188f8c5d3d250ee15d36bd655227696869ed21aab@%3Cdev.poi.apache.org%3E),
I reworked my initial submis
12 matches
Mail list logo
