Should we also merge API+IMPL in 3.x? Pro: 1) less code, less duplicate code 2) no reflection 3) better maintainability
Contra: 1) there is no seperate API jar, with just the javax.faces.* classes -> users could import org.apache.myfaces.* classes What about the contra: 1) we don't care? 2) wait for a flattened API jar from Mojarra 3) create a flattened API (it's quite high effort and requires to keep it sync with the "real" API) (-0.5 from my side as we have to maintain it) 4) create a API jar from the merged API+IMPL jar, which can not be used it as runtime jar as it would throw many NoClassDefFoundErrors Am Do., 10. Jan. 2019 um 13:01 Uhr schrieb Thomas Andraschko < [email protected]>: > Hi, > > it think it's impossible actually. Just have a look how many > implementation details are inside the API. > > Mojarra also merged the API+IMPL in one jar, to avoid duplicate code and > reflection calls from API->IMPL. > Which is good actually. > > I can image something like this: > the javaee-api.jar could contain flatten API classes, without > implementation details. Just the plain API, without actual logic. > user could simply add this as provided dependency. > > The AS (or deployed within the WAR on tomcat e.g.) could dann just add the > 1 myfaces-core.jar. > > Best regards, > Thomas > > > > Am Do., 10. Jan. 2019 um 11:05 Uhr schrieb Dennis Kieselhorst < > [email protected]>: > >> Hi, >> >> yesterday I noticed this issue: >> https://github.com/eclipse-ee4j/mojarra/issues/4480 >> >> Is it that complicated to create an API jar that both works for Mojarra >> and MyFaces? >> >> Regards >> Dennis >> >
