|
|
| Re: Matching feature versions [message #133102 is a reply to message #133089] |
Mon, 15 June 2009 14:57   |
 Andrew Niefer
Messages: 990
Registered: July 2009 |
Senior Member |
|
|
The long suffix at the end of the feature's version is a kind of base-64
sum of the things that are included by the feature. This way, when one
of the plug-ins included by the feature increased its version, and the
feature is then requiring the new plugin version, the feature's version
also increases.
As Paul mentioned, the old Update Manager only supported patching a
specific version of a feature. But, p2 is much more flexible, the
problem is that the only tooling we currently have for generating
patches is based on the old Update stuff, so you need to edit the
generated metadata by hand to relax the version ranges.
I am currently writing a blog post or two on this topic, they will show
up here when they are done: http://aniefer.blogspot.com/
The p2 metadata for a patch contains something like this:
<unit id='org.example.patch.feature.group' version='1.0.0'
singleton='false'>
<patchScope>
<scope>
<requires size='1'>
<required namespace='org.eclipse.equinox.p2.iu'
name='org.eclipse.equinox.p2.user.ui.feature.group'
range=''/>
</requires>
</scope>
</patchScope>
This specifies the feature you are patching, and the tooling currently
generates a specific version range because that was the semantics of the
old update feature patch.
You can relax this version range as Paul did, even to something a bit
narrower than Paul's [3.5.0,4.0.0):
[3.5.0.v20090527-2000, 3.5.0.v20090527-2001)
Which is any version equal to or larger than 3.5.0.v20090527-2000, but
smaller than 3.5.0.v20090527-2001. This matches all the different
generated suffixes.
Paul Webster wrote:
> Stephan Herrmann wrote:
>> Hi,
>>
>> I was wondering, how the matching of feature versions happens.
>> Consider these features:
>> 3.5RC3
>> org.eclipse.jdt_3.5.0.v20090527-2000-7r88FEeFJePyvYe69JGnUag 1
>> 3.5RC4
>> org.eclipse.jdt_3.5.0.v20090527-2000-7r88FEeFJePyvYeA27DiZdc 1
>
> The long string at the end is to ensure that these one feature is
> "greater" than the other, so that you would be able to install an
> upgrade (they're generated by a mix of things, one of which is a
> contained plugin incremented its version).
>
> The problem is Feature Patches are designed to target a specific
> feature, and PDE tools/build propagates the exact feature ID into the p2
> metadata. In my case, I had to hack the content.xml directly to replace
> the range for the feature I was patching:
>
> <xsl:template match="@range[../@name='org.eclipse.rcp.feature.group']">
> <xsl:attribute name="range">[3.5.0,4.0.0)</xsl:attribute>
> </xsl:template>
> <!-- Whenever you match any node or any attribute -->
> <xsl:template match="node()|@*">
> <!-- Copy the current node -->
> <xsl:copy>
> <!-- Including any attributes it has and any child nodes -->
> <xsl:apply-templates select="@*|node()"/>
> </xsl:copy>
> </xsl:template>
>
>
> If there's another way to do it, I'm all ears.
>
> PW
>
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.03511 seconds
] 
Search
Help
Register
Login
Home
