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

Reply via email to