Add deprecation notice for javax support by the E4 injector

[HannesWell]

Part of #1056

I also added a corresponding N&N entry: eclipse-platform/www.eclipse.org-eclipse#79

[HannesWell]

Btw. does anybody know why tonight the I-builds did not run?

[merks]

Maybe the switch back to standard time overnight has changed when you should expect that build to happen by 1 hour...

[merks]

BTW, I'd like the/a build to happen after I merge this so that I can use it in PDE:

eclipse-equinox/p2#377

[iloveeclipse]

Btw. does anybody know why tonight the I-builds did not run?

It looks lile the builds were changed by @MohananRahul, but I fail to understand the logic behind the config:
https://ci.eclipse.org/releng/job/Builds/job/I-build-4.30/jobConfigHistory/showDiffFiles?timestamp1=2023-11-04_12-06-41&timestamp2=2023-11-04_12-11-42

[iloveeclipse]

Looking closer into the config, it says : "would next run at Sunday, November 5, 2023 at 6:00:59 AM Eastern Standard Time."

[MohananRahul]

Btw. does anybody know why tonight the I-builds did not run?

It looks lile the builds were changed by @MohananRahul, but I fail to understand the logic behind the config: https://ci.eclipse.org/releng/job/Builds/job/I-build-4.30/jobConfigHistory/showDiffFiles?timestamp1=2023-11-04_12-06-41&timestamp2=2023-11-04_12-11-42

Milestone week will have 2 builds.

[HannesWell]

Back to the actual topic: How should we proceed with the deprecation and eventual removal of javax-support?

But we can of course think about extending the deprecation period. As a suggestion I changed to text to:
scheduled to be disabled by default after the December 2026 release and scheduled for removal after the December 2028 release., which means three years until being disabled by default and five years until support is fully removed.
If a Plugin does not manage to apply the simple change and produce new builds I would consider it dead anyways.

What do you think about that? If there is real demand the javax-support could also stay (disabled by default?) until it causes real pain.

[akurtakov]

Back to the actual topic: How should we proceed with the deprecation and eventual removal of javax-support?

But we can of course think about extending the deprecation period. As a suggestion I changed to text to:
scheduled to be disabled by default after the December 2026 release and scheduled for removal after the December 2028 release., which means three years until being disabled by default and five years until support is fully removed.
If a Plugin does not manage to apply the simple change and produce new builds I would consider it dead anyways.

What do you think about that? If there is real demand the javax-support could also stay (disabled by default?) until it causes real pain.

I think it's already what we have . The document says that something is deprecated and will stay until XXX date at least . E.g. if you look at ICU4J removal item - it's marked as "API removals after June 2022" but it's still there. Similar thing happened with Navigator view.
Setting longer deprecation period will impose self-limit on our self for no good reason in case an issue arise, current workflow doesn't mandate that we remove in January 2025 but that we can remove after January 2025 when we see fit.

[HannesWell]

current workflow doesn't mandate that we remove in January 2025 but that we can remove after January 2025 when we see fit.

That makes sense too.
If there is agreement on this, I can Update the notice to state that compabitlity is retainted/guaranteed for the next two years and from this point on might be removed at any time without further notice.

Btw. I created an update for the N&N entry:
eclipse-platform/www.eclipse.org-eclipse#85

Can we references that in the deprecation notice?

[HannesWell]

Setting longer deprecation period will impose self-limit on our self for no good reason in case an issue arise, current workflow doesn't mandate that we remove in January 2025 but that we can remove after January 2025 when we see fit.

I updated the deprecation notice to reflect that.
@akurtakov, @laeubi please have a look. If you are fine with this I would like to submit that soon so that it will be in the doc of the upcomming release.

[HannesWell]

Slightly enhanced the section about how to explicitly enable and disable javax-annotation processing.

[HannesWell]

Setting longer deprecation period will impose self-limit on our self for no good reason in case an issue arise, current workflow doesn't mandate that we remove in January 2025 but that we can remove after January 2025 when we see fit.

I updated the deprecation notice to reflect that.

Since the updated message is (I assume) in the sense of @akurtakov I'm going to merge this now.