Hi Scott,
Bin and Al have been working at the packaging of the Java client,
and the current state can be found at:
http://build.eclipse.org/technology/paho/Java/
I think we still need to allow different versions of the plugins to
be installed. We'd like to know if this repository looks right
for/to you, or if any or what other changes might be needed.
Thanks
Ian
On 05/22/2014 06:07 PM, Scott Lewis
wrote:
Howdy,
Is there a snapshot build of the revised/updated paho java
client available? If so I would like to begin technical work
to use it as an ECF remote services provider...and I currently
only have 0.4.1 snapshot links (i.e. before the changes/fixes
previously discussed on this thread).
Thanksinadvance,
Scott
On 5/2/2014 5:38 PM, Scott Lewis wrote:
On 5/2/2014 4:51 PM, Ian Craggs
wrote:
I'm just trying to follow whatever build/naming/versioning
conventions are the right ones for Eclipse - info seems to be
scattered across a lot of web pages.
The primary one for EF projects is: https://wiki.eclipse.org/Version_Numbering
The OSGi semantic versioning one I give below is similiar...in
many respects...to the one above. It's more recent, however,
and strictly concerns OSGi bundles (as opposed to eclipse
plugins...which are a type of OSGi bundle). I would use it for
reference.
The Export-Package is not versioned at the moment.
I believe that's ok...not required to be there...but it is a
good OSGi practice to provide package-level versions...but I
wouldn't worry too much about it...because you are still
pre-1.0.0.
There's a plugin.xml in the bundle that I'm
building.
I would try deleting it from the project...as it doesn't look
like you are using it...at least in the jar that you've built
over the past few days.
And yes I moved the bundle version to 0.9.0 but
that was because it seemed to make sense to follow the release
number.
Generally, your bundle versions should *not* be the same as the
release number. The reason for this is that as per the
Version_Numbering wiki page, changing the bundle's major or
minor segment should be done when changes occur *inside the
particular bundle). For example, let's say that you add a
class to an existing package. This should mean that the bundle
version minor segment will/should change...e.g. 0.5.1 ->
0.6.0. This indicates to consumers that a non-breaking API
change (addition of a new class in this case) has taken place
for that bundle. This is independent of what release version
you are on...e.g. 0.9.0.
I believe people differ on what should happen with your 1.0.0
release. I think it's reasonable...for your 1.0.0 release in
particular (when you have it). To move all your bundle level
versions to 1.0.0 (unless they are already at or above
1.0)...because that's basically saying to your consumers that:
'here's a solid, non-incubation, 1.0.0 api'. If I'm out of
bounds here I trust that someone will jump on me about
this...and it's admittedly been a while since ECF's 1.0
release...so I may be wrong about this. But you aren't to your
1.0 release yet anyway, so I wouldn't be too concerned about it
for now...and you can get input from others before 1.0.0.
Will probably make sense when I've put all this together ...
One suggestion if you are using Eclipse...once you complete your
release...so that you have something to baseline...you can use
the API tools [1] to help you manage the bundle and API
changes. We find it helpful.
Scott
[1] https://wiki.eclipse.org/PDE/API_Tools
_______________________________________________
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
|