DefaultBuildContext cannot be provisioned outside a Maven session in 1.3.0

[slachiewicz]

DefaultBuildContext gained two constructor dependencies in 1.3.0:

1.2.0  DefaultBuildContext(org.sonatype.plexus.build.incremental.BuildContext)
1.3.0  DefaultBuildContext(org.sonatype.plexus.build.incremental.BuildContext,
                           org.codehaus.plexus.build.connect.BuildConnection,
                           org.apache.maven.plugin.LegacySupport)

org.apache.maven.plugin.LegacySupport is a Maven session component. In a plain sisu container — a unit
test, or any consumer that is not running inside a Maven build — it cannot be provisioned, so sisu injects
null where a BuildContext is expected.

Reproducer

Raising the pin from 1.2.0 to 1.3.0 in modello is enough. Modello Java Plugin then fails 13 of 17 tests,
each with:

com.google.inject.ProvisionException:
1) [Guice/NullInjectedIntoNonNullable]: null returned by binding at LocatorWiring
 but AbstractModelloGenerator.buildContext(AbstractModelloGenerator.java:59) is not @Nullable
  while locating JavaModelloGenerator

The same module is green on 1.2.0 with no other change, so the version bump is the whole difference.

Also changed

1.3.0 ships META-INF/maven/extension.xml, which 1.2.0 did not. Together with the LegacySupport
dependency that moves the artifact from a library any sisu consumer can use towards something that expects
a Maven runtime around it. If that is the intended direction it is worth saying so in the README, since
BuildContext injection outside Maven is what the earlier versions supported.

Possible resolutions

• Make BuildConnection and LegacySupport optional, or the field @Nullable, so DefaultBuildContext
  still provisions without a Maven session — a 1.3.1.
• Keep the behaviour and document it; consumers outside a Maven runtime then stay on 1.2.0 and the change
  is a major rather than a minor.

Raised while bumping the pin across the codehaus-plexus components after the 1.3.0 release. modello stays
on 1.2.0 for now.

This issue was created with AI assistance.

[laeubi]

org.apache.maven.plugin.LegacySupport is a Maven session component. In a plain sisu container — a unit
test, or any consumer that is not running inside a Maven build — it cannot be provisioned, so sisu injects
null where a BuildContext is expected.

For me the main interesting question would be what are those consumers and why they need DefaultBuildContext at all?

From the Readme:

This API allows IDEs to integrate with Maven deeper than it would be possible by just using regular Maven/Mojo API.

So this is explicitly tailored to maven-ide- integration ... so having a non-maven context is not really a goal here at all.

[laeubi]

Modello Java Plugin then fails 13 of 17 tests

For a test setup it is likely the best to override the DefaultBuildContext with a test specific implementation that allows asserting certain thins are actually called what DefaultBuildContext can not offer by purpose, it is targeted to supply a polyfill for maven plugins when running outside an IDE...

[laeubi]

If that is the intended direction it is worth saying so in the README, since BuildContext injection outside Maven is what the earlier versions supported.

I think this statement is much to optimistic. It is the other way round, it was never documented to work outside maven so it was actually undefined behavior (what includes it might has worked by chance before).

[slachiewicz]

Worth recording why modello depends on this at all, because it makes the blast radius wider than a test-only problem.

modello uses BuildContext for exactly what it exists for:

• AbstractModelloGenerator.newWriter() calls getBuildContext().refresh(path.toFile()) whenever a generated file actually changed, so an IDE picks up regenerated sources.
• AbstractModelloGeneratorMojo reports generation failures through addMessage(..., SEVERITY_ERROR, ...), so they surface in the IDE rather than only in the log.

The part that matters here is where the first one lives: modello-core, a library, not the Maven plugin. The field is a plain @Inject private BuildContext buildContext with no null guard, and refresh() is called unconditionally on every changed file. So anything that drives modello-core outside a Maven session — its own unit tests, and any embedder — needs DefaultBuildContext to provision without one. Under 1.3.0 it cannot, because the constructor now requires org.apache.maven.plugin.LegacySupport.

That is the difference between "modello should guard the field" and this being a library-level regression: a consumer of modello-core has no way to supply a LegacySupport outside Maven.

This comment was created with AI assistance.

[laeubi]

So anything that drives modello-core outside a Maven session — its own unit tests, and any embedder — needs DefaultBuildContext to provision without one.

This is wrong, see above. DefaultBuildContext (as implied by its name) is the default implementation (tailored in providing some no-op/sensible defaults during a maven build) but it is not the sole only implementation possible (e.g. m2e as an IDE extension provide an own binding here).

So for the embedded/unit test case modello should provide an own implementation of BuildContext that doe some sensible things in its context (e.g. junit or embedding). It should in no case provide an own LegacySupport implementation as this makes no sense especially as your provided example getBuildContext().refresh(path.toFile()) directly relies on the legacy support, so making it optional would be wrong as it obviously is not. Also the fallback to the legacy API is here likely not desired.