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

Reply via email to