Re: [HEADS UP] Next releases

2016-10-13 Thread Markus Rathgeb 
> -- Container 4.0.8: the ARM/Solaris issue should be fixed now (that was an
> important regression in 4.0.6 & 4.0.7). Other fixes and upgrades are coming
> too.

I tested the recent snapshot, but this does not work for me.
See JIRA

Re: [HEADS UP] Next releases

2016-10-13 Thread Jean-Baptiste Onofré 

Just publishing a new SNAPSHOT if you can test with it.

Regards
JB

On 10/13/2016 08:35 PM, Markus Rathgeb wrote:

-- Container 4.0.8: the ARM/Solaris issue should be fixed now (that was an
important regression in 4.0.6 & 4.0.7). Other fixes and upgrades are coming
too.


I tested the recent snapshot, but this does not work for me.
See JIRA



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [DISCUSS] Feature package, feature generation and validation

2016-10-13 Thread Milen Dyankov 
I have 2 things to say to that
- I agree with all the pain points you've identified (experienced them
myself)
- I'd prefer to fix things instead of claim them useless due to
malfunctioning

Perhaps a middle ground would be a good starting point? Something like how
bndrun resolution works. I mean:
 - developer says - this is what I care to run (perhaps a prototype feature
or something ...)
 - feature-generate-descriptor takes it from there and fills in the gaps
 - developer can change/fix things by tweaking the prototype if not happy
with what feature-generate-descriptor did

This is just my first thought and I'm pretty sure reality is not that
simple. Just wanted to vote against removing it and suggest to start
looking for better solution instead.

Best,
Milen

On Thu, Oct 13, 2016 at 11:07 AM, Guillaume Nodet  wrote:

> The feature packaging is a nice thing, as it allows automatic attachment of
> the feature file.
> However, it always use the feature-generate-descriptor, which produces a
> lot of weird results.
> Afaik, the feature packaging is not much used and all projects i've seen,
> such as pax projects, camel, cxf, and even karaf itself (including
> decanter, cellar, karaf container...).
>
> I think part of the problem comes from the feature descriptor generation,
> which is difficult to control.  I have always found much easier to simply
> write the feature manually.
> Although the generation process rewrites the xml entirely, so that any xml
> comments or license header is lost.
>
> Overall, I'm not sure that it makes our users life really easier.
>
> So I'd like to propose to get rid of the feature-generate-descriptor from
> inside the feature packaging and replace it with the verify goal to
> validate the hand-written features instead.
>
> Thoughts ?
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>



-- 
http://about.me/milen

Re: [jira] [Work started] (KARAF-4767) Decanter: collectors and appenders can't be re-used without default configuration

2016-10-13 Thread Christian Schneider 
I see the need to deploy features with your own config.. or maybe even 
no config at all to install but not activate the decanter module.

If there is no other way I agree with this change.

It sounds a bit like a generic problem though. On one hand we have the 
requirement for a very nice experience when a user first installs 
decanter. So
we provide the default configs. On the other hand for production you 
typically want a different config anyway so the default configs there 
rather hurt.


One generic solution might be to have a feature option config with 
default true. So the normal case would be unchanged and still Achim 
could use it like this:



scr
config="false">decanter-appender-elasticsearch-rest
config="false">decanter-collector-jmx
config="false">decanter-collector-process

mvn:${project.groupId}/Decanter-Module/${project.version}
finalname="/etc/org.apache.karaf.decanter.appender.elasticsearch.rest.cfg">mvn:de.nierbeck.karaf.decanter/Decanter-Module/${project.version}/cfg



WDYT?

This is not a quick solution though as it requires a changes in karaf 
and a new karaf version. So lets have the core features for now but 
later eventually remove them again.


Christian

On 13.10.2016 08:28, Achim Nierbeck wrote:

Hi Christian,

yes it's actually more like double the features, as it's really hard to
seperate the config from the modules for re-usage.
A concrete example for this can be found here [1].

regards, Achim

[1] -
https://github.com/ANierbeck/Karaf-Decanter-Runtime/blob/master/Decanter-Feature/src/main/feature/feature.xml


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [jira] [Work started] (KARAF-4767) Decanter: collectors and appenders can't be re-used without default configuration

