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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>
