12 Replies Latest reply on Apr 8, 2013 12:08 PM by lfryc

    Switching RichFaces QA to JBoss EAP

    bleathem

      Currently RichFaces tests against JBoss AS 7.1.1.Final.  With JBoss EAP 6.1.0.Alpha1 being available, AS 7.1.1.Final is looking a little long in the tooth.

       

      What are others thoughts on moving QA of RichFaces (not talking about WFK here) to JBoss EAP 6.1.0.Alpha1?

       

      Brian

        • 1. Re: Switching RichFaces QA to JBoss EAP
          ppitonak

          We are ready to start testing on EAP 6.1 but it isn't as easy as with AS 7.1.1 because EAP's binaries aren't in Maven repository.

          • 2. Re: Switching RichFaces QA to JBoss EAP
            lfryc

            What is suggested workaround?

             

            The download-plugin could be used:

            https://github.com/maven-download-plugin/maven-download-plugin

             

            However when you do "clean" step, the downloaded distribution will be deleted.

             

            The solution would be using "download -> install to Maven repository -> unpack" procedure.

            I belive there is a plugin which can do so.

            • 3. Re: Switching RichFaces QA to JBoss EAP
              ppitonak

              We used to use download plugin for Tomcat distributions but it showed to be quite unreliable. Now we just have Tomcat downloaded on the disk and provide Maven a path to Tomcat zip.

               

              Installing zip to local Maven repository would solve it, however you still need to download it somehow so it's basically the same as what we do for Tomcat.

              • 4. Re: Switching RichFaces QA to JBoss EAP
                lfryc

                However this setup needs to be reproducible by anyone, without any assumptions about target environment.

                 

                It means the ZIP distribution needs to be:

                • downloaded
                • cached
                • unpacked

                independently on the user.

                 

                In case of AS 7.1.1.Final, it is all achieved using Maven.

                 

                Question is whether we are able to achieve that with EAP 6.1.0.Alpha1.

                • 5. Re: Switching RichFaces QA to JBoss EAP
                  ppitonak

                  Since EAP 6.1.0.Alpha1 is in Maven repository now, I updated Arquillian profile jbosseap-managed-6-1 and also created Jenkins job for Metamer. Now it works in the same way as job for JBoss AS 7.1.1.Final.

                  • 6. Re: Switching RichFaces QA to JBoss EAP
                    lfryc

                    Pavol, could you please go ahead and define this profile in richfaces5 as well?

                    • 7. Re: Switching RichFaces QA to JBoss EAP
                      ppitonak

                      Hi,

                       

                      sure, I can prepare a new profile. However, a new Maven repository is needed [1]. What is our strategy about Maven repositories? Do we want to put it in pom.xml or in custom settings.xml?

                       

                      [1] http://maven.repository.redhat.com/techpreview/all

                      • 8. Re: Switching RichFaces QA to JBoss EAP
                        lfryc

                        I hesitate to add repositories directly to pom.xml, it's good practice to let user decide from which repository/mirror to obtain artifacts from.

                         

                        We can always provide this settings.xml - there is buildhive-settings.xml which can be renamed and used as the reference for what repositories need people active in order to get RF built successfully.

                        • 9. Re: Switching RichFaces QA to JBoss EAP
                          bleathem

                          We should always prefer putting artifacts in maven central, so that we don't have to specify repositories in our POMs.  However in this case (EAP), the artifacts cannot be published to maven central, so we have a bit of a dilemma.

                           

                          Option 1) Repository in settings.xml

                          With the repository in the settings.xml, the project would be unbuildable without custom configuration.  This problem can be averted if the repository is only required when a particular profile is active.

                           

                          Option 2) Repository in pom.xml

                          With the repository in the pom.xml, the repository information gets propagated to downstream projects (like WFK) and can be a bit of a mess when users want to swap out different repos.  This again can be handled by profiles in the pom, but is much more messy.

                           

                          My vote is for Option 1 (setting.xml) provided we can restrict the requirement of the repository definition in the settings.xml to an optional profile.  We should be able to build the project without this repository.

                           

                          Brian

                          • 10. Re: Switching RichFaces QA to JBoss EAP
                            lfryc

                            Note that not all of our dependencies are in Maven central

                             

                            • in a development time - we depend on snapshots, which are just in JBoss snapshots repo
                            • in a release - e.g. jsf-test is build dependency which is not propagated to Central

                             

                            therefore people who wants to build RichFaces needs to have recommended JBoss repository settings anyway.

                            • 11. Re: Switching RichFaces QA to JBoss EAP
                              bleathem
                              • in development time - we depend on snapshots, which are just in JBoss snapshots repo

                               

                              SNAPSHOT dependencies can be built locally.  We should included instructions on building all SNAPSHOT dependencies.  With the consolidated RichFaces 5 repository this becomes easier, with the CDK being the major SNAPSHOT dependency remaining outside of the richfaces5 repo.

                               

                              • in a release - e.g. jsf-test is build dependency which is not propagated to Central

                               

                               

                              Performing a release is not a typical use case for building RichFaces.  We need to make sure that it is easy to build the RichFaces project after a git clone without a lot of client side steps for the most basic use cases.  Releases and CI can be considered advanced use cases of the build, and are complexity is more tolerable (although still not ideal!). 

                               

                              therefore people who wants to build RichFaces needs to have recommended JBoss repository settings anyway.

                               

                              If we truly need the JBoss SNAPSHOTS repository to be able to do this build, let's consider putting the repository definition in a profile in the pom.  In this way we can tell people to build the profile with the SNAPSHOT repository active.

                               

                              As we make these decisions, let's keep in mind the perspective of those not familiar with the project:

                               

                              "As a potential RichFaces contributor I want to be able to checkout and build the project as easily as possible so I can focus on fixing my issue."

                               

                              Brian

                              • 12. Re: Switching RichFaces QA to JBoss EAP
                                lfryc

                                Brian Leathem wrote:

                                 

                                SNAPSHOT dependencies can be built locally.  We should included instructions on building all SNAPSHOT dependencies.

                                I would really avoid this - these dependencies are build regularly with Jenkins and pushed to the JBoss snapshots repo - no need to document that.

                                \

                                In the release, we need to turn those into released artifacts anyway otherwise we won't meet release staging criteria, so released artifacts doesn't depend on snapshots at all.

                                 

                                 

                                Brian Leathem wrote:

                                 

                                Performing a release is not a typical use case for building RichFaces.  We need to make sure that it is easy to build the RichFaces project after a git clone without a lot of client side steps for the most basic use cases.  Releases and CI can be considered advanced use cases of the build, and are complexity is more tolerable (although still not ideal!).

                                I rather meant "building a release version" - we need to depend on released versions of build dependencies, jsf-test is one of these basic dependencies.

                                 

                                Additionally we can't simply get rif od many dependencies, even though they might not be directly required in basic profile - since they are referenced in build module (various BOMs) or build-resources module (e.g. Arquillian deps), the Maven will need to download them anyway.

                                 

                                 

                                Brian Leathem wrote:

                                 

                                If we truly need the JBoss SNAPSHOTS repository to be able to do this build, let's consider putting the repository definition in a profile in the pom.  In this way we can tell people to build the profile with the SNAPSHOT repository active.

                                 

                                Brian

                                 

                                We can put them into own profile, but it's strongly discouraged to place repositories settings into pom.xml directly - it will break our staging and productization process (both use restricted repository list).

                                 

                                 

                                Brian Leathem wrote:

                                 

                                As we make these decisions, let's keep in mind the perspective of those not familiar with the project:

                                 

                                "As a potential RichFaces contributor I want to be able to checkout and build the project as easily as possible so I can focus on fixing my issue."

                                 

                                 

                                Brian

                                 

                                I can't see anything simpler then:

                                 

                                $ cd richfaces5/
                                $ mvn clean install -s settings.xml
                                

                                 

                                It's imho better than referencing to JBoss Maven Getting Started.