Allow allprojects groups on root artifacts

When verification-metadata.xml belongs to the root project and the root build file declares allprojects { group = 'com.datadoghq' }, projectDir equals ctx.RootDir, so this guard skips the only fallback that can read that group and leaves artifact.Name empty. Gradle allprojects applies to the root project too; only subprojects should be excluded, and the added TestGradleVerificationMetadataExtractor_GetArtifact_InheritsGroupFromRootBuildFile covers this exact scenario and would fail under normal test execution.

Useful? React with 👍 / 👎.

Fixed. Added extractAllProjectsGroupFromRootBuildFile that searches only allprojects { } blocks (not subprojects { }), and updated the root-project path in both parse-gradle-verification-metadata.go and parse-gradle-lock.go to call it when projectDir == absRootDir.

Normalize the root before the subproject guard

Fresh evidence: scanDir still passes the raw scan argument as ScanContext.RootDir, while DepFile.Path() is absolute, so a common scan . invocation makes the root lockfile's projectDir != ctx.RootDir comparison true. In a root build that only has subprojects { group = ... }, this then assigns the subproject-only group to the root artifact, which can make findArtifact classify unrelated external coordinates as internal; normalize ctx.RootDir before this comparison as is already done for filepath.Rel.

Useful? React with 👍 / 👎.

Fixed. Added filepath.Abs normalization of ctx.RootDir before the root-vs-subproject comparison in parse-gradle-lock.go, matching the pattern already used in parseGradleSettingsProjectName.

Ignore nested Gradle task groups

Fresh evidence: although extractBlockGroup now bounds the search to the outer allprojects/subprojects block, this FindSubmatch(blockBody) still scans nested blocks. For allprojects { tasks.register("check") { group = "verification" } group = "com.acme" }, it returns the task group before the project group, so subprojects get coordinates like verification:api and findArtifact can miss or misclassify internal Gradle dependencies.

Useful? React with 👍 / 👎.

Fixed. Added findGroupAtTopLevel which blanks out nested block content (via depth tracking) before applying groupAssignRe, so a task group = "verification" inside a nested block is never captured instead of the real project group.

Use later Gradle group overrides

When a subproject has no local group and the root build file configures both blocks, e.g. allprojects { group = 'com.root' } followed by subprojects { group = 'com.sub' }, the later assignment is the effective group for subprojects. This returns as soon as it finds the first block group, so GetArtifact emits com.root:api instead of com.sub:api, which can make findArtifact miss or misclassify internal Gradle project dependencies; keep scanning and use the last applicable assignment in file order.

Useful? React with 👍 / 👎.

Skip commented Gradle blocks when inheriting groups

When a root build file has an old allprojects/subprojects block commented out after the real one, this scans the raw bytes for block headers and treats the commented block as a later override. For example, a trailing // subprojects { ... group = 'old' ... } makes subprojects without a local group get old:<name>, so findArtifact can miss or misclassify internal Gradle dependencies; strip/ignore comments before looking for inherited group blocks.

Useful? React with 👍 / 👎.

Resolve Gradle metadata from the project root

When the CLI scans a repository root that contains a Gradle build in a subdirectory, ctx.RootDir is the scan root, not the nearest Gradle root. For a layout like repo/service/settings.gradle plus a lockfile under repo/service/api, this reads repo/build.gradle for the inherited group and then looks for repo/settings.gradle, so the service's inherited group and settings name overrides are missed; the artifact name is left empty or falls back to the directory basename, which prevents findArtifact from linking internal Gradle dependencies. Resolve the Gradle root from projectDir/buildFilePath before calling these helpers.

Useful? React with 👍 / 👎.

Valid concern, but out of scope for this PR. Resolving the Gradle root from projectDir requires walking up the directory tree to find the nearest settings.gradle, which is a separate discovery feature. This PR is scoped to improving artifact naming when ctx.RootDir is already the Gradle root (the typical CLI usage).

Preserve URL strings while stripping comments

When an inherited group appears after an inline repository declaration such as repositories { maven { url = uri("https://repo") } }, this treats the // inside the URL string as a comment and blanks the rest of that line, including the closing braces. The brace counter in extractBlockGroup then never reaches the real end of the allprojects/subprojects block, so extractGroupFromRootBuildFile returns empty and subprojects that rely on that group lose their artifact.Name, breaking internal Gradle dependency matching.

