Return-Path: X-Original-To: apmail-karaf-issues-archive@minotaur.apache.org Delivered-To: apmail-karaf-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A6A5B91AA for ; Mon, 6 Feb 2012 15:28:24 +0000 (UTC) Received: (qmail 61575 invoked by uid 500); 6 Feb 2012 15:28:24 -0000 Delivered-To: apmail-karaf-issues-archive@karaf.apache.org Received: (qmail 61518 invoked by uid 500); 6 Feb 2012 15:28:24 -0000 Mailing-List: contact issues-help@karaf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@karaf.apache.org Delivered-To: mailing list issues@karaf.apache.org Received: (qmail 61492 invoked by uid 99); 6 Feb 2012 15:28:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Feb 2012 15:28:23 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Feb 2012 15:28:19 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 64C1DCBC4B for ; Mon, 6 Feb 2012 15:27:59 +0000 (UTC) Date: Mon, 6 Feb 2012 15:27:59 +0000 (UTC) From: "Andreas Pieber (Created) (JIRA)" To: issues@karaf.apache.org Message-ID: <954115439.2303.1328542079414.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Created] (KARAF-1187) Add bundle:search command MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Add bundle:search command ------------------------- Key: KARAF-1187 URL: https://issues.apache.org/jira/browse/KARAF-1187 Project: Karaf Issue Type: New Feature Components: karaf-shell Reporter: Andreas Pieber Fix For: 3.0.0 We've discussed a successor of the 2.x "ls -al | grep" and "packages:exports | grep" commands for 3.x. The idea is to provide a bundle:search command allowing commands such as: * bundle:search service=*Command* * bundle:search export=*Command* This should make use of the bundle capabilities / requirements api; a simple match using an osgi filter by iterating through the capabilities Excerpt from the chat: {code} (04:06:22 PM) pieber: gnodet: a VERY simple implementation quite similar to ls | grep and package | grep could be useful (04:06:29 PM) pieber: gnodet: printing more detailed informations about the locations (04:06:42 PM) pieber: gnodet: currently you get only the bundle id when doing a | grep (04:06:49 PM) gnodet: pieber: yeah, as long as you don't go into rewriting a resolver, that's also fine with me (04:07:12 PM) gnodet: but even a simple matching like we have with our:resolve could be handy (04:07:37 PM) pieber: gnodet: why not (04:07:57 PM) pieber: gnodet: I don't want to invest too much time anyhow if we're going to replace it again once the new obr spec is out (04:08:13 PM) gnodet: bundle:search service=*Command* (04:08:21 PM) gnodet: yeah (04:08:53 PM) pieber: gnodet: yep, and the same for bundle (04:08:59 PM) pieber: gnodet: should provide a nice start at least (04:09:15 PM) gnodet: but using the bundle capabilities / requirements api, a simple match using an osgi filter by iterating through the capabilities should work (04:13:54 PM) pieber: gnodet: yeah, sounds reasonable {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira