faces icon indicating copy to clipboard operation
faces copied to clipboard

Remove unused composite:extension

Open tandraschko opened this issue 4 years ago • 1 comments

as discussed on the mailing list

tandraschko avatar Nov 18 '20 08:11 tandraschko

Thanks @tandraschko

arjantijms avatar Nov 24 '20 14:11 arjantijms

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

volosied avatar Jul 07 '23 16:07 volosied

Remove without deprecation?

Edit: something like this thus? https://github.com/eclipse-ee4j/mojarra/commit/08e737dc8bc84aa408c7fe39a68fbb1ad3c0fedf

BalusC avatar Jul 30 '23 15:07 BalusC

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

tandraschko avatar Jul 31 '23 07:07 tandraschko

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 avatar Aug 02 '23 15:08 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.

volosied avatar Sep 13 '23 01:09 volosied

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.

edburns avatar Sep 19 '23 15:09 edburns

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 https://github.com/jakartaee/faces/issues/1707 and https://github.com/jakartaee/faces/issues/1725? Does this mean that we should redo #1707 to physically remove these rather than deprecate these?

BalusC avatar Nov 04 '23 19:11 BalusC

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. https://github.com/jakartaee/faces/issues/1549

  • composite:extension tag (tag created, but never implemented behavior) https://github.com/jakartaee/faces/issues/1707
  • PreDestroyCustomScopeEvent and PostConstructCustomScopeEvent classes (not used due to the removal of JSF managed beans) https://github.com/jakartaee/faces/issues/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.

volosied avatar Nov 04 '23 20:11 volosied

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

BalusC avatar Nov 04 '23 20:11 BalusC

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 avatar Nov 05 '23 01:11 volosied

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

@BalusC safe to close this issue?

volosied avatar Nov 15 '23 14:11 volosied