[VOTE] Apache Karaf Cellar 4.0.3 release

Hi all, I submit Apache Karaf Cellar 4.0.3 release to your vote. Release Notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12338324 Staging Repository: https://repository.apache.org/content/repositories/orgapachekaraf-1076/ Git Tag: cellar-4.0.3 Please v

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

This custom resource repository is what I would love to see as far as bndtools and karaf integration. I think bndtools had made a huge leap with their new maven integration in the bnd pom repository. I would love to see a feature repository built off of that. Ideally when I run karaf in pax exam

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

On 19.10.2016 16:57, Guillaume Nodet wrote: Something like: mvn:... mvn:... ... That sounds like a feature to me ;-) The advantage would be that you can use IDE tooling for poms like M2E. So you get search and completion for the artifacts. You get nice introspection for the transiti

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

2016-10-19 16:13 GMT+02:00 Christian Schneider : > On 19.10.2016 15:53, Guillaume Nodet wrote: > >> 2016-10-19 15:28 GMT+02:00 Christian Schneider : >> >> On 19.10.2016 15:22, Guillaume Nodet wrote: >>> >>> I disagree. All the problems come when you start using maven transitive dependenc

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

On 19.10.2016 15:53, Guillaume Nodet wrote: 2016-10-19 15:28 GMT+02:00 Christian Schneider : On 19.10.2016 15:22, Guillaume Nodet wrote: I disagree. All the problems come when you start using maven transitive dependencies in real projects and hit lots of dependencies which are not OSGi bundl

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

2016-10-19 15:28 GMT+02:00 Christian Schneider : > On 19.10.2016 15:22, Guillaume Nodet wrote: > >> I disagree. >> >> All the problems come when you start using maven transitive dependencies >> in >> real projects and hit lots of dependencies which are not OSGi bundles or >> not OSGi ready. Think

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

I disagree. All the problems come when you start using maven transitive dependencies in real projects and hit lots of dependencies which are not OSGi bundles or not OSGi ready. Think about simple examples like spring, or all the bundles that we do re-wrap in servicemix. I think this idea is nice

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

On 19.10.2016 15:22, Guillaume Nodet wrote: I disagree. All the problems come when you start using maven transitive dependencies in real projects and hit lots of dependencies which are not OSGi bundles or not OSGi ready. Think about simple examples like spring, or all the bundles that we do re-

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

Christian - sounds like a good idea ;) Paremus have always pursued this sort of approach - See https://docs.paremus.com/pages/viewpage.action?pageId=8060997 for a simple example. Cheers > On 19 Oct 2016, at 14:04, Christian

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

I agree. Currently the feature files are too low level. Basically you have to list all bundles. We need something like bndtools resolution. So I think a feature should be backed by an index. I have made some good experiences with pom based indexes. This is a pom that depends on bundles (includ

Re: [DISCUSS] Gogo commands completion data

I really think the scripts are more flexible and powerful than command metadata. But I agree having to ship them is a pain, so I hope we can find a better way in the future. Your proposal of a known location in the bundle makes sense. 2016-10-19 13:51 GMT+02:00 Christian Schneider : > The comman

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

I am +1 on removing it, especially if nobody wants to maintain it. I tried to use it at one point and it just never really worked well. Hand-crafted features files are always the best option, IMHO. It might be nice to have a Maven archetype or something that would generate a "features module" fr

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

So I'll go ahead with the following: * change the verify goal to be a default goal for the feature packaging * change the feature-generate-descriptor to be a non default goal for the feature packaging The benefits is that people who want to hand-write features will be able to use the feature p

Re: [DISCUSS] Gogo commands completion data

The command metadata service API of course would need to live at felix gogo. So the plain gogo shell could also make use of it. We could then provide an extender at karaf that creates these services out of the karaf specific commands. The problem I see with the scripts is how to add them to the

Re: [DISCUSS] Gogo commands completion data

The command metadata service API of course would need to live at felix gogo. So the plain gogo shell could also make use of it. We could then provide an extender at karaf that creates these services out of the karaf specific commands. The problem I see with the scripts is how to add them to the

Re: [DISCUSS] Gogo commands completion data

I thought about that, but then, the bundles would be tied to Karaf while the goal is to support commands from projects which are not related to karaf. Else, we could just force them to use our own command api if they want to support Karaf ;-) Also remember that scripting offers very nice addition

Re: [DISCUSS] Gogo commands completion data

Not sure if the script approach is good for the long run. What we could do with it though is to provide a script in a magic location in each bundle. The shell could then dynamically add and remove the scripts as the bundles are started / stopped. Does that make sense ? For the long run I thin

Re: [DISCUSS] Gogo commands completion data

Awesome. I will take a look. Let me know for the scr commands, I can tackle that. Regards JB On 10/19/2016 11:30 AM, Guillaume Nodet wrote: I have committed my changes. I still need to replace the karaf scr commands with the native ones and write the completion data for it. 2016-10-12 17:57

Re: [DISCUSS] Gogo commands completion data

I have committed my changes. I still need to replace the karaf scr commands with the native ones and write the completion data for it. 2016-10-12 17:57 GMT+02:00 Guillaume Nodet : > I'm working on trying to nicely integrate gogo commands. > The new gogo-jline bundle has a very nice way to allow

Karaf feature service and AbstractRetryableDownloadTask

Hello Recently I worked a bit on pax-url-aether and among other fixes (like timeout configuration or improved error reporting), I added 2nd variant of org.ops4j.pax.url.mvn.MavenResolver.resolve() methods - an exception can be passed as additional argument which should be treated as _hint_. This _