[MNG-7838] Local repository breaks exec plugin

[jira-importer]

Romain Manni-Bucau opened MNG-7838 and commented

Didn't fully investigate but in a multimodule project with modules A and B and A used in B with exec plugin (exec:java, add project deps =true), doing cd A && mvn install && cd ../B && mvn package exec:java keeps using an outdated version of A whereas it shouldnt.

 

here some logs when replacing second command by one from the root module:

 

[INFO] --- exec:3.0.0:java (generate-model) @ B ---
[WARNING] File 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is more recent than the packaged artifact for 'A', please run a full `mvn package` build
[WARNING] File 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is more recent than the packaged artifact for 'A', please run a full `mvn package` build
[WARNING] File 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is more recent than the packaged artifact for 'A', please run a full `mvn package` build
[INFOS]ㅤGenerated 73 files in /opt/rmannibucau/dev/app/B/target/generated-sources/models (some.xsd)
[INFO]  

---

Affects: 4.0.0-alpha-5

Remote Links:

• GitHub Pull Request #278
  
• GitHub Pull Request #1199
  

Backported to: 4.0.0-beta-4

[jira-importer]

Slawomir Jaranowski commented

exec-m-p in version 3.0.0 use MAT it can have impact on it.

exec-m-p in version 3.1.0 use deprecated {{org.apache.maven.repository.RepositorySystem for resolving artifacts

exec-m-p current snapshot use Resolver Api

[jira-importer]

Slawomir Jaranowski commented

I will try release next version of exec-m-p in next weekend.

[jira-importer]

Guillaume Nodet commented

Fwiw, I'm not sure this is related to exec plugin at all.

[jira-importer]

Romain Manni-Bucau commented

gnodet think I narrowed something which can be half on my side half on maven side: seems I was doing the "installs" in 2 consoles with different env (one with maven 3 and one with maven 4), but wonder if the isPackagedArtifactUpToDate should also check the local m2 (skipping remotes) and not only in project artifacts which are just a partial view of the "up-to-date" state.

[jira-importer]

Guillaume Nodet commented

That would definitely explain the issue I think.
AFAIK, the resolver will handle that local m2 repo if the WorkspaceReader does not find any artifact.

[jira-importer]

Romain Manni-Bucau commented

Issue is when it finds one probably. Guess it can be ok we shouldnt mix version when doing that but we can also take some more time to think if we should enhance the "dirty checking" or not.

[jira-importer]

Guillaume Nodet commented

Yes, but afaik, there's no way to make sure your use a consistent set of artifacts. You could build halt the project locally, switch a branch and build the other half...

[jira-importer]

Romain Manni-Bucau commented

Right but maven set of sources is known (repos), so guess we should check all local ones at least - maybe just all since remote ones will be ignored with the update policy. Don't think it is what we do, we just check the other module target which misses the case I mention. Likely not critical but a bit weird if you get an artifact installed in another way. From my window it looks like maven does not respects maven or that end user must understand the internals, this is why I'm a bit mixed about this issue.