ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bram de Kruijff (JIRA)" <>
Subject [jira] [Commented] (ACE-365) OBR non-bundle metadata has no symbolicname/version metadata
Date Tue, 25 Jun 2013 14:42:21 GMT


Bram de Kruijff commented on ACE-365:

I think the difference is between 'OSGi Repository Service Resource' and 'ACE artifact'. According
to the Repository Service R5 spec resource is required to have an osgi.identity capability
(see OSGi Enterprise R5 p532) and the osgi.identity namespace states that the version attribute
is mandatory (see OSGi Code p150). Therefore, as we will probably move to R5 at some point,
I think it is a good idea to align the ACE OBR with this and simply default to Version.emptyVersion
where we do not know it.

* Requiring an (empty) version in the OBR does not necessarily imply that version has a meaning
in the ACE model. For example configuration artifacts do not consider the version (a separate
* Determining the version for arbitrary resources type (eg. jpg) is an implementation concern.
RepoIndex (fka bindex2) is pluggable and again defaulting to Version.emptyVersion is always
an option.

> OBR non-bundle metadata has no symbolicname/version metadata
> ------------------------------------------------------------
>                 Key: ACE-365
>                 URL:
>             Project: ACE
>          Issue Type: Improvement
>    Affects Versions: 1.0.0
>            Reporter: Bram de Kruijff
> Although the ACE OBR support uploading non-bundle resources based on the filename :=
<bsn>-<version>.<ext>  heuristic, this metadata is not reflected in the
respository.xml index. Infact it only species the resource.uri.
> As a result it is impossible to find these resources by querying the repository in a
sensible way, such as using a requirement with an osgi.identity=<bsn> filter directive.
> Therefore, I suggest to at least add the resource.symbolicname and resource.version to
the current implementation. This is in line with R5 where every resource will have an osgi.identity
and osgi.content namespace capability.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message