You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Werner Punz <we...@gmail.com> on 2022/09/06 08:13:25 UTC
JSF.js TS
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
Re: JSF.js TS
Posted by Melloware <me...@gmail.com>.
I am looking forward to seeing it!
On 9/9/2022 1:19 PM, Werner Punz wrote:
> 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
> <lo...@apache.org>:
>
> 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
>> <we...@gmail.com>:
>>
>> 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
>> <me...@gmail.com>:
>>
>> 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
>>> <we...@gmail.com>:
>>>
>>> Sounds great I will have a look.
>>>
>>> Thanks for the hint.
>>>
>>> Werner
>>>
>>>
>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware
>>> Inc <me...@gmail.com>:
>>>
>>> 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
>>>> <we...@gmail.com> 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 <an...@gmail.com>:
>>>>
>>>> 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 <we...@gmail.com>:
>>>>
>>>> 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
>>>> <we...@gmail.com>:
>>>>
>>>> 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
>>>>
>>>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
Hi, I checked the integration tests.
I think I will spend an extra time if possible next week to overhaul them.
Following they are based anyway on my github integration tests, but atm do
not work due to dependencies issues.
My github integration tests run fine, but I want to overhaul them as well
to get rid of the last of the old codebase there as well if possible next
week.
So once done with those I will change the codebase in the integration tests
for ajax as well.
For me it is fine for now not to have them working in myfaces, all 136 unit
tests and 19 integration tests I have on github pass atm with a standard
myfaces installation, and tobago works as well with the integrated version.
This is fine enough for me for now.
So I would be ready to commit. The question is I want people in the mailing
list to test the codebase
before we are going with it into the main branch, I do not want to risk to
damage the build process or working projects by sending off such a severe
change into RC4
So how about I push everything into a temporary new branch like
feature/RC4_AJAX or something like it, which we will delete after merge.
That way everyone can test out and review the code, and as soon as the
mailinglist gives the ok, we will merge back into main.
Am Mi., 28. Sept. 2022 um 17:56 Uhr schrieb Werner Punz <
werner.punz@gmail.com>:
> Hi last mail for today on this issue. I have the integration now fully
> running, the last item pending are the Arquilian based integration tests. I
> will check them tomorrow and see whether we still need all of them. We now
> have quite extensive coverage on source level via Mocha based unit tests
> (136 tests so far). If all goes well, I should have a commit ready for
> Friday or Monday.
>
> The question is, the changes are quite extensive.
> I dropped basically the entire old scripts, changed stuff in the resource
> handlers to get el resolution and mapping support in and also changed the
> client build files, adding the Maven client plugin and node with it and a
> new jsdoc generation via webpack.
>
> Shall I commit it once I am ready, or simply drop a patch for now so that
> others can test, before my commit? Also a short lived testing branch would
> be possible. I am open for anything. But given we are already in release
> candidate status for 4.0 I would prefer to have other people testing it on
> in myfaces before doing the final commit in main.
>
>>
>>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
Hi last mail for today on this issue. I have the integration now fully
running, the last item pending are the Arquilian based integration tests. I
will check them tomorrow and see whether we still need all of them. We now
have quite extensive coverage on source level via Mocha based unit tests
(136 tests so far). If all goes well, I should have a commit ready for
Friday or Monday.
The question is, the changes are quite extensive.
I dropped basically the entire old scripts, changed stuff in the resource
handlers to get el resolution and mapping support in and also changed the
client build files, adding the Maven client plugin and node with it and a
new jsdoc generation via webpack.
Shall I commit it once I am ready, or simply drop a patch for now so that
others can test, before my commit? Also a short lived testing branch would
be possible. I am open for anything. But given we are already in release
candidate status for 4.0 I would prefer to have other people testing it on
in myfaces before doing the final commit in main.
>
>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
Never mind, I just found the affecting code, you can mark resources as
having value expressions, which I can do for the jsf.js file. This will
open the door for solution 1 I have proposed, using direct bean calls/aka
value expressions in the js codebase.
Werner
Am Mi., 28. Sept. 2022 um 15:14 Uhr schrieb Werner Punz <
werner.punz@gmail.com>:
> Hi...
>
> Following, I am almost done with the integration on JSF 4.0 level (yes i
> moved the code spec level wise already up, all namespaces are relegated, but
> the codebase still works witzh 2.3, some fallback code was added).
> But when checking the spec I noticed that something was added which did
> not make it into the high level documentation:
> https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.html
>
> a new property was added contextPath which relegates to
> ExternalContext.getRequestContextPath()
> on javascript level, basically similar to the property separatorChar which
> has been in there for ages.
> Now to the problem and where I need feedback
> Up until now this separator char on our side was added as url parameter to
> the jsf.js loading request (code from the new impl)
>
> searchJsfJsFor(/separator=([^&;]*)/).orElse(":")
>
> You get the idea. First of all this code does not seem to work anymore. I
> am not getting this parameter attached anymore.
> But secondly I wonder if there is not a better way to get this in. Given
> this wont be the only call.
> Aka maybe bean resolution on load time on the code by searching for
> #{xxxx} patterns straight in the js source, or template markers which
> replace the template marker with the final result on resource loading level.
>
> Either way I would need a decision on this one and then a little bit of
> help on the java side by either fixing this or implementing one of the 2
> solutions i proposed on code level.
>
> Werner
>
>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
Hi...
Following, I am almost done with the integration on JSF 4.0 level (yes i
moved the code spec level wise already up, all namespaces are relegated, but
the codebase still works witzh 2.3, some fallback code was added).
But when checking the spec I noticed that something was added which did not
make it into the high level documentation:
https://jakarta.ee/specifications/faces/4.0/jsdoc/faces.html
a new property was added contextPath which relegates to
ExternalContext.getRequestContextPath()
on javascript level, basically similar to the property separatorChar which
has been in there for ages.
Now to the problem and where I need feedback
Up until now this separator char on our side was added as url parameter to
the jsf.js loading request (code from the new impl)
searchJsfJsFor(/separator=([^&;]*)/).orElse(":")
You get the idea. First of all this code does not seem to work anymore. I
am not getting this parameter attached anymore.
But secondly I wonder if there is not a better way to get this in. Given
this wont be the only call.
Aka maybe bean resolution on load time on the code by searching for #{xxxx}
patterns straight in the js source, or template markers which replace the
template marker with the final result on resource loading level.
Either way I would need a decision on this one and then a little bit of
help on the java side by either fixing this or implementing one of the 2
solutions i proposed on code level.
Werner
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
Hi small status update, I am almost done with the merge, however given we
are targetting 4.0, I have upgraded the codebase now to Faces 4.0 level.
Which means the entire namespace change has been performed now. The
codebase now has two builds on the github project
a full functionality with jsf now being jakarta in all references and javax
being faces in all references.
The build generates on my github project two files. A jsf.js which has
still 2.3 references aka, jsf being jsf and javax being javax,
and a faces.js file with the new namespaces and references.
I have to adapt however my integration tests now for the 4.0 codebase, (the
2.3 still runs through) but after that I should be ready to finally wrap
things up.
The unit tests already pass the 4.0 codebase. So I do not expect any
pitfalls on the integration tests.
Werner
Am Fr., 23. Sept. 2022 um 14:29 Uhr schrieb Melloware <
mellowaredev@gmail.com>:
> Agreed IE is dead forever :)
>
>
> On 9/23/2022 6:27 AM, Udo Schnurpfeil wrote:
> >
> > Short: no IE11 support
> >
> >
>
Re: JSF.js TS
Posted by Melloware <me...@gmail.com>.
Agreed IE is dead forever :)
On 9/23/2022 6:27 AM, Udo Schnurpfeil wrote:
>
> Short: no IE11 support
>
>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
Great then we can axe ie11 for good for now, I wont test until I really
have the time to do it.
Btw. one feature we have now is that we now have a brotli and gzip build.
As far as I can see atm we do not serve those files upon request. We
probably should add
this feature to our resource loader, given we serve those files from our
jars ourselves.
This reduces the filesize sent over the net significantly and it is a
feature which comes barebones with the browsers with no
extra effort.
100K reduced but raw js compared to 21k brotli.
Mapping file loading already works here locally. I fixed this today.
I can see the ts files and debug into them when I load the final jsf.js
files.
Werner
Am Fr., 23. Sept. 2022 um 12:27 Uhr schrieb Udo Schnurpfeil <
lofwyr@apache.org>:
> Short: no IE11 support
>
> Details:
>
> This jsf.js impl ist only relevant for Tobago 5 and higher.
>
> Since Tobago 5 we use Bootstrap 5. Bootstrap 5 has no support for IE11. =>
> Tobago 5 also has no support for IE11.
>
> Udo
> Am 23.09.22 um 12:10 schrieb Werner Punz:
>
> mhh... I will replace it for now completely which cuts down on the code,
> we still can readd the old codebase with a switch if the need arises, if
> that is ok with everyone.
> I am not just sure wheter the code still works on IE11, have not tested
> the codebase for a long time with it.
> I probably need to run a set of tests to see that. Either way, lets go for
> a full replacement for now, we still can readd it.
> I will run ie11 as baseline tests next week. Also expect my commit/push on
> the myfaces codebase next week.
>
> Re Ie11 Tobago guys, have you run tests regarding it? Or are we going to
> skip this one as baseline?
>
>
> Werner
>
>
> Am Fr., 23. Sept. 2022 um 10:40 Uhr schrieb Thomas Andraschko <
> andraschko.thomas@gmail.com>:
>
>> 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 <
>> lofwyr@apache.org>:
>>
>>> 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 <
>>> werner.punz@gmail.com>:
>>>
>>>> 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 <
>>>> werner.punz@gmail.com>:
>>>>
>>>>> 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 <
>>>>> lofwyr@apache.org>:
>>>>>
>>>>>> 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 <
>>>>>> lofwyr@apache.org>:
>>>>>>
>>>>>>> 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 <
>>>>>>> lofwyr@apache.org>:
>>>>>>>
>>>>>>>> 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 <lo...@apache.org> 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 <
>>>>>>>>> lofwyr@apache.org>:
>>>>>>>>>
>>>>>>>>>> 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 <
>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>>>>>>> mellowaredev@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> 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 <
>>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> Sounds great I will have a look.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for the hint.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Werner
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
>>>>>>>>>>>>> mellowaredev@gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>> werner.punz@gmail.com> 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 <
>>>>>>>>>>>>>> andraschko.thomas@gmail.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
Re: JSF.js TS
Posted by Udo Schnurpfeil <lo...@apache.org>.
Short: no IE11 support
Details:
This jsf.js impl ist only relevant for Tobago 5 and higher.
Since Tobago 5 we use Bootstrap 5. Bootstrap 5 has no support for IE11.
=> Tobago 5 also has no support for IE11.
Udo
Am 23.09.22 um 12:10 schrieb Werner Punz:
> mhh... I will replace it for now completely which cuts down on the
> code, we still can readd the old codebase with a switch if the need
> arises, if that is ok with everyone.
> I am not just sure wheter the code still works on IE11, have not
> tested the codebase for a long time with it.
> I probably need to run a set of tests to see that. Either way, lets go
> for a full replacement for now, we still can readd it.
> I will run ie11 as baseline tests next week. Also expect my
> commit/push on the myfaces codebase next week.
>
> Re Ie11 Tobago guys, have you run tests regarding it? Or are we going
> to skip this one as baseline?
>
>
> Werner
>
>
> Am Fr., 23. Sept. 2022 um 10:40 Uhr schrieb Thomas Andraschko
> <an...@gmail.com>:
>
> 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
> <lo...@apache.org>:
>
> 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
>> <we...@gmail.com>:
>>
>> 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
>> <we...@gmail.com>:
>>
>> 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 <lo...@apache.org>:
>>
>> 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 <lo...@apache.org>:
>>>
>>> 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 <lo...@apache.org>:
>>>>
>>>> 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 <lo...@apache.org>
>>>>> 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
>>>>>> <lo...@apache.org>:
>>>>>>
>>>>>> 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 <we...@gmail.com>:
>>>>>>>
>>>>>>> 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
>>>>>>> <me...@gmail.com>:
>>>>>>>
>>>>>>> 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
>>>>>>>> <we...@gmail.com>:
>>>>>>>>
>>>>>>>> Sounds great I
>>>>>>>> will have a look.
>>>>>>>>
>>>>>>>> Thanks for the
>>>>>>>> hint.
>>>>>>>>
>>>>>>>> Werner
>>>>>>>>
>>>>>>>>
>>>>>>>> Am Di., 6.
>>>>>>>> Sept. 2022 um
>>>>>>>> 11:05 Uhr
>>>>>>>> schrieb
>>>>>>>> Melloware Inc
>>>>>>>> <me...@gmail.com>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>> <we...@gmail.com>
>>>>>>>>> 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
>>>>>>>>> <an...@gmail.com>:
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> <we...@gmail.com>:
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> <we...@gmail.com>:
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
mhh... I will replace it for now completely which cuts down on the code, we
still can readd the old codebase with a switch if the need arises, if that
is ok with everyone.
I am not just sure wheter the code still works on IE11, have not tested the
codebase for a long time with it.
I probably need to run a set of tests to see that. Either way, lets go for
a full replacement for now, we still can readd it.
I will run ie11 as baseline tests next week. Also expect my commit/push on
the myfaces codebase next week.
Re Ie11 Tobago guys, have you run tests regarding it? Or are we going to
skip this one as baseline?
Werner
Am Fr., 23. Sept. 2022 um 10:40 Uhr schrieb Thomas Andraschko <
andraschko.thomas@gmail.com>:
> 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 <
> lofwyr@apache.org>:
>
>> 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 <
>> werner.punz@gmail.com>:
>>
>>> 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 <
>>> werner.punz@gmail.com>:
>>>
>>>> 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 <
>>>> lofwyr@apache.org>:
>>>>
>>>>> 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 <
>>>>> lofwyr@apache.org>:
>>>>>
>>>>>> 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 <
>>>>>> lofwyr@apache.org>:
>>>>>>
>>>>>>> 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 <lo...@apache.org> 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 <
>>>>>>>> lofwyr@apache.org>:
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>
>>>>>>>>>> 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 <
>>>>>>>>>> mellowaredev@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> Sounds great I will have a look.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the hint.
>>>>>>>>>>>>
>>>>>>>>>>>> Werner
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
>>>>>>>>>>>> mellowaredev@gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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 <we...@gmail.com>
>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>> andraschko.thomas@gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
Re: JSF.js TS
Posted by Thomas Andraschko <an...@gmail.com>.
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 <
lofwyr@apache.org>:
> 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 <
> werner.punz@gmail.com>:
>
>> 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 <
>> werner.punz@gmail.com>:
>>
>>> 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 <
>>> lofwyr@apache.org>:
>>>
>>>> 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 <
>>>> lofwyr@apache.org>:
>>>>
>>>>> 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 <
>>>>> lofwyr@apache.org>:
>>>>>
>>>>>> 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 <lo...@apache.org> 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 <
>>>>>>> lofwyr@apache.org>:
>>>>>>>
>>>>>>>> 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 <
>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>> mellowaredev@gmail.com>:
>>>>>>>>>
>>>>>>>>>> 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 <
>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> Sounds great I will have a look.
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the hint.
>>>>>>>>>>>
>>>>>>>>>>> Werner
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
>>>>>>>>>>> mellowaredev@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> 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 <we...@gmail.com>
>>>>>>>>>>>> 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 <
>>>>>>>>>>>> andraschko.thomas@gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
Re: JSF.js TS
Posted by Udo Schnurpfeil <lo...@apache.org>.
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
> <we...@gmail.com>:
>
> 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
> <we...@gmail.com>:
>
> 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
> <lo...@apache.org>:
>
> 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 <lo...@apache.org>:
>>
>> 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 <lo...@apache.org>:
>>>
>>> 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 <lo...@apache.org> 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 <lo...@apache.org>:
>>>>>
>>>>> 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
>>>>>> <we...@gmail.com>:
>>>>>>
>>>>>> 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
>>>>>> <me...@gmail.com>:
>>>>>>
>>>>>> 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 <we...@gmail.com>:
>>>>>>>
>>>>>>> Sounds great I will have
>>>>>>> a look.
>>>>>>>
>>>>>>> Thanks for the hint.
>>>>>>>
>>>>>>> Werner
>>>>>>>
>>>>>>>
>>>>>>> Am Di., 6. Sept. 2022 um
>>>>>>> 11:05 Uhr schrieb
>>>>>>> Melloware Inc
>>>>>>> <me...@gmail.com>:
>>>>>>>
>>>>>>> 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
>>>>>>>> <we...@gmail.com>
>>>>>>>> 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
>>>>>>>> <an...@gmail.com>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>> <we...@gmail.com>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>> <we...@gmail.com>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
Re: JSF.js TS
Posted by Thomas Andraschko <an...@gmail.com>.
I would replace it completely
its still a release candidate, so we have enough time to fix something
Am Fr., 23. Sept. 2022 um 09:56 Uhr schrieb Werner Punz <
werner.punz@gmail.com>:
> 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 <
> werner.punz@gmail.com>:
>
>> 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 <
>> werner.punz@gmail.com>:
>>
>>> 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 <
>>> lofwyr@apache.org>:
>>>
>>>> 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 <
>>>> lofwyr@apache.org>:
>>>>
>>>>> 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 <
>>>>> lofwyr@apache.org>:
>>>>>
>>>>>> 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 <lo...@apache.org> 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 <
>>>>>>> lofwyr@apache.org>:
>>>>>>>
>>>>>>>> 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 <
>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>> mellowaredev@gmail.com>:
>>>>>>>>>
>>>>>>>>>> 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 <
>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> Sounds great I will have a look.
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the hint.
>>>>>>>>>>>
>>>>>>>>>>> Werner
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
>>>>>>>>>>> mellowaredev@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> 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 <we...@gmail.com>
>>>>>>>>>>>> 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 <
>>>>>>>>>>>> andraschko.thomas@gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
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 <
werner.punz@gmail.com>:
> 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 <
> werner.punz@gmail.com>:
>
>> 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 <
>> lofwyr@apache.org>:
>>
>>> 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 <
>>> lofwyr@apache.org>:
>>>
>>>> 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 <
>>>> lofwyr@apache.org>:
>>>>
>>>>> 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 <lo...@apache.org> 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 <
>>>>>> lofwyr@apache.org>:
>>>>>>
>>>>>>> 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 <
>>>>>>> werner.punz@gmail.com>:
>>>>>>>
>>>>>>>> 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 <
>>>>>>>> mellowaredev@gmail.com>:
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>
>>>>>>>>>> Sounds great I will have a look.
>>>>>>>>>>
>>>>>>>>>> Thanks for the hint.
>>>>>>>>>>
>>>>>>>>>> Werner
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
>>>>>>>>>> mellowaredev@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> 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 <we...@gmail.com>
>>>>>>>>>>> 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 <
>>>>>>>>>>> andraschko.thomas@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> 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 <
>>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
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 <
werner.punz@gmail.com>:
> 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 <
> lofwyr@apache.org>:
>
>> 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 <
>> lofwyr@apache.org>:
>>
>>> 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 <
>>> lofwyr@apache.org>:
>>>
>>>> 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 <lo...@apache.org> 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 <
>>>>> lofwyr@apache.org>:
>>>>>
>>>>>> 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 <
>>>>>> werner.punz@gmail.com>:
>>>>>>
>>>>>>> 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 <
>>>>>>> mellowaredev@gmail.com>:
>>>>>>>
>>>>>>>> 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 <
>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>
>>>>>>>>> Sounds great I will have a look.
>>>>>>>>>
>>>>>>>>> Thanks for the hint.
>>>>>>>>>
>>>>>>>>> Werner
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
>>>>>>>>> mellowaredev@gmail.com>:
>>>>>>>>>
>>>>>>>>>> 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 <we...@gmail.com>
>>>>>>>>>> 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 <
>>>>>>>>>> andraschko.thomas@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> 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 <
>>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
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 <
lofwyr@apache.org>:
> 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 <
> lofwyr@apache.org>:
>
>> 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 <
>> lofwyr@apache.org>:
>>
>>> 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 <lo...@apache.org> 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 <
>>>> lofwyr@apache.org>:
>>>>
>>>>> 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 <
>>>>> werner.punz@gmail.com>:
>>>>>
>>>>>> 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 <
>>>>>> mellowaredev@gmail.com>:
>>>>>>
>>>>>>> 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 <
>>>>>>> werner.punz@gmail.com>:
>>>>>>>
>>>>>>>> Sounds great I will have a look.
>>>>>>>>
>>>>>>>> Thanks for the hint.
>>>>>>>>
>>>>>>>> Werner
>>>>>>>>
>>>>>>>>
>>>>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
>>>>>>>> mellowaredev@gmail.com>:
>>>>>>>>
>>>>>>>>> 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 <we...@gmail.com>
>>>>>>>>> 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 <
>>>>>>>>> andraschko.thomas@gmail.com>:
>>>>>>>>>
>>>>>>>>>> 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 <
>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
Re: JSF.js TS
Posted by Udo Schnurpfeil <lo...@apache.org>.
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
> <lo...@apache.org>:
>
> 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
>> <lo...@apache.org>:
>>
>> 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 <lo...@apache.org> 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 <lo...@apache.org>:
>>>>
>>>> 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 <we...@gmail.com>:
>>>>>
>>>>> 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 <me...@gmail.com>:
>>>>>
>>>>> 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 <we...@gmail.com>:
>>>>>>
>>>>>> Sounds great I will have a look.
>>>>>>
>>>>>> Thanks for the hint.
>>>>>>
>>>>>> Werner
>>>>>>
>>>>>>
>>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr
>>>>>> schrieb Melloware Inc
>>>>>> <me...@gmail.com>:
>>>>>>
>>>>>> 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
>>>>>>> <we...@gmail.com> 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
>>>>>>> <an...@gmail.com>:
>>>>>>>
>>>>>>> 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 <we...@gmail.com>:
>>>>>>>
>>>>>>> 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
>>>>>>> <we...@gmail.com>:
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
Re: JSF.js TS
Posted by Thomas Andraschko <an...@gmail.com>.
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 <
lofwyr@apache.org>:
> 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 <
> lofwyr@apache.org>:
>
>> 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 <lo...@apache.org> 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 <
>>> lofwyr@apache.org>:
>>>
>>>> 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 <
>>>> werner.punz@gmail.com>:
>>>>
>>>>> 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 <
>>>>> mellowaredev@gmail.com>:
>>>>>
>>>>>> 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 <
>>>>>> werner.punz@gmail.com>:
>>>>>>
>>>>>>> Sounds great I will have a look.
>>>>>>>
>>>>>>> Thanks for the hint.
>>>>>>>
>>>>>>> Werner
>>>>>>>
>>>>>>>
>>>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
>>>>>>> mellowaredev@gmail.com>:
>>>>>>>
>>>>>>>> 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 <we...@gmail.com>
>>>>>>>> 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 <
>>>>>>>> andraschko.thomas@gmail.com>:
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>
>>>>>>>>>> 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 <
>>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
Re: JSF.js TS
Posted by Udo Schnurpfeil <lo...@apache.org>.
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
> <lo...@apache.org>:
>
> 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 <lo...@apache.org> 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
>>> <lo...@apache.org>:
>>>
>>> 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
>>>> <we...@gmail.com>:
>>>>
>>>> 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 <me...@gmail.com>:
>>>>
>>>> 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 <we...@gmail.com>:
>>>>>
>>>>> Sounds great I will have a look.
>>>>>
>>>>> Thanks for the hint.
>>>>>
>>>>> Werner
>>>>>
>>>>>
>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb
>>>>> Melloware Inc <me...@gmail.com>:
>>>>>
>>>>> 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 <we...@gmail.com> 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
>>>>>> <an...@gmail.com>:
>>>>>>
>>>>>> 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
>>>>>> <we...@gmail.com>:
>>>>>>
>>>>>> 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
>>>>>> <we...@gmail.com>:
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
Re: JSF.js TS
Posted by Thomas Andraschko <an...@gmail.com>.
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 <
lofwyr@apache.org>:
> 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 <lo...@apache.org> 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 <
>> lofwyr@apache.org>:
>>
>>> 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 <
>>> werner.punz@gmail.com>:
>>>
>>>> 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 <
>>>> mellowaredev@gmail.com>:
>>>>
>>>>> 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 <
>>>>> werner.punz@gmail.com>:
>>>>>
>>>>>> Sounds great I will have a look.
>>>>>>
>>>>>> Thanks for the hint.
>>>>>>
>>>>>> Werner
>>>>>>
>>>>>>
>>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
>>>>>> mellowaredev@gmail.com>:
>>>>>>
>>>>>>> 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 <we...@gmail.com>
>>>>>>> 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 <
>>>>>>> andraschko.thomas@gmail.com>:
>>>>>>>
>>>>>>>> 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 <
>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
Re: JSF.js TS
Posted by Udo Schnurpfeil <lo...@apache.org>.
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 <lo...@apache.org> 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
>> <lo...@apache.org>:
>>
>> 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
>>> <we...@gmail.com>:
>>>
>>> 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
>>> <me...@gmail.com>:
>>>
>>> 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 <we...@gmail.com>:
>>>>
>>>> Sounds great I will have a look.
>>>>
>>>> Thanks for the hint.
>>>>
>>>> Werner
>>>>
>>>>
>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb
>>>> Melloware Inc <me...@gmail.com>:
>>>>
>>>> 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
>>>>> <we...@gmail.com> 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
>>>>> <an...@gmail.com>:
>>>>>
>>>>> 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
>>>>> <we...@gmail.com>:
>>>>>
>>>>> 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
>>>>> <we...@gmail.com>:
>>>>>
>>>>> 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
>>>>>
>>>>>
Re: JSF.js TS
Posted by Thomas Andraschko <an...@gmail.com>.
I would only add it in 4.0 (Jakarta), all other branches are stable
Udo Schnurpfeil <lo...@apache.org> 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 <
> lofwyr@apache.org>:
>
>> 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 <
>> werner.punz@gmail.com>:
>>
>>> 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 <
>>> mellowaredev@gmail.com>:
>>>
>>>> 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 <
>>>> werner.punz@gmail.com>:
>>>>
>>>>> Sounds great I will have a look.
>>>>>
>>>>> Thanks for the hint.
>>>>>
>>>>> Werner
>>>>>
>>>>>
>>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
>>>>> mellowaredev@gmail.com>:
>>>>>
>>>>>> 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 <we...@gmail.com>
>>>>>> 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 <
>>>>>> andraschko.thomas@gmail.com>:
>>>>>>
>>>>>>> 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 <
>>>>>>> werner.punz@gmail.com>:
>>>>>>>
>>>>>>>> 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 <
>>>>>>>> werner.punz@gmail.com>:
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
Re: JSF.js TS
Posted by Udo Schnurpfeil <lo...@apache.org>.
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
> <lo...@apache.org>:
>
> 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
>> <we...@gmail.com>:
>>
>> 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
>> <me...@gmail.com>:
>>
>> 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
>>> <we...@gmail.com>:
>>>
>>> Sounds great I will have a look.
>>>
>>> Thanks for the hint.
>>>
>>> Werner
>>>
>>>
>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware
>>> Inc <me...@gmail.com>:
>>>
>>> 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
>>>> <we...@gmail.com> 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 <an...@gmail.com>:
>>>>
>>>> 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 <we...@gmail.com>:
>>>>
>>>> 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
>>>> <we...@gmail.com>:
>>>>
>>>> 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
>>>>
>>>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
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 <
lofwyr@apache.org>:
> 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 <
> werner.punz@gmail.com>:
>
>> 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 <
>> mellowaredev@gmail.com>:
>>
>>> 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 <
>>> werner.punz@gmail.com>:
>>>
>>>> Sounds great I will have a look.
>>>>
>>>> Thanks for the hint.
>>>>
>>>> Werner
>>>>
>>>>
>>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
>>>> mellowaredev@gmail.com>:
>>>>
>>>>> 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 <we...@gmail.com> 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 <
>>>>> andraschko.thomas@gmail.com>:
>>>>>
>>>>>> 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 <
>>>>>> werner.punz@gmail.com>:
>>>>>>
>>>>>>> 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 <
>>>>>>> werner.punz@gmail.com>:
>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
Re: JSF.js TS
Posted by Udo Schnurpfeil <lo...@apache.org>.
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
> <we...@gmail.com>:
>
> 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
> <me...@gmail.com>:
>
> 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
>> <we...@gmail.com>:
>>
>> Sounds great I will have a look.
>>
>> Thanks for the hint.
>>
>> Werner
>>
>>
>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc
>> <me...@gmail.com>:
>>
>> 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
>>> <we...@gmail.com> 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 <an...@gmail.com>:
>>>
>>> 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 <we...@gmail.com>:
>>>
>>> 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 <we...@gmail.com>:
>>>
>>> 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
>>>
>>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
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 <
werner.punz@gmail.com>:
> 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 <
> mellowaredev@gmail.com>:
>
>> 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 <
>> werner.punz@gmail.com>:
>>
>>> Sounds great I will have a look.
>>>
>>> Thanks for the hint.
>>>
>>> Werner
>>>
>>>
>>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
>>> mellowaredev@gmail.com>:
>>>
>>>> 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 <we...@gmail.com> 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 <
>>>> andraschko.thomas@gmail.com>:
>>>>
>>>>> 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 <
>>>>> werner.punz@gmail.com>:
>>>>>
>>>>>> 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 <
>>>>>> werner.punz@gmail.com>:
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
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 <mellowaredev@gmail.com
>:
> 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 <
> werner.punz@gmail.com>:
>
>> Sounds great I will have a look.
>>
>> Thanks for the hint.
>>
>> Werner
>>
>>
>> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
>> mellowaredev@gmail.com>:
>>
>>> 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 <we...@gmail.com> 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 <
>>> andraschko.thomas@gmail.com>:
>>>
>>>> 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 <
>>>> werner.punz@gmail.com>:
>>>>
>>>>> 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 <
>>>>> werner.punz@gmail.com>:
>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
Re: JSF.js TS
Posted by Melloware <me...@gmail.com>.
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
> <we...@gmail.com>:
>
> Sounds great I will have a look.
>
> Thanks for the hint.
>
> Werner
>
>
> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc
> <me...@gmail.com>:
>
> 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
>> <we...@gmail.com> 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
>> <an...@gmail.com>:
>>
>> 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
>> <we...@gmail.com>:
>>
>> 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 <we...@gmail.com>:
>>
>> 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
>>
>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
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 <
werner.punz@gmail.com>:
> Sounds great I will have a look.
>
> Thanks for the hint.
>
> Werner
>
>
> Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
> mellowaredev@gmail.com>:
>
>> 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 <we...@gmail.com> 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 <
>> andraschko.thomas@gmail.com>:
>>
>>> 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 <
>>> werner.punz@gmail.com>:
>>>
>>>> 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 <
>>>> werner.punz@gmail.com>:
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
Sounds great I will have a look.
Thanks for the hint.
Werner
Am Di., 6. Sept. 2022 um 11:05 Uhr schrieb Melloware Inc <
mellowaredev@gmail.com>:
> 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 <we...@gmail.com> 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 <
> andraschko.thomas@gmail.com>:
>
>> 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 <
>> werner.punz@gmail.com>:
>>
>>> 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 <
>>> werner.punz@gmail.com>:
>>>
>>>> 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
>>>>
>>>>
>>>>
Re: JSF.js TS
Posted by Melloware Inc <me...@gmail.com>.
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 <we...@gmail.com> 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 <an...@gmail.com>:
>> 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 <we...@gmail.com>:
>>> 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 <we...@gmail.com>:
>>>> 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
>>>>
>>>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
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 <
andraschko.thomas@gmail.com>:
> 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 <
> werner.punz@gmail.com>:
>
>> 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 <
>> werner.punz@gmail.com>:
>>
>>> 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
>>>
>>>
>>>
Re: JSF.js TS
Posted by Thomas Andraschko <an...@gmail.com>.
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 <
werner.punz@gmail.com>:
> 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 <
> werner.punz@gmail.com>:
>
>> 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
>>
>>
>>
Re: JSF.js TS
Posted by Werner Punz <we...@gmail.com>.
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 <
werner.punz@gmail.com>:
> 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
>
>
>