9:23 a.m.
Currently we have the RichWidgets resources included in RichFaces via a git submodule with
RichWidgets storing it's compiled resources in version control to make them available
for RichFaces. This is less than ideal for two reasons:
1. Storing the compiled resources in the RichWidgets "dist" folder is messy and
leads to lots of merge conflicts and other superfluous commits
2. Having a submodule in RichFaces (slightly) complicates the clone and build process.* It
will likely fail for most people on the first attempt.
* With appropriate error messaging and docs we can however reduce the impact of this (but
still a PITA)
A solution to 1) is to configure maven to build the grunt resources directly. I have
created RF-13123 (https://issues.jboss.org/browse/RF-13123) [A] to address this. As the
first comment in that issue I posted a brief survey of the respective approaches to
building the RichWidget resources. In this thread I would like to discuss an alternate
approach.
Consider if we drop the RichWidgets github sub-module, and instead manually copy the
compiled RichWidgets files directly into the RichFaces repo (storing them there in version
control). This is the same workflow we used in RichFaces 4 for including other
upstream/3rd party javascript resources. Updating the RichWidgets used in RichFaces would
then involve:
1. locally executing the RichWidget grunt build
2. manually copying (rsync) the dist folder into RichFaces
3. committing the updated resources into the RichFaces repo
The advantages of doing this is we keep the RichFaces build to be a "pure java"
maven build, and simplify the clone/build process that may trip up new contributors (see
problem # 2 at the top). One counter-argument to this approach is the introduction of an
additional step (compile and commit) to keep the RichFaces build current. However this is
essentially the same as it is now, since one has to update the submodule and commit the
submodule change to the RichFaces repo.
This approach also has the advantage of being "The Simplest Thing That Could Possibly
Work" [B], and would get us rolling with a workable solution right away. We could
re-visit the problem down the road when the maven/node plugins have matured.
Thoughts?
[A] https://issues.jboss.org/browse/RF-13123
[B] http://xp.c2.com/DoTheSimplestThingThatCouldPossiblyWork.html
Posted by forums
Original post: https://community.jboss.org/message/841394#841394
7:22 a.m.
Even though I would agree with the suggested solution as a temporary workaround,
I wouldn't recommend it for two reasons:
* we are losing fast turnaround (grunt dev / JRebel resource reload)
* we are losing advantage of potential maven/grunt integration which open us possibilities
in form of web-development-world tooling (such as JS compilers)...* that could potentially
replace our solutions which aren't maintained actively (Resource Optimizer)
Just today, I did several changes in a widget in order to improve it for consumption by
JSF bridge code.
I can't imagine I would use copy&paste step you suggested.
----
One solution which would fit proposed solution would be introduction of grunt step which
will copy the resources manually to prepared structure, based on on environment issue,
e.g.:
export
EXTTERNAL_LOCATION=~/richfaces/framework/target/classes/META-INF/resources/richwidgets
grunt dev copy-dist-to-external-location
// once dist/** is updated, it is copied to EXTERNAL_LOCATION, which everyone needs to
setup on its own in order to achieve quick turnaround
Posted by forums
Original post: https://community.jboss.org/message/841588#841588
12:24 p.m.
On 13-10-14 09:22 AM, Lukáš Fryč wrote:
Even though I would agree with the suggested solution as a temporary
workaround,
I wouldn't recommend it for two reasons:
* we are losing fast turnaround (grunt dev / JRebel resource reload)
We have to achieve a balance between rapid-widget-turnaround and
build-complexity. I believe the suggested solution *greatly* simplifies
the build. Rapid trunaround can be maintained with either a local
symlink, or by adding a optional copy task to the grunt watch task.
* we are losing advantage of potential maven/grunt integration which
open us possibilities in form of web-development-world tooling (such as JS compilers)...*
that could potentially replace our solutions which aren't maintained actively
(Resource Optimizer)
Yes, we can re-visit this in the future when both 1) we are ready to
take advantage of such integrations, and 2) when the maven/grunt tooling
is more mature (or we are in a position to actively help develop such
tooling).
Brian
3:27 p.m.
+1 for interim solution
Just note another advantage of maven/grunt integration is leveraging
testing tooling,
e.g. just hit an issue with richfaces.js, I would love to cover it by
tests, but there is nothing who would perform it atm.
~ Lukas
On 10/14/2013 07:24 PM, Brian Leathem wrote:
On 13-10-14 09:22 AM, Lukáš Fryč wrote:
> Even though I would agree with the suggested solution as a temporary workaround,
>
> I wouldn't recommend it for two reasons:
>
> * we are losing fast turnaround (grunt dev / JRebel resource reload)
We have to achieve a balance between rapid-widget-turnaround and
build-complexity. I believe the suggested solution *greatly* simplifies
the build. Rapid trunaround can be maintained with either a local
symlink, or by adding a optional copy task to the grunt watch task.
> * we are losing advantage of potential maven/grunt integration which open us
possibilities in form of web-development-world tooling (such as JS compilers)...* that
could potentially replace our solutions which aren't maintained actively (Resource
Optimizer)
Yes, we can re-visit this in the future when both 1) we are ready to
take advantage of such integrations, and 2) when the maven/grunt tooling
is more mature (or we are in a position to actively help develop such
tooling).
Brian
_______________________________________________
richfaces-dev mailing list
richfaces-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-dev
4:56 p.m.
On Mon 14 Oct 2013 01:27:35 PM PDT, Lukas Fryc wrote:
+1 for interim solution
Just note another advantage of maven/grunt integration is leveraging
testing tooling,
e.g. just hit an issue with richfaces.js, I would love to cover it by
tests, but there is nothing who would perform it atm.
As I come to implement this, I realize the resource copy is not
one-to-one, and benefits from being scripted to stay reproducible. This
naturally made me think of grunt ;)
I propose placing a grunt project in framework/src/js that has
RichWidgets as a bower dependency. We could then create a grunt task to
build RichWidgets and copy the resources into the
framework/src/resources tree. The grunt script could be run whenever we
wanted to update the resources in the framework/src/resources tree.
It's a little bit gross that we would be mixing a non-maven project
within a maven project. However since the alternative is a bash or ant
script to copy the resources the point is moot.
I'll PoC this, and see how it looks.
Brian
4365
days inactive
4369
days old
4 comments
4 participants
participants (4)
-
Brian Leathem -
Lukas Fryc -
Lukáš Fryč -
richfaces-dev＠lists.jboss.org