Transforming application classes and XML and other metadata. Either on-demand, or at server or application startup. Requires a transformation mechanism. Also requires a mechanism to detect and direct application transformation. Possibly requires caching mechanisms. A primary impact is to application classloaders, which would use the existing transformer tool to rewrite bytecodes and metadata. A second primary impact is to access to metadata through the Liberty artifact file system, which would need to be similarly intercepted and transformed. JakartaEE transformations are the primary use case (https://github.com/eclipse/transformer). JAX-RPC to JAX-WS transformation is a possible use case (https://www.ibm.com/docs/en/was-liberty/base?topic=liberty-migrating-jax-rpc-applications).
Documents
When available, add links to required feature documents. Use "N/A" to mark particular documents which are not required by the feature.
Important: Labels are used to trigger particular steps and must be added as indicated.
Prioritization (Complete Before Development Starts)
The (OpenLiberty/chief-architect) and area leads are responsible for prioritizing the features and determining which features are being actively worked on.
Epics can be added to the board in one of two ways:
From this issue, use the "Projects" section to select the appropriate project board.
From the appropriate project board click "Add card" and select your Feature Epic issue
[ ] Priority assigned
Attend the Liberty Backlog Prioritization meeting
Design (Complete Before Development Starts)
Design preliminaries determine whether a formal design, which will be provided by an Upcoming Feature Overview (UFO) document, must be created and reviewed. A formal design is required if the feature requires any of the following: UI, Serviceability, SVT, Performance testing, or non-trivial documentation/ID.
Design Preliminaries
[ ] UI requirements identified. (Owner and UI focal point)
[ ] ID requirements identified. (Owner and ID focal point)
Add the public link to the UFO in Box to the Documents section.
The UFO must always accurately reflect the final implementation of the feature. Any changes must be first approved. Afterwards, update the UFO by creating a copy of the original approved slide(s) at the end of the deck and prepend "OLD" to the title(s). A single updated copy of the slide(s) should take the original's place, and have its title(s) prepended with "UPDATED".
A feature must be prioritized and socialized (or No Design Approved) before any implementation work may begin and is the minimum before any beta code may be delivered. All new Liberty content must be inaccessible in our GA releases until it is Feature Complete by either marking it kind=noship or beta fencing it.
Code may not GA until this feature has obtained the "Design Approved" or "No Design Approved" label, along with all other tasks outlines in GA section.
Feature Development Begins
[ ] Add the In Progress label
Legal and Translation
In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. Both MUST be completed before GA is requested.
Legal (Complete before Feature Complete Date)
[ ] Changed or new open source libraries are cleared and approved, or N/A. (Legal Release Services/Cass Tucker/Release PM).
[ ] Licenses and Certificates of Originality (COOs) are updated, or N/A
Translation (Complete 1 week before Feature Complete Date)
[ ] PII updates are merged, or N/A. Note timing with translation shipments.
GA
A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.
Feature Complete
[ ] Feature implementation and tests completed.
[ ] All PRs are merged.
[ ] All epic and child issues are closed.
[ ] All stop ship issues are completed.
[ ] Legal: all necessary approvals granted.
[ ] Translation: All messages translated or sent for translation for upcoming release
[ ] GA development complete and feature ready for inclusion in a GA release
Add label target:ga and the appropriate target:YY00X (where YY00X is the targeted GA version).
Inclusion in a release requires the completion of all Focal Point Approvals.
Focal Point Approvals (Complete by Feature Complete Date)
These occur only after GA of this feature is requested (by adding a target:ga label). GA of this feature may not occur until all approvals are obtained.
NOTE: If only trivial documentation changes are required, you may reach out to the ID Feature Focal to request a ID Required - Trivial label. Unlike features with regular ID requirement, those with ID Required - Trivial label do not have a hard requirement for a Design/UFO.
[ ] WDT Liberty Developer Tools work is complete or N/A. (Leonard Theivendra)
Design considerations
I'm updating this story to cover the broader question of how we should be handling application transformation. Detecting the feature set of an application and automatically transforming the application is one of several scenarios of interest.
Design questions included in the design space:
What is our target scenario:
Should the feature set (pre-EE9, EE9, EE10) be compared with the server provisioning, with the application being migrated to match the provisioned features?
Conversely, do we want generic features and have the server automatically provision to the version which supports the features contained within the application?
Or, should application transformation be performed explicitly using a new application configuration option, either in the application or module configuration element, or in the application manager configuration element?
What application elements should be transformed?
This is a basic expression of intent: Application artifacts include configuration elements, deployment descriptors, classes, and service configuration files. Is the goal to transform all necessary application artifacts?
What do we mean by "dynamic"?
One option is to enable class and resource loading to transform resources dynamically, performing a new transformation every time the resource is loaded.
A second option is to perform whole application transformation as a preparatory step.
In either case, the transformation results might or might not be cached.
User story:
"As an existing user of Java EE, I expect to transform my applications to Jakarta without including special configuration for transformation of deployment descriptors."
Deployment descriptors (web.xml, ejb-jar.xml, application.xml), as well as the types of resources that can be included within the resource references and other entries within them, are well-defined within the Java EE/Jakarta specifications and therefore users will expect these to transform seamlessly out of the box without any special additional configuration or settings. The transformer ought to do this automatically.
Currently, to accomplish this, (as shown under #12080) I had to ask people who worked on the tool, who were able to direct me to modify and create special properties files for the transformer before it would process the xml files and make conversions within them:
dev/wlp-jakartaee-transform/rules/jakarta-xml-master.properties
dev/wlp-jakartaee-transform/rules/jakarta-web.properties
I cannot see any good reason why end users ought to ever have to even think about this sort of detail or take steps like this. It should just happen automatically based on built-in knowledge of what is spelled out by the Jakarta/Java EE specifications around deployment descriptors and equivalent packages.
njr-11
commented
4 years ago
Description
Transforming application classes and XML and other metadata. Either on-demand, or at server or application startup. Requires a transformation mechanism. Also requires a mechanism to detect and direct application transformation. Possibly requires caching mechanisms. A primary impact is to application classloaders, which would use the existing transformer tool to rewrite bytecodes and metadata. A second primary impact is to access to metadata through the Liberty artifact file system, which would need to be similarly intercepted and transformed. JakartaEE transformations are the primary use case (https://github.com/eclipse/transformer). JAX-RPC to JAX-WS transformation is a possible use case (https://www.ibm.com/docs/en/was-liberty/base?topic=liberty-migrating-jax-rpc-applications).
Documents
When available, add links to required feature documents. Use "N/A" to mark particular documents which are not required by the feature.
Aha: Externally raised RFE (Aha)
UFO: Link to Upcoming Feature Overview document
FTS: Link to Feature Test Summary GH Issue
Process Overview
Prioritization
Design
Implementation
Legal and Translation
GA
Other Deliverables
General Instructions
The process steps occur roughly in the order as presented. Process steps occasionally overlap. If unsure
Each process step has a number of tasks which must be completed or must be marked as not applicable ("N/A").
Unless otherwise indicated, the tasks are the responsibility of the Feature Owner or a Delegate of the Feature Owner.
If you need assistance, check out the Feature and UFO (WAD) Approval Process wiki, or reach out to the (OpenLiberty/release-architect).
Important: Labels are used to trigger particular steps and must be added as indicated.
Prioritization (Complete Before Development Starts)
The (OpenLiberty/chief-architect) and area leads are responsible for prioritizing the features and determining which features are being actively worked on.
Prioritization
[ ] Feature added to the "New" column of the Liberty confidential project board
[ ] Priority assigned
Design (Complete Before Development Starts)
Design preliminaries determine whether a formal design, which will be provided by an Upcoming Feature Overview (UFO) document, must be created and reviewed. A formal design is required if the feature requires any of the following: UI, Serviceability, SVT, Performance testing, or non-trivial documentation/ID.
Design Preliminaries
ID Required, if non-trivial documentation needs to be created by the ID team.ID Required - Trivial, if no design will be performed and only trivial ID updates are needed.Design
Design Review RequestDesign ApprovedNo Design
No Design Approval RequestNo Design ApprovedFAT Documentation
[ ] "Feature Test Summary" child task created
Implementation
A feature must be prioritized and socialized (or
No Design Approved) before any implementation work may begin and is the minimum before any beta code may be delivered. All new Liberty content must be inaccessible in our GA releases until it is Feature Complete by either marking itkind=noshipor beta fencing it.Code may not GA until this feature has obtained the "Design Approved" or "No Design Approved" label, along with all other tasks outlines in GA section.
Feature Development Begins
In ProgresslabelLegal and Translation
In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. Both MUST be completed before GA is requested.
Legal (Complete before Feature Complete Date)
Translation (Complete 1 week before Feature Complete Date)
[ ] PII updates are merged, or N/A. Note timing with translation shipments.
GA
A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.
Feature Complete
target:gaand the appropriatetarget:YY00X(where YY00X is the targeted GA version).Focal Point Approvals (Complete by Feature Complete Date)
These occur only after GA of this feature is requested (by adding a
target:galabel). GA of this feature may not occur until all approvals are obtained.All Features
focalApproved:fat.focalApproved:demo.focalApproved:globalization.Design Approved Features
focalApproved:accessibility.focalApproved:externalsfocalApproved:id.focalApproved:performance.focalApproved:sve.focalApproved:ste.focalApproved:svt.Post GA
[ ] Replace
target:YY00Xlabel with the appropriaterelease:YY00X. (OpenLiberty/release-manager)Other Deliverables
[ ] WDT Liberty Developer Tools work is complete or N/A. (Leonard Theivendra)
Design considerations
I'm updating this story to cover the broader question of how we should be handling application transformation. Detecting the feature set of an application and automatically transforming the application is one of several scenarios of interest.
Design questions included in the design space:
What is our target scenario:
What application elements should be transformed?
What do we mean by "dynamic"?
User story: "As an existing user of Java EE, I expect to transform my applications to Jakarta without including special configuration for transformation of deployment descriptors."
Deployment descriptors (web.xml, ejb-jar.xml, application.xml), as well as the types of resources that can be included within the resource references and other entries within them, are well-defined within the Java EE/Jakarta specifications and therefore users will expect these to transform seamlessly out of the box without any special additional configuration or settings. The transformer ought to do this automatically.
Currently, to accomplish this, (as shown under #12080) I had to ask people who worked on the tool, who were able to direct me to modify and create special properties files for the transformer before it would process the xml files and make conversions within them: dev/wlp-jakartaee-transform/rules/jakarta-xml-master.properties dev/wlp-jakartaee-transform/rules/jakarta-web.properties
I cannot see any good reason why end users ought to ever have to even think about this sort of detail or take steps like this. It should just happen automatically based on built-in knowledge of what is spelled out by the Jakarta/Java EE specifications around deployment descriptors and equivalent packages.