Community
Participate
Working Groups
Build Identifier: M20100909-0800 Auto-generated source features depend on fragments of plugins even though the fragments themselves are not included in the (binary) feature. A minimal example (see also attachement): - de.plugin is a normal plugin - de.plugin.fragment is a fragment with de.plugin as its host. It has a platform filter (os=win32). - de.feature.plugin bundles de.plugin only (the fragment will be bundled in a different feature) - de.update contains de.feature.plugin only (no references to the fragment!) Now if you build the update site by invoking the site.p2 action the source feature of de.feature.plugin (de.feature.plugin.source.feature) suddenly has a dependency to the fragment de.plugin.fragment! And the platform filter on the fragment then prevents installation of the source feature. Closing the fragment project prior to building the US works fine. Reproducible: Always Steps to Reproduce: 1. Import the attached projects in your workspace 2. Invoke site.p2 on de.update 3. Try to install the source feature of de.feature.plugin into a non-win32 eclipse installation. 4. In content.xml the de.feature.plugin.source.feature.group entry shows a dependency on de.plugin.fragment although it is not referenced in the binary feature.
Created attachment 182991 [details] Zipped projects to reproduce the bug
Ah, I forgot to mention the version numbers of the Buckminster features I'm using: org.eclipse.buckminster.core.feature_1.3.1.r11579 org.eclipse.buckminster.pde.feature_1.2.1.r11582
Here is an (ugly) workaround for the courageous that works by applying an XSLT to generated content.xml: <xsl:template match="unit[starts-with(@id, 'org.knime') and contains(@id, 'source.feature.group')]/requires"> <xsl:variable name="real-source-entries" select="required[(@namespace = 'org.eclipse.equinox.p2.iu') and contains(@name, '.source')]" /> <requires size="{count($real-source-entries)}"> <xsl:apply-templates select="$real-source-entries" /> </requires> </xsl:template> Taking a quick look at the real cause, the problem seems to be that the "bundle.and.fragments.source"-attribute in the host-plugin picks up the fragment, too. This attribute is later on indirectly used in source-feature generation.
(In reply to comment #3) > Here is an (ugly) workaround for the courageous that works by applying an XSLT > to generated content.xml: > > <xsl:template match="unit[starts-with(@id, 'org.knime') and contains(@id, > 'source.feature.group')]/requires"> > <xsl:variable name="real-source-entries" > select="required[(@namespace = 'org.eclipse.equinox.p2.iu') and > contains(@name, '.source')]" /> > > <requires size="{count($real-source-entries)}"> > <xsl:apply-templates select="$real-source-entries" /> > </requires> > </xsl:template> > > > Taking a quick look at the real cause, the problem seems to be that the > "bundle.and.fragments.source"-attribute in the host-plugin picks up the > fragment, too. This attribute is later on indirectly used in source-feature > generation. Hi, I did have the same problem during Modeling/MDT/Papyrus source generation on the common hudson server using Buckminster. I have developed junit tests fragments for some of my plugins. I retrieved the fragment included in the sdk, whereas the binary feature does not contain them. Do Buckminster propose some control or options over the source generation? Thanks, rémi
Same issue here. With a feature bundling fragments, the generated source feature also includes the fragments, making it impossible to install (no way to install a source feature on Windows while it always requires a Linux fragment)
This bug affects a project I am working on as well. It will also ensure that your repository will never be able to be merged into other repositories through the use of the b3 aggregator as it uses the standard planner as well. I am disabling auto generation of my source bundles as they aren't required for my project but this probably needs a look.
This is fixed in the Juno release.
*** Bug 368274 has been marked as a duplicate of this bug. ***
