[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] platform-685: Wave discussion
|
Hi,
I think the requirements in the spec and the TCK need to be respected in
the waves too (not only the API).
We want to have a directed acyclic graph for the dependencies to be able
to release them.
In general, I think it is a good Idea to release the component spec
parts (spec, API, TCK) together in the future, where the dependencies
between the parts (and the outside world) can be easily managend in a
multi module Maven setup. We have some examples organized like this in
Jakarta and this is successful in MicroProfile too. But there are lot of
component specs that use separate parts in separate repos - this is hard
to maintain, as there need to be a version mapping, sometimes an issue
mapping with manual syncs being necessary...
Reason for this is intended way is, when there is one change in reality,
there will be on change in each of the component specs parts. I.e. when
a feature is added, then it need to be mentioned in the spec doc, an API
change is necessary and TCK test(s) need to be added at the same time -
or the sync need to be done manually before the release. Unfortunately,
in reality there are to many examples where the sync in incomplete...
In the case of conflicts (like circular dependencies) in the release
order there are different ways to solve this:
- Tests from a TCK could be moved to upper spec or the lowest possible
umbrella spec - an example could be an integration test of two component
specs, where a (integration) test need to be moved from the lower wave
component spec TCK to the higher wave component spec, to prevent
circular dependencies.
- Spec document references to component spec dependencies could be
weaker than they need to be in the API, but it might make sense to model
them as an technical dependency in it's Maven POM to manage them
technically, as declaring the exact (minimum) required version and
display this setting in the spec document as an Asciidoc attribute
(allows definition and maintenance in one single place). A so defined
dependency can be monitored and verified by tools like jQA too - up to
breaking the build for a final release...
- Releasing specs together or even merge them could help out too. A
start can be to align or merge the teams behind the specs first.
I can add results to
https://github.com/jakartaee/jakartaee-platform/issues/687 for the spec
documents (on staging) and do PR in the jQA demo project, so everybody
can run updates for them.
Another step might be to extent the report to show the dependencies of
the parts in one single graph - but the current API one is complex
already...
Best,
Jan
Am 30.05.23 um 18:15 schrieb Scott Stark:
This is a fundamental issue that requires coordination between the
component spec and the target component spec project that the former
is attempting to define integration requirements for. It is the reason
why we have TCKs with circular dependencies. To clean this up, we need
to break up both specifications and TCK artifacts to align with the
target specification dependencies. Those spec fragments and TCK
artifacts should be released with the most downstream wave component
specification.
The current specification project structure is not great for this as
there are no cross projects committers or permissions. You have to be
a committer on each component project.
It seems most natural for a component specifications integration
requirements to live in the platform project. The profile and platform
specification can override these anyway, but in terms of structural
dependencies that is what makes the most sense to us. The TCK
artifacts should have a repo in the platform TCK project. This will
require updates to how the project management guides, and probably
more committers or permission groups to the platform and platform tck
projects.
On Tue, May 30, 2023 at 9:18 AM Arjan Tijms <arjan.tijms@xxxxxxxxxxx> wrote:
Hi,
Last week we discussed the waves to release Jakarta EE APIs in.
Historically we have been looking at Maven dependencies, but there are also dependencies via the specification documentations. E.g. Jakarta Authentication has no API dependencies on Servlet and SOAP, but the specification documentation very strongly depends on them.
Would we like to take that into account this time?
Kind regards,
Arjan Tijms
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
