On 26.11.2015 12:54, David Leangen wrote:
Hi Christian,
This part of the bndrun file is the input for the resolver. This is
always needed. […] It is the purpose of a feature file or a bndrun
file. [...] You need to give the resolver the initial hooks to pull
the needed bundles out of this pool.
What I understand from what you write is that the bndrun/feature file
(call it a “runtime descriptor”?) is also nothing but a list of
requirements and capabilities. If so, it seems to be essentially the
same thing as an obr index: a list of resources with requirements and
capabilities. The only difference I can see is that the obr index is
for storing stuff and is ignorant of the runtime, while the the
runtime descriptor only cares about what is required during a runtime,
and doesn’t care if it contains all the stored resources or not. The
contents otherwise seem very similar, if not identical.
Sounds like two different views on the same thing, maybe.
They are kind of similar but you could argue the same for bundles and
the obr index. The bundle contains the requirement and capability
headers as well as the index. Still you need the bundles as the index is
created out of the bundle meta data. So in some way you could consider
the index to be just a cache for the meta data. It could be replaced by
just a list of resources as the resolver could also look into each
bundle / feature / bndrun file individually.
Or perhaps the features.xml file is itself nothing but a resource
(having requirements and capabilities) that could be expressed in an
obr index.
The feature/bndrun file is indeed a resource in the obr repository
sense. You still need it though as the index is normally created out of
something (as it is a kind of cache).
Also, I am still a bit stuck on the fact that the developers are the
ones expected to create the runtime descriptor. I can understand if
they want to immediately run something in a local test environment,
but otherwise it seems to couple the devs to the deployment/runtime.
Am I missing something, or is this related to the page of the
yet-to-be-developers scenario you showed in your previous post
(reposted below)?
Theoretically you could have a split there that developers only write
the code of bundles and do not care about the deployment at all. In
reality you want to create automated build/test pipelines that maybe
reach even into
production.
As you correctly stated developers need to at the very least test their
code locally. So they need to be involved at least in that part of the
pipeline. In fact developers are normally also responsible for the
integration tests that run locally as well as in a dev or test
environments. On the other hand you could have a deployer role that is
responsible for all of this. So yes you can say that the developer is
not responsible for the features.
As you typically want to build kind of devops teams today in the end the
development team is most times responsible for development + deployment
sometimes until dev, test sometimes even to production.
What I see in practice is that the real admins (that are not part of the
dev team) often are just responsible for the production servers. As the
deployment must already be present for previous steps in the pipeline it
typically does not make sense to let them define the deployment on their
own.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
