Files
sbt/notes/2.0.0/patterns-maven-compatible-default.md
T
Jozef Koval 73d164fa84 [2.x] fix: Substitute [organisation] literally by defaulting Patterns.isMavenCompatible to false (#9344)
**Problem**

In an Ivy resolver pattern, the [organisation]/[organization] token has its dots rewritten to slashes (org.example → org/example), behaving like Ivy's [orgPath] token rather than being literal. Per the [Apache Ivy spec](http://ant.apache.org/ivy/history/latest-milestone/concept.html), [organisation] should be substituted literally and [orgPath] is the slash-separated form.

Root cause: Patterns.isMavenCompatible defaulted to true, which sbt forwards to Apache Ivy as setM2compatible(true); with m2-compatibility on, Ivy rewrites the [organisation] token to slash form. A user supplying a custom Ivy pattern (e.g. for an SFTP/SSH resolver) inherited that default and got the wrong paths, with no obvious indication why. The only workaround was the non-obvious withIsMavenCompatible(false).

**Solution**

Flip the default of Patterns.isMavenCompatible from true to false, so a hand-written Patterns keeps [organisation] literal by default — matching the Ivy spec.
2026-06-15 23:54:28 -04:00

1.9 KiB

Patterns.isMavenCompatible now defaults to false

The default value of Patterns.isMavenCompatible changed from true to false so that the [organisation]/[organization] token in an Ivy pattern is substituted literally, matching the Apache Ivy specification (see #535).

What changed

// before: organization "org.example" rendered as "org/example"
// now:     organization "org.example" rendered as "org.example"
val p = Patterns()
  .withIvyPatterns(Vector("[organisation]/[module]/ivys/ivy-[revision].xml"))
  .withArtifactPatterns(Vector("[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"))

Use the [orgPath] token if you want the slash-separated form regardless of the flag, or set isMavenCompatible = true explicitly to opt back into the previous Maven m2-compatible behavior:

Patterns(/* ... */).withIsMavenCompatible(true)

Who is affected

  • Custom Ivy/SFTP/SSH/URL/file resolvers built with a hand-written Patterns that uses the [organisation] token and previously relied on the implicit dot-to-slash rewrite.
    • Under the Ivy engine, the organization is now rendered literally for these patterns.
    • Under Coursier (the default since sbt 1.3), SFTP/SSH resolvers are ignored entirely, so they are unaffected. Custom URL/file pattern resolvers, however, can still be affected: Coursier chooses between Maven-base extraction and Ivy-pattern parsing based on isMavenCompatible, so a resolver that relied on the old true default may now be parsed as an Ivy-pattern repository. Set isMavenCompatible = true explicitly to keep the Maven handling.
  • The built-in Resolver.mavenStylePatterns is unchanged: it remains explicitly isMavenCompatible = true, so Resolver.url/Resolver.file/Resolver.sftp/Resolver.ssh constructed with the default patterns continue to use the Maven layout.