Home » Archived » Buckminster » How to ensure the exact same target platform is materialized
|
| Re: How to ensure the exact same target platform is materialized [message #454323 is a reply to message #442759] |
Sat, 01 August 2009 17:41   |
|
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 #467858 is a reply to message #467847] |
Mon, 03 August 2009 08:10 |
|
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 10:52 |
|
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 11:44 |
 Tas Frangoullides
Messages: 195
Registered: July 2009 |
Senior Member |
|
|
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 #467982 is a reply to message #467917] |
Mon, 03 August 2009 13:58 |
|
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
|
|
|
| Re: How to ensure the exact same target platform is materialized [message #467998 is a reply to message #467982] |
Mon, 03 August 2009 14:53 |
Tas Frangoullides
Messages: 195
Registered: July 2009 |
Senior Member |
|
|
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: Fri Apr 26 00:12:43 GMT 2024
Powered by FUDForum. Page generated in 0.03613 seconds |
] 
Search
Help
Register
Login
Home
