4 Replies Latest reply on Oct 15, 2013 5:56 PM by Brian Leathem

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

    Brian Leathem Master

      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

        • 1. Re: In search of the best way to include RichWidgets resources in RichFaces
          Lukáš Fryč Master

          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

          • 2. Re: [richfaces-dev] In search of the best way to include RichWidgets resources in RichFaces
            Brian Leathem Master

            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@lists.jboss.org

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

             

             

            • 3. Re: [richfaces-dev] In search of the best way to include RichWidgets resources in RichFaces
              Lukáš Fryč Master

              +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@lists.jboss.org

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

               

              _______________________________________________

              richfaces-dev mailing list

              richfaces-dev@lists.jboss.org

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

               

               

              • 4. Re: [richfaces-dev] In search of the best way to include RichWidgets resources in RichFaces
                Brian Leathem Master

                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

                richfaces-dev@lists.jboss.org

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