Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] plan for java client?

Hi Pahoers,

First, congrats on your successful 0.9 release review.

I'm doing some work upgrade ECF's MQTT remote services provider [1], and so thought I would try out the latest build of 0.4.1 prior to Juno RC1.  I went to [2] and picked up today's build...which was/is [3].   A couple of thoughts/comments about this build as a consumer

1) Bundle-Version is 0.4.1.SNAPSHOT

although I understand what Bin Zhang writes below about this, I feel I should point you at this [4] from the Versioning Guidelines wrt the qualifier segment.   I looked in the 5/1 jar, and it has the same qualifier (0.4.1.SNAPSHOT).   One reason the qualifier matters to consumers (like ECF/me) is that it can make installing the latest version very error prone...especially once you've deployed and consumers are using multiple versions of the Paho java client...after several releases.

2) I see that the singleton bit is set for the bundle...i.e:

Bundle-SymbolicName: org.eclipse.paho.mqtt-client;singleton:=true

Is this singleton declaration actually needed?   If not, I would recommend taking out the singleton:=true attribute...so that it would be possible to use multiple versions of paho java client in a single OSGi framework.   For OSGi it's a best practice to make bundles non-singleton...if possible.   But as I'm sure you realize, that would also mean that the qualifiers would have to be different for different versions.

3) WRT the symbolic name, Bin Zhang says (below):

It seems it not always the case, e.g. eclipse jetty doesn't follow the convention also.
I think the symbolic name with groupId prefix will be more identifiable.

I understand.   There is a potential problem that can result from this, however...and that's while org.eclipse.paho.mqtt-client is guaranteed to be globally unique (because of org.eclipse.paho prefix), the filename 'mqtt-client' alone is not.  This separation between the jar name and the bundle name...while not fatal...can result in some very complex and ambiguous situations for consumers...particularly when multiple versions have been released/are available.  Obviously you have not yet had multiple releases for Paho java client, but once you do this will matter to consumers.

4) A question:  Are you going to make the paho java client bundle available in a P2 repo...in addition to maven repo?...That would then allow direct install into Eclipse...and it would then allow all other EF project to more easily consume each other's work...without having to redistribute multiple copies in their own repos (e.g. a part of ECF depends upon a bundle from EMF).  That's the primary reason it's a simultaneous release requirement, I believe.

Good to see the release coming together...and good luck.

Scott

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=420896
[2] https://repo.eclipse.org/content/repositories/paho-snapshots/org/eclipse/paho/mqtt-client/0.4.1-SNAPSHOT/
[3] https://repo.eclipse.org/content/repositories/paho-snapshots/org/eclipse/paho/mqtt-client/0.4.1-SNAPSHOT/mqtt-client-0.4.1-20140502.040047-69.jar
[4] https://wiki.eclipse.org/Version_Numbering#When_to_change_the_qualifier_segment


On 4/14/2014 1:35 AM, Bin BJ Zhang wrote:
Hi Scott,

I updated the manifest.mf in maven build according to your comments, except for the following two:


1.  Bundle-Version: 0.4.1.SNAPSHOT

This is generated by maven-bundle-plugin according to the version defined in pom.


2. Symbolic name

// One other observation/question:   I see the jar file name is:
// mqtt-client-0.4.1-20140407.102244-44.jar and the bundle symbolic name
is:  org.eclipse.paho.mqtt-client.
// At one time I thought there was some convention around having the jar
name match the symbolic name + // the version...e.g.:


It seems it not always the case, e.g. eclipse jetty doesn't follow the convention also.
I think the symbolic name with groupId prefix will be more identifiable.


Best Regards,
Bin Zhang(张斌)
--------------------------------------------------------------------------------------------
WebSphere MQ, IBM China Software Development Lab
Notes:   Bin BJ Zhang/China/IBM
E-Mail:  zhbinbj@xxxxxxxxxx
Address: Ring Building 3F, ZhongGuanCun Software Park,

DongBeiWang West Road No.8, Haidian District, Beijing, 100193, China
-------------------------------------------------------------------------------------------




From:        Scott Lewis <slewis@xxxxxxxxxxxxx>
To:        paho-dev@xxxxxxxxxxx
Date:        2014/04/08 07:48
Subject:        Re: [paho-dev] plan for java client?
Sent by:        paho-dev-bounces@xxxxxxxxxxx




Hi Al,

On 4/7/2014 3:43 AM, Al Stockdill-Mander wrote:
> Scott,
>
> Thanks for your feedback, very useful. If it helps we actually publish
> nightly dev builds to a nexus repo hosted by eclipse (The recent
> builds are actually a mix of regular and gerrit triggered builds while
> I was configuring gerrit, the most recent is back to being just a
> build from the develop branch). You can download the jars directly
> here;
>
https://repo.eclipse.org/content/repositories/paho-snapshots/org/eclipse/paho/mqtt-client/0.4.1-SNAPSHOT/
> Given your points 2 and 3 I would appreciate it if you could take a
> look at the output and let me know if it needs any work.

Sure.   Below is the manifest for 0.4.1.SNAPSHOT bundle for the
following jar:

mqtt-client-0.4.1-20140407.102244-44.jar

