|
edburns@xxxxxxxxxxxxx | office: +1 954 727 1095
| Calendar Booking:
https://aka.ms/meetedburns
|
| Please don't feel obliged to read or reply to this e-mail outside
| of your normal working hours.
|
| Reply anonymously to this email:
https://purl.oclc.org/NET/edburns/contact
## jea-98
- In order to complete the Wave discussion we must find a way to deal
with the existing circular dependencies.
- There are several different approaches. Let us enumerate them on a
spectrum from "the most correct way" to "least correct way".
### Describe the problem exactly
- Consider this POM from the **cdi-tck** repository, in the **web** directory.
-
https://github.com/jakartaee/cdi-tck/blob/master/web/pom.xml
- This POM has problematic dependencies. Ideally, this POM should
only have dependencies on
- technologies in the Core profile.
- technical dependencies to allow the TCK to actually run.
However, it currently has dependencies on technologies in the Web
and Platform profiles, as show here.
Core
```xml
<dependency>
<groupId>jakarta.ws.rs</groupId>
<artifactId>jakarta.ws.rs-api</artifactId>
<version>${jaxrs.api.version}</version>
</dependency>
<dependency>
<groupId>jakarta.interceptor</groupId>
<artifactId>jakarta.interceptor-api</artifactId>
</dependency>
<dependency>
<groupId>jakarta.annotation</groupId>
<artifactId>jakarta.annotation-api</artifactId>
</dependency>
<dependency>
<groupId>jakarta.inject</groupId>
<artifactId>jakarta.inject-api</artifactId>
</dependency>
```
Core (optional)
```xml
<dependency>
<groupId>jakarta.el</groupId>
<artifactId>jakarta.el-api</artifactId>
</dependency>
```
Web
```xml
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>${servlet.api.version}</version>
</dependency>
<dependency>
<groupId>jakarta.servlet.jsp</groupId>
<artifactId>jakarta.servlet.jsp-api</artifactId>
<version>${jsp.api.version}</version>
</dependency>
<dependency>
<groupId>jakarta.transaction</groupId>
<artifactId>jakarta.transaction-api</artifactId>
<version>${jta.api.version}</version>
</dependency>
<dependency>
<groupId>jakarta.faces</groupId>
<artifactId>jakarta.faces-api</artifactId>
<version>${jsf.api.version}</version>
</dependency>
<dependency>
<groupId>jakarta.persistence</groupId>
<artifactId>jakarta.persistence-api</artifactId>
<version>${jpa.api.version}</version>
</dependency>
<dependency>
<groupId>jakarta.ejb</groupId>
<artifactId>jakarta.ejb-api</artifactId>
<version>${ejb.api.version}</version>
</dependency>
```
Platform
```xml
<dependency>
<groupId>jakarta.jms</groupId>
<artifactId>jakarta.jms-api</artifactId>
<version>${jms.api.version}</version>
</dependency>
<dependency>
<groupId>jakarta.resource</groupId>
<artifactId>jakarta.resource-api</artifactId>
<version>${jca.api.version}</version>
</dependency>
```
Technical dependencies to allow the TCK to actually run
```xml
<dependency>
<groupId>jakarta.enterprise</groupId>
<artifactId>cdi-tck-core-impl</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>jakarta.enterprise</groupId>
<artifactId>jakarta.enterprise.cdi-api</artifactId>
</dependency>
<dependency>
<groupId>jakarta.enterprise</groupId>
<artifactId>cdi-tck-api</artifactId>
</dependency>
<dependency>
<groupId>jakarta.enterprise</groupId>
<artifactId>cdi-tck-ext-lib</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.arquillian.testng</groupId>
<artifactId>arquillian-testng-container</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.arquillian.container</groupId>
<artifactId>container-se-api</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.shrinkwrap.descriptors</groupId>
<artifactId>shrinkwrap-descriptors-impl-javaee</artifactId>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
</dependency>
<dependency>
<groupId>commons-httpclient</groupId>
<artifactId>commons-httpclient</artifactId>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-chrome-driver</artifactId>
</dependency>
<dependency>
<groupId>io.github.bonigarcia</groupId>
<artifactId>webdrivermanager</artifactId>
</dependency>
<dependency>
<groupId>net.sourceforge.htmlunit</groupId>
<artifactId>htmlunit</artifactId>
</dependency>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.2</version>
<scope>test</scope>
</dependency>
```
on technologies that **are not** in the
Jakarta EE Web Profile.
### The most correct way: The complete CDI split option
Creating top-level Jakarta EE specifications for CDI-core, CDI-web,
CDI-platform. This would including splitting up the APIs into separate
API jar artifacts and spliting up the corresponding TCKs.
#### CDI TCK
https://github.com/jakartaee/cdi-tck is refactored into something like
- cdi/core-tck
- cdi/web-tck
- cdi/platform-tck
#### CDI spec
https://github.com/jakartaee/cdi is refactored into something like
- cdi/core
- cdi/web
### A little less correct way: TCK only split option
Split up only the TCKs, not the specification (and therefore also API).
Create two new top-level Jakarta EE specifications: CDI-web-TCK-only,
CDI-platform-TCK-only.
- Each of these are essentially a top-level Jakarta EE specification
that references the existing top-level Jakarta CDI specification
but includes its own TCK.
- To satisfy the requirement to have a compatible implementation, each
of these simply uses the corresponding implementation of the
existing top-level CDI Jakarta EE specification. (Not CDI-lite
only).
- To satisfy the TCK requirements
- The TCK of the existing top-level CDI Jakarta EE specification
would be reduced. The web and platform profile tests would be removed
from this TCK and moved into the corresponding web and platform
TCK-only specifications.
### Even less correct way: Discover "the violating set" and move tests around
#### Context
Core
A
B
Web
C
Platform
D
Dependencies
C -> B
B -> A
Regarding "integration-test" style TCK tests, the most important rule
is that "integration-test" style TCK tests in a component spec must
obey the dependency graph. There are component spec TCK tests that
violate this rule. For discussion, all such tests are called "members
of the violating set". This violation makes it impossible to separate
the TCK tests in a way that allows the best Wave list ordering. This
makes it impossible to release the specs independently (within each
wave).
#### Solution
Instead of creating separate CDI specifications, with separated TCKs,
we only separate the tests and put them in the TCK for the Web Profile
and Core Profile specs.
Moving the tests that violate the dependency rule "up" in the
dependency graph.
Let's say we have a test in A that uses functionality in B, the
problem can be solved by moving that test from A to B.
To solve the problem without creating any new specifications, we move
the violating tests from where currently are (wherever that may be)
"up" from the component spec to either the TCK for an umbrella spec
(web, core, platform) **or** the other component spec.
#### Challenges to this option
- We do not have a good handle on what exact tests are members "the
violating set".
### The least correct way: do nothing
We accept that, when doing the waves, when we get to higher waves,
specs that were in lower waves will have to be updated and
re-released **or** will have dependencies on outdated versions.
## What is the business benefit of trying to solve this problem?
- Bugs stay more within their own "bulkheads".
- Release management is less complicated.
- Less effort in release management can mean
- a more agile cadence.
- less risk in the schedule.
