for years we are planning to move the integration tests closer to the actual implementation - esp. for those modules where we have integration tests in separate git repositories, which were stuck with old provision-based sling versions.
i started an attempt for sling models impl and integrated the integration tests from [1] into the impl repository with this PR: https://github.com/apache/sling-org-apache-sling-models-impl/pull/68 the integration tests are running fine, however integrating them comes with a couple of implications: - to my knowledge it's not possible to just integrate the ITs in the bundle maven module, they have to be run from a separate maven module - also, the Its often come with additional test models/classes/bundle which need to be deployed into the sling launcher instance as well, so this needs another maven module - as a result, we need to move the actual impl code to a module, create a maven project hierarchy for the other ones - technically, this is no problem and the released bundle is exactly the same - but the project structure is now more complicated than before. is this the way we want to go? other ideas? personally, i'm fine with this way - but i would focus on those projects where we can eliminate separate integration tests projects. i would not start to move the ITs we currently have as part of our sling starter to all the individual bundles, then we would have to refactor tons of other repositories in this way as well. i also struggled to get the code coverage correct for the integration tests in the single repository. i managed to get the maven/jacoco configuration right so the generated jacoco report contains the correct coverage in the "integration-test" module, but it's not picked up properly in jenkins for sonar checks. this is something we need to look into. WDYT? stefan [1] https://github.com/apache/sling-org-apache-sling-models-integration-tests