Below I intersperse comments and suggestions.

Thanks,

Scott

Manifest.mf from mqtt-client-0.4.1-20140407.102244-44.jar

Manifest-Version: 1.0
Bnd-LastModified: 1396866160489
Build-Jdk: 1.6.0_45
Built-By: genie.technology.paho
Bundle-Description: The Paho project provides scalable open-source imple
 mentations of open and standard messaging protocols aimed at new, exist
 ing, and emerging applications for Machine to Machine (M2M) and Interne
 t of Things (IoT).
Bundle-DocURL:
http://www.eclipse.org/paho
Bundle-License:
http://www.eclipse.org/org/documents/epl-v10.php
Bundle-ManifestVersion: 2
Bundle-Name: mqtt-client
Bundle-SymbolicName: org.eclipse.paho.mqtt-client
Bundle-Vendor: Eclipse Paho

// Scott:  In looking at other bundles, I think the convention is:
// Bundle-Vendor:  Eclipse.org - Paho
// There's also a convention that the values for Bundle-Name and
Bundle-Vendor use values from a properties
// file...e.g.

// Bundle-Name: %bundle.name
// Bundle-Vendor: %bundle.provider
// Bundle-Localization: bundle
// and in separate bundle.properties file (e.g.):

//
############################################################################
// # Copyright (c) 2010 Composent Inc., IBM and others.
// # All rights reserved. This program and the accompanying materials
// # are made available under the terms of the Eclipse Public License v1.0
// # which accompanies this distribution, and is available at
// #
http://www.eclipse.org/legal/epl-v10.html
// #
//
############################################################################
// bundle.name=ECF Core API
// bundle.provider=Eclipse.org - ECF

// I believe that having these manifest values in a separate properties
file
// allows multilanguage handling in Eclipse...so that the bundle name
// and bundle vendor can be presented in appropriate language in Eclipse
About listing...with
// language translation done of all properties files done by the Babel
project.

Bundle-Version: 0.4.1.SNAPSHOT

// Scott:  You might want to look at the EF version numbering spec...i.e:
//
http://wiki.eclipse.org/Version_Numbering.  Among other things,
projects that want to participate in the
// simultaneous release are required to use 4 part version numbering.  
Now I know that maven has
// conventions around the use of 'SNAPSHOT'...so it might be useful for
you to get the input of someone like
// David Williams, who is the usual releng person for the simultaneous
releases.   One way to get a hold
// of David for his opinion about this is via the cross-projects mailing
list:
//
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Created-By: Apache Maven Bundle Plugin
Export-Package: org.eclipse.paho.client.mqttv3;version="0.4.1.SNAPSHOT";
 uses:="javax.net,org.eclipse.paho.client.mqttv3.logging,org.eclipse.pah
 o.client.mqttv3.util",org.eclipse.paho.client.mqttv3.util;version="0.4.
 1.SNAPSHOT",org.eclipse.paho.client.mqttv3.persist;version="0.4.1.SNAPS
 HOT";uses:="org.eclipse.paho.client.mqttv3",org.eclipse.paho.client.mqt
 tv3.logging;version="0.4.1.SNAPSHOT"

// Scott:  I personally would like to not see any part of the qualifier
for the Export-Package
// version specification...e.g. why not just "0.4.1"?...rather than
"0.4.0.SNAPSHOT".   This
// isn't required/fatal by any means, but as a consumer I find it
off-putting to have
// anything in the qualifier for package export versions...because then
things look different
// between snapshot releases and 'real' releases.

Import-Package: javax.net,javax.net.ssl,org.eclipse.paho.client.mqttv3.l
 ogging;version="[0.4,1)"

// Scott:  I know there can be good reasons for it, but why is the
logging package both exported
// and imported by this bundle?  Can you do with out it?

Tool: Bnd-2.1.0.20130426-122213

// Scott:  I don't see and Bundle Required Execution Environment
(BREE)...e.g. here's one for one of our
// bundles:

Bundle-RequiredExecutionEnvironment: CDC-1.1/Foundation-1.1,
 J2SE-1.4

// I believe a properly set BREE is required for the simultaneous
release requirements...i.e. see here
//
http://eclipse.org/indigo/planning/EclipseSimultaneousRelease.php and
//  
http://wiki.eclipse.org/Execution_Environments

// For running in Eclipse, I would suggest adding this
// Bundle-ActivationPolicy: lazy

This is an OSGi standard header that Eclipse bundles traditionally
use...since Eclipse uses lazy startup.

// One other observation/question:   I see the jar file name is:
// mqtt-client-0.4.1-20140407.102244-44.jar and the bundle symbolic name
is:  org.eclipse.paho.mqtt-client.
// At one time I thought there was some convention around having the jar
name match the symbolic name + // the version...e.g.:

// org.eclipse.emf.ecore_2.10.0.v20131209-0519.jar for emf ecore...with
version 2.10.0.v20131209-0519.

// I can't recall right at this moment why that convention was put in
place...and it may not be necessary any // longer...with more recent
versions of OSGi and Eclipse...but it might be worthwhile inquiring
about it with
// someone that remembers why it was done that way.

Thanks,

Scott


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev




_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev


Back to the top