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
