Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Discussion of how dependencies trigger updates

What this make clear is that the use of OSGi it not well defined in Jakarta. We have this issue that certainly has not been addressed for EE10:

https://github.com/eclipse-ee4j/jakartaee-platform/issues/360

When we discussed adding in supporting tooling that was postponed until after EE10, so what I will take away from your analysis is that the existing open ended version requirements do not required that proposed service releases need to do anything to absorb the major changes such as CDI.

The module system we provided minimal guidance for (JPMS) has limited version support and no package level version support as far as I understand, and it is generally not something individual component specification are in a position to deal with. It seems like this conversation around tooling and requirements needs to be one of the longer term focuses that we adopt for the EE11 agenda.


We can discuss more about any EE10 issues tomorrow.


On Dec 2, 2021 at 4:02:02 PM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
The latest CDI-4.0 in maven central (jakarta.enterprise:jakarta.enterprise.cdi-api:4.0.0.Beta2) has not updated its package versions for the Export-Package header:
 
All exports are at version 3.0, just like CDI-3.0, for example: jakarta.enterprise.context;version="3.0"
 
I assume this is an oversite for CDI-4.0 and that it must be fixed before a final CDI-4.0 is produced.  It is unclear if all the packages of CDI should be a major breaking version change and bumped to 4.0 or if only a subset of them are really breaking.  CDI team would need to evaluate that.  At any rate a version of 3.0 for all of them must be wrong.  It is unfortunate that we don't have the tools enabled to determine what the correct semantic version is for these packages in CDI-4.0 vs CDI-3.0.  As such, I suspect teams will take the simple road of bumping all the package versions to 4.0 and throw any notion of semantic package versioning out for these packages.
 
I have not been around for all the discussions in Jakarta.  My understanding is that, as a group it was decided to use semantic versions.  But it does not appear that we are taking any precautions to validate that semantic versions are being defined correctly across the board.  Furthermore, it does not appear that our specifications that depend on other jakarta specifications are ensuring that they depend on compatible versions with respect to consumer vs producer types.  With that, let us look at the three specification JARs in question for EE 10 and dependency on CDI.
 
 
JTA: jakarta.transaction:jakarta.transaction-api:2.0.0
 
This JAR manifest has Import-Package for CDI packages but specifies no required version for: 
 
jakarta.enterprise.context
jakarta.enterprise.util
 
No versions on imports means that the importer cares nothing about what version of these packages it gets.  I have my doubts this is correct for JTA-2.0., but it does mean it can resolve against CDI-4.0 even if they do end up bumping the package versions all to 4.0.
 
 
BV: jakarta.validation:jakarta.validation-api:3.0.0
 
As already reported, this JAR has no direct dependency on CDI and therefore does not import any CDI packages
 
 
Batch: jakarta.batch:jakarta.batch-api:2.0.0
 
This JAR manifest has optional imports with no required versions.  So it really cares less if it gets wired to a CDI package at all and if it does get wired it cares nothing about what package it gets wired to.  Again, I have my doubts it can just get wired to any and all versions of CDI packages:
 
Import-Package: jakarta.enterprise.util;resolution:=optional,jakarta.inject;resolution:=optional
 
 
As it stands now, the OSGi meta-data for these JARs that have no planned major or minor release for Jakarta 10 seem to be able to get wired to CDI-4.0 packages from an OSGi resolution perspective.  To be honest, if packages are not going to be semantically versioned then I see little value in specifying a package version at all.  In fact, I argue it causes confusion because it leaves a consumer of such packages with a false impression that the version actually means something with respect to the API contract.  I can also understand why the various Import-Package requirements do not specify any version range given the current state.  Version ranges are useless if the exporter is not going to evolve with semantic versions.  Useless may be a slight overstatement, but at the very least it is hard to explain to a consumer of the API what valid range they should use when importing our API.
 
Overall I think this is not a good state to be in.

Tom
 
 
----- Original message -----
From: "Scott Stark" <starksm64@xxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Discussion of how dependencies trigger updates
Date: Wed, Dec 1, 2021 9:15 AM
 
