Hi Carsten,
can you provide some insights on timing wrt Felix Snapshot dependencies.
When we plugged together the demo we still had a few dependencies on
unreleased artifacts for the OSGi R7 work.
I would rather see this change happening yesterday than tomorrow to start
working on how the model c
Hi Bertrand
I suppose it would be
cat provisioning-model | jsmin | jq .
I have not tested this, however.
Regards
Julian
On Thu, Oct 5, 2017 at 3:39 PM, Bertrand Delacretaz
wrote:
> On Thu, Oct 5, 2017 at 11:39 AM, Julian Sedding wrote:
>> ...lets stick with JSON + comments...
>
> Is tha
I don't think jq supports comments.
But as I stated, all our code writes out perfectly valid JSON without
any comments. So you can use this with any tooling that supports JSON.
*If* you want to have comments in your source feature, we currently
support them as described.
Now, looking at the exis
On Thu, Oct 5, 2017 at 11:39 AM, Julian Sedding wrote:
> ...lets stick with JSON + comments...
Is that format accepted by JSON tools? Can I for example do
cat provisioning-model | jq .
?
Otherwise I fear the format combines the worst of both worlds: hard
for humans to read and write (JSON) a
Hi Carsten
That's fine with me. It just seemed like it might be a good fit
because of the comments. Seen that you went down that route already,
lets stick with JSON + comments.
Regards
Julian
On Thu, Oct 5, 2017 at 11:23 AM, Carsten Ziegeler wrote:
> Hi Julian
>
> yes, we considered YAML. Firs
Hi Julian
yes, we considered YAML. First of all, the OSGi Configuration Admin
specification will use JSON. That spec started with using YAML, but in
the end no one was happy with the format, so we replaced YAML with JSON.
While YAML can support JSON, no one really does this - so we end up with
re
Hi Carsten
This looks very interesting!
Regarding the format, have you considered YAML? It is a superset of
JSON (well, it's designed to also support JSON syntax) and it allows
comments out of the box. Furthermore, it's well specified (in contrast
to JSON with comments). I assume that using YAML,
Totally agree with what Karl said.
One major aspect of the new feature based model is that it describes
what a feature is and how features are combined and how the result looks
like.
Any tooling can then act on this. This will allow us to create Karaf
features or an OSGi subsystem or launch it wi
On Wed, 2017-10-04 at 10:01 +0200, Carsten Ziegeler wrote:
> Robert Munteanu wrote> On Tue, 2017-10-03 at 11:52 +0200, Carsten
> Ziegeler wrote:
>
> > > > 2. Reading the section on configuration merging, it is not
> > > > clear to
> > > > me
> > > > if merging is merging of values or overriding of
Robert Munteanu wrote> On Tue, 2017-10-03 at 11:52 +0200, Carsten
Ziegeler wrote:
>>> 2. Reading the section on configuration merging, it is not clear to
>>> me
>>> if merging is merging of values or overriding of values.
>>>
>>> Consider
>>>
>>>
>>> feature 1:
>>>
>>> com.foo.bar.Service
>>>p
On Tue, 2017-10-03 at 11:52 +0200, Carsten Ziegeler wrote:
> > 2. Reading the section on configuration merging, it is not clear to
> > me
> > if merging is merging of values or overriding of values.
> >
> > Consider
> >
> >
> > feature 1:
> >
> > com.foo.bar.Service
> >prop1="A"
> >prop
On Fri, Sep 29, 2017 at 5:15 PM, Carsten Ziegeler wrote:
> Stefan Seifert wrote>
>
>>> * No support for run modes in the model - run modes can be modeled
>>> through separate features
>>
>> is there a plan to generally remove the "run mode" concept from sling - or
>> just not express it in the fe
Hi Nicolas,
I think the points you mention are definitely worthwhile and for sure,
inline with what we have been thinking about.
While it is true that for starters, we are only considering the
starting of the instance it should be not too difficult to implement
the runtime extensions you proposed
Hi,
from what i understood, new provisioning model discussions and
thoughts are targeted on starting an instance from a future
standardized description.
What i would like to understand is if there is any room at this time
for thinking about runtime: a way of
- describing what is running (feature l
I don't want to split hairs here. Whatever is generated by our code is
JSON. We are able to process JSON *and* JSON enhanced with comments.
Carsten
Julian Reschke wrote
> On 2017-10-03 11:52, Carsten Ziegeler wrote:
>> ...
>>> 1. How can we add comments to a feature or application json file? AFA
On 2017-10-03 11:52, Carsten Ziegeler wrote:
...
1. How can we add comments to a feature or application json file? AFAIK
JSON does not allow comments
Right, strict JSON does not allow it, but we allow comments and the JSON
is preprocessed by a JSMin like processor. But after reading all
comme
Robert Munteanu wrote> Hi Carsten> > Thanks for the extensive write-up,
it took some time to digest :-)
:)
>
> I have a couple of questions based on who we currenly can (or can't)
> use the provisioning model.
>
> 1. How can we add comments to a feature or application json file? AFAIK
> JSON do
Hi Carsten,
Thanks for the extensive write-up, it took some time to digest :-)
I have a couple of questions based on who we currenly can (or can't)
use the provisioning model.
1. How can we add comments to a feature or application json file? AFAIK
JSON does not allow comments
2. Reading the sec
Stefan Seifert wrote>
>> * No support for run modes in the model - run modes can be modeled
>> through separate features
>
> is there a plan to generally remove the "run mode" concept from sling - or
> just not express it in the feature model?
> if it is kept - where come the features and run mo
>Carsten Ziegeler wrote>
>
>> Thanks for the pointer Stefan. We should definitely support this, I'll
>> update the code.
>> For some reason we have based the provisioning model and therefore the
>> feature model on
>> https://ops4j1.jira.com/wiki/spaces/paxurl/pages/3833866/Mvn+Protocol
>>
>
>I th
>* No support for run modes in the model - run modes can be modeled
>through separate features
is there a plan to generally remove the "run mode" concept from sling - or just
not express it in the feature model?
if it is kept - where come the features and run modes together?
stefan
Carsten Ziegeler wrote>
> Thanks for the pointer Stefan. We should definitely support this, I'll
> update the code.
> For some reason we have based the provisioning model and therefore the
> feature model on
> https://ops4j1.jira.com/wiki/spaces/paxurl/pages/3833866/Mvn+Protocol
>
I think the ma
Stefan Seifert wrote>
>> One minor thing, the current proposal uses the Maven coordinates to
>> describe artifacts. It's using the path part of a maven url, so
>> basically group id, artifact id, version are separated by a slash. It
>> seems that the notation of separating these things by a colon
>One minor thing, the current proposal uses the Maven coordinates to
>describe artifacts. It's using the path part of a maven url, so
>basically group id, artifact id, version are separated by a slash. It
>seems that the notation of separating these things by a colon is more
>common/natural. And w
Hi,
as some of you might already have seen or heard during adaptTo, the
whiteboard contains a new feature based model at [1] which is intended
to be a better provisioning model.
The repository at [1] contains a readme which details the reasons and is
a basic description of the approach. But I wou
25 matches
Mail list logo