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
