In search of the best way to include RichWidgets resources in RichFaces

[bleathem]

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 [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

[lfryc]

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

[bleathem]

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

[e-mail]

https://lists.jboss.org/mailman/listinfo/richfaces-dev

[lfryc]

+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

[e-mail]

https://lists.jboss.org/mailman/listinfo/richfaces-dev

_______________________________________________

richfaces-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/richfaces-dev

[bleathem]

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

_______________________________________________

richfaces-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/richfaces-dev