ITD usage in ROO adopts some conventions to facilitate ease of use.
The first requirement is that metadata identification is by way of the {@link PhysicalTypeIdentifierNamingUtils} if the type that will receive anypotential 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 {@link PhysicalTypeIdentifierNamingUtils} used for metadata identification.Secondly, the ITD compilation unit must adopt an identical filename as that used by the {@link 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 {@link #getItdUniquenessFilenameSuffix()}. For example, consider a {@link PhysicalTypeIdentifierNamingUtils} for com/foo/Bar.java within{@link Path#SRC_MAIN_JAVA} and a result of{@link #getItdUniquenessFilenameSuffix()} being "Jpa". This would indicate anITD filename within {@link Path#SRC_MAIN_JAVA} of "com/foo/Bar_Roo_Jpa.aj".
The third requirement is that implementations can assume {@link ItdFileDeletionService} will automatically eliminate any unnecessaryITDs that no longer have a {@link PhysicalTypeIdentifierNamingUtils} thatcould potentially receive them. Conversely, if a {@link PhysicalTypeIdentifierNamingUtils} does exist, it is required that theimplementation 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 {@link PhysicalTypeMetadataProvider} so as to be notified of any new{@link PhysicalTypeMetadata} that becomes available. Implementations shouldconsider whether the {@link PhysicalTypeMetadata} represents an instance thatshould have ITD-specific metadata created. If so, the implementation should create a metadata instance and cause that instance to monitor the {@link PhysicalTypeMetadata} directly. The {@link ItdMetadataProvider} shouldinstantiate an ITD metadata instance with both the {@link PhysicalTypeMetadata} it is monitoring, plus{@link org.springframework.roo.file.monitor.polling.PollingFileMonitorService}for the .aj it should monitor (even if the .aj does not yet exist, because the metadata will create it). @author Ben Alex @since 1.0
| |
| |