|
Re: Feature vs. Plugin qualifiers [message #377754 is a reply to message #377747] |
Wed, 25 June 2008 07:22 |
|
Hi Scott,
The feature qualifier is calculated based on the revision/timestamp of
the feature itself and the qualifiers of the included features and
plug-ins that are recognized as being of the same type. The highest
value wins.
At present, we only support timestamps and, in case you use SVN,
revisions. The actual qualifier replacement strategy is however an
extension point so if you like, you can write a strategy of your own
(and perhaps contribute it to Buckminster).
If you'd like to look more closely at what it would take to do that,
please study the extension point 'qualifierGenerators' defined in the
org.eclipse.buckminster.core plug-in. An implementation must implement
the org.eclipse.buckminster.core.version.IQualifierGenerator interface.
Alternatively, describe, in detail, the strategy that you would like to
have in a Bugzilla enhancement request and we'll see what we can do to help.
Regards,
Thomas Hallgren
Scott A. Hendrickson wrote:
> I've just succeeded in setting up an update site for our project, which
> uses subversion. I've configured it so that each 'qualifier' is replaced
> with the latest revision.
>
> My question is this: How is the qualifier for a feature calculated? Will
> it be updated to reflect when I commit an update for a plugin that is
> contained in the feature, but do not modify the feature itself? Also, is
> it possible to use the seemingly random base-64 string at the end of a
> feature, but revision numbers at the end of a plugin -- or something
> that works sufficiently well?
>
> Thanks,
> -- Scott
|
|
|
Re: Feature vs. Plugin qualifiers [message #378140 is a reply to message #377754] |
Thu, 26 June 2008 19:37 |
Scott Hendrickson Messages: 69 Registered: July 2009 |
Member |
|
|
Thomas Hallgren wrote:
> Hi Scott,
> The feature qualifier is calculated based on the revision/timestamp of
> the feature itself and the qualifiers of the included features and
> plug-ins that are recognized as being of the same type. The highest
> value wins.
This is exactly what I was hoping. Thank you Thomas!
I think that my build didn't reflect a new revisions because, even
though I committed updates to files within the projects, I had not
update the projects as a whole themselves. So, the project folder was
reporting that it was an order version than it's contents, and
buckminster didn't pick up the changed revisions. Once I updated the
projects, this fixed the problem. :) User error :)
Thank you,
-- Scott
> At present, we only support timestamps and, in case you use SVN,
> revisions. The actual qualifier replacement strategy is however an
> extension point so if you like, you can write a strategy of your own
> (and perhaps contribute it to Buckminster).
>
> If you'd like to look more closely at what it would take to do that,
> please study the extension point 'qualifierGenerators' defined in the
> org.eclipse.buckminster.core plug-in. An implementation must implement
> the org.eclipse.buckminster.core.version.IQualifierGenerator interface.
>
> Alternatively, describe, in detail, the strategy that you would like to
> have in a Bugzilla enhancement request and we'll see what we can do to
> help.
>
> Regards,
> Thomas Hallgren
>
>
> Scott A. Hendrickson wrote:
>> I've just succeeded in setting up an update site for our project,
>> which uses subversion. I've configured it so that each 'qualifier' is
>> replaced with the latest revision.
>>
>> My question is this: How is the qualifier for a feature calculated?
>> Will it be updated to reflect when I commit an update for a plugin
>> that is contained in the feature, but do not modify the feature
>> itself? Also, is it possible to use the seemingly random base-64
>> string at the end of a feature, but revision numbers at the end of a
>> plugin -- or something that works sufficiently well?
>>
>> Thanks,
>> -- Scott
|
|
|
Powered by
FUDForum. Page generated in 0.03863 seconds