[richfaces-dev] In search of the best way to include RichWidgets resources in RichFaces
by richfaces-dev＠lists.jboss.org
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
