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