The JTA service release would be free to keep the current 3.0 CDI provided dependency, and the only testing in EE10 would be against CDI 4.0.
 
On Dec 1, 2021 at 8:58:17 AM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
Scott, I think I agree with your criteria for minor and major updates:
 
- service release; any update in the dependency could trigger an update to the artifact, but it is not required and there is no spec update.
- minor update; new minor features in the dependent spec are being made available via the dependee spec API and/or the specification is referring to those new minor features.
- major update; new major features in the dependent spec are being made available via the dependee spec API and/or the specification is referring to those new major features.
But my concern is with the server release criteria.  For example, JTA-2.0.1 -> CDI-4.0.  Would such a service release JTA API force CDI-4.0 to be used or would implementations be free to also support JTA-2.0.1 with CDI-3.0?  I assume the TCK for EE 10 would only test compatibility with CDI-4.0.
 
I have a similar question for other specifications that are not doing any service release for EE 10 and have a dependency on CDI-3.0.  I assume implementations of such specifications are free to support integrations with CDI-3.0 and CDI-4.0 implementations.  Again, the TCK here for EE 10 would only test that integration with CDI-4.0 works as expected.

Tom
 
 
 
----- Original message -----
From: "Scott Stark" <starksm64@xxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] [jakartaee-platform-dev] Discussion of how dependencies trigger updates
Date: Tue, Nov 30, 2021 12:54 PM
 
Today's discussion was centered on what impact both minor and major and potentially breaking updates to individual specs and their APIs have on specifications that depend on the changes at either the spec level or both the spec and API level.
 
CDI 4.0 is a major update that has breaking changes both due to removal of deprecated APIs, possibly changes to some APIs, and certainly the default semantics of interpreting how to identify the CDI beans in a bean archive.
 
Three specs that have a dependency on CDI but have no current plans for anything other than service release updates are Bean Validation(BV), Transactions(JTA), and Batch.
 
BV has no dependency on the CDI APIs. It mentions requirements that containers and dependency injection frameworks should follow in order to make BV ValidatorFactory, Validator(s), ConstraintValidator(s), etc. be made available to the application components. So if an implementation of BV relies on CDI to achieve this, it will potentially have to be updated to work with a CDI 4.0 environment.
 
A BV 3.0 -> 4.0 update to the specification and API artifact does not make sense to me for this dependency as nowhere would there be a change to accomplish this. Again, there are no API dependencies, and the references to dependency injection are abstract and make no mention of APIs or artifact semantics. All of those details are covered in the CDI spec itself that BV is bundled with by virtue of the Platform spec.
 
JTA does have a dependency on the CDI Nonbinding and NormalScope annotations, and it's API artifact has a dependency on CDI 3.0.0-M1 with a provided scope. Neither of these annotations has changed in terms of either compile time or runtime semantics. 
 
Here again I don't see that a JTA 2.0 -> 3.0 update is warranted for simply due to the dependency. We are doing a service release to add a module-info, so it also makes sense to update the dependency on CDI to be consistent with the platform, but if there was no other reason for a service release, why do one just to update the dependency?
 
Batch is similar to JTA in that is has a dependency on the CDI Nonbinding annotation, and a provided scope dependency on the 3.0.0 CDI API artifact. The Batch spec does state that @Inject from CDI must work with @BatchProperty when used. It does not go into what CDI deployment semantics are.
 
Here again I don't see that a Batch 2.0 -> 3.0 spec update is needed. 
 
The question that was not answered in today's call is what is the criteria for a dependency on another spec to trigger the following release of the dependee specification:
- service release
- minor update
- major update
 
For me, I would have the following criteria:
- service release; any update in the dependency could trigger an update to the artifact, but it is not required and there is no spec update.
- minor update; new minor features in the dependent spec are being made available via the dependee spec API and/or the specification is referring to those new minor features.
- major update; new major features in the dependent spec are being made available via the dependee spec API and/or the specification is referring to those new major features.
 
 
_______________________________________________
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
_______________________________________________
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

Back to the top