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