Fix update-site: Xpect IU's needs to use a range with upper bounds set for required sibling IU's.

[torstenkraemer]

After the release of Xpect 0.2.0 the resolution of org.xpect.xtext.lib 0.1.0.201609091551 pulls in jars from the 0.2.0 release.

[INFO] Resolving dependencies of MavenProject: eu.numberfour.n4js:eu.numberfour.n4js.xpect.ui:0.0.1-SNAPSHOT @ /var/lib/build/workspace/N4JS-PUBLIC_II/n4js/plugins/eu.numberfour.n4js.xpect.ui/pom.xml
[INFO] Fetching org.xpect.xtext.lib_0.1.0.201609091551.jar from http://www.xpect-tests.org/updatesite/nightly/local/plugins/ (0B of 127.3kB at 0B/s)
[INFO] Fetching org.junit_4.12.0.v201504281640.jar.pack.gz from http://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/eclipse/updates/4.6/R-4.6-201606061100/plugins/ (0B of 283.72kB at 0B/s)
[INFO] Fetching org.hamcrest.core_1.3.0.v201303031735.jar.pack.gz from http://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/eclipse/updates/4.6/R-4.6-201606061100/plugins/ (0B of 19.33kB at 0B/s)
[INFO] Fetching org.xpect_0.2.0.201611170958.jar from http://www.xpect-tests.org/updatesite/nightly/local/plugins/ (0B of 551.77kB at 0B/s)
[INFO] Fetching org.xpect.ui_0.2.0.201611170958.jar from http://www.xpect-tests.org/updatesite/nightly/local/plugins/ (0B of 178.07kB at 0B/s)
[INFO] Resolving class path of MavenProject: eu.numberfour.n4js:eu.numberfour.n4js.xpect.ui:0.0.1-SNAPSHOT @ /var/lib/build/workspace/N4JS-PUBLIC_II/n4js/plugins/eu.numberfour.n4js.xpect.ui/pom.xml

The target-platform looks like that:
https://github.com/NumberFour/n4js/blob/master/releng/eu.numberfour.n4js.targetplatform/eu.numberfour.n4js.targetplatform.target#L73

<location includeAllPlatforms="false" includeConfigurePhase="true" includeMode="planner" includeSource="true" type="InstallableUnit">
      <unit id="org.xpect.xtext.lib" version="0.1.0.201609091551"/>
      <repository location="http://www.xpect-tests.org/updatesite/nightly/"/>
</location>

The IU loaded org.xpect.xtext.lib 0.1.0.201609091551 has a requirement:

      <required namespace='osgi.bundle' name='org.xpect' range='0.1.0'/>
      <required namespace='osgi.bundle' name='org.xpect.ui' range='0.1.0'/>

To stay within the 0.1.0 release this should be something like:

      <required namespace='osgi.bundle' name='org.xpect' range='[0.1.0,0.2.0)'/>
      <required namespace='osgi.bundle' name='org.xpect.ui' range='[0.1.0,0.2.0)'/>

As a reference, the full description of the IU for org.xpect.xtext.lib 0.1.0.201609091551 is:

<?xml version='1.0' encoding='UTF-8'?>
<units size='1'>
  <unit id='org.xpect.xtext.lib' version='0.1.0.201609091551' singleton='false'>
    <update id='org.xpect.xtext.lib' range='[0.0.0,0.1.0.201609091551)' severity='0'/>
    <properties size='5'>
      <property name='org.eclipse.equinox.p2.name' value='Lib'/>
      <property name='org.eclipse.equinox.p2.provider' value='itemis AG'/>
      <property name='maven-groupId' value='org.xpect'/>
      <property name='maven-artifactId' value='org.xpect.xtext.lib'/>
      <property name='maven-version' value='0.1.0-SNAPSHOT'/>
    </properties>
    <provides size='9'>
      <provided namespace='org.eclipse.equinox.p2.iu' name='org.xpect.xtext.lib' version='0.1.0.201609091551'/>
      <provided namespace='osgi.bundle' name='org.xpect.xtext.lib' version='0.1.0.201609091551'/>
      <provided namespace='java.package' name='org.xpect.xtext.lib.setup' version='0.0.0'/>
      <provided namespace='java.package' name='org.xpect.xtext.lib.setup.emf' version='0.0.0'/>
      <provided namespace='java.package' name='org.xpect.xtext.lib.setup.generic' version='0.0.0'/>
      <provided namespace='java.package' name='org.xpect.xtext.lib.setup.workspace' version='0.0.0'/>
      <provided namespace='java.package' name='org.xpect.xtext.lib.tests' version='0.0.0'/>
      <provided namespace='java.package' name='org.xpect.xtext.lib.util' version='0.0.0'/>
      <provided namespace='org.eclipse.equinox.p2.eclipse.type' name='bundle' version='1.0.0'/>
    </provides>
    <requires size='8'>
      <required namespace='osgi.bundle' name='org.eclipse.core.runtime' range='3.7.0'/>
      <required namespace='osgi.bundle' name='org.eclipse.core.resources' range='3.7.0'/>
      <required namespace='osgi.bundle' name='org.eclipse.xtext.xbase' range='2.4.0'/>
      <required namespace='osgi.bundle' name='org.xpect' range='0.1.0'/>
      <required namespace='osgi.bundle' name='org.xpect.ui' range='0.1.0'/>
      <required namespace='osgi.bundle' name='org.eclipse.xtext.ui' range='2.4.0'/>
      <required namespace='osgi.bundle' name='org.eclipse.jdt.core' range='3.7.0'/>
      <required namespace='osgi.bundle' name='org.eclipse.ui.ide' range='3.7.0'/>
    </requires>
    <artifacts size='1'>
      <artifact classifier='osgi.bundle' id='org.xpect.xtext.lib' version='0.1.0.201609091551'/>
    </artifacts>
    <touchpoint id='org.eclipse.equinox.p2.osgi' version='1.0.0'/>
    <touchpointData size='1'>
      <instructions size='1'>
        <instruction key='manifest'>
          Bundle-SymbolicName: org.xpect.xtext.lib&#xA;Bundle-Version: 0.1.0.201609091551
        </instruction>
      </instructions>
    </touchpointData>
  </unit>
</units>

[meysholdt]

thanks for analysis and report! I'll create a new release with having this fixed.

[meysholdt]

I've fixed the issue and published maintenance-release 0.1.0.201611181623.

However, that doesn't get to the bottom of the problem because in your case your may still get bundles with mixed version-qualifiers pulled in.

A better solution would be to have an Eclipse Feature that you can reference in your target platform definition.

[torstenkraemer]

@meysholdt can you elaborate a little bit more why this still could happen?

Providing an installable feature may help, but remember I'm not directly in control of the target-file. It is generated by Oomph during the provision phase. We do not edit this file (and also don't want to).

[meysholdt]

I changed it to

<required namespace='osgi.bundle' name='org.xpect' range='[0.1.0,0.2.0)'/>

as you suggested.

Now, if you (or OOMPH) updates your target platform definition to pull in org.xpect.xtext.lib in version 0.1.0.201611181623 and tomorrow I release org.xpect version 0.1.0.201611190000 (I'm not planning to), then your org.xpect.xtext.lib will automagically pull in the new org.xpect.

Could you reference the feature in OOMPH, like you do it for EGit?

[torstenkraemer]

Thanks for the fix.

As mentioned before, we do not reference the feature of EGit directly. We have dependencies in our plugins or features and we list available updates-sites in the Oomph-setup file.
What artifact is actually pulled in and stored in the target-definition, is entirely computed by Oomph.

[meysholdt]

the new feature also need to be included into the update-site