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