[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mojarra-dev] [faces-dev] Splitting the API into faces-api?
|
I see now that some
of this has already been discussed (without a solution, of course) in this
Issue:https://github.com/eclipse-ee4j/mojarra/issues/4480I'll update this
Issue with a reference to this conversation. It doesn't look like
there's an "easy" answer to this problem. I still think
it would a worthwhile effort to separate the API from the Implementation,
but I can also understand if there's not enough runway to accomplish this
for Jakarat EE 9. Maybe this can be a priority for Jakarta EE 10?
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutterFrom:
"Guillermo
González de Agüero" <z06.guillermo@xxxxxxxxx>To:
mojarra
developer discussions <mojarra-dev@xxxxxxxxxxx>Cc:
faces
developer discussions <faces-dev@xxxxxxxxxxx>Date:
02/24/2020
11:25Subject:
[EXTERNAL]
Re: [mojarra-dev] [faces-dev] Splitting the API into faces-api?Sent
by: mojarra-dev-bounces@xxxxxxxxxxx
Hi,I once started a POC to remove the implementation
code from the JSF API classes using JavaParser: https://github.com/ggam/jsfparser/blob/master/src/main/java/eu/ggam/jsfparser/App.javaThat could be used as a temporary solution
but in the long run, a new cleaned API would be a better choice to keep
Faces relevant.Regards,Guillermo González de AgüeroOn Mon, Feb 24, 2020 at 4:58 PM arjan
tijms <arjan.tijms@xxxxxxxxx>
wrote:Hi,Indeed, what I think the best way forward
would be to create a new API largely resembling the existing one,
but in another package and completely (or how much is reasonably possible)
based on interfaces. Not sure how much work that will be,
but surely won't be trivial.Kind regards,Arjan On Mon, Feb 24, 2020 at 4:53 PM Thomas
Andraschko <andraschko.thomas@xxxxxxxxx>
wrote:here, i'm one of the MyFaces guys! :D
It's not really cleaner at all. Both
Mojarra and MyFaces contains toooo much implementation details.I think the only way is to create a new
cleaned API without method implementations, only the signatures should
be there.
Am Mo., 24. Feb. 2020 um 16:43 Uhr
schrieb Kevin Sutter <sutter@xxxxxxxxxx>:Thanks for the
background, Arjan. So, thinking outside of the box... What
about the Apache MyFaces API? Is that a cleaner version of the API?
I don't know who we have on these lists that are MyFaces experts.
But, maybe that would be a better base to start with for faces-api?
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: arjan
tijms <arjan.tijms@xxxxxxxxx>
To: mojarra
developer discussions <mojarra-dev@xxxxxxxxxxx>
Date: 02/24/2020
09:32
Subject: [EXTERNAL]
Re: [mojarra-dev] [faces-dev] Splitting the API into faces-api?
Sent by: mojarra-dev-bounces@xxxxxxxxxxx
Hi,
It's not a super clean API, but clean enough to compile against. It
can't be actually on the class path.
What happens in the build process is that the full Mojarra jar is generated,
which is then extracted and the API classes are repackaged. Those classes
would not compile on their own, and when put on the class path lead to
linking errors.
It's a quite unfortunate process, but the one we inherited.
Kind regards,
Arjan
On Mon, Feb 24, 2020 at 4:23 PM Kevin Sutter <sutter@xxxxxxxxxx>
wrote:
Hi Arjan,
The current process is to somehow "clean up" these APIs with
code and distribute them as *the* Faces API, correct? This is done
as part of the build process? Or, is it a manual process? I'm
curious how we currently generate a "clean" API for the Faces
component. And, whatever process that is, can it be done in reverse
to add the code back into the API for Mojarra? I know I'm probably
over-simplifying this complicated problem, but it sure would be nice to
make this break.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx
Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: arjan
tijms <arjan.tijms@xxxxxxxxx>
To: faces
developer discussions <faces-dev@xxxxxxxxxxx>
Cc: mojarra
developer discussions <mojarra-dev@xxxxxxxxxxx>
Date: 02/24/2020
09:13
Subject: [EXTERNAL]
Re: [mojarra-dev] [faces-dev] Splitting the API into faces-api?
Sent by: mojarra-dev-bounces@xxxxxxxxxxx
Hi,
It's been long on the list, but not a trivial thing to do. Many API
classes contain large amounts of code (UIData is particularly bad).
We'd need to find a way to re-architect that, presumably with some level
of backward compatibility.
Kind regards,
Arjan
On Mon, Feb 24, 2020 at 4:09 PM Thomas Andraschko <andraschko.thomas@xxxxxxxxx>
wrote:
+1 for doing a "empty" faces-api without method implementations
as they contain many implementation details in both mojarra and myfaces
Am Mo., 24. Feb. 2020 um 15:32 Uhr schrieb Kevin Sutter <sutter@xxxxxxxxxx>:
Hi,
As we look at the work in front of us for Jakarta EE 9, I am wondering
if there is any interest in breaking out the API from Mojarra and putting
it into the Faces project (faces-api repo)? I have no idea how much
work this would entail, but it seems like a good time to do this split.
We have to change the package names for the API anyway (and I doubt you'll
be changing the package names through out the implementation). So,
why not make the split into separate repos? Yes? No?
Reasons?
Thanks!
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx
Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/faces-dev
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/faces-dev_______________________________________________
mojarra-dev mailing list
mojarra-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/mojarra-dev
_______________________________________________
mojarra-dev mailing list
mojarra-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/mojarra-dev_______________________________________________
mojarra-dev mailing list
mojarra-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/mojarra-dev
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/faces-dev
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/faces-dev
_______________________________________________
mojarra-dev mailing list
mojarra-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/mojarra-dev_______________________________________________
mojarra-dev mailing list
mojarra-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/mojarra-dev