I found an interesting one I wanted the teams thoughts on. I am using
MyFaces with Wildfly and I see this warning message
INFO [org.jboss.weld.Event] (MSC service thread 1-5) WELD-000411:
Observer method [BackedAnnotatedMethod]
Hi just some updates, I have check the integration tests, they do not work
atm infrastructurewise, however
they should work theoretically once the test infrastructure is debugged
(aquilian seems to have some issues atm)
https://issues.apache.org/jira/browse/MYFACES-4473
The thing is, I just ran a
So next steps: While you guys now can review the code and test it.
I will overhaul my internal integration tests to reduce the remnants of the
old framework code and make the code better.
After that I will tackle the internal myfaces js integration tests which
atm are defunct.
For now not having
Thanks, pull request is now in place,
https://github.com/apache/myfaces/pull/325
please review and test!
Werner
Am Do., 29. Sept. 2022 um 13:33 Uhr schrieb Werner Punz <
werner.p...@gmail.com>:
> Yes thats even better.
> I will issue a pull request, I think thats the best idea for now.
> I
Yes thats even better.
I will issue a pull request, I think thats the best idea for now.
I will go this route then.
Werner
Am Do., 29. Sept. 2022 um 13:31 Uhr schrieb Melloware <
melloware...@gmail.com>:
> Yep why not just submit a PR in a feature branch so we can code review
> it on GitHub
Yep why not just submit a PR in a feature branch so we can code review
it on GitHub like a normal PR?
On 9/29/2022 5:57 AM, Werner Punz wrote:
Hi I wrote it before, but in the never ending list of replies it went
under.
I am basically commit-ready for the updated code. I will skip the work
on
Hi I wrote it before, but in the never ending list of replies it went under.
I am basically commit-ready for the updated code. I will skip the work on
the integration tests now
given they do not work atm anyway due to dependency issues and they are
based on my working github ones anyway.
(I will
Hi, I checked the integration tests.
I think I will spend an extra time if possible next week to overhaul them.
Following they are based anyway on my github integration tests, but atm do
not work due to dependencies issues.
My github integration tests run fine, but I want to overhaul them as well
Hi last mail for today on this issue. I have the integration now fully
running, the last item pending are the Arquilian based integration tests. I
will check them tomorrow and see whether we still need all of them. We now
have quite extensive coverage on source level via Mocha based unit tests
Never mind, I just found the affecting code, you can mark resources as
having value expressions, which I can do for the jsf.js file. This will
open the door for solution 1 I have proposed, using direct bean calls/aka
value expressions in the js codebase.
Werner
Am Mi., 28. Sept. 2022 um 15:14
Hi...
Following, I am almost done with the integration on JSF 4.0 level (yes i
moved the code spec level wise already up, all namespaces are relegated, but
the codebase still works witzh 2.3, some fallback code was added).
But when checking the spec I noticed that something was added which did
Hi small status update, I am almost done with the merge, however given we
are targetting 4.0, I have upgraded the codebase now to Faces 4.0 level.
Which means the entire namespace change has been performed now. The
codebase now has two builds on the github project
a full functionality with jsf now
Agreed IE is dead forever :)
On 9/23/2022 6:27 AM, Udo Schnurpfeil wrote:
Short: no IE11 support
Great then we can axe ie11 for good for now, I wont test until I really
have the time to do it.
Btw. one feature we have now is that we now have a brotli and gzip build.
As far as I can see atm we do not serve those files upon request. We
probably should add
this feature to our resource loader,
mhh... I will replace it for now completely which cuts down on the code, we
still can readd the old codebase with a switch if the need arises, if that
is ok with everyone.
I am not just sure wheter the code still works on IE11, have not tested the
codebase for a long time with it.
I probably need
TBH i would not add it in older versions, maybe just 2.3-next
2.3 is stable
3.0 is the exact same codebase as 2.3 and isnt really used in public, 99%
of the people just skip JakartaEE9
Am Fr., 23. Sept. 2022 um 10:35 Uhr schrieb Udo Schnurpfeil <
lof...@apache.org>:
> I think:
>
> for version
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
I would replace it completely
its still a release candidate, so we have enough time to fix something
Am Fr., 23. Sept. 2022 um 09:56 Uhr schrieb Werner Punz <
werner.p...@gmail.com>:
> Hi I would need an answer, to my original question, now that I have picked
> up the work on MyFaces again.
>
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
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.
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
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
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
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
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
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
I would only add it in 4.0 (Jakarta), all other branches are stable
Udo Schnurpfeil 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
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
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
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
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
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
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
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,
Just checked the code, it uses basically the frontend maven plugin,
which is a maven shim over node:
com.github.eirslett
frontend-maven-plugin
1.12.1
v16.13.1
8.1.2
${main.basedir}/target/node
I can go this route, this would be the least painful one because it
basically just downloads node
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
>
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 wrote:
>
>
> Hi there is code reduction going on in the build step anyway, but I also can
> move
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
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.
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
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
41 matches
Mail list logo
