API will be split off from the implementation code - step 1

[volosied]

Listed under the Spec Changes, but I don't see any associated issue.

https://jakarta.ee/specifications/faces/5.0/

Question: Will this apply to MyFaces or only Mojarra? We have a few implementation specific packages in our API. Should they be move to the implementation? @tandraschko

[tandraschko]

TBH MyFaces contains many impl specific code in the API, even in Mojarra. We have soooo many tasks to make faces better for users. No user will benefit from this, lets better invest our time for more important tasks.

[arjantijms]

The fact that no user will ever benefit from this is exactly the reason why it still hasn't been done after all this time.

[tjwatson]

TBH MyFaces contains many impl specific code in the API, even in Mojarra. We have soooo many tasks to make faces better for users. No user will benefit from this, lets better invest our time for more important tasks.

Maintaining the API source in the specification project with no implementation specific stuff (e.g. Mojarra) will help avoid issues like #1714 where the Mojarra project directly impacts normative text (in the form of Javadoc) and the TCK signature tests themselves.

This way a PR that updates specification text to remove/add/modify APIs can also update the actual .java source in the specification project to make the same updates without coordinating with another project outside the governance of the specification project itself.

This also puts all implementations of faces on equal footing with respect to the API JARs that are published from the specification project itself.

[tandraschko]

We could simply introduce "empty" API sources in the spec

[arjantijms]

About half a year ago I did an initial attempt just for Mojarra, in a Mojarra specific way. It's a bit of work, and in the POC there's still a single Mojarra type in the API (which can be removed, but for simplicity is still there).

See: https://github.com/arjantijms/mojarra/tree/api_split

[jasondlee]

FWIW, I personally and we the WildFly team would love this. We're currently just using Mojarra 4.x directly now (instead of forking and using an API-only quasi-jar -- a term I just came up with), but the leaves us with exposing implementation code to deployments (via our JBoss Modules support) where we'd rather just expose API classes for a cleaner, safer classpath for deployments. The same would apply to our MyFaces feature pack, which allows users to add MyFaces support to WildFly should they choose to do so.

[jhanders34]

I agree. Currently products that implement the Faces specification cannot just use the faces API bundle that is published to maven central. They need to use a special API bundle that is specific to the implementation of the specification which is a real black eye for Jakarta EE because the provided API bundle (unlike other specifications) cannot be used as is because it only has API function in it with the appropriate extension points and interfaces being defined to be implemented by an implementation of the specification.

[tandraschko]

That might be true but we are not many active contributors here and doing the split is many many work. We dont even have enough resources to work on long-time missing very important features, which is much much more important to gain new users or not even loose users.

[tjwatson]

What @jhanders34 and @jasondlee want is the ideal end goal. But I think that could take more work than what we have time for in EE 11. I was suggesting the specification project produce a "pure" API JAR that has no references to any Mojarra implementation types. I think that is similar to what @tandraschko was suggesting with the "empty" API sources. But the end result of that may be a specification project JAR that is really only useful for applications to compile against. I expect Faces implementations would then have to take the source of the API and plugin their implementations and recompile the faces APIs with their implementation. My understanding is that is what all other Faces implementations need to do, besides Mojarra because currently Mojarra is the project holding the normative source of the APIs.

To design a general purpose solution that can plugin any implementation of Faces without modifying the source of the faces API likely will take time to agree on and specify correctly.

[BalusC]

There are efforts in Mojarra https://github.com/eclipse-ee4j/mojarra/issues/4480

[tandraschko]

whats the goal? just a splitup like in myfaces for now, which still contains impl specific code?

[mnriem]

Baby steps towards a true API JAR

[arjantijms]

Fixed by #1856

Note that we're still far from a true separate API, but at least the weird "download mojarra source, split in two, and recompile api part" is now gone.

[anbusampath]

Any work still pending here to separate API/Impl

we're still far from a true separate API

Baby steps towards a true API JAR

[BalusC]

5.0 is already separate. See the last comment of Arjan Tijms referring to #1856.