Switch both call sites from dynamic property access to NamedDomainObjectCollection.findByName(), which returns null safely, and fall back to conventional default paths when the java plugin is absent

[venmanyarun]

Fixes #1092

Fix: MissingPropertyException in DevTask when Java plugin is absent (EAR projects)

DevTask.action() and DevTask.getProjectModules() both accessed sourceSets via Groovy dynamic property dispatch (project.sourceSets.main). On projects that don't apply the java plugin — such as a pure EAR module — this property doesn't exist and throws MissingPropertyException at libertyDev startup.

Changes:

• Replace project.sourceSets.main / .test with project.extensions.findByType(SourceSetContainer)?.findByName(...) at both call sites, returning null safely when the java plugin is absent.
• Fall back to conventional Gradle layout paths (src/main/java, build/classes/java/main, etc.) when sourceSets is null, matching what the Java plugin would produce anyway.
• Add integration test TestMultiModuleEarNoJavaPluginDevMode with a multi-module project (ear + war + jar) where the EAR submodule intentionally has no java plugin, reproducing the exact failing scenario.

[cherylking]

Where is the test that uses sourceSets? I looked through all the build.gradle files and did not see it.

[venmanyarun]

Where is the test that uses sourceSets? I looked through all the build.gradle files and did not see it.

The test intentionally has no sourceSets block.
That absence is the test condition — it reproduces the exact user scenario: an EAR project where the java plugin is not applied, so sourceSets does not exist on the project.
Adding a sourceSets block would require applying the java plugin, which would make the bug disappear without the fix and would no longer test anything.

The ear/build.gradle deliberately applies only ear + liberty plugins to prove that DevTask handles a missing SourceSetContainer gracefully. The WAR and JAR submodules in the same test project do apply the java plugin and have valid sourceSets, so both the null path (EAR) and the normal path (WAR/JAR) are exercised within the same test run.

[cherylking]

The end user had a sourceSets block. I get why you have the tests without (to test the null path), but why don't we also have a test with sourceSets. There is a lot of new logic here on how you are retrieving and using the sourceSets.

[venmanyarun]

The end user had a sourceSets block. I get why you have the tests without (to test the null path), but why don't we also have a test with sourceSets. There is a lot of new logic here on how you are retrieving and using the sourceSets.

Tests added for sourceSet based projects for both devMode and deploy