Re: Test and what's next?

Guillermo González de Agüero

Regardinf pre-UEL, are there already alternative methods on thosw interfaces to use UEL? I imagine that would mean a lot of duplication, unless a new interface with the same purpose could be introduced, while deprecating the former one.

That could make it all even bigger, but I'm now thinking about cleaner stacktraces (using only new artifacts) more than in splitted modules.

Do you have a whole list of "legacy/deprecated" JSF features?


Guillermo González de Agüero

El sáb., 13 de mayo de 2017 18:02, Arjan Tijms <arjan.tijms@...> escribió:
On Sat, May 13, 2017 at 08:57 am, Guillermo González de Agüero wrote:
Btw, what about the JSP view facility? Is it already deprecated? That could be another candidate to be moved to another module IMO.

It's certainly effectively deprecated. Many newer features are not supported when JSP is used, which is in a way a strategy to slowly phase it out.

But indeed, I love to move that one to a separate module/jar file too so that people can totally exclude it. Some things in JSF (Mojarra at least) are a bit more difficult to exclude as it's interwoven into the code at various places.

Some of the native EL resolvers would be another candidate to move to a legacy module. The pre-UEL support that's still there in JSF would be more difficult to completely remove, as it shows up as (interface) methods in a wide variety of types. Removing that would be a breaking change, which under Java EE rules is not that easy.


Join to automatically receive all group messages.