Bug 378502 - Dependency resolver may prefer explicit target platform content over locally built artifacts
Summary: Dependency resolver may prefer explicit target platform content over locally ...
Status: ASSIGNED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Tycho (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P2 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 355367
Blocks:
  Show dependency tree
 
Reported: 2012-05-04 10:53 EDT by Tobias Oberlies CLA
Modified: 2021-04-28 16:54 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Oberlies CLA 2012-05-04 10:53:34 EDT
Tycho (like Maven) supports that locally installed artifacts are used to resolve project dependencies. However, it is not guaranteed that the locally installed artifacts are used for dependency resolution, because the p2 resolver may choose the version from the explicitly configured target platform.

This leads to differences between full and partial reactor builds: in the (full) reactor build, any units built in the reactor take hard precedence over other versions of the same unit from the target platform (through an implicit filter).

We should consider adding the same implicit filter for all units installed in the local Maven repository. Before we do that however, I suppose that we need to make it easier to clear the list of locally installed units (as proposed in bug 355367).
Comment 1 Tobias Oberlies CLA 2012-10-02 12:29:20 EDT
Bug 355367 introduced the -Dtycho.considerLocal={false|warn|true} option.

In order to support partial reactor builds that behave exactly like full builds, we'd need to be able to specify that locally installed artifacts should take precedence over artifacts from the target platform. (Technically, this would be enforced by removing all artifacts with the same ID - just as for artifacts from the reactor.) This new option is not independent of the -Dtycho.considerLocal switch, so we should consider merging them into one.

Just as with considerLocal, the new option would use everything from the local Maven repository. Therefore it should be easier to manipulate the list of "locally installed Tycho artifacts", e.g. through new command line goals for clearing or filtering the .m2/repository/.meta/p2-local-metadata.properties file.

Alternatively, I could also imagine a different option that allows you to say "include locally built artifacts which are from modules aggregated by this POM". In this way, I'd for example say "mvn clean install -f my.submodule/ -Dtycho.virtualReactor=my.parent/" and get exactly the same target platform in my.submodule as if I had built the full my.parent reactor.
Comment 2 Tobias Oberlies CLA 2012-10-11 07:33:22 EDT
I propose to name the new switch "tycho.localArtifacts". For 0.16.0, I will only implement the options to cover the use cases of bug 355367:
* tycho.localArtifacts=ignore with the semantics of tycho.considerLocal=false
* tycho.localArtifacts=default with the semantics of tycho.considerLocal=warn. I explicitly want this case so that the default behaviour can be re-enabled via the command line in case tycho.localArtifacts=ignore is set in the settings.xml

I'll also remove the switch "tycho.considerLocal" now - which means that it won't exist in any released Tycho version.

I am aware that this means that I'll be dropping the option tycho.localArtifacts=true for now. This may be re-added later (but IMHO there isn't enough time until 0.16.0 to agree on a good name for that option). Later, we can also extend tycho.localArtifacts to cover the use case of this bug, e.g. tycho.localArtifacts=force.
Comment 3 Tobias Oberlies CLA 2012-10-12 04:06:49 EDT
(In reply to comment #2)
> I propose to name the new switch "tycho.localArtifacts". For 0.16.0, I will only
> implement the options to cover the use cases of bug 355367:
> * tycho.localArtifacts=ignore with the semantics of tycho.considerLocal=false
> * tycho.localArtifacts=default with the semantics of tycho.considerLocal=warn
This is submitted for 0.16.0 [1]

Returning to inbox - I don't work on the remaining ideas at the moment.

[1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/refs/?id=79e25d479bf96e80402888500be91c6c7276872d
Comment 4 Christoph Laeubrich CLA 2020-07-09 06:45:57 EDT
@Tobias do you still think there is something left here or can we close this bug?
Comment 5 Mickael Istria CLA 2021-04-08 18:05:17 EDT
Eclipse Tycho is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/tycho/issues/ instead. If this issue is relevant to you, your action is required.
0. Verify this issue is still happening with latest Tycho 2.4.0-SNAPSHOT
  if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done
  if issue is still present when latest release:
* Create a new issue at https://github.com/eclipse/tycho/issues/
  ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience)
  ** In the GitHub description, start with a link to this bugzilla ticket
  ** Optionally add new content to the description if it can helps towards resolution
  ** Submit GitHub issue
* Update bugzilla ticket
  ** Add to "See also" property (up right column) the link to the newly created GitHub issue
  ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>"
  ** Set status as CLOSED MOVED
  ** Submit

All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for Tycho will be archived and made read-only.