Home » Archived » Buckminster » How to ensure the exact same target platform is materialized
| How to ensure the exact same target platform is materialized [message #442759] |
Fri, 31 July 2009 09:38  |
Eclipse User |
|
|
|
I am materializing a target platform by using a feature which includes the
features I want in my target platform. For example here is my feature
<feature
id="com.mialos.tutorial.mailapp.targetplatform"
label="Targetplatform"
version="1.0.0.qualifier"
provider-name="ME">
<includes
id="org.eclipse.equinox.executable"
version="3.3.200"/>
<includes
id="org.eclipse.rcp"
version="3.5"/>
</feature>
Materialization works fine when the versions in the target feature are
available. I tried changing the rcp version to 3.6 and it failed as I
expected. However, when I tried changing it to 3.4 it still worked and
materialzed 3.5 instead. I can see how this might be desirable in some
applications but I really need the versions to be exact in this case. How do
I achieve it?
Thanks,
Tas
|
|
| | |
| Re: How to ensure the exact same target platform is materialized [message #467858 is a reply to message #467847] |
Mon, 03 August 2009 04:10  |
| Eclipse User |
|
|
|
Hi Tas,
The PDE feature.xml will only allow match rules for "required" features and plug-ins (runtime requirement, not build
requirement), not for the included features. In the Java API, the includes show up as entries with "greater or equal"
set. It's not allowed write <includes match="equivalent" ... but my guess is that it would work.
A better option is perhaps to use a buckminster.cspec instead of a feature to declare your target.
Regards,
Thomas Hallgren
Tas Frangoullides wrote:
> Hi Thomas,
>
> My understanding so far is that a BOM also specifies where to obtain the
> components - which I don't want, I still want to take advantage of
> buckminsters resolution. I'd like to simply specify that an exact
> version of a feature is resolved.
>
> Thanks,
> Tas
>
> "Thomas Hallgren" <thomas@tada.se> wrote in message
> news:h51uof$42b$1@build.eclipse.org...
>> Hi Tas,
>> One option is to take advantage of the split between resolution and
>> materialization. If you do an import with --bomfile <aFile> you'll get
>> a Bill Of Material (BOM) file that represents the resolution. You can
>> then appoint this BOM instead of a CQUERY from your MSPEC or when
>> issuing another import. That way, you ensure that no new resolution
>> takes place. The BOM appoints explicit versions and should guarantee
>> that you always get the exact same version of everything that it
>> contains.
>>
>> Regards,
>> Thomas Hallgren
>>
>>
>> Tas Frangoullides wrote:
>>> I am materializing a target platform by using a feature which
>>> includes the features I want in my target platform. For example here
>>> is my feature
>>>
>>> <feature
>>> id="com.mialos.tutorial.mailapp.targetplatform"
>>> label="Targetplatform"
>>> version="1.0.0.qualifier"
>>> provider-name="ME">
>>> <includes
>>> id="org.eclipse.equinox.executable"
>>> version="3.3.200"/>
>>> <includes
>>> id="org.eclipse.rcp"
>>> version="3.5"/>
>>> </feature>
>>>
>>> Materialization works fine when the versions in the target feature
>>> are available. I tried changing the rcp version to 3.6 and it failed
>>> as I expected. However, when I tried changing it to 3.4 it still
>>> worked and materialzed 3.5 instead. I can see how this might be
>>> desirable in some applications but I really need the versions to be
>>> exact in this case. How do I achieve it?
>>>
>>> Thanks,
>>> Tas
>
|
|
|
| Re: How to ensure the exact same target platform is materialized [message #467901 is a reply to message #467858] |
Mon, 03 August 2009 06:52 |
| Eclipse User |
|
|
|
The feature.xml <include> element should really generate an explicit dependency. That's what P2 does. I added this
bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=285421
Regards,
Thomas Hallgren
Thomas Hallgren wrote:
> Hi Tas,
> The PDE feature.xml will only allow match rules for "required" features
> and plug-ins (runtime requirement, not build requirement), not for the
> included features. In the Java API, the includes show up as entries with
> "greater or equal" set. It's not allowed write <includes
> match="equivalent" ... but my guess is that it would work.
>
> A better option is perhaps to use a buckminster.cspec instead of a
> feature to declare your target.
>
> Regards,
> Thomas Hallgren
>
>
> Tas Frangoullides wrote:
>> Hi Thomas,
>>
>> My understanding so far is that a BOM also specifies where to obtain
>> the components - which I don't want, I still want to take advantage of
>> buckminsters resolution. I'd like to simply specify that an exact
>> version of a feature is resolved.
>>
>> Thanks,
>> Tas
>>
>> "Thomas Hallgren" <thomas@tada.se> wrote in message
>> news:h51uof$42b$1@build.eclipse.org...
>>> Hi Tas,
>>> One option is to take advantage of the split between resolution and
>>> materialization. If you do an import with --bomfile <aFile> you'll
>>> get a Bill Of Material (BOM) file that represents the resolution. You
>>> can then appoint this BOM instead of a CQUERY from your MSPEC or when
>>> issuing another import. That way, you ensure that no new resolution
>>> takes place. The BOM appoints explicit versions and should guarantee
>>> that you always get the exact same version of everything that it
>>> contains.
>>>
>>> Regards,
>>> Thomas Hallgren
>>>
>>>
>>> Tas Frangoullides wrote:
>>>> I am materializing a target platform by using a feature which
>>>> includes the features I want in my target platform. For example here
>>>> is my feature
>>>>
>>>> <feature
>>>> id="com.mialos.tutorial.mailapp.targetplatform"
>>>> label="Targetplatform"
>>>> version="1.0.0.qualifier"
>>>> provider-name="ME">
>>>> <includes
>>>> id="org.eclipse.equinox.executable"
>>>> version="3.3.200"/>
>>>> <includes
>>>> id="org.eclipse.rcp"
>>>> version="3.5"/>
>>>> </feature>
>>>>
>>>> Materialization works fine when the versions in the target feature
>>>> are available. I tried changing the rcp version to 3.6 and it failed
>>>> as I expected. However, when I tried changing it to 3.4 it still
>>>> worked and materialzed 3.5 instead. I can see how this might be
>>>> desirable in some applications but I really need the versions to be
>>>> exact in this case. How do I achieve it?
>>>>
>>>> Thanks,
>>>> Tas
>>
|
|
|
| Re: How to ensure the exact same target platform is materialized [message #467917 is a reply to message #467901] |
Mon, 03 August 2009 07:44 |
| Eclipse User |
|
|
|
Ok. That makes sense.
I've tried using a cspec for now which works fine. I have found that a
dependencies such at the following doesn't work
<cs:dependency name="org.eclipse.rcp" componentType="eclipse.feature"
versionDesignator="[3.5.0)"/>
Is this because the precense of a qualifier is treated as a later version? I
then found that a versionDesignator of [3.5.0.3.5.1] or
[3.5.0.v20090519-9SA0FwxFv6x089WEf-TWh11] works. I guess the fully qualified
verison number is the best if I want a precise target platform.
Thanks,
Tas
"Thomas Hallgren" <thomas@tada.se> wrote in message
news:h56fgs$to7$1@build.eclipse.org...
> The feature.xml <include> element should really generate an explicit
> dependency. That's what P2 does. I added this bugzilla:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=285421
>
> Regards,
> Thomas Hallgren
>
>
> Thomas Hallgren wrote:
>> Hi Tas,
>> The PDE feature.xml will only allow match rules for "required" features
>> and plug-ins (runtime requirement, not build requirement), not for the
>> included features. In the Java API, the includes show up as entries with
>> "greater or equal" set. It's not allowed write <includes
>> match="equivalent" ... but my guess is that it would work.
>>
>> A better option is perhaps to use a buckminster.cspec instead of a
>> feature to declare your target.
>>
>> Regards,
>> Thomas Hallgren
>>
>>
>> Tas Frangoullides wrote:
>>> Hi Thomas,
>>>
>>> My understanding so far is that a BOM also specifies where to obtain the
>>> components - which I don't want, I still want to take advantage of
>>> buckminsters resolution. I'd like to simply specify that an exact
>>> version of a feature is resolved.
>>>
>>> Thanks,
>>> Tas
>>>
>>> "Thomas Hallgren" <thomas@tada.se> wrote in message
>>> news:h51uof$42b$1@build.eclipse.org...
>>>> Hi Tas,
>>>> One option is to take advantage of the split between resolution and
>>>> materialization. If you do an import with --bomfile <aFile> you'll get
>>>> a Bill Of Material (BOM) file that represents the resolution. You can
>>>> then appoint this BOM instead of a CQUERY from your MSPEC or when
>>>> issuing another import. That way, you ensure that no new resolution
>>>> takes place. The BOM appoints explicit versions and should guarantee
>>>> that you always get the exact same version of everything that it
>>>> contains.
>>>>
>>>> Regards,
>>>> Thomas Hallgren
>>>>
>>>>
>>>> Tas Frangoullides wrote:
>>>>> I am materializing a target platform by using a feature which includes
>>>>> the features I want in my target platform. For example here is my
>>>>> feature
>>>>>
>>>>> <feature
>>>>> id="com.mialos.tutorial.mailapp.targetplatform"
>>>>> label="Targetplatform"
>>>>> version="1.0.0.qualifier"
>>>>> provider-name="ME">
>>>>> <includes
>>>>> id="org.eclipse.equinox.executable"
>>>>> version="3.3.200"/>
>>>>> <includes
>>>>> id="org.eclipse.rcp"
>>>>> version="3.5"/>
>>>>> </feature>
>>>>>
>>>>> Materialization works fine when the versions in the target feature are
>>>>> available. I tried changing the rcp version to 3.6 and it failed as I
>>>>> expected. However, when I tried changing it to 3.4 it still worked and
>>>>> materialzed 3.5 instead. I can see how this might be desirable in some
>>>>> applications but I really need the versions to be exact in this case.
>>>>> How do I achieve it?
>>>>>
>>>>> Thanks,
>>>>> Tas
>>>
|
|
| |
| Re: How to ensure the exact same target platform is materialized [message #467998 is a reply to message #467982] |
Mon, 03 August 2009 10:53 |
| Eclipse User |
|
|
|
Hi Thomas,
It's only when you pointed out using ')' instead of ']' that I realized this
is actually what I am using. (At first I thought you'd made a typo). I had
selected "From <= ? < To" in the cspec editor which resulted in that
designator.
So now cspec is working very well for describing target platforms.
Thanks,
Tas
"Thomas Hallgren" <thomas@tada.se> wrote in message
news:h56qdl$hjk$1@build.eclipse.org...
> Tas Frangoullides wrote:
>> Ok. That makes sense.
>>
>> I've tried using a cspec for now which works fine. I have found that a
>> dependencies such at the following doesn't work
>>
>> <cs:dependency name="org.eclipse.rcp" componentType="eclipse.feature"
>> versionDesignator="[3.5.0)"/>
>>
> The syntax [3.5.0) is not supported. That would mean [3.5.0,3.5.0) which
> is a negative range (it starts at 3.5.0 inclusive and stops at 3.5.0 non
> inclusive).
>
> [3.5.0] is short for [3.5.0,3.5.0] which denotes an exact match for 3.5.0
>
>> Is this because the precense of a qualifier is treated as a later
>> version?
> >
> Yes, in OSGi, the empty qualifier is less then all other qualifiers.
>
>> I then found that a versionDesignator of [3.5.0.3.5.1] or
>> [3.5.0.v20090519-9SA0FwxFv6x089WEf-TWh11] works. I guess the fully
>> qualified verison number is the best if I want a precise target platform.
>>
> You can also do [3.5.0,3.5.1) which will be slightly more restrictive then
> [3.5.0,3.5.1] since the upper bound is non inclusive.
>
> Regards,
> Thomas Hallgren
|
|
|
Goto Forum:
Current Time: Mon Jul 07 00:09:54 EDT 2025
Powered by FUDForum. Page generated in 0.12033 seconds |
Home