Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9C2F8102EC for ; Mon, 22 Dec 2014 22:30:48 +0000 (UTC) Received: (qmail 9094 invoked by uid 500); 22 Dec 2014 22:30:47 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 8990 invoked by uid 500); 22 Dec 2014 22:30:47 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 8975 invoked by uid 99); 22 Dec 2014 22:30:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Dec 2014 22:30:46 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates 209.85.220.179 as permitted sender) Received: from [209.85.220.179] (HELO mail-vc0-f179.google.com) (209.85.220.179) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Dec 2014 22:30:21 +0000 Received: by mail-vc0-f179.google.com with SMTP id le20so1958563vcb.24 for ; Mon, 22 Dec 2014 14:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=JAdnE6L4nrTNKUz/fR3iPGzO/OR8EXbBKghKLYK+Ge8=; b=X9rd/vRvhGl8sMggXhYORkviN0p0cZSxPOD2savPkr+KjINKEE7ZGaSTnHsmhm6n+W lzrbbzS2G5YeXCxp2zjAEMeMZqf1tZ3ukvImQ0qT1d8uKAll8uFCKfrcE0/veEhXR+6s Xu3zZ0Q3PDPzKCXLe57BJFTbkJ9PAKDjwJg72chGfHW595DYw/c1oAxYoxB4g1fBBNK9 gA+pqIrihLjtS0MRO1lsLpLNMSgEe0m5Y616RcmCWTSx06ph2rGT0qQ9kix5B7WtoauR NT7TRx+fVKuxZ3sNW9SWjBtXLUWq6U3jQNdIKOzM9vVzCPCGtOml3KFeQNtqU5R9j8od 3e/w== MIME-Version: 1.0 X-Received: by 10.52.253.234 with SMTP id ad10mr7235963vdd.54.1419287374515; Mon, 22 Dec 2014 14:29:34 -0800 (PST) Received: by 10.52.36.174 with HTTP; Mon, 22 Dec 2014 14:29:34 -0800 (PST) In-Reply-To: <20141222225702.00005ea2.ecki@zusammenkunft.net> References: <20141222215910.00001d64.ecki@zusammenkunft.net> <20141222225702.00005ea2.ecki@zusammenkunft.net> Date: Mon, 22 Dec 2014 22:29:34 +0000 Message-ID: Subject: Re: [vfs] bundle symbolix name and major version From: sebb To: Commons Developers List Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org On 22 December 2014 at 21:57, Bernd Eckenfels wrote: > Am Mon, 22 Dec 2014 21:43:01 +0000 > schrieb sebb : > >> > a) follow the math lead and make it org.apache.commons.vfs2 (asuming >> > this does not break anything from 2.0 to 2.1) >> >> If the OSGi bundle name relates to the Java package name or the Maven >> coordinates then this might break things. > > Well, 2.0 would be broken, I wonder if it should be fixed with 2.1 > >> What is the OSGi name actually used for? > > The Bundle-SymbolicName is the symbolic name for a JAR. It is together > with the version uniquely identifying a bundle in OSGi. OK, so provided that VFS does not re-use version numbers then AFAICT a fixed name should be OK from that particular point of view. > It is mostly used for other jars to depend on it with "Require-Bundle". > However require-bundle is seldomly used (normally you import packages > instead) > > The bundle plugin uses by default the group.artifactid, but that does > not mean it is required to add major versions. I guess it would however > not harm to have a different ID if the packages change, as the bundle > would not be useable for an older consumer anyway. > > I guess it is mostly a question on tooling, if you want to see that > there is a new (major) version of a bundle available (which you would > only see if you keep the same symbolic name). But if we always use the same symbolic name, it may look as though an app that was built using VFS2.0 will just be able to use VFS19.2 without any adjustments. However, that may not be the case. In order to only identify jars that are upwards compatible, the OSGi name needs to change whenever this changes. So I can see why the default is group.artifactId. Looks like any other choice would have disadvantages. > Gruss > Bernd > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org