Indicates a
MetadataProvider that supports ITDs.
ITD usage in ROO adopts some conventions to facilitate ease of use.
The first requirement is that metadata identification is by way of the
PhysicalTypeIdentifierNamingUtils if the type that will receive any
potential introduction. It is important to recognize that implementations may
not actually introduce members via a traditional ITD but instead may place
the methods directly in the physical type. This is a supported usage pattern
and is highly compatible with using the aforementioned metadata
identification approach.
The second requirement is that if an implementation wishes to create an ITD
it does so strictly in accordance with the following compilation unit file
placement and naming convention. The convention is that all ITD compilation
units must be placed in the same source directory as the
PhysicalTypeIdentifierNamingUtils used for metadata identification.
Secondly, the ITD compilation unit must adopt an identical filename as that
used by the
PhysicalTypeIdentifierNamingUtils, except that the
extension must be ".aj" and there must be a suffix immediately following the
file name (but prior to the extension). The suffix is composed of "_Roo_"
plus an implementation-specific string, as returned by
#getItdUniquenessFilenameSuffix(). For example, consider a
PhysicalTypeIdentifierNamingUtils for com/foo/Bar.java within
Path#SRC_MAIN_JAVA and a result of
#getItdUniquenessFilenameSuffix() being "Jpa". This would indicate an
ITD filename within
Path#SRC_MAIN_JAVA of "com/foo/Bar_Roo_Jpa.aj".
The third requirement is that implementations can assume
ItdFileDeletionService will automatically eliminate any unnecessary
ITDs that no longer have a
PhysicalTypeIdentifierNamingUtils that
could potentially receive them. Conversely, if a
PhysicalTypeIdentifierNamingUtils does exist, it is required that the
implementation will delete any unnecessary ITDs if the ITD should no longer
exist and also monitor that ITD for changes.
A recommendation is that implementations listen to
PhysicalTypeMetadataProvider so as to be notified of any new
PhysicalTypeMetadata that becomes available. Implementations should
consider whether the
PhysicalTypeMetadata represents an instance that
should have ITD-specific metadata created. If so, the implementation should
create a metadata instance and cause that instance to monitor the
PhysicalTypeMetadata directly. The
ItdMetadataProvider should
instantiate an ITD metadata instance with both the
PhysicalTypeMetadata it is monitoring, plus
org.springframework.roo.file.monitor.polling.PollingFileMonitorServicefor the .aj it should monitor (even if the .aj does not yet exist, because
the metadata will create it).