Re: [tycho-user] What does feature/requires/import/version="0.0.0" mean

[Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>]

Hi Mickael,

>> Unlike for feature/plugin/@version the "0.0.0" of
>> feature/requires/import/@version is not expanded to the feature version
>> actually visible during the build (be it from the target platform or the
>> reactor).
> That's expected. The versions are kept as it, and are resolved when
> users *installs* the feature, not during the build. It basically allows
> to put dependency on version ranges and provide more flexibility.

That's what I figured. Unlike other instances of "0.0.0" Tycho doesn't
expand feature/requires/import/@version so the matching has to be done
during the install. It's just confusing that the version "0.0.0" is
overloading in this fashion, sometimes meaning "replacing during the
build" and sometimes (like in Import-Package's version) meaning "any
version".

>> And as far as I could tell during some experimental feature
>> installs/updates, any version of org.example.feature is a perfect match
>> for this requirement, making the above requirement pretty much useless.
> I believe 0.0.0 is automatically translated to "any version" by p2, so
> the "perfect" here doesn't have much effect on the request.

Yes, that's what it looked like.

>> And how is "perfect" supposed to be used? At least for
>> other features produced during the same build it's pretty much
>> impossible to predict their version up to and including the qualifier?
>> How can I therefore put a perfect version in there?
> I've never used "perfect" and I can't think of any use-case that would
> make it useful. If you want to depend on a very specific version of a
> feature, it seems better to *include* the feature than to require/import
> it. include resolves version during build so the output is locked to a
> fully-qualified version of the feature, similarly to what "perfect"
> would do, I guess.

I think the use case for "perfect" would be to allow for a smooth
transition to stricter matching rules like "equivalent" or "compatible".
At the moment, we have two rapidly co-evolving features where the API
may change even from one micro release to the next, but in the future
this will hopefully settle down. Then a previously introduced feature
inclusion may be harder to get rid of than a mere requirement, but I
haven't thought this completely through yet.

Anyways, thanks you very much for your insights.

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940