search

jakartaee / platform

The Jakarta EE Platform project produces the Jakarta EE platform specification, which is an umbrella specification that aggregates all other Jakarta EE specifications.
https://jakartaee.github.io/platform/
Eclipse Public License 2.0
197 stars 68 forks source link

Verify the web profile and full platform staged api artifacts before ballot #521

Closed starksm64 closed 2 years ago

starksm64 commented 2 years ago

The web profile and platform api artifacts may be missing the latest service releases. We need to update these before going to final ballot.

JanWesterkamp-iJUG commented 2 years ago

Concurrency needs to be updated from 3.0.0 to 3.0.1.

JanWesterkamp-iJUG commented 2 years ago

Validation version needs to be updated from 3.0.1 to 3.0.2 as well.

JanWesterkamp-iJUG commented 2 years ago

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.

JanWesterkamp-iJUG commented 2 years ago

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:

1.8 1.8 UTF-8 3.0.0 license.txt 7.0.0.Alpha5 6.14.3 3.7.0 3.0.0-M3 4.0.0-RC1 2.0.0-RC2 4.0.0-RC1 2.0.0-RC1 1.1.3.Final 1.7.0.Alpha2 2.0.0 1.0.1.Final 1.5.3 1.7.26 1.5.4.1 1.5.0-alpha.11 ${project.basedir} 8.29

@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... ;-)

JanWesterkamp-iJUG commented 2 years ago

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).

starksm64 commented 2 years ago

@JanWesterkamp-iJUG The API jar build was updated last night

JanWesterkamp-iJUG commented 2 years ago

@starksm64 many thanks, I updated and commented the analysis here: https://github.com/eclipse-ee4j/jakartaee-api/issues/125#issuecomment-1210611757