Revision meta data #137
Revision meta data #137
Conversation
There was a problem hiding this comment.
@vapadwal Thanks for taking over this PR and improving 👍
This is now nice rearding the API. Can you generate the JavaDoc and check if it is sane? AFAIK JavaDoc taglets are case sensitive and @deprecated in JavaDoc has to be lower-case.
However, it is still not working as planned yet.
See the APIs and implementation here:
- https://github.com/devonfw/devon4j/blob/develop/modules/jpa-envers/src/main/java/com/devonfw/module/jpa/dataaccess/base/AbstractGenericRevisionedDao.java#L13
- https://github.com/devonfw/devon4j/blob/develop/modules/jpa-envers/src/main/java/com/devonfw/module/jpa/dataaccess/api/GenericRevisionedDao.java#L45
- https://github.com/devonfw/devon4j/blob/develop/modules/jpa-spring-data/src/main/java/com/devonfw/module/jpa/dataaccess/api/data/GenericRevisionedRepository.java#L6
- https://github.com/devonfw/devon4j/blob/develop/modules/jpa-spring-data/src/main/java/com/devonfw/module/jpa/dataaccess/impl/data/GenericRevisionedRepositoryImpl.java#L20
It is still producing the old depreated code which is unrealted to the new one. Therefore the new API can not yet be used.
My proposal would be:
Let the old and deprecated code extend the new API such that the old deprected interface and class are more or less empty and just inherit from the new API types.
For compatibility we could go these steps:
- keep the DAO/Repositories untouched for the moment (using deprecated code).
- push out a release like this
- let projects update to that release
- now projects can update their code such that they use the new API and remove references to the deprecated classes from their code.
- For the next devon4j release we then remove the deprecated classes and only use the new APIs.
- Projects that did step 4. are now safe to upgrade to 5.
An alternative would be to simplify and go this way:
- we give up compatibility and remove the old code (instead of deprecating it)
- we directly refactor DAO/Repository to the new API
- we provide support in devon-ide for updating projects in our migrator
I would vote that we have migration support for our projects regarding this change anyhow. So maybe the latter approach would be much simpler. I am not entirely sure how our projects deal with breaking changes and if they are all aware of devon-ide and its migration feature.
I was able to generated javadoc with it. |
There was a problem hiding this comment.
You should use Eclipse refactoring features. Otherwise you should search References on Workspace on the old code in order to manually refactor the code to ensure a working result.
Here are my hits (but do not use me as "refactoring service" - I am just working in the browser on github what does not mean I am not missing places, this is just what I was missing in the diffs and why I notice it can not work this way. It would be awesome if we had JUnits for all these features.):
| * @return die Instanz von {@link RevisionMetadataType} bzw. {@code null} falls {@code revision} den Wert {@code null} | ||
| * hat. | ||
| */ | ||
| public static RevisionMetadataType of(AdvancedRevisionEntity revEntity) { |
There was a problem hiding this comment.
The static of method is typically used as a factory method of the same class defining the static method (as a short form for valueOf what is used inside the JDK as convention/pattern).
In this case JpaHelper.of(entity) the API is IMHO very confusing. You need to move the method to RevisionMetadataType. In case it should remain in JpaHelper you should rename this of method to asRevisionMetadata (like e.g. asEntity).
|
Just to be aligned. I understand the latest state of this PR such that:
|
Fix for Issue : - #47 .
This is new PR created against PR #134