2016-10-13 Thread Jean-Baptiste Onofré 
Agree, but it requires a Karaf change. So, in the mean time, I agree 
with Achim's change.


Regards
JB

On 10/13/2016 09:14 AM, Christian Schneider wrote:

I see the need to deploy features with your own config.. or maybe even
no config at all to install but not activate the decanter module.
If there is no other way I agree with this change.

It sounds a bit like a generic problem though. On one hand we have the
requirement for a very nice experience when a user first installs
decanter. So
we provide the default configs. On the other hand for production you
typically want a different config anyway so the default configs there
rather hurt.

One generic solution might be to have a feature option config with
default true. So the normal case would be unchanged and still Achim
could use it like this:


scr
decanter-appender-elasticsearch-rest
decanter-collector-jmx
decanter-collector-process
mvn:${project.groupId}/Decanter-Module/${project.version}
mvn:de.nierbeck.karaf.decanter/Decanter-Module/${project.version}/cfg



WDYT?

This is not a quick solution though as it requires a changes in karaf
and a new karaf version. So lets have the core features for now but
later eventually remove them again.

Christian

On 13.10.2016 08:28, Achim Nierbeck wrote:

Hi Christian,

yes it's actually more like double the features, as it's really hard to
seperate the config from the modules for re-usage.
A concrete example for this can be found here [1].

regards, Achim

[1] -
https://github.com/ANierbeck/Karaf-Decanter-Runtime/blob/master/Decanter-Feature/src/main/feature/feature.xml





--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

[DISCUSS] Feature package, feature generation and validation

2016-10-13 Thread Guillaume Nodet 
The feature packaging is a nice thing, as it allows automatic attachment of
the feature file.
However, it always use the feature-generate-descriptor, which produces a
lot of weird results.
Afaik, the feature packaging is not much used and all projects i've seen,
such as pax projects, camel, cxf, and even karaf itself (including
decanter, cellar, karaf container...).

I think part of the problem comes from the feature descriptor generation,
which is difficult to control.  I have always found much easier to simply
write the feature manually.
Although the generation process rewrites the xml entirely, so that any xml
comments or license header is lost.

Overall, I'm not sure that it makes our users life really easier.

So I'd like to propose to get rid of the feature-generate-descriptor from
inside the feature packaging and replace it with the verify goal to
validate the hand-written features instead.

Thoughts ?

-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [DISCUSS] Feature package, feature generation and validation

2016-10-13 Thread Grzegorz Grzybek 
Good idea in my opinion.

Feature descriptors should be (are) first-class artifacts and should be
carefully maintained. Relying simply on underlying dependencies of another
category (like Maven) is not enough.

Manual creation + build time verification is much better idea.

regards
Grzegorz Grzybek

2016-10-13 11:07 GMT+02:00 Guillaume Nodet :

> The feature packaging is a nice thing, as it allows automatic attachment of
> the feature file.
> However, it always use the feature-generate-descriptor, which produces a
> lot of weird results.
> Afaik, the feature packaging is not much used and all projects i've seen,
> such as pax projects, camel, cxf, and even karaf itself (including
> decanter, cellar, karaf container...).
>
> I think part of the problem comes from the feature descriptor generation,
> which is difficult to control.  I have always found much easier to simply
> write the feature manually.
> Although the generation process rewrites the xml entirely, so that any xml
> comments or license header is lost.
>
> Overall, I'm not sure that it makes our users life really easier.
>
> So I'd like to propose to get rid of the feature-generate-descriptor from
> inside the feature packaging and replace it with the verify goal to
> validate the hand-written features instead.
>
> Thoughts ?
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

Re: [DISCUSS] Feature package, feature generation and validation

2016-10-13 Thread Achim Nierbeck 
Hi,

as I'm the one with the most pain right now, I'm +1 on a pure validation
goal.
OTH I know a lot of people use the Feature generation as a starting point
to actually get going.
Especially since the "hand" writing for starters of using Karaf is
cumbersome in the beginning.
May I introduce another posibility?
Could we seperate the two concerns?
Have a validation which actually only validates but the plugin still
attaches the feature artifact to the build process so
it can be deployed.
And a second non-default generation goal, which uses all compile
dependencies to generate a new feature file which then
can also be used as attached artifact?

