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

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:

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

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

[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,

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

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

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

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

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

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

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

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,

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

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] -