Reusing Fundamental Tests' CI Setup

[lfryc]

Hey guys,

in RichFaces 4.3, we have introduced integration-tests profile which allows to run fundamental tests with different containers and browsers.

Thanks to placing this profile in richfacces-root-parent, we could not only share it with all UI modules (Core, Input, Output, Iteration, ...),

but we was able to potentially share it with any POM which would use richfaces-root-parent as a parent- e.g. Showcase, dev-examples, even Sandbox modules or Metamer.

In RichFaces 5.0, integration-tests profile is placed in richfaces-framework module directly - which basically prevents reusal of continuous integration setup.

Few more thoughts:

• we didn't want to make it reused by Examples
  • SimpleApp, Photoalbum, Quickstarts
  • since they should be "parent-less" (their parent should be just jboss-parent, which does simply plugin management + import richfaces-bom and richfaces-build)
• however all other untrivial examples could reuse this setup
  • showcase, bootstrap-demo, metamer

What are your thoughts about this?

[ppitonak]

Hi Lukas,

• since they should be "parent-less" (their parent should be just jboss-parent, which does simply plugin management + import richfaces-bom and richfaces-build)

examples have to be parent-less, i.e. they have no parent. This applied to Showcase, too. Metamer isn't distributed so we can use whatever makes our work easier.

As I think about it, there is probably no way how not to copy all configuration in examples, is there?

[lfryc]

No, there is no way how to distribute CI setup to parentless examples.

----

The purpose of examples not having parent is afaik:

• having all the necessary project configuration in one place as a reference usage
• and this is not offended by using jboss-parent, which just unifies the necessary setup (distrubution, plugin version management, etc.)

But more importantly, as we have discussed earlier,

• Showcase is not a generic sample for writing RichFaces applications
  • it's so complex that it can't simply serve this task

----

However the Photoalbum application could be potentially used as reference usage example:

• so richfaces-parent couldn't be used here
  • and CI setup would need to be configured just for this example

[lfryc]

I need a decision that we can continue with following setup:

Setup for Framework and other modules

I have managed to generalize the continuous integration setup, which now consits of:

• Maven profiles in richfaces-parent
• arquillian.xml in richfaces-build-resources
  • it is copied over to the destination project and evaluated  as part of the build
• container-specific configuration in richfaces-build-resources (necessary for Tomcats now)

It means that we don't need to copy anything across modules consuming this setup (Framework, Showcase, Metamer, Sandbox modules),

you just need to inherit from richfaces-parent and select particular profile to make everything work:

• in Maven
• in Eclipse/JBDS

I also got rid of richfaces-build, since we can't define versions in richfaces-build (there would be cyclic dependency between richfaces-build and richfaces-parent).

Setup for parentless modules (such as Photoalbum)

If you can't inherit from richfaces-parent (like in a case of examples, e.g. Photoalbum), you need to define continuous integration setup in example itself:

• Maven profiles
• arquillian.xml

Note that

• this setup differts conceptually from setup in richfaces-parent (it is closer to one used in Metamer)
• but the usage is the same - select a profile in IDE or Maven and run the test - tooling will take care of everything else
• the profiles cover just JBoss AS7, TomEE and GlassFish - no Tomcats!
• the setup needs to be kept up to date with rest of the build
  • it's a tax for duplication

----

I will prepare a documents which will document the usage (like fundamental-tests.md).

I will also record an video on how to use the Maven and the IDE to run a test, so everyone involved can learn a reference usage.

Any ideas, objections? Can I continue with the incorporation to the master?

[bleathem]

This is a great start, nice work Lukas!

Getting rid of the richfaces-build BOM by moving the version definition to richfaces-parent means that we will have to duplicate the version information across all projects that don't inherit from richfaces-parent.  Having the version definition specified via the DependencyManagement, and not by the project inheritence was a very nice pattern IMO.

If the profiles do not cover Tomcat 6/7, then how are they configured?  How do we include the extra dependencies required to run in servlet environments?

[lfryc]

Getting rid of the richfaces-build BOM by moving the version definition to richfaces-parent means that we will have to duplicate the version information across all projects that don't inherit from richfaces-parent.  Having the version definition specified via the DependencyManagement, and not by the project inheritence was a very nice pattern IMO.

Nothing has changed - you can just import richfaces-parent to get your dependencies' versions managed, see Photoalbum example.

The thing is that we either

• move all the CI setup and dependency management to richfaces-build
• or we move that into richfaces-parent

Otherwise, we will make both POMs play multiple roles.

If the profiles do not cover Tomcat 6/7, then how are they configured?  How do we include the extra dependencies required to run in servlet environments?

The profiles for Tomcat 6/7 are not defined for parentless modules (e.g. Photoalbum) for several reasons:

• the Photoalbum is an example application and as such it should show the reference usage
  • and as we have agreed earlier we won't make examples unnecessarily complex by targetting servlet containers (such as Tomcats)
  • only official Arquillian extensions are used here
    • the container distribution installation (which is managed by custom Arquillian extension in Framework) is solved here using maven-dependencies-plugin:unpack
    • the Tomcats requires to overwrite configuration, which is another added complexity to the POM

If my assumptions are wrong, we need to re-design this layer.

But the overally simple support for Tomcats is achieved by custom Arquillian extensions, which means that we would need to use them in Photoalbum as well.

[bleathem]

We did a deep dive on this topic in a Google Hangout, here are the results of the discussion:

• The circular dependency between richfaces-and richfaces-build can re alleviated by making richfaces-build parentless
• Keeping the version management out of the parent and in the richfaces-build BOM is a nice spearation of concerns.  We will try to follow this pattern moving forward.
• Developer facng examples should be parentless, this makes it difficult to inherit the required integration test setup definifiton
  • We will keep a simple end-use rconsummable test setup in the examples, separating full RF multi-container integration testing into a separate project called "<example>-ftest"
  • We will try this first with the Photoalbum demo, then look at doing the same to the showcase

Let's carry on this discussion as required in this forum thread.

[lfryc]

I also assume all the goals discussed ^ are targetting 5.0.0.Alpha1.

For the Showcase refactoring, we will open an Enhancement request.