regards, Achim


2016-10-13 11:18 GMT+02:00 Grzegorz Grzybek :

> Good idea in my opinion.
>
> Feature descriptors should be (are) first-class artifacts and should be
> carefully maintained. Relying simply on underlying dependencies of another
> category (like Maven) is not enough.
>
> Manual creation + build time verification is much better idea.
>
> regards
> Grzegorz Grzybek
>
> 2016-10-13 11:07 GMT+02:00 Guillaume Nodet :
>
> > The feature packaging is a nice thing, as it allows automatic attachment
> of
> > the feature file.
> > However, it always use the feature-generate-descriptor, which produces a
> > lot of weird results.
> > Afaik, the feature packaging is not much used and all projects i've seen,
> > such as pax projects, camel, cxf, and even karaf itself (including
> > decanter, cellar, karaf container...).
> >
> > I think part of the problem comes from the feature descriptor generation,
> > which is difficult to control.  I have always found much easier to simply
> > write the feature manually.
> > Although the generation process rewrites the xml entirely, so that any
> xml
> > comments or license header is lost.
> >
> > Overall, I'm not sure that it makes our users life really easier.
> >
> > So I'd like to propose to get rid of the feature-generate-descriptor from
> > inside the feature packaging and replace it with the verify goal to
> > validate the hand-written features instead.
> >
> > Thoughts ?
> >
> > --
> > 
> > Guillaume Nodet
> > 
> > Red Hat, Open Source Integration
> >
> > Email: gno...@redhat.com
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
> >
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Hibernate 5

2016-10-13 Thread nseb 
Hi , 
It is planned the integration Hibernate 5 in version 4.1.0?

Best Regards,



-
CTO , JeetConsulting.

Analyze now your Maven Java projects' dependencies , here 
--
View this message in context: 
http://karaf.922171.n3.nabble.com/Hibernate-5-tp4048343.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Re: [DISCUSS] Gogo commands completion data

2016-10-13 Thread Achim Nierbeck 
Just one question,
what's the effect on already existing Karaf commands and those completions
etc.
If that is not affected at all I've got no complaints ;)

regards, Achim


2016-10-12 18:41 GMT+02:00 Guillaume Nodet :

> The problem is to obtain the list of scripts that needs to be loaded
> somehow.
> If we somehow include (using the source command for example), it means we
> need to copy the script file *and* modify another script, which may be a
> bit more complicated than necessary.
>
> 2016-10-12 18:38 GMT+02:00 Jean-Baptiste Onofré :
>
> > Hi Guillaume,
> >
> > what about a etc/gosh_profilerc that can load other scripts ?
> >
> > Regards
> > JB
> >
> >
> > On 10/12/2016 05:57 PM, Guillaume Nodet wrote:
> >
> >> I'm working on trying to nicely integrate gogo commands.
> >> The new gogo-jline bundle has a very nice way to allow external
> >> configuration for command completion. For example, one need to execute
> the
> >> script at https://gist.github.com/gnodet/18de68d57fc959efb7f9e4766415ff
> 5e
> >> to add full completion to the Karaf shell once you have the scr bundle
> >> installed (it always provides gogo commands).  Other examples are
> >> available
> >> at
> >> https://github.com/apache/felix/blob/trunk/gogo/jline/src/
> >> main/resources/gosh_profile
> >>
> >> The question is : how to provide such a script.
> >> One possibility would be to have a dedicated folder such as etc/scripts/
> >> where all scripts would be loaded when a session is started. We could
> then
> >> reference those files in features so that they are copied when features
> >> are
> >> installed.
> >> This would allow leveraging the  feature xml element.
> >>
> >> Do you guys have better ideas ?
> >>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Re: [DISCUSS] Feature package, feature generation and validation

2016-10-13 Thread Stephen Kitt 
Hi Guillaume,

On Thu, 13 Oct 2016 11:07:50 +0200
Guillaume Nodet  wrote:
[...]
> So I'd like to propose to get rid of the feature-generate-descriptor
> from inside the feature packaging and replace it with the verify goal
> to validate the hand-written features instead.

