Deprecate unused composite:extension

[tandraschko]

as discussed on the mailing list

[arjantijms]

Thanks @tandraschko

[volosied]

Email for reference: https://www.eclipse.org/lists/faces-dev/msg00070.html

[BalusC]

Remove without deprecation?

Edit: something like this thus? eclipse-ee4j/mojarra@08e737d

[tandraschko]

for me it would also be ok to deprecate first in 4.1

[volosied]

Although this is unused, this could still be considered a breaking change? If we deprecate it in 4.1, should it stay deprecated in 5.0 until it can be removed in the next major release after 5.0?

[volosied]

I'll try to have this brought up in one of the upcoming Jakarta Platform calls to get approval to have this removed without deprecation. I don't know too much about this tag or it's history, however.

Looking around a bit though...

The VLD Doc says:
Used within a <composite:interface> section, within any sub-element of that section, to include XML content not defined by this specification. This element can be used to incorporate [JSR-276](http://jcp.org/en/jsr/detail?id=276) metadata into a composite component.

As Arjan said in the email thread, The entire design time thing obviously never took off in general, and obviously those extension tags never did anything at all for even the few tools that did exist for JSF visual editing.

JSR 276 Link: https://download.oracle.com/otn-pub/jcp/dt_metadata_jsf-0.5-edr-oth-JSpec/dt_metadata-jsf-0_5-edr-spec.pdf?AuthParam=1694566997_26177af8a0e9d6b66f87b4d5b0192d95 which also mentions: The tags also allow composite:extension element children for embedding additional design time metadata.

MyFaces did not implement anything as Thomas said. We just have a TODO note:

        // TODO: In theory the xml data inside this tag should be saved,
        // but the spec does not say where and how this should be done.
        // For now we just prevent execute any handler inside this tag.
        // As soon JSR-276 is available, some behavior for this tag
        // should be added.

So I guess this tag wasn't really followed up with. So in terms of behavior, it should be okay to remove it? Only issue is if a facelet does use the tag (for whatever reason -- i.e demo apps), then it should remove it to avoid undefined tag errors.

[edburns]

Discussed at 2023-09-19 Platform Project meeting:
These three would have been removed in Faces 4.1. The recently approved deprecation process does indeed cover this kind of case.
Emily observed

• The spec committee needs to grant this exception.
• Will bring this up at the next spec committee meeting, with the understanding this is pre-approved.
• It is a wasted effort to do 4.1 to accommodate these changes.

[BalusC]

would have been removed in Faces 4.1

The wording confuses me. Can we remove it for 4.1 or not?

These three

This one, and #1707 and #1725? Does this mean that we should redo #1707 to physically remove these rather than deprecate these?

[volosied]

I think it was a misunderstanding.
We can still deprecate them in 4.1 and then remove in 5.0.

Approval was to remove them from 5.0 (since faces 5.0 is part of EE11, but meeting minutes don't state it explicitly)

---

Spec Committee Minutes from Sept 20 2023:
Seek exception from Jakarta Faces to remove the apis without going through the deprecation stage. It was discussed at this week’s Platform call and it was approved there.
#1549

• composite:extension tag (tag created, but never implemented behavior)
  Deprecate unused PreDestroyCustomScopeEvent and PostConstructCustomScopeEvent #1707
• PreDestroyCustomScopeEvent and PostConstructCustomScopeEvent classes (not used due to the removal of JSF managed beans)
  Remove UIComponent.bindings field #1725
• UIComponent.bindings field (should have been removed in Faces 4.0)
  Does the Specification Committee approve this exception request? No objections noted, this request is approved.

[BalusC]

Ah okay. I'll look how best to deprecate the composite:extension.

[volosied]

Sounds good. I was thinking of just adding a warning if it was used?

Edit: just saw your PR. Javadoc is be good too. I see what I can do in myfaces, too.

[volosied]

fixed in myfaces via https://github.com/apache/myfaces/pull/639

@BalusC safe to close this issue?