Closed starksm64 closed 2 years ago
Concurrency needs to be updated from 3.0.0 to 3.0.1.
Validation version needs to be updated from 3.0.1 to 3.0.2 as well.
I created a PR as mentioned in the Platform Call to fix the (yet available) API versions: https://github.com/eclipse-ee4j/jakartaee-api/pull/132
But there are still findings, like the definition of CP specific versions, that are not used - I would suggest, that they should be part of the comment saying that they may deviate (but in fact did not). Some definitions are missing or are reused:
I would suggest to add the CP specific versions to the comment and reoder the CP related definitons from WP to CP. I also could reorder the version definitions and dependencies according to the "waves" or dependency levels (lowest first) - but a build with the last changes would help doing that, because it cleans up a lot of duplicate dependencies in the graphs.
While waiting for the last fixes in the Web Profile implementations at the moment, we could thing about fixing the dependency definitions in at least Interceptor API (-> 2.1.1) and CDI API (-> 4.0.2 and Model Lang API?), to have a clean Core Profile right from the beginning.
The last (potential) finding is the transitive dependency from the optional XML Bind in CP to Activation - should we reference the (optional) dependency directly here too?
@starksm64 can you review and merge the PR and trigger a build of it afterwards, please? When you ping me, I can create updated dependency analysis and we can have a look on the results to discuss the remaining topics above. Meanwhile, I also pushed my changes to the depenency analysis demo project and Dirk merged them already - so you can run them by yourself easily, if you like.
Validation version needs to be updated from 3.0.1 or 3.0.2 as well.
This deviation came form Faces 4.0.1, which has a dependency to Validation API 3.0.2. But note, Validation TCKs last version is still 3.0.1, but this TCK version has a lot of outdated and creapy dependencies like Milestone and RC versions too:
@starksm64, @scottmarlow That means for me, (in this case) the component spec test environment deviates significantly from the umbrella spec environment (not only regarding it's service release version) and this may lead to different test results (!) - and so generates a high potential for late supprises in the Platform/Profile releases... Should we create a new Validation TCK (Service?) release here? How is it ensured, that the CI for the component spec will rerun the changed component spec TCK?
@starksm64 some of these aspects may be delegated to the (Platform) retrospective and might be addressed in a Jakarta Next release - they are a little bit resulting from a discussion in the last TCK call too... ;-)
Another (minor) aspect, that should be solved is the occurence of test(-framework) dependencies inside API artifacts at all and their version deviations.
Do we want to address them too? With the current or the next release? My suggestion would be to at least address the version deviations as much as possible as soon as possible. Some of the occurences could be easily removed from the API when they are resulting from a (maven) multiple module project setup with dependency definitions in the parent but actual use only in the TCK submodule (i.e. I fixed that in Concurrent 3.0.1).
@JanWesterkamp-iJUG The API jar build was updated last night
@starksm64 many thanks, I updated and commented the analysis here: https://github.com/eclipse-ee4j/jakartaee-api/issues/125#issuecomment-1210611757
The web profile and platform api artifacts may be missing the latest service releases. We need to update these before going to final ballot.