Hi Scott,
Correct me, if I am wrong, but a goal
of a Maven dependency graph, as for the Jakarta EE APIs, is to
have a acyclic, directed graph, that contains only one (in most
cases the last) version for each dependency.
That was not the case in the past, like
in 9.1 and may have caused some trouble - like the fact, that this
cycle between CDI and Transactions was not in focus for a longer
time...
Results of that cycle are:
- more than one CDI version included in
the dependency graph
- a lot of duplicated transitive
dependencies
- Core Profile has a transitive
(required!) dependency to Transactions
- the cycle can only be fixes in it's
current form with a simultaneous release of CDI and Transactions
(or alternatively with an externalised dependency, as mentioned by
you)
I think we should fix this as soon as
possible, as the erosion because of the multiple involved versions
takes place one higher level specs (like i.e. Faces) too.
When this is because of a documentation
issue (javadoc) only, than it should be strait forward to be
solved - by a workaround or an external dependency as final
solution.
Because of the transitive breaking
changes of the involved CDI and Java SE major versions,
Transactions must do a major release reflecting this for it's
users (platform vendors and application developers) on my opinion.
But this should be strait forward too.
Best,
Jan
Am 16.05.22 um 16:05 schrieb Scott
Stark:
I'm not following why Transactions needs any updates?
Transactions did a service release for EE10 that added the
module-info.class for JPMS support. CDI should be referencing
that, but it is not a major issue. The bigger problem is that
inability to define javadoc level dependencies. There is no
code level dependency between CDI and Transactions. The
jakarta.enterprise.event.TransactionPhase enum that describes
how the enum values relate to
jakarta.transaction.Synchronization should have been in a CDI
integration library from the Transactions project, but this
decision was made 10+ years ago.
There should be a javadoc scope for dependencies that allows
such javadoc only uses to be differentiated. We will discuss
removing the actual links in the javadoc to avoid the
dependency, but this is a bit of a false circular dependency
in my view.
Hello
together,
I updated the jQA repo and let fixed the issue with an
outdated index at
Sonatype for the staging repo (again) - now we have new
results for the
upcoming Jakarta EE 10.0.0 release!
I uploaded the report results in a zip file to
https://github.com/eclipse-ee4j/jakartaee-api/issues/125.
The good news: We are making progress solving issues with
dependencies!
The bad news: We have a cyclic dependency in all the Platform
Profiles
(Core, Web and "Full"/Platform):
CDI has a required dependency to Jakarta Transactions, which
in turn has
has required dependency to an older CDI version!
I think, besides Jakarta Transactions referencing an old
version of CDI,
the last must not have a dependency to Transactions at all (or
at least
not a required one using:
<optional>true</optional> <!-- value will be
true or false only -->).
Regarding the comment in CDI, this reference is only used in
Javadoc
references:
<!-- Only for javadoc references -->
<dependency>
<groupId>jakarta.transaction</groupId>
<artifactId>jakarta.transaction-api</artifactId>
<version>${transaction.api.version}</version>
</dependency>
There are notes in the POM at property level like that too:
<!-- These are only used in javadoc links -->
<ejb.api.version>4.0.0</ejb.api.version>
<transaction.api.version>2.0.0</transaction.api.version>
But Transactions will need a updated version to be released
and part of
the referencing spec configurations too!
It would be even better to get rid of that cyclic dependency
at all, if
possible to prevent future issues like that.
You can see this issue at best in the simpler Core Profile
graph
(jakarta.jakartaee-core-api/plantuml/jakarta-ee-dependencies_PlatformDependencyDiagram.svg
and the version list
(jakarta.jakartaee-core-api/plantuml/jakarta-ee-dependencies_PlatformDependencyVersionsByArtifact.csv)
in the zip file mentioned above. The Core Profile should not
depend on
Transactions (and my be others required by CDI directly), but
the
dependency problem with resulting versioning issues can be
seen in all
Profiles, sometimes even worse regarding the use of API
versions.
How do we proceed with that issue? Creating on in the relevant
spec
projects (CDI, Transactions and Platform) and discuss this
first here in
the mailing list or in the Jakarta Platform call (that might
cause delay)?
Best,
Jan
PS: This might not be the only finding in the jQA analysis,
but my first
severe one - it might be helpful to spend some additional time
into it.