I've started migrating OpenDaylight to generated features (if you're
really keen, https://git.opendaylight.org/gerrit/39539 is the first
patch in the migration), for a variety of reasons:
* the dependencies are only specified once (in the POM)
* bundles are wrapped automatically
* dependencies aren't forgotten (this is caught by automated tests, but
  if the plugin can handle it for us that's even better)

The main reason is the first one; we've hit all sorts of pain points
dealing with duplicate dependency definitions, and I'd really like to
avoid them.

I've been working on improving feature-generate-descriptor to support
our use-cases, and I am still planning on improving it (e.g. to handle
aggregate feature repositories). We still need hand-written feature.xml
snippets in some cases, and I'm not sure we'll ever be able to handle
them... But overall I've found the generator useful.

Regards,

Stephen


pgpqnVGLj2eMe.pgp
Description: OpenPGP digital signature

Re: [DISCUSS] Feature package, feature generation and validation

2016-10-13 Thread Jean-Baptiste Onofré 
+1

It would remove or at least limit the generate feature execution. It's too 
simple and never cleanly cover the use cases. Writing the features XML by hand 
is always better IMHO.

Regards
JB



On Oct 13, 2016, 11:08, at 11:08, Guillaume Nodet  wrote:
>The feature packaging is a nice thing, as it allows automatic
>attachment of
>the feature file.
>However, it always use the feature-generate-descriptor, which produces
>a
>lot of weird results.
>Afaik, the feature packaging is not much used and all projects i've
>seen,
>such as pax projects, camel, cxf, and even karaf itself (including
>decanter, cellar, karaf container...).
>
>I think part of the problem comes from the feature descriptor
>generation,
>which is difficult to control.  I have always found much easier to
>simply
>write the feature manually.
>Although the generation process rewrites the xml entirely, so that any
>xml
>comments or license header is lost.
>
>Overall, I'm not sure that it makes our users life really easier.
>
>So I'd like to propose to get rid of the feature-generate-descriptor
>from
>inside the feature packaging and replace it with the verify goal to
>validate the hand-written features instead.
>
>Thoughts ?
>
>-- 
>
>Guillaume Nodet
>
>Red Hat, Open Source Integration
>
>Email: gno...@redhat.com
>Web: http://fusesource.com
>Blog: http://gnodet.blogspot.com/

Re: [DISCUSS] Gogo commands completion data

2016-10-13 Thread Achim Nierbeck 
fully agree on the scr ones and those posix commands.
We don't need to re-invent the wheel a fifth time ;)

regards, Achim


2016-10-13 11:47 GMT+02:00 Guillaume Nodet :

