In our company, we have large ear files to which developer groups contribute jars. This is a many-to-many relation, where each ear has 30-50 jars and some of the jars are within 10 or more ear files.
We are thinking about introducing more automatic testing to move in the direction of CI. Integration tests usually happen on the ear level, not for individual jars.
So my dilemma is as follows: When a developer checks in code, the CI server builds and unit-tests his jar. Then, there would be the need for integration tests. How should I handle this?
I could build the jar as SNAPSHOT and then trigger a SNAPSHOT build for the ear(s) as well. This is nice and easy, but SNAPSHOT builds are really only for development and should not be promoted to a release stage.
I could construct a minimal test ear for each group of jars. If a jar is built, the test ear dependency list is updated with the newest version number and then built. These tests would be meaningful, but they would not test the "real" ears, just test ears.
I could automatically update dependencies in the real ears, which could confuse people.