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
<lof...@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.p...@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
<melloware...@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.p...@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 <melloware...@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.p...@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.tho...@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.p...@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.p...@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
