[GitHub] [felix-dev] bosschaert opened a new pull request #83: FELIX-6441 Make it possible to run the Configuration Interpolation independently of Configuration Admin

2021-07-30 Thread GitBox


bosschaert opened a new pull request #83:
URL: https://github.com/apache/felix-dev/pull/83


   The new StandaloneInterpolator class provides the entry-point for using
   the interpolator outside of a Configuration Admin environment.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@felix.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




[jira] [Work started] (FELIX-6441) Make it possible to run the Configuration Interpolation independently of Configuration Admin

2021-07-30 Thread A. J. David Bosschaert (Jira)


 [ 
https://issues.apache.org/jira/browse/FELIX-6441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on FELIX-6441 started by A. J. David Bosschaert.
-
> Make it possible to run the Configuration Interpolation independently of 
> Configuration Admin
> 
>
> Key: FELIX-6441
> URL: https://issues.apache.org/jira/browse/FELIX-6441
> Project: Felix
>  Issue Type: Improvement
>  Components: Configuration Admin
>Affects Versions: configadmin-interpolation-plugin-1.1.2
>Reporter: A. J. David Bosschaert
>Assignee: A. J. David Bosschaert
>Priority: Major
>
> The configadmin interpolation plugin is currently always run as a plugin to 
> the Configuration Admin service.
> However, it can be very useful to be able to run this plugin outside of 
> Config Admin , for example for static analysis and validation of the 
> configuration before it's applied to a running system.
> Therefore we should provide an entrypoint to the interpolation provided by 
> this plugin that can run outside of the OSGi Configuration Admin Service.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (FELIX-6441) Make it possible to run the Configuration Interpolation independently of Configuration Admin

2021-07-30 Thread A. J. David Bosschaert (Jira)
A. J. David Bosschaert created FELIX-6441:
-

 Summary: Make it possible to run the Configuration Interpolation 
independently of Configuration Admin
 Key: FELIX-6441
 URL: https://issues.apache.org/jira/browse/FELIX-6441
 Project: Felix
  Issue Type: Improvement
  Components: Configuration Admin
Affects Versions: configadmin-interpolation-plugin-1.1.2
Reporter: A. J. David Bosschaert
Assignee: A. J. David Bosschaert


The configadmin interpolation plugin is currently always run as a plugin to the 
Configuration Admin service.

However, it can be very useful to be able to run this plugin outside of Config 
Admin , for example for static analysis and validation of the configuration 
before it's applied to a running system.

Therefore we should provide an entrypoint to the interpolation provided by this 
plugin that can run outside of the OSGi Configuration Admin Service.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: Putting subproject docs in the code repos -- sample preview available

2021-07-30 Thread Carsten Ziegeler

Hi David,

the directory path is not nice and deep, but I don't mind that much.

I didn't want to rehash a discussion about markdown vs asciidoc in 
general - asciidoc for our website is totally fine. There is not much 
happening on that front anyway.


As I said if everyone is fine with converting the sub project docs 
stored next to the code from markdown to asciidoc as well, so be it.


So we should really hear from others

Regards
Carsten


Am 30.07.2021 um 08:42 schrieb David Jencks:

inline...


On Jul 29, 2021, at 9:28 PM, Carsten Ziegeler  wrote:

I like the approach in general, the location of the adoc file within the scr 
tree is a little bit awkward, but not a showstopper.


To me Antora directory structure is a bit like maven project layout, once you 
get used to it anything else seems odd.

We could shorten the path slightly to 
/docs/modules//pages/.adoc, making each 
subproject an Antora “module”.
I think it’s a good idea to separate the docs under “docs” although Antora would be just 
as happy with /modules>/…
The directory name “modules” doesn’t immediately imply “documentation” to me, 
and this shortening would put the required antora.yml next to e.g. the pom.xml.


What I personally don't like is that these files need to be written in asciidoc 
and not gh markdown. But if everyone else is fine with that, I can probably 
adjust.

It might have been more appropriate to bring this up when I proposed using 
Antora.
I’m curious what you prefer about markdown. I would not participate in a 
documentation project using markdown rather than AsciiDoc: I find it ugly and 
limited.

David Jencks



Regards
Carsten

Am 29.07.2021 um 02:31 schrieb David Jencks:

I’ve set up a somewhat usable preview workflow and a preview for scr for what 
I’d like for the subproject docs.
Take a look at https://felix.staged.apache.org/.  Scr is now in the nav under 
subprojects and linked from the table of subprojects.
The minimal README.adoc is visible at 
https://github.com/djencks/felix-dev/tree/adoc-preview/scr. Note that here 
GitHub is rendering AsciiDoc.  The source scr website content is at 
https://github.com/djencks/felix-dev/blob/adoc-preview/scr/docs/modules/ROOT/pages/subprojects/scr.adoc
I’d suggest doing this transformation for all the subprojects currently relying 
on READMEs and moving the docs for the other subprojects from the 
felix-antora-site repo to appropriate places in felix-dev.
David Jencks

On Jul 27, 2021, at 12:17 PM, David Jencks  wrote:

The new version of that page, 
https://felix.staged.apache.org/documentation/subprojects.html, still has links 
to the GitHub README.  If we stick with this (my 3rd option) we should at least 
also have links in the nav.

I suspect that it’s not clear how my preferred solution would work or look.  
I’ll see about setting up a preview for scr, since I already translated the 
README to .adoc.

In any case I’d suggest translating all the READMEs to AsciiDoc so all the  
documentation is in the same language.  GitHub renders AsciiDoc for READMEs 
automatically.

David Jencks


On Jul 27, 2021, at 2:05 AM, Carsten Ziegeler  wrote:



Am 27.07.2021 um 10:59 schrieb Bertrand Delacretaz:

On Tue, Jul 27, 2021 at 10:50 AM Carsten Ziegeler  wrote:

...I prefer having the docs of a subproject directly within git as this
makes updates that involve code and docs much easier (a single PR)...

I also like that option as long as all modules are discoverable from
the main website.
For Sling and its more than 300 modules we have
https://sling.apache.org/repolist.html which lists all modules on a
single page.


Good point, we have this at 
https://felix.apache.org/documentation/subprojects.html , the links currently 
either point to a readme in git or a page on the website.
Regards
Carsten

--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org




--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org




--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


Re: Putting subproject docs in the code repos -- sample preview available

2021-07-30 Thread David Jencks
inline...

> On Jul 29, 2021, at 9:28 PM, Carsten Ziegeler  wrote:
> 
> I like the approach in general, the location of the adoc file within the scr 
> tree is a little bit awkward, but not a showstopper.

To me Antora directory structure is a bit like maven project layout, once you 
get used to it anything else seems odd.

We could shorten the path slightly to 
/docs/modules//pages/.adoc, making each 
subproject an Antora “module”.
I think it’s a good idea to separate the docs under “docs” although Antora 
would be just as happy with /modules>/…
The directory name “modules” doesn’t immediately imply “documentation” to me, 
and this shortening would put the required antora.yml next to e.g. the pom.xml.

> What I personally don't like is that these files need to be written in 
> asciidoc and not gh markdown. But if everyone else is fine with that, I can 
> probably adjust.
It might have been more appropriate to bring this up when I proposed using 
Antora.
I’m curious what you prefer about markdown. I would not participate in a 
documentation project using markdown rather than AsciiDoc: I find it ugly and 
limited.

David Jencks

> 
> Regards
> Carsten
> 
> Am 29.07.2021 um 02:31 schrieb David Jencks:
>> I’ve set up a somewhat usable preview workflow and a preview for scr for 
>> what I’d like for the subproject docs.
>> Take a look at https://felix.staged.apache.org/.  Scr is now in the nav 
>> under subprojects and linked from the table of subprojects.
>> The minimal README.adoc is visible at 
>> https://github.com/djencks/felix-dev/tree/adoc-preview/scr. Note that here 
>> GitHub is rendering AsciiDoc.  The source scr website content is at 
>> https://github.com/djencks/felix-dev/blob/adoc-preview/scr/docs/modules/ROOT/pages/subprojects/scr.adoc
>> I’d suggest doing this transformation for all the subprojects currently 
>> relying on READMEs and moving the docs for the other subprojects from the 
>> felix-antora-site repo to appropriate places in felix-dev.
>> David Jencks
>>> On Jul 27, 2021, at 12:17 PM, David Jencks  wrote:
>>> 
>>> The new version of that page, 
>>> https://felix.staged.apache.org/documentation/subprojects.html, still has 
>>> links to the GitHub README.  If we stick with this (my 3rd option) we 
>>> should at least also have links in the nav.
>>> 
>>> I suspect that it’s not clear how my preferred solution would work or look. 
>>>  I’ll see about setting up a preview for scr, since I already translated 
>>> the README to .adoc.
>>> 
>>> In any case I’d suggest translating all the READMEs to AsciiDoc so all the  
>>> documentation is in the same language.  GitHub renders AsciiDoc for READMEs 
>>> automatically.
>>> 
>>> David Jencks
>>> 
 On Jul 27, 2021, at 2:05 AM, Carsten Ziegeler  wrote:
 
 
 
 Am 27.07.2021 um 10:59 schrieb Bertrand Delacretaz:
> On Tue, Jul 27, 2021 at 10:50 AM Carsten Ziegeler  
> wrote:
>> ...I prefer having the docs of a subproject directly within git as this
>> makes updates that involve code and docs much easier (a single PR)...
> I also like that option as long as all modules are discoverable from
> the main website.
> For Sling and its more than 300 modules we have
> https://sling.apache.org/repolist.html which lists all modules on a
> single page.
 
 Good point, we have this at 
 https://felix.apache.org/documentation/subprojects.html , the links 
 currently either point to a readme in git or a page on the website.
 Regards
 Carsten
 
 --
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org
>>> 
> 
> -- 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org