> 2016-10-13 11:28 GMT+02:00 Achim Nierbeck :
>
> > Just one question,
> > what's the effect on already existing Karaf commands and those
> completions
> > etc.
> > If that is not affected at all I've got no complaints ;)
> >
>
> Existing commands are not affected.
>
> To achieve the above, I'm using a completer which delegate to both the
> completer for karaf commands and the gogo-jline completer.
> One change in jline3 made that easy, as jline3 completers do not have to
> filter the completions, and jline will filter non matching completion
> candidates itself.  In particular, this allow to do typos corrections ;-)
>
> That said, I think we should get rid of duplicated commands, such as the
> posix / procedural ones (each, if, grep, less, etc...) and the ones that
> are provided by projects directly such as the scr commands.
>
>
> >
> > regards, Achim
> >
> >
> > 2016-10-12 18:41 GMT+02:00 Guillaume Nodet :
> >
> > > The problem is to obtain the list of scripts that needs to be loaded
> > > somehow.
> > > If we somehow include (using the source command for example), it means
> we
> > > need to copy the script file *and* modify another script, which may be
> a
> > > bit more complicated than necessary.
> > >
> > > 2016-10-12 18:38 GMT+02:00 Jean-Baptiste Onofré :
> > >
> > > > Hi Guillaume,
> > > >
> > > > what about a etc/gosh_profilerc that can load other scripts ?
> > > >
> > > > Regards
> > > > JB
> > > >
> > > >
> > > > On 10/12/2016 05:57 PM, Guillaume Nodet wrote:
> > > >
> > > >> I'm working on trying to nicely integrate gogo commands.
> > > >> The new gogo-jline bundle has a very nice way to allow external
> > > >> configuration for command completion. For example, one need to
> execute
> > > the
> > > >> script at https://gist.github.com/gnodet/
> > 18de68d57fc959efb7f9e4766415ff
> > > 5e
> > > >> to add full completion to the Karaf shell once you have the scr
> bundle
> > > >> installed (it always provides gogo commands).  Other examples are
> > > >> available
> > > >> at
> > > >> https://github.com/apache/felix/blob/trunk/gogo/jline/src/
> > > >> main/resources/gosh_profile
> > > >>
> > > >> The question is : how to provide such a script.
> > > >> One possibility would be to have a dedicated folder such as
> > etc/scripts/
> > > >> where all scripts would be loaded when a session is started. We
> could
> > > then
> > > >> reference those files in features so that they are copied when
> > features
> > > >> are
> > > >> installed.
> > > >> This would allow leveraging the  feature xml element.
> > > >>
> > > >> Do you guys have better ideas ?
> > > >>
> > > >>
> > > > --
> > > > Jean-Baptiste Onofré
> > > > jbono...@apache.org
> > > > http://blog.nanthrax.net
> > > > Talend - http://www.talend.com
> > > >
> > >
> > >
> > >
> > > --
> > > 
> > > Guillaume Nodet
> > > 
> > > Red Hat, Open Source Integration
> > >
> > > Email: gno...@redhat.com
> > > Web: http://fusesource.com
> > > Blog: http://gnodet.blogspot.com/
> > >
> >
> >
> >
> > --
> >
> > Apache Member
> > Apache Karaf  Committer & PMC
> > OPS4J Pax Web  Committer
> &
> > Project Lead
> > blog 
> > Co-Author of Apache Karaf Cookbook 
> >
> > Software Architect / Project Manager / Scrum Master
> >
>
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Re: [DISCUSS] Gogo commands completion data

2016-10-13 Thread Guillaume Nodet 
2016-10-13 11:28 GMT+02:00 Achim Nierbeck :

> Just one question,
> what's the effect on already existing Karaf commands and those completions
> etc.
> If that is not affected at all I've got no complaints ;)
>

Existing commands are not affected.

To achieve the above, I'm using a completer which delegate to both the
completer for karaf commands and the gogo-jline completer.
One change in jline3 made that easy, as jline3 completers do not have to
filter the completions, and jline will filter non matching completion
candidates itself.  In particular, this allow to do typos corrections ;-)

That said, I think we should get rid of duplicated commands, such as the
posix / procedural ones (each, if, grep, less, etc...) and the ones that
are provided by projects directly such as the scr commands.


>
> regards, Achim
>
>
> 2016-10-12 18:41 GMT+02:00 Guillaume Nodet :
>
> > The problem is to obtain the list of scripts that needs to be loaded
> > somehow.
> > If we somehow include (using the source command for example), it means we
> > need to copy the script file *and* modify another script, which may be a
> > bit more complicated than necessary.
> >
> > 2016-10-12 18:38 GMT+02:00 Jean-Baptiste Onofré :
> >
> > > Hi Guillaume,
> > >
> > > what about a etc/gosh_profilerc that can load other scripts ?
> > >
> > > Regards
> > > JB
> > >
> > >
> > > On 10/12/2016 05:57 PM, Guillaume Nodet wrote:
> > >
> > >> I'm working on trying to nicely integrate gogo commands.
> > >> The new gogo-jline bundle has a very nice way to allow external
> > >> configuration for command completion. For example, one need to execute
> > the
> > >> script at https://gist.github.com/gnodet/
> 18de68d57fc959efb7f9e4766415ff
> > 5e
> > >> to add full completion to the Karaf shell once you have the scr bundle
> > >> installed (it always provides gogo commands).  Other examples are
> > >> available
> > >> at
> > >> https://github.com/apache/felix/blob/trunk/gogo/jline/src/
> > >> main/resources/gosh_profile
> > >>
> > >> The question is : how to provide such a script.
> > >> One possibility would be to have a dedicated folder such as
> etc/scripts/
> > >> where all scripts would be loaded when a session is started. We could
> > then
> > >> reference those files in features so that they are copied when
> features
> > >> are
> > >> installed.
> > >> This would allow leveraging the  feature xml element.
> > >>
> > >> Do you guys have better ideas ?
> > >>
> > >>
> > > --
> > > Jean-Baptiste Onofré
> > > jbono...@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> > >
> >
> >
> >
> > --
> > 
> > Guillaume Nodet
> > 
> > Red Hat, Open Source Integration
> >
> > Email: gno...@redhat.com
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
> >
>
>
>
> --
>
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
>
> Software Architect / Project Manager / Scrum Master
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [DISCUSS] Feature package, feature generation and validation

