I think:
for version 4.0: replace it
for version 2.3, 2.3-next, 3.0: it should be configurable - of course
only if it is to be integrated there at all
Udo
Am 23.09.22 um 09:56 schrieb Werner Punz:
Hi I would need an answer, to my original question, now that I have
picked up the work on MyFaces again.
Are we going to completely replace the scripts or at allow some kind
of dual mode where users can switch between old and new
for some period of time?
Werner
Am Do., 22. Sept. 2022 um 12:50 Uhr schrieb Werner Punz
<werner.p...@gmail.com>:
Re Myfaces 2.3, not sure, the idea of the new codebase was to get
a cleaner code and get rid of all this dead old browser legacy
support
which messed up the readability with tons of fallbacks for
everything we did)
So that we can have a cleaner more maintainable codebase to move
forward onwards.
If you want to integrate it into a stable version then I would
make a fork or switch the codebases via context param.
Neither really is a solution. I would recommend for Tobago to
leave it in for now until the baseline is higher than 2.3!
It is the same codebase in the long run anyway.
Am Do., 22. Sept. 2022 um 12:46 Uhr schrieb Werner Punz
<werner.p...@gmail.com>:
Hi sorry for being silent for so long. I was on vacation last
week as announced but I have picked up work again.
Following I was basically spending this week, to fix a ton of
smaller issues I ran along in mona-dish and the typescript
codebase.
Also I did some code improvement in the jsf.js codebase to get
rid of some legacy code which is covered in a better way now
regarding
file inputs.
Also the github project which is my main workbench for the
scripts now integrates the streams and query lib on source
level so that the code maps
are down to the last and only dependency reachable as well.
(see https://github.com/werpu/jsfs_js_ts for the latest
codebase before it makes it into myfaces)
I will now pick up the integration into myfaces again.
Question is:
Do we still want to have the old scripts reachable or not?
If not we can drop a ton of custom code in the resource
loaders, because all the compressed, uncompressed single file
stuff is not needed anymore.
The new implementation can provide sourcemaps, so the users
can always reach the sources for debugging.
A simple development/production flag should be enough to serve
the files mangled or unmangled, subsequent source map requests
done by the browser can do the rest.
Also one advantage of the new codebase is that files with gzip
and brotli compression are generated with the rest of the
build and the server can serve those as well
reducing bandwidth.
Downside is if we do not provide the old scripts then some
legacy browsers won't have a working impl anymore.
Werner
Am Fr., 16. Sept. 2022 um 10:39 Uhr schrieb Udo Schnurpfeil
<lof...@apache.org>:
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 <lof...@apache.org>:
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 <lof...@apache.org>:
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 <lof...@apache.org> 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 <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
