Hi David,
You can use the feature service, to install the "top level" feature
containing the requirements. Then the resolver will install all bundles
needed from the OBR repo.
WDYT ?
Regards
JB
On 11/26/2015 02:29 PM, David Leangen wrote:
Hi Christian,
Thank you very much for this discussion. It is very interesting (and
educational) since it is relevant to my current top priority: getting
our development—> deployment pipeline up and running quickly.
Getting back to more immediate practical matters…
Given that there is not currently a bnd plugin to create a features
file, and since I do not want to head in a solitary direction, what do
you recommend I do to automate the generation / installation of my features?
What I have:
* OBR repositories “deployed” by the devs, which are handed over to
the deployer
* A Karaf command for the deployer to browse the available OBR repos
What I need:
* A means to actually install and start the bundles
I don’t mind doing this against the Features service in runtime, since I
am building a “deployment” service anyway, to be used by the deployer.
Any thoughts to help me get up and running quickly would be very
welcome. :-)
Cheers,
=David
On Nov 26, 2015, at 10:20 PM, Christian Schneider
<ch...@die-schneider.net <mailto:ch...@die-schneider.net>> wrote:
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
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
