Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 330088

Summary: Source features depends on non-referenced fragment
Product: z_Archived Reporter: Thorsten Meinl <thorsten>
Component: BuckminsterAssignee: buckminster.core-inbox <buckminster.core-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: dpochet, rschnekenburger, thomas, trip, vincent.lorenzo
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: All   
Whiteboard:
Attachments:
Description Flags
Zipped projects to reproduce the bug none

Description Thorsten Meinl CLA 2010-11-12 08:54:45 EST 
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.
Comment 1 Thorsten Meinl CLA 2010-11-12 08:55:16 EST 
Created attachment 182991 [details]
Zipped projects to reproduce the bug
Comment 2 Thorsten Meinl CLA 2010-11-12 08:57:13 EST 
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
Comment 3 Thorsten Meinl CLA 2010-11-13 06:47:39 EST 
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.
Comment 4 Remi Schnekenburger CLA 2011-02-04 10:26:59 EST 
(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
Comment 5 David Pochet CLA 2011-02-08 10:51:23 EST 
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)
Comment 6 Terran Gilman CLA 2011-06-12 14:20:48 EDT 
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.
Comment 7 Thomas Hallgren CLA 2012-06-28 08:43:03 EDT 
This is fixed in the Juno release.
Comment 8 Thomas Hallgren CLA 2012-06-28 09:29:56 EDT 
*** Bug 368274 has been marked as a duplicate of this bug. ***