Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Paho downloads


We had a similar question recently and a bug was raised that we did
not have OSGi meta data in our jar. Based on that changes have been
made to the develop branch that should have added the appropriate
If you could take a look at the snapshots repo and let me know how
that works for you.
As for when releases will be, that's a discussion we're having atm,
but i would look to do a 0.4.1 release if there are changes that



On 12/11/2013, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
> Hi Pahoers,
> We at ECF are working on a remote services provider that uses mqtt as a
> transport [1].  What this will allow:  People will then be able to use
> ECF's implementation of the OSGi Remote Services standard to
> communicate/interact via mqtt...with all the devices/systems that
> support it.
> The natural first thing for us to do is to implement a client provider,
> and base it upon the existing Paho MQTT client codebase.
> I've downloaded and started working with the mqtt-client-0.4.0.jar (and
> sources and javadocs)...and have some questions that will help me
> understand how to setup our own projects.
> ECF's projects are all OSGi bundles/plugins...which means the easiest
> way for us to consume the Paho Java client would be to have the Paho
> Java client also be an OSGi bundle (rather than a plain 'ol java jar).
> I understand that the existing jar is *not* an OSGi bundle, but my
> question is:  are there plans to add the OSGi meta-data (mostly in
> manifest) to make it also a bundle?  Or do you expect it to remain a
> java lib/jar indefinitely?
> In either frequently do you expect to do releases?   I'm
> trying to decide whether (for our own development) we should get binary
> releases/ that we can insert them into our bundles...or
> whether we/ECF should build the Paho code ourselves and work from the
> source code in the Paho git repo.  We can do either, but it would be
> quite a lot easier for us if we knew approximately when Paho releases
> were to we didn't have to build from Paho source (with
> possibility of regressions, build breaks, etc).
> One other question:  Is Paho going to be a participant in the Luna
> simultaneous release?
> Thanksinadvance,
> Scott
> [1]
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx

Back to the top