TBH i would not add it in older versions, maybe just 2.3-next 2.3 is stable 3.0 is the exact same codebase as 2.3 and isnt really used in public, 99% of the people just skip JakartaEE9
Am Fr., 23. Sept. 2022 um 10:35 Uhr schrieb Udo Schnurpfeil < [email protected]>: > I think: > > for version 4.0: replace it > > for version 2.3, 2.3-next, 3.0: it should be configurable - of course only > if it is to be integrated there at all > > Udo > Am 23.09.22 um 09:56 schrieb Werner Punz: > > Hi I would need an answer, to my original question, now that I have picked > up the work on MyFaces again. > Are we going to completely replace the scripts or at allow some kind of > dual mode where users can switch between old and new > for some period of time? > > Werner > > > > Am Do., 22. Sept. 2022 um 12:50 Uhr schrieb Werner Punz < > [email protected]>: > >> Re Myfaces 2.3, not sure, the idea of the new codebase was to get a >> cleaner code and get rid of all this dead old browser legacy support >> which messed up the readability with tons of fallbacks for everything we >> did) >> >> So that we can have a cleaner more maintainable codebase to move forward >> onwards. >> If you want to integrate it into a stable version then I would make a >> fork or switch the codebases via context param. >> Neither really is a solution. I would recommend for Tobago to leave it in >> for now until the baseline is higher than 2.3! >> It is the same codebase in the long run anyway. >> >> >> Am Do., 22. Sept. 2022 um 12:46 Uhr schrieb Werner Punz < >> [email protected]>: >> >>> Hi sorry for being silent for so long. I was on vacation last week as >>> announced but I have picked up work again. >>> Following I was basically spending this week, to fix a ton of smaller >>> issues I ran along in mona-dish and the typescript codebase. >>> Also I did some code improvement in the jsf.js codebase to get rid of >>> some legacy code which is covered in a better way now regarding >>> file inputs. >>> Also the github project which is my main workbench for the scripts now >>> integrates the streams and query lib on source level so that the code maps >>> are down to the last and only dependency reachable as well. (see >>> https://github.com/werpu/jsfs_js_ts for the latest codebase before it >>> makes it into myfaces) >>> >>> I will now pick up the integration into myfaces again. >>> Question is: >>> Do we still want to have the old scripts reachable or not? >>> If not we can drop a ton of custom code in the resource loaders, because >>> all the compressed, uncompressed single file stuff is not needed anymore. >>> The new implementation can provide sourcemaps, so the users can always >>> reach the sources for debugging. >>> A simple development/production flag should be enough to serve the files >>> mangled or unmangled, subsequent source map requests done by the browser >>> can do the rest. >>> >>> Also one advantage of the new codebase is that files with gzip and >>> brotli compression are generated with the rest of the build and the server >>> can serve those as well >>> reducing bandwidth. >>> >>> Downside is if we do not provide the old scripts then some legacy >>> browsers won't have a working impl anymore. >>> >>> Werner >>> >>> >>> >>> Am Fr., 16. Sept. 2022 um 10:39 Uhr schrieb Udo Schnurpfeil < >>> [email protected]>: >>> >>>> Tobago 4 works with the jsf.js from MyFaces only with several >>>> modifications. >>>> >>>> Tobago 5 was migrated to use Werner's Typescript implementation. It >>>> works without patches 😁. This version was never released with MyFaces, and >>>> you don't want, because it's stable (I think that is fine). But the >>>> consequence is: there is no MyFaces 2.3 based application server working >>>> with Tobago when we remove the jsf.js from Tobago. >>>> Am 16.09.22 um 10:21 schrieb Thomas Andraschko: >>>> >>>> Isnt that maybe outdated? >>>> the last fixes on our JS was in 2018: >>>> https://github.com/apache/myfaces/commits/2.3.x/api/src/main/javascript/META-INF/resources/myfaces >>>> >>>> Am Fr., 16. Sept. 2022 um 10:18 Uhr schrieb Udo Schnurpfeil < >>>> [email protected]>: >>>> >>>>> The reason is, that problems in the jsf.js often breaks Tobago to be >>>>> unusable, and some application servers tent to need much time to update >>>>> there external libs (e.g. MyFaces) and some users of Tobago need much time >>>>> to update there application servers. I know the solution is not pretty, >>>>> but >>>>> it fixes real world problems. I've spent too much time in the last years >>>>> to >>>>> solve this category of problems, I'm exhausted. >>>>> Am 16.09.22 um 09:57 schrieb Thomas Andraschko: >>>>> >>>>> I always wonder why you need it in tobago? doesnt you just reuse >>>>> jsf.js from the impl? >>>>> >>>>> If we really really really need it, we could create something like a >>>>> myfaces-js repo and create a master and 2.3 branch there + release it in >>>>> NPM. >>>>> >>>>> Otherwise i would just like to have the source in the myfaces-core >>>>> master branch and compile it. Multiple repos always makes everything >>>>> harder >>>>> to release. >>>>> >>>>> Am Fr., 16. Sept. 2022 um 09:30 Uhr schrieb Udo Schnurpfeil < >>>>> [email protected]>: >>>>> >>>>>> It would be nice to have a branch or project where the JSF 2.3 >>>>>> compatible version can live, because we may need it for fixes. >>>>>> >>>>>> Maybe in Werners own project (but its not real community), or in the >>>>>> Tobago project. The disadvantage is, that fixes for both versions affects >>>>>> sources in different projects. It's a bit more error-prone and more >>>>>> work... >>>>>> >>>>>> Maybe we put the built in the branch of MyFaces 2.3 or 3 but do not >>>>>> use it there, only releasing to NPM? This may a bit more transparent. >>>>>> >>>>>> Regards >>>>>> >>>>>> Udo >>>>>> Am 15.09.22 um 17:26 schrieb Thomas Andraschko: >>>>>> >>>>>> I would only add it in 4.0 (Jakarta), all other branches are stable >>>>>> >>>>>> Udo Schnurpfeil <[email protected]> schrieb am Do., 15. Sept. 2022, >>>>>> 16:43: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> in which versions of MyFaces this will be integrated? I think there >>>>>>> is a difference because of the jakarta namespace for the new version. >>>>>>> >>>>>>> In Tobago we integrate the generated js file directly in the npm >>>>>>> build process of Tobago. The JS will be provieded by Tobago, NOT from >>>>>>> the >>>>>>> used JSF implemantation. The reason is old (but might be right today), >>>>>>> some >>>>>>> application servers bring old versions of JSF with them, and the JS was >>>>>>> buggy. >>>>>>> >>>>>>> My question: >>>>>>> >>>>>>> Will it be possible in the future to get the JS via npm in both >>>>>>> versions (namespace javax and namespace jakarta). >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Udo >>>>>>> Am 09.09.22 um 19:19 schrieb Werner Punz: >>>>>>> >>>>>>> Hi I think the build speed does not make a huge difference. >>>>>>> But I think the best option would be to simply make the build >>>>>>> optional and for normal builds just use the js files, which of course >>>>>>> can be comitted together with the ts files. >>>>>>> Theoretically we do not need to rebuild every time, a simple copy of >>>>>>> the javascripts >>>>>>> to the target directory is enough. But a working build must be in >>>>>>> there for verification. >>>>>>> >>>>>>> Timetable, second issue. I thought I could wrap things up this week, >>>>>>> but given I am on vacation next week, it will be probably the week >>>>>>> after. >>>>>>> I have a pretty well working myfaces setup already which however atm >>>>>>> still runs the build every time, but we can move to "optional". >>>>>>> >>>>>>> Atm 3 of my external integration tests fail on extreme corner cases >>>>>>> atm, I have to check why. >>>>>>> So I will need another 2-3 days the week after next to wrap things >>>>>>> up, I guess. >>>>>>> >>>>>>> Werner >>>>>>> >>>>>>> >>>>>>> Am Fr., 9. Sept. 2022 um 12:44 Uhr schrieb Udo Schnurpfeil < >>>>>>> [email protected]>: >>>>>>> >>>>>>>> Hi Werner, >>>>>>>> >>>>>>>> good to hear from you. >>>>>>>> >>>>>>>> About the build process: All the JavaScript code of Tobago was >>>>>>>> migrated to TypeScript and we use the maven-frontend-plugin to compile >>>>>>>> it >>>>>>>> to JavaScript. >>>>>>>> >>>>>>>> Because of the problems you have indicated, we build the TS -> JS >>>>>>>> with Maven profile -Pfrontend to activate the NPM. >>>>>>>> >>>>>>>> We commit the generated code as resources in the project. So, we >>>>>>>> can build with or without regenerating the JavaScript code. >>>>>>>> >>>>>>>> advantage: >>>>>>>> >>>>>>>> - normal build is faster >>>>>>>> - independent from npm infrastructure >>>>>>>> >>>>>>>> disadvantage: >>>>>>>> >>>>>>>> - generated code under source control >>>>>>>> - explicit re-generation is needed, sometimes >>>>>>>> >>>>>>>> What is the best option for MyFaces core? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Udo >>>>>>>> >>>>>>>> >>>>>>>> Am 08.09.22 um 15:55 schrieb Werner Punz: >>>>>>>> >>>>>>>> Sorry for my silence the last few days. >>>>>>>> >>>>>>>> Given my long "hiatus" it took me a little bit to get everything >>>>>>>> together again. >>>>>>>> Following, I think i found a solution I think we can live with >>>>>>>> >>>>>>>> a) The main hosting for now of the scripts and the monadish base >>>>>>>> lib still is on github, but >>>>>>>> b) I basically added s small node project to the api, which pulls >>>>>>>> the npm files from node and extracts the sources and tests and pushes >>>>>>>> them >>>>>>>> into the myfaces source structure, that way we can host the sources on >>>>>>>> the >>>>>>>> myfaces side >>>>>>>> c) You can run then a full build via node and also can run all the >>>>>>>> tests on both projects >>>>>>>> d) The final result is the jsf.js and the jsf-development.js along >>>>>>>> with the corresponding map files and a gz and br compressed version of >>>>>>>> the >>>>>>>> files (for browsers which reques compressed files) >>>>>>>> c and d) will be triggered by the maven frontend plugin which is a >>>>>>>> shim over node (which also does a local download and install of node >>>>>>>> and >>>>>>>> the subproject dependencies) >>>>>>>> >>>>>>>> The end result of the build process is the files at the required >>>>>>>> location and given we now have mapping files we can drop the special >>>>>>>> builds, so the >>>>>>>> resource loader will become smaller. >>>>>>>> The downside is, we now have node as intermediate step for building >>>>>>>> the files and some node dependencies (jsf_ts for loading the sources, >>>>>>>> but >>>>>>>> that is not >>>>>>>> needed given we host them ourselfs, and a ton of dependencies for >>>>>>>> the javascript based unit tests, around mocha) >>>>>>>> >>>>>>>> Unfortunately we cannot skip the entire node embedded into maven >>>>>>>> part.given we want to start from typescript level and want to have unit >>>>>>>> tests on top of it. >>>>>>>> The easier way of course would be just to use the npm packages and >>>>>>>> the final js files, but we want to have the full build cycle. >>>>>>>> >>>>>>>> So there are some dependencies for the build which are outside of >>>>>>>> maven and apache. But normally organisations have an npm proxy >>>>>>>> somewhere, >>>>>>>> so that in case the node infrastructure goes down the build systems >>>>>>>> survive. Does apache have something like this? Myfaces probably is not >>>>>>>> the >>>>>>>> only Apache project >>>>>>>> relying on node/npm infrastructure for their builds. >>>>>>>> >>>>>>>> >>>>>>>> Werner >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Am Di., 6. Sept. 2022 um 14:06 Uhr schrieb Werner Punz < >>>>>>>> [email protected]>: >>>>>>>> >>>>>>>>> Yes i was just worried to drag npm into the build process, but if >>>>>>>>> everyone is fine going with the frontend-plugin i am perfectly fine >>>>>>>>> with >>>>>>>>> it, as well. >>>>>>>>> >>>>>>>>> This is the best way to combine npm and maven builds atm anyway, >>>>>>>>> because it simply relegates whatever npm has to do to npm >>>>>>>>> and maven takes care of the rest. You even can set local proxies >>>>>>>>> and have full control over the npm and node versions that way via >>>>>>>>> maven. >>>>>>>>> >>>>>>>>> Werner >>>>>>>>> >>>>>>>>> >>>>>>>>> Am Di., 6. Sept. 2022 um 14:03 Uhr schrieb Melloware < >>>>>>>>> [email protected]>: >>>>>>>>> >>>>>>>>>> Absolutely this is the way to go. It will download node run your >>>>>>>>>> package.json script to compile the TypeScript code and put it in the >>>>>>>>>> right >>>>>>>>>> location all as part of the Maven Build. >>>>>>>>>> On 9/6/2022 5:46 AM, Werner Punz wrote: >>>>>>>>>> >>>>>>>>>> Just checked the code, it uses basically the frontend maven >>>>>>>>>> plugin, >>>>>>>>>> which is a maven shim over node: >>>>>>>>>> <plugin> >>>>>>>>>> >>>>>>>>>> <groupId>com.github.eirslett</groupId> >>>>>>>>>> >>>>>>>>>> <artifactId>frontend-maven-plugin</artifactId> >>>>>>>>>> >>>>>>>>>> <version>1.12.1</version> >>>>>>>>>> >>>>>>>>>> <configuration> >>>>>>>>>> >>>>>>>>>> <nodeVersion>v16.13.1</nodeVersion> >>>>>>>>>> >>>>>>>>>> <npmVersion>8.1.2</npmVersion> >>>>>>>>>> >>>>>>>>>> <installDirectory>${main.basedir}/target/node</installDirectory> >>>>>>>>>> >>>>>>>>>> </configuration> >>>>>>>>>> >>>>>>>>>> </plugin> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I can go this route, this would be the least painful one because >>>>>>>>>> it basically just downloads node and executes the node build as is, >>>>>>>>>> if this >>>>>>>>>> is ok with the apache build process. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Werner >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Am Di., 6. Sept. 2022 um 11:08 Uhr schrieb Werner Punz < >>>>>>>>>> [email protected]>: >>>>>>>>>> >>>>>>>>>>> Sounds great I will have a look. >>>>>>>>>>> >>>>>>>>>>> Thanks for the hint. >>>>>>>>>>> >>>>>>>>>>> Werner >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc < >>>>>>>>>>> [email protected]>: >>>>>>>>>>> >>>>>>>>>>>> Werner, >>>>>>>>>>>> >>>>>>>>>>>> I can get the code building in maven even if it’s in >>>>>>>>>>>> Typescript. We do something similar in PF extensions. >>>>>>>>>>>> >>>>>>>>>>>> Melloware >>>>>>>>>>>> @melloware on GitHub >>>>>>>>>>>> >>>>>>>>>>>> On Sep 6, 2022, at 4:52 AM, Werner Punz <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi there is code reduction going on in the build step anyway, >>>>>>>>>>>> but I also can move the parts from mona-dish over (which i had in >>>>>>>>>>>> the past) >>>>>>>>>>>> Problem is that we still will be npm dependent for testing libs >>>>>>>>>>>> etc... so i cannot get npm entirely out of the loop for testing >>>>>>>>>>>> purposes >>>>>>>>>>>> shim libraries for testing etc... >>>>>>>>>>>> That means if we move the ts code over we have to introduce an >>>>>>>>>>>> npm build step. >>>>>>>>>>>> >>>>>>>>>>>> I will work on something here and then we can all have a look >>>>>>>>>>>> whether this should be the way to go. >>>>>>>>>>>> >>>>>>>>>>>> Werner >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Am Di., 6. Sept. 2022 um 10:35 Uhr schrieb Thomas Andraschko < >>>>>>>>>>>> [email protected]>: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Werner, >>>>>>>>>>>>> >>>>>>>>>>>>> great to hear that you are back and hope you are fine again :) >>>>>>>>>>>>> >>>>>>>>>>>>> IMO the reimplementation is great and improves the >>>>>>>>>>>>> maintainability a lot for the future. >>>>>>>>>>>>> I would personally only push it in the master (4.0 / >>>>>>>>>>>>> jakarta.*), all other branches are "stable" and we should not >>>>>>>>>>>>> touch them. >>>>>>>>>>>>> >>>>>>>>>>>>> Therefore we are totally fine to only support IE11+. >>>>>>>>>>>>> So it would be great if you can also remove some older IE >>>>>>>>>>>>> hacks like >>>>>>>>>>>>> https://github.com/werpu/jsfs_js_ts/blob/master/src/main/typescript/impl/xhrCore/RequestDataResolver.ts#L113 >>>>>>>>>>>>> >>>>>>>>>>>>> Also it would be great if you can further improve readability. >>>>>>>>>>>>> >>>>>>>>>>>>> For me its absolutely mandatory that all code is directly in >>>>>>>>>>>>> MyFaces and compiles with Maven somehow. >>>>>>>>>>>>> So it would also be great if you could only use a minimal of >>>>>>>>>>>>> your TS mona-dish lib, so we are as clean and minimalistic as >>>>>>>>>>>>> possible. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Thomas >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Am Di., 6. Sept. 2022 um 10:21 Uhr schrieb Werner Punz < >>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>> >>>>>>>>>>>>>> I will add a short summary on what we have: >>>>>>>>>>>>>> >>>>>>>>>>>>>> The project atm is hosted on github and basically 100% my >>>>>>>>>>>>>> code (although split into 2 projects) >>>>>>>>>>>>>> it is 100% implemented in typescript and fortified with a >>>>>>>>>>>>>> ton of unit tests. I have yet given i did not work on it for >>>>>>>>>>>>>> quite some >>>>>>>>>>>>>> time, check the coverage percentage, but it is high. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Downside is, I cut off a ton of old browser support. I think >>>>>>>>>>>>>> IE11 is still supported but nothing below. >>>>>>>>>>>>>> The code is way more readable although some parts still can >>>>>>>>>>>>>> be improved. Maintainability was Prio #1 something the old code >>>>>>>>>>>>>> which had >>>>>>>>>>>>>> to support a ton of legacy browsers did not have. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Downside is, it is 100% typescript, so we need to merge that >>>>>>>>>>>>>> into the myfaces base one way or the other but there is no way >>>>>>>>>>>>>> to avoid an >>>>>>>>>>>>>> npm build step if we drag in the package via npm or on >>>>>>>>>>>>>> typescript level. >>>>>>>>>>>>>> Another option simply would be to fetch the compiled sources >>>>>>>>>>>>>> but that leaves out the connection to the original sources >>>>>>>>>>>>>> entirely (except >>>>>>>>>>>>>> for the sourcemaps), which I would not prefer. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The implementation level is atm jsf 2.x i have to check >>>>>>>>>>>>>> whether we need siginficant extensions for 3 when I stalled my >>>>>>>>>>>>>> work the >>>>>>>>>>>>>> status was the js parts did not change. >>>>>>>>>>>>>> (one thing I have on my plan for the next few days) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Werner >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Am Di., 6. Sept. 2022 um 10:13 Uhr schrieb Werner Punz < >>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Sorry for my long absence. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thing is I had severe health problems last year with a disc >>>>>>>>>>>>>>> prolapse becoming acute, and had a ton of private stuff on my >>>>>>>>>>>>>>> back this >>>>>>>>>>>>>>> year on top of my job. >>>>>>>>>>>>>>> However I have now picked up the work on the JSF,js >>>>>>>>>>>>>>> Typescript again. >>>>>>>>>>>>>>> I have yet to check the latest specs of JSF given i was out >>>>>>>>>>>>>>> of the loop for a year if anything significant needs to be >>>>>>>>>>>>>>> added. >>>>>>>>>>>>>>> The Scripts themselve work and have been in usage in Tobago >>>>>>>>>>>>>>> for quite a while. >>>>>>>>>>>>>>> I am just asking whether we want them to add to myfaces or >>>>>>>>>>>>>>> not. If yes then I would start the work to add them as a build >>>>>>>>>>>>>>> option. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But I want the community decide on this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Lets start a discussion. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Werner >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>