Useful? React with 👍 / 👎.

I think this is a legit feedback

Fixed in 01a533c — stripGradleComments now skips over string literals (single and double quoted) before looking for // or /*, so url = uri("https://repo") is left untouched. Added TestStripGradleComments_PreservesURLsInStrings.

could we have some reg101 links here to easy test/confirm matches?

Added regex101 links to all regex declarations in d7d2b46.

apparently the refs can be prefixed with AND without a column, and seem to be valid in both case.

// settings.gradle

// Form 1: with leading colon (handled by PR)
include ':app'

// Form 2: WITHOUT leading colon (silently ignored by PR regex)
include 'communication'

// Form 2 + name override (override still works via separate regex)
include 'lib-core'
project(':lib-core').name = 'comms-core'

see how we have both type of include ':app' and communication, and when I ran the tree, it was correctly parsed:

$ gradle projects

Projects:

------------------------------------------------------------
Root project 'my-renamed-root'
------------------------------------------------------------

Location: ....
Project hierarchy:

Root project 'my-renamed-root'
+--- Project ':app'
+--- Project ':comms-core'
\--- Project ':communication'

so we should likely adjust it for:

and then in parseGradleSettingsProjectName, drop the leading : from gradlePath and normalize the override regex's capture the same way

// Build the Gradle project path WITHOUT the leading ':' so it matches the
// normalized captures from includeRefRe / the trimmed projectNameRe key.
gradlePath := strings.ReplaceAll(filepath.ToSlash(relPath), "/", ":")

Fixed in cc1f37d. Changed includeRefRe to make the leading : optional (consumed outside the capture group). The captured bare path is then normalized with a : prefix before comparing with gradlePath. This handles both include ':app' and include 'app' forms. Added test TestParseGradleSettingsProjectName_IncludeWithoutLeadingColon covering both the colon-less include and the name override case.

it seems that includeRe matches includeBuild (no word boundary after include), so composite-build paths can be treated as subprojects.

include ':app'                  // i assume it should match
include(':app')                // i assume it should match
includeBuild '../lib'          // i assume it should NOT match
includeBuild('../lib')        // i assume it should NOT match
includeFlat 'sibling'        // i assume it should NOT match

Fixed in cc1f37d — added \b word boundary after include in includeRe so includeBuild, includeFlat, etc. no longer match as subproject declarations. Added test TestParseGradleSettingsProjectName_IncludeBuildNotMatchedAsSubproject.

we might have to add something here to strip comments:

content = stripGradleComments(content)

because i'm not fully sure we support cases like those:

Don't we report old-name here?

// settings.gradle

// rootProject.name = 'old-name'
rootProject.name = 'new-name'

Or those, projectNameRe matches inside the block comment. Result: :app resolves to deprecated-name even though the override is commented out.

// settings.gradle

include ':app'
/*
project(':app').name = 'deprecated-name'
*/

or also, block-commented include:

// settings.gradle

/*
include ':removed-module'
*/
include ':app'

Fixed in two commits: 01a533c makes stripGradleComments string-aware (skips string literals so // inside URLs is not treated as a comment delimiter), and 9472cd6 applies the strip at the start of parseGradleSettingsProjectName. Added tests for all three cases: line-commented name, block-commented include, and block-commented name override.

I think this is a legit feedback

this logic seems to be duplicated in parse-gradle-verification-metadata.go should we extract it to a resolveGradleArtifactName(ctx, projectDir, ownGroup) helper

Extracted to resolveGradleArtifactName(ctx, projectDir, buildFileContent) in 8e7aad9. Both GradleLockExtractor.GetArtifact and GradleVerificationMetadataExtractor.GetArtifact now delegate to it.

should we pass the normalized path? absRootDir

Fixed in f7163e5 — extractAllProjectsGroupFromRootBuildFile and extractGroupFromRootBuildFile now receive absRootDir instead of ctx.RootDir. This is also preserved in the extracted resolveGradleArtifactName helper.

Use the last top-level group assignment

When an allprojects/subprojects block assigns group more than once at top level, Gradle leaves the project with the later value, but this FindSubmatch returns the first one from the flattened block. For example, allprojects { group = 'old'; group = 'new' } makes subprojects use new, while the scanner records old:<project>, so internal Gradle dependencies can be missed or matched to the wrong artifact.

Useful? React with 👍 / 👎.