Hi Scott,
I'm working on the packaging of the Java client for 0.9.0. Creating
an OSGi bundle, proper name, p2 repo etc. It's the first time I've
done this for a while (say 5 or 6 years) and I've never created a p2
repo, so I'm learning it all as I go (I'm following the Tycho
tutorial/examples). I imagine that it's going to take me a few days
of next week (1.5 days so far, and there is a public holiday for us
on Monday).
1) Bundle-Version as I have it is 0.9.0.201405021602
2) singleton is currently still set to true because the Eclipse IDE
advised me to do so (I can't remember the reason offhand, but if I
remove it I'm sure it'll let me know)
3) Bundle-SymbolicName as I have it is currently
org.eclipse.paho.client.mqttv3
4) yep, working on it. Got to the stage of working out how to
"create" a p2 repo, as the Maven build was complaining.
I have the Maven Grioup Id as org.eclipse.paho.client and the
Artifact id as mqttv3, as the Tycho tutorial says "Note: Tycho requires that the artifactId
in the POM is the same as the Bundle-SymbolicName in the
OSGi manifest, and that the versions match (with .qualifier
replaced by -SNAPSHOT) "
Any advice to make this quicker for me is welcome :-)
I'm also working on packaging the MQTT client Eclipse view (will
also be in the p2 repo) and Swing sample GUI application (which may
not be as it is meant to be run standalone).
I'm also working on the builds of the C client and packaging of the
_javascript_ client for 0.9.0, so they'll be ready as soon as I can
complete them.
Ian
On 05/02/2014 11:31 PM, Scott Lewis
wrote:
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
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Committer on Paho, Mosquitto
|
