Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 355367 - Locally built artifacts override target platform configuration
Summary: Locally built artifacts override target platform configuration
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Tycho (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P2 normal with 2 votes (vote)
Target Milestone: ---   Edit
Assignee: Jan Sievers CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 378502
  Show dependency tree
 
Reported: 2011-08-22 07:44 EDT by Tobias Oberlies CLA
Modified: 2021-04-28 16:55 EDT (History)
17 users (show)

See Also:


Attachments
proposed patch (issues a warning when IUs are resolved locally) (10.28 KB, patch)
2011-09-02 07:56 EDT, Holger Oehm CLA
t-oberlies: iplog+
Details | Diff
add debug output (5.58 KB, patch)
2011-09-06 04:35 EDT, Holger Oehm CLA
t-oberlies: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Oberlies CLA 2011-08-22 07:44:48 EDT
Although it is a feature that a Tycho build can reference other locally built artifacts (which is for example needed for rebuilds of parts of a reactor), this feature can be very irritating for users who are not aware of it. If someone happens to have built the HEAD version of a project with mvn install, the target platform configuration of downstream projects is effectively overridden because Tycho always allows the access to the locally built version. To make sure that users are aware of this, at least a warning should be issued.

I would propose the following measures to defuse the described situation:
- Print out a warning if there are locally built artifacts/IUs with newer versions compared to the configured target platform. These IUs are likely to be chosen over the versions of the explicitly configured target. If this is possible, the warning could be even more specific and only list the locally built artifacts/IUs that have been chosen for project dependency resolution. The message should explain how to resolve this situation, i.e. refer to
- A new mojo for clearing locally built artifacts (either physically or just logically)
- Print out a debug message with all GAVs/IU Ids of locally built content. This information is important because it can be the reason why certain resolution problems occur only locally.
- I would even go as far as deactivating the "locally built is part of the target platform" feature by default, and only activate it if a system property is set, or if configured in the target-platform-configuration (for people who are keen on the old behaviour). The feature is potentially dangerous, so I would be okay to confirm through something like "-Dtycho.includeLocal" that I want it active.
Comment 1 Igor Fedorenko CLA 2011-08-22 10:13:55 EDT
(In reply to comment #0)
> - I would even go as far as deactivating the "locally built is part of the
> target platform" feature by default, and only activate it if a system property
> is set, or if configured in the target-platform-configuration (for people who
> are keen on the old behaviour). The feature is potentially dangerous, so I
> would be okay to confirm through something like "-Dtycho.includeLocal" that I
> want it active.

-1. There is a lot me to target platform stability. Disabling locally installed artifacts will not make builds much more predictable, but, at the same time, will break useful scenarios like ability to build individual modules of multi-module projects or building with locally patched thirdparty bundles (like I currently do with PDE and P2, for example).
Comment 2 Tobias Oberlies CLA 2011-08-22 10:24:31 EDT
(In reply to comment #1)
> -1. There is a lot me to target platform stability. Disabling locally installed
> artifacts will not make builds much more predictable, but, at the same time,
> will break useful scenarios like ability to build individual modules of
> multi-module projects or building with locally patched thirdparty bundles (like
> I currently do with PDE and P2, for example).

If you want a stable target platform, you should try the slicer mode :-)  And with immutable p2 repositories, the target platform is also always stable. For us, locally built artifacts are the only thing that make it unstable.

Note that the proposal was just to change the default. If you like the current behaviour, you can re-enable it in your project through the target-platform-configuration, and if you only need it temporarily (e.g. for an incremental rebuild), you can switch it on from the target platform.

The use cases you are describing are pretty advanced, and I would rather like to ask power-users to switch on an advanced feature than to ask beginners to switch it off.
Comment 3 Igor Fedorenko CLA 2011-08-22 10:42:09 EDT
Put it for a discussion on tycho-users/tycho-dev. I don't think we'll find a good compromise by talking "my usecases" vs "your usecases" just between two of us.
Comment 4 Holger Oehm CLA 2011-09-02 07:56:52 EDT
Created attachment 202664 [details]
proposed patch (issues a warning when IUs are resolved locally)

The patch issues a warning if IUs have been resolved against the local metadata repository. The warnings (taken from the integration test) look like this:

-----snip----
[WARNING] The following locally built units have been used to resolve project dependencies:
[WARNING]   org.codehaus.tycho.tychoits.tycho0209.build01.bundle03/0.0.1....
[WARNING]   org.codehaus.tycho.tychoits.tycho0209.build01.bundle01/0.0.1....
-----snip----
Comment 5 Holger Oehm CLA 2011-09-06 04:35:18 EDT
Created attachment 202788 [details]
add debug output

second patch (based on the first patch) adds debug message that lists locally available IUs.
The output looks like this (taken from the integration test TYCHO 0209 TychoRepositoryRoundtripTest):
-------snip---------
[DEBUG] The following installable units are available from the local repository:
[DEBUG]   org.eclipse.tycho.p2.tools.impl/0.13.0.201109061025
[DEBUG]   org.codehaus.tycho.tychoits.tycho0209.build01.bundle03/0.0.1.201109060830
[DEBUG]   org.codehaus.tycho.tychoits.tycho0209.build01.feature01.feature.jar/0.0.1.201109060830
[DEBUG]   org.eclipse.tycho.p2.resolver.facade/0.13.0.201109061025
[DEBUG]   org.eclipse.tycho.surefire.junit/0.13.0.201109061027
[DEBUG]   org.eclipse.tycho.p2.tools.tests/0.13.0.201109061025
[DEBUG]   TYCHO0367localRepositoryCrosstalk.bundle02/1.0.0.201109021634
[DEBUG]   org.codehaus.tycho.tychoits.tycho0209.build01.feature01.feature.group/0.0.1.201109060830
[DEBUG]   org.codehaus.tycho.tychoits.tycho0209.build02.bundle02/0.0.1.201109021631
[DEBUG]   org.eclipse.tycho.p2.tools.facade/0.13.0.201109061025
[DEBUG]   feature.feature.group/1.0.0
[DEBUG]   org.codehaus.tycho.tychoits.tycho0209.build01.bundle02/0.0.1.201109060830
[DEBUG]   org.eclipse.tycho.p2.maven.repository/0.13.0.201109061025
[DEBUG]   org.eclipse.tycho.surefire.junit4/0.13.0.201109061027
[DEBUG]   org.eclipse.tycho.p2.resolver.impl/0.13.0.201109061025
[DEBUG]   org.eclipse.tycho.surefire.osgibooter/0.13.0.201109061027
[DEBUG]   org.codehaus.tycho.tychoits.tycho0209.build02.feature01.feature.group/0.0.1.201109021631
[DEBUG]   org.codehaus.tycho.tychoits.tycho0209.build02.feature01.feature.jar/0.0.1.201109021631
[DEBUG]   TYCHO282implicitTestDependencies.bundle/0.0.1.201109021632
[DEBUG]   org.codehaus.tycho.tychoits.tycho0340.plugin/0.0.1.201109060829
[DEBUG]   TYCHO0367localRepositoryCrosstalk.bundle01/1.0.0.201109021634
[DEBUG]   org.codehaus.tycho.tychoits.tycho0340.test/0.0.1.201109060829
[DEBUG]   org.eclipse.tycho.noopsecurity/0.13.0.201109061025
[DEBUG]   feature.feature.jar/1.0.0
[DEBUG]   bundle/1.0.0
[DEBUG]   org.codehaus.tycho.tychoits.tycho0209.build01.bundle01/0.0.1.201109060830
[DEBUG]   org.eclipse.tycho.p2.resolver.impl.test/0.13.0.201109061025
[DEBUG]   org.codehaus.tycho.tychoits.tycho0209.build03.bundle01/0.0.1.201109021631
[DEBUG]   org.eclipse.tycho.p2.maven.repository.tests/0.13.0.201109061025
-------snip---------
Comment 6 Tobias Oberlies CLA 2011-09-06 11:14:44 EDT
I have included both patches in master (with a small change to the debug message) - thank you, Holger.

With this, the first and third proposed enhancements are implemented in 0.13.0. This does at least defuse the problem a bit, so I am reducing the priority to "normal". I would still keep this open, because I would also like the other two points to be discussed & implemented in the next release after 0.13.0.
Comment 7 Steffen Pingel CLA 2011-12-09 13:30:00 EST
If I interpret this correctly, there is no way to ignore the local repository when using an implicit target (at least at this point)?
Comment 8 Tobias Oberlies CLA 2011-12-13 04:51:07 EST
Yes, there is no switch to prevent the usage of locally built artifacts. (And this is independent of whether you use a simple target platform or target files.)
As a workaround, you can delete the file that contains the list of locally built artifacts: ~/.m2/repository/.meta/p2-local-metadata.properties

See also: http://wiki.eclipse.org/Tycho/Target_Platform
Comment 9 Allan CLA 2012-01-04 12:06:25 EST
I didn't see this ticket until now and because I thought this problem would be solved by issue 342808.  I was very surprised to still have this problem after upgrading to 0.13.0.

Yes, please provide a way, e.g. some sort of plugin configuration property to disable using local artifacts when resolving the dependencies.  This has caused quite a bit of grief for me already. Thanks.
Comment 10 Anthony Dahanne CLA 2012-01-06 18:08:13 EST
so if I understand the problem well, since Tycho puts everything in its cache
when resolving, if your feature includes/requires a plugin without version,
then Tycho will choose the latest one, that could be not the one defined in the
target platform (the "override target platform definition") 

as a workaround, one can use a private repo.(to make sure tycho will only
choose the version from the target platform)

instead of trying to segregate IUs from the target platform from the ones from
the cache (I tried this pm and it does not seem to be easy to do) a solution to
this problem would rather be to disable the UpdateLocalIndexMojo goal
update-local-index when building plugins : that way you would make sure that
you won't find your previously built artifacts in the local maven repository.
use this snippet when building your artifacts :
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.eclipse.tycho</groupId>
                    <artifactId>tycho-p2-plugin</artifactId>
                    <version>${tycho-version}</version>
                    <executions>
                        <execution>
                            <id>default-update-local-index</id>
                            <phase>NOOP</phase>
                            <goals>
                                <goal>update-local-index</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </pluginManagement>

but this solution only works for plugins you build; if you use twice the same
repo in different versions (say you use Hudson to build several projects that
do not use the same version of Orbit for example) then Tycho will continue to
always pick the latest versions...
Comment 11 Igor Fedorenko CLA 2012-01-06 19:18:35 EST
@Anthony The behaviour discussed in this enhancement request only applies to locally built artifacts and does not affect artifacts downloaded from remote repositories. If Tycho is "mixing" artifacts downloaded from remote repositories, please open a separate bug report, but make sure to provide complete standalone example and detailed steps to reproduce the problem.
Comment 12 Allan CLA 2012-01-09 11:48:43 EST
@Anthony

That's kind of neat, didn't know you could disable a goal like that.

I ended up using a separate local maven repo for each of my builds.  Annoying yes, but it prevents local artifacts from other builds getting in the way.
Comment 13 Anthony Dahanne CLA 2012-01-09 12:07:00 EST
@Igor : 'If Tycho is "mixing" artifacts downloaded from remote repositories, please open a separate bug report' , I am not sure about this actually, I did not experience it , I just guessed it would (yes, I will come back with an example if I run into this)

@Allan : using a private repo is the safest option, but it is quite sad to give up caching, since it is actually a cool tycho feature
Comment 14 Corneliud Dirmeier CLA 2012-02-07 11:52:10 EST
Would this feature get it into 0.14.0? At the moment we need to build every branch in a private repository, that's not realy nice.

I agree with Tobias that default should be not using the local repository. But you may add a hint to this option in debug output.
Comment 15 Igor Fedorenko CLA 2012-02-07 13:46:32 EST
(In reply to comment #14)
> Would this feature get it into 0.14.0? At the moment we need to build every
> branch in a private repository, that's not realy nice.
> 
> I agree with Tobias that default should be not using the local repository. But
> you may add a hint to this option in debug output.

Use of locally installed artifacts is a Maven feature. If Maven resolves locally installed artifacts by default so will Tycho.
Comment 16 Jan Sievers CLA 2012-02-08 03:10:26 EST
whatever the fix will be, it will not make it into 0.14.0
Comment 17 Tobias Oberlies CLA 2012-05-04 10:38:11 EDT
At EclipseCon Europe, we came to the following agreement about the default: The default should be that locally artifacts are used for resolution, but a warning is printed out. There should be a configuration parameter to explicitly allow local resolution (for people who want to get rid of the warning) or prevent local resolution.
Comment 18 Jan Sievers CLA 2012-08-10 09:56:04 EDT
https://git.eclipse.org/r/#/c/7187/1
Comment 19 Jan Sievers CLA 2012-08-10 10:15:18 EDT
@everyone watching this bug:

let us know if the proposed change
https://git.eclipse.org/r/#/c/7187/1

is going in the right direction.
Comment 20 Igor Fedorenko CLA 2012-08-10 10:32:23 EDT
(In reply to comment #19)
> @everyone watching this bug:
> 
> let us know if the proposed change
> https://git.eclipse.org/r/#/c/7187/1
> 
> is going in the right direction.

no, it does not ;-)
Comment 21 Allan CLA 2012-08-16 14:44:19 EDT
I think the patch is going to fix the problem.
Comment 22 Tobias Oberlies CLA 2012-08-17 11:05:03 EDT
(In reply to comment #19)
> is going in the right direction.

Yes it does, but I also would have expected that it is possible to set the option as target-platform-configuration, so that for example projects that don't like the warning can disable it in their parent POM.
Comment 23 Igor Fedorenko CLA 2012-08-17 14:11:01 EDT
(In reply to comment #22)
> (In reply to comment #19)
> > is going in the right direction.
> 
> Yes it does, but I also would have expected that it is possible to set the
> option as target-platform-configuration, so that for example projects that
> don't like the warning can disable it in their parent POM.

Is it target-platform-configuration or user settings.xml? Somehow this feels like local/user configuration, not somebody project can or should decide for all its adopters.
Comment 24 Jan Sievers CLA 2012-08-20 04:10:52 EDT
(In reply to comment #23)
> Is it target-platform-configuration or user settings.xml? Somehow this feels
> like local/user configuration, not somebody project can or should decide for
> all its adopters.

I agree. This should be local configuration, so it should be possible to set via property on CLI or settings.xml. Will check/adapt the proposal accordingly.
Comment 26 Tobias Oberlies CLA 2012-08-31 09:48:24 EDT
Proposed to call the session property to contol the inclusion of locally built artifacts into the target platform "tycho.includeLocal" (instead of "tycho.considerLocal") [1]

[1] https://git.eclipse.org/r/#/c/7543/
Comment 27 Tobias Oberlies CLA 2012-10-02 12:31:44 EDT
(In reply to comment #26)
> Proposed to call the session property to contol the inclusion of locally built
> artifacts into the target platform "tycho.includeLocal" (instead of
> "tycho.considerLocal") [1]
> 
> [1] https://git.eclipse.org/r/#/c/7543/
Bug 378502 requires more switch options, so we may merge the tycho.considerLocal switch into a single, new switch for both use cases.
Comment 28 Tobias Oberlies CLA 2012-10-11 08:28:58 EDT
Taking bug 378502 into account, I propose to rename the switch to tycho.localArtifacts with the possible values "ignore" and "default" [1]. The latter would be the default and include a warning. I don't have a good name for the former tycho.considerLocal=true (which was "consider local artifacts for dependency resolution and don't issue a warning if they are used") - if someone comes up with a good proposal, I'm happy to re-insert this case. I'd propose to use bug 378502 for this, because this is where we'll add even more options.

[1] https://git.eclipse.org/r/8162
Comment 29 Tobias Oberlies CLA 2012-10-12 03:37:01 EDT
The proposed change is submitted: In order to prevent that locally built artifacts are used in a build, call Maven with the command line option -Dtycho.localArtifacts=ignore. The option may also be set in the settings.xml.
Comment 30 Jan Sievers CLA 2012-10-12 03:39:13 EDT
(In reply to comment #29)
> The proposed change is submitted: In order to prevent that locally built
> artifacts are used in a build, call Maven with the command line option
> -Dtycho.localArtifacts=ignore. The option may also be set in the
> settings.xml.

don't forget to update
http://wiki.eclipse.org/Tycho/Release_Notes/0.16
Comment 31 Tobias Oberlies CLA 2012-10-16 05:37:39 EDT
(In reply to comment #30)
> don't forget to update
> http://wiki.eclipse.org/Tycho/Release_Notes/0.16
Done. Also added a section on local artifacts on the target platform spec page [1]

[1] http://wiki.eclipse.org/Tycho/Target_Platform#Locally_built_artifacts