2016-10-13 Thread Stephen Kitt 
On Thu, 13 Oct 2016 12:18:04 +0200
Stephen Kitt  wrote:
> I've been working on improving feature-generate-descriptor to support
> our use-cases, and I am still planning on improving it (e.g. to handle
> aggregate feature repositories). We still need hand-written
> feature.xml snippets in some cases, and I'm not sure we'll ever be
> able to handle them... But overall I've found the generator useful.

That being said, I don't mind of course if the generator is dropped
from the default execution!

Regards,

Stephen


pgpeKbB9aViQB.pgp
Description: OpenPGP digital signature

Re: [jira] [Work started] (KARAF-4767) Decanter: collectors and appenders can't be re-used without default configuration

2016-10-13 Thread Achim Nierbeck 
Hi Christian,

yes it's actually more like double the features, as it's really hard to
seperate the config from the modules for re-usage.
A concrete example for this can be found here [1].

regards, Achim

[1] -
https://github.com/ANierbeck/Karaf-Decanter-Runtime/blob/master/Decanter-Feature/src/main/feature/feature.xml



2016-10-13 7:42 GMT+02:00 Jean-Baptiste Onofré :

> Basically, Achim wants to use the Decanter features without the default
> cfg.
>
> For instance, today, when you install the decanter-collector-jmx feature,
> it installs local-jmx.cfg configuration file by default.
>
> Achim doesn't want the default config, only the "core" features (bundles)
> and define his own configuration.
>
> Regards
> JB
>
>
> On 10/13/2016 07:14 AM, Christian Schneider wrote:
>
>> This change creates a lot of new features. I do not yet understand the
>> reasoning behind it.
>> Can you explain?
>>
>> Christian
>>
>> 2016-10-12 19:59 GMT+02:00 Achim Nierbeck :
>>
>> Working on it, but been in a hurry to complete. Will be done tonight
>>>
>>> Am Mittwoch, 12. Oktober 2016 schrieb Jean-Baptiste Onofré (JIRA) :
>>>
>>>
 [ https://issues.apache.org/jira/browse/KARAF-4767?page=
 com.atlassian.jira.plugin.system.issuetabpanels:comment-
 tabpanel=15569195#comment-15569195 ]

 Jean-Baptiste Onofré commented on KARAF-4767:
 -

 By the way, I already created a Jira regarding the JMX appender and
 already started for this one.

 Decanter: collectors and appenders can't be re-used without default
>
 configuration

> 
>
 -

>
> Key: KARAF-4767
> URL: https://issues.apache.org/jira/browse/KARAF-4767
> Project: Karaf
>  Issue Type: Bug
>  Components: decanter
>Affects Versions: decanter-1.2.0
>Reporter: Achim Nierbeck
>Assignee: Achim Nierbeck
> Fix For: decanter-1.3.0
>
>
> Right now the jmx collector and various appenders can't be re-used
>
 without the default configs, those features should be split into the
 current one which references a *-core feature. This way it's easier to
 re-use the jmx collector or the elasticsearch appender ...



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)


>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf  Committer & PMC
>>> OPS4J Pax Web  Committer
>>> &
>>> Project Lead
>>> blog 
>>> Co-Author of Apache Karaf Cookbook 
>>>
>>> Software Architect / Project Manager / Scrum Master
>>>
>>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master