The issue stated that it was resolved as duplicate and the duplicate
issue is still open (RT-30986), nobody stated the issue is fixed.
Unfortunatelly there was confusion and there are in fact two issues
(with very similar manifestation). One is missing importClass from
Nashorn, which we will need
but using values from
> 'fxml.version' and 'javafx.version'.
> It may also use those variables to improve error report or version
> management (to be defined).
>
> Cheers.
>
> Eric
>
>
>
> > From: Milan Kubec <mai
Details about versioning and proposed namespaces are described in issue:
https://javafx-jira.kenai.com/browse/RT-28599
Thanks for comments
Milan
Dne 7.6.2013 10:49, Milan Kubec napsal(a):
> Hello,
> I have implemented simple versioning for FXML documents in FXMLLoader, but
> without
he other issue though is changes to the classes that the FXML references.
> For example when Builders go, suddenly a whole lot of FXML files will
> suddenly become invalid.
>
> Are there any plans for version management at this level, and if not
> could/should there be?
broken bits then the loader failing
> at this point is highly undesirable.
>
>
> On Fri, Jun 7, 2013 at 6:49 PM, Milan Kubec <mailto:milan.ku...@oracle.com>> wrote:
>
> Hello,
> I have implemented simple versioning for FXML documents in
> FXMLLoader, but
Hello,
I have implemented simple versioning for FXML documents in FXMLLoader, but
without support in tools it won't be very useful. I have agreed with NetBeans
and Scene Builder folks that they will include support for versioning too.
Support means that they will produce document with two XML na
