tycho: Provide a way to opt out of the behavior introduced by issue 898, i.e., don't include imports in the p2 repository
Please provide a configuration option to opt out of the new behavior that was introduced by this issue:
https://github.com/eclipse-tycho/tycho/issues/898
The new behavior has already broken EPP’s repository assembly build:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=580592#c3
Note the comment in that bug: I think I am going to stay on older Tycho for the foreseeable future.
I tested 2.7.4 with EMF’s and here too the repository contains more than it has for the past 5 years of using Tycho. E.g., these plugins are now all present and I definitely don’t want to duplicate such content in each EMF repository:
org.antlr.runtime_3.2.0.v20220404-1927.jar
org.apache.ant_1.10.12.v20211102-1452.jar
org.apache.commons.logging_1.2.0.v20180409-1502.jar
org.apache.commons.logging_1.2.0.v20180409-1502.jar.pack.gz
org.apache.log4j_1.2.19.v20220208-1728.jar
org.eclipse.ant.core_3.6.500.v20220718-1722.jar
org.eclipse.compare_3.8.500.v20220812-1406.jar
org.eclipse.core.resources_3.18.0.v20220817-1539.jar
org.eclipse.core.runtime_3.26.0.v20220813-0916.jar
org.eclipse.datatools.connectivity.oda.design.ui_3.4.101.201811012051.jar
org.eclipse.datatools.connectivity.oda_3.6.101.201811012051.jar
org.eclipse.debug.core_3.20.0.v20220811-0741.jar
org.eclipse.jdt.core_3.31.0.v20220822-0619.jar
org.eclipse.jdt.launching_3.19.700.v20220730-1850.jar
org.eclipse.jface.text_3.21.0.v20220817-1340.jar
org.eclipse.rap.ui.views_3.22.0.20220617-1351.jar
org.eclipse.rap.ui.workbench_3.22.0.20220617-1351.jar
org.eclipse.rap.ui_3.22.0.20220617-1351.jar
org.eclipse.text_3.12.200.v20220817-1340.jar
org.eclipse.ui.editors_3.14.400.v20220730-1844.jar
org.eclipse.ui.ide_3.19.100.v20220820-0412.jar
org.eclipse.ui.views_3.11.200.v20220817-1444.jar
org.eclipse.ui.workbench.texteditor_3.16.600.v20220809-1658.jar
org.eclipse.ui.workbench_3.126.0.v20220817-1444.jar
org.eclipse.ui_3.201.0.v20220124-1108.jar
org.eclipse.xtext.builder_2.28.0.v20220801-0623.jar
org.eclipse.xtext.common.types.ui_2.28.0.v20220801-0623.jar
org.eclipse.xtext.common.types_2.28.0.v20220801-0607.jar
org.eclipse.xtext.ui.shared_2.28.0.v20220801-0623.jar
org.eclipse.xtext.ui_2.28.0.v20220801-0623.jar
org.eclipse.xtext.util_2.28.0.v20220801-0559.jar
org.eclipse.xtext.xbase.lib_2.28.0.v20220801-0556.jar
org.eclipse.xtext.xbase.ui_2.28.0.v20220801-0623.jar
org.eclipse.xtext.xbase_2.28.0.v20220801-0607.jar
org.eclipse.xtext_2.28.0.v20220801-0559.jar
Only strictly included plugins (and features) ended up in the repo before but now all imported things end up in the repo as well. Worse still, I see no mechanism to fix this, other than to delete things from the feature.xml. But if I didn’t need or want those imports in the feature.xml they wouldn’t be there there in the first place. So I have lost significant control over what’s in my repository and I need that back. Even this change of behavior as the default new behavior is rather questionable because none of us expect the repository to grow when switching to the latest and greatest Tycho version; many of us would easily fail to notice this change.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 46 (44 by maintainers)
Commits related to this issue
- test for #1281 Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de> — committed to cdietrich/tycho by cdietrich 2 years ago
- test for #1281 Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de> — committed to cdietrich/tycho by cdietrich 2 years ago
- test for #1281 Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de> — committed to cdietrich/tycho by cdietrich 2 years ago
- test for #1281 Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de> — committed to cdietrich/tycho by cdietrich 2 years ago
- test for #1281 Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de> — committed to cdietrich/tycho by cdietrich 2 years ago
- test for #1281 Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de> — committed to cdietrich/tycho by cdietrich 2 years ago
- test for #1281 Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de> — committed to cdietrich/tycho by cdietrich 2 years ago
- test for #1281 Signed-off-by: Christian Dietrich <christian.dietrich@itemis.de> — committed to eclipse-tycho/tycho by cdietrich 2 years ago
- 136: temporarily revert to Tycho 2.7.3 because of https://github.com/eclipse-tycho/tycho/issues/1281 Task-Url: http://github.com/pitest/pitclipse/issues/136 — committed to pitest/pitclipse by LorenzoBettini 2 years ago
- [releng] Revert to Tycho 2.7.1 See https://github.com/eclipse-tycho/tycho/issues/1281 Change-Id: I5d63a10cdcf757970332041582973c2ddc29ad28 Signed-off-by: Pierre-Charles David <pierre-charles.david@o... — committed to pcdavid/org.eclipse.sirius by pcdavid 2 years ago
This change came as a huge surprise to us as well.
We meticulously take care of what features/plugins to
<include>and what features to<require>, in order to control which parts we actually ship and which parts we expect to be already there during install time (or to be fetched from other update sites)!Due to this change, this suddenly changes what we are shipping.
So this is a highly incompatible change for a bugfix release / micro increment of Tycho 2.7.x.
As others have explained, the differentiation between include and require is significant.
To summarize:
I think it’s questionable to talk about ‘right’ versus ‘wrong’, and ‘consistent’ versus ‘inconsistent’ while at the same time arguing that there is no normative definition of the behavior. There is no right or wrong without a definition, there are just opinions about to the long-standing behavior of the last 5 years versus the new behavior you introduced (and I’m not sure anyone actually wants). I wonder, for example, if that new behavior is driven by a concrete use case. E.g., I wonder if there was some update site with specific content you could not achieve without this new behavior; I’m doubtful. It’s certainly the case now that some of us can no longer produce the update site with restricted content that we want, with the specific metadata we want, with the new behavior where required implies inclusion in the site. Note too that having you call the update site with the exact content we want and the exact metadata we want, and always got before now, ‘inconsistent’ because it’s not p2-complete is kind of misguided at best if not downright insulting at worst.
Arguably to include all requirements of all features mentioned in the category.xml but not doing so for all bundles mentioned in the category.xml is also inconsistent behavior, but in the end ‘consistency’ of a site is just not a meaningful concept. Complete versus incomplete is simply not the same as consistent versus inconsistent. Hopefully people don’t have to explain that repeatedly; it has been explained several times now.
Stop and think for a just moment the real semantic/behavior difference between an include versus an import. An include specifies a specific exact version, not a range, and the resulting p2 requirement can only be satisfied by one specific artifact version, often one being built in the current build. If that version of that artifact is not in the assembled into p2 update site, some other very specific update site with exactly that version will need to be composed, available, or referenced when p2 installs from the site. But that’s not true when a version range is specified. In that case there are an unbounded number of different artifacts that will produce a consistent installation.
When I build an update site for EMF’s generator, which produces Java files, it doesn’t make much sense to install that feature if JDT’s feature is not also installed. But that doesn’t mean I want one specific version of JDT in my update site when all versions Helios through today will work nicely. I simply don’t want any version of JDT in my update site. I just want JDT installed when the generator is installed, hence the requirement. But it’s no longer possible to specify this range-based requirement without forcing a specific version to be composed into my update site.
Note that this the third repetition of this explanation. It’s also fully fleshed out here with a feature.xml:
https://github.com/eclipse-tycho/tycho/issues/1281#issuecomment-1223823422