Le 29/07/15 18:46, Emmanuel Blondel a écrit :
> Well, i found my issue, i was trying also set up the DateInfo as per
> anticipated for ISO 19115:2014... together with this information the
> /setDateStamp /had no effect.
Actually they work together, and the result depends on the order on
which the method are invoked. The golden rules is that all deprecated
methods in org.apache.sis.metadata.iso have been rewritten in term of
non-deprecated methods. This means that there is no "dateStamp" field in
the DefaultMetadata class. Instead, when the deprecated
DefaultMetadata.setDateStamp(...) method is invoked, that method
converts the given argument into the new objects then invoke the
non-deprecated DefaultMetadata.setDateInfo(...) method. This means that
all operations on the deprecated "dateStamp" property have an impact on
the non-deprecated "dateInfo" property, and conversely. The intend is to
allow transition: you can unmarshall a XML file containing the old
properties, then use the unmarshalled object through its new properties
(or conversely).
In the particular case of "dateStamp" versus "dateInfo", the
setDateStamp(...) implementation is as below:
* If a DateInfo having the type DateType.CREATION exists, replace the
date of that DateInfo instance by the given Date value.
* Otherwise adds a new DateInfo with the type DateType.CREATION and
the given date.
Similar rules apply to all deprecated methods. Generally:
* Setting the deprecated property will alter the non-deprecated
property, but only the part that correspond to the deprecated property.
* Setting the non-deprecated property will completely overwrite the
deprecated property.
So it is better to avoid deprecated methods completely. But if you
wished to use them anyway, I suggest to invoke deprecated setters after
non-deprecated ones.
Martin