Community
Participate
Working Groups
Through a GitHub fork, I worked on the mavenization of the Java implementation of the MQTT client. It allows to use the MQTT client library as a project dependency: - in Eclipse by using the m2e plugin (http://www.eclipse.org/m2e/) - in a standard Maven project or any build tool that is compatible with the Maven dependencies (Ivy, Gradle, sbt, Grape, Buildr...) The "package" Maven phase creates the Manifest file for OSGi bundle. It also allows to launch unit tests easily, and to execute continuous integration builds (using free platforms such as BuildHive, https://buildhive.cloudbees.com/). Please note, that I added Nick and Dave as core developers (https://github.com/ndeverge/paho.mqtt.java/blob/mavenize/pom.xml), by refering to the People wiki page (http://wiki.eclipse.org/Paho/People). And if everyone is ok, I'll release a first version and publish the artefact in the newly created Eclipse Maven repository (http://wiki.eclipse.org/Maven). git repo: git://github.com/ndeverge/paho.mqtt.java.git branch: mavenize full link: https://github.com/ndeverge/paho.mqtt.java/commits/mavenize I wrote all this code and have the rights to contribute it to Eclipse under the eclipse.org web site terms of use.
@Nicolas I found the dependency in parent pom.xml is 'jpaho-mqtt-client'. Is that a mistake or there is something I've missed? (In reply to comment #0) > Through a GitHub fork, I worked on the mavenization of the Java implementation > of the MQTT client. > > It allows to use the MQTT client library as a project dependency: > - in Eclipse by using the m2e plugin (http://www.eclipse.org/m2e/) > - in a standard Maven project or any build tool that is compatible with the > Maven dependencies (Ivy, Gradle, sbt, Grape, Buildr...) > > The "package" Maven phase creates the Manifest file for OSGi bundle. > > It also allows to launch unit tests easily, and to execute continuous > integration builds (using free platforms such as BuildHive, > https://buildhive.cloudbees.com/). > > Please note, that I added Nick and Dave as core developers > (https://github.com/ndeverge/paho.mqtt.java/blob/mavenize/pom.xml), by refering > to the People wiki page (http://wiki.eclipse.org/Paho/People). > > And if everyone is ok, I'll release a first version and publish the artefact in > the newly created Eclipse Maven repository (http://wiki.eclipse.org/Maven). > > git repo: git://github.com/ndeverge/paho.mqtt.java.git > branch: mavenize > full link: > https://github.com/ndeverge/paho.mqtt.java/commits/mavenize > > I wrote all this code and have the rights to contribute it to Eclipse under the > eclipse.org web site terms of use.
(In reply to comment #1) Well done ! It was a mistake. I updated the code. Thanks a lot ! > @Nicolas > I found the dependency in parent pom.xml is 'jpaho-mqtt-client'. Is that a > mistake or there is something I've missed? >
Created attachment 219620 [details] mavenization of the paho project
Starting from Nicholas' excellent contribution, I mavenized the latest paho code from the eclipse git repository. The additional change I did was moving the localization resources under src/main/resources as suggested by the maven standard directory layout. The attached zip contains the full directory of the project.
I know others who are starting to Mavenize their projects based on Paho (e.g. the forthcoming MqGnatt from Arlen) - Dave, any reason why we shouldn't look at merging this contribution?
Yeah, I'd like to see this contribution merged. Because it could ease the integration of the client library on third party apps. (In reply to comment #5) > I know others who are starting to Mavenize their projects based on Paho > (e.g. the forthcoming MqGnatt from Arlen) - Dave, any reason why we > shouldn't look at merging this contribution?
+1
Assigning to Dave, although Nick or I may pick this up shortly.
+1 I would like to add an MQTT module using Paho to the vert.x project. Our standard build template uses the Maven repositories to download dependencies - and I'm unwilling to add a Paho jar to a source code repository. This seems like an easy win and will make a big difference to your projects' accessibility.
Makes perfect sense. We should prioritise getting a Paho build into Maven Central. Raising the priority on this one.
@Andy if you need some support with the Maven support for the latest Paho source code, I'll be happy to help.
(In reply to comment #11) > @Andy if you need some support with the Maven support for the latest Paho > source code, I'll be happy to help. Thanks. There's an active discussion on a couple of open bugs which are being worked on the develop branch. I think Marco has a patch which can be modified too. Appreciated.
Now that the timing bugs are fixed this is our number 1 priority. Blocks all work on the tooling until delivered.
Hi, I just rewrote the Mavenization support from the latest development branch. - I create a branch from the "development" branch - I moved source files to have a Maven-like structure - I created pom.xml files (compilation, OSGI, Java 1.2 compat, filtering with tokens) Please test it and send me any feedback if I missed something. The updates are available on my Github repository: git repo: git://github.com/ndeverge/paho.mqtt.java.git branch: mavenize full link: https://github.com/ndeverge/paho.mqtt.java/commits/mavenize I wrote all this code and have the rights to contribute it to Eclipse under the eclipse.org web site terms of use.
+1 for this feature. I'd like to use the Paho client for a Jenkins MQTT notification plugin.
(In reply to comment #14) > The updates are available on my Github repository: > git repo: git://github.com/ndeverge/paho.mqtt.java.git > branch: mavenize > full link: > https://github.com/ndeverge/paho.mqtt.java/commits/mavenize > > I wrote all this code and have the rights to contribute it to Eclipse under > the eclipse.org web site terms of use. Could you please attach a patch to this bug consisting of the diff between the two branches?
Created attachment 229674 [details] Patch to create Maven artifacts
Since the patch is large (because basically the whole source tree gets moved to a Maven structure) I have submitted this for IP review. CQ #7183
I just noticed that you've again made the ArtifactId jpaho (and I'm tempted to just drop paho from the naming since the group id specifies org.eclipse.paho already). I don't think you pulled in the changes that Marco made on top of your last patch either?
Set component to MQTT-Java Awaiting feedback from Nicolas and/or Marco.
Sorry, I didn't take into account the Mike's updates. Do you need me to merge these, or can you do it ? I'm a little busy this week, so I'd not be able to do it until the end of the week. For the IP part, I was in touch with Sharon Corbett; it should be ok now.
Is there any progress on this? We just released a milestone of the Spring Integration MQTT extensions using the version in v0.2.1 tag from GitHub; but it's a pain having to have users install it into their local repo. We can temporarily host the jar in our own public repo, but we want to make sure the group and artifact (and version) are right before we do that. Thanks.
(In reply to comment #22) > Is there any progress on this? We just released a milestone of the Spring > Integration MQTT extensions using the version in v0.2.1 tag from GitHub; but > it's a pain having to have users install it into their local repo. > > We can temporarily host the jar in our own public repo, but we want to make > sure the group and artifact (and version) are right before we do that. > > Thanks. Thanks Gary. As I communicated privately, when we get this done I anticipate using: <groupId>org.eclipse.paho</groupId> <artifactId>mqtt-client</artifactId> <packaging>jar</packaging> <version>0.3.0</version> (it seems redundant to add "java" or "paho" in the artifactId in the end) Version is likely to be 0.5 which is the current milestone we are working towards. Dave has said several times that he has IBM internal code he wants to merge into the Java client before we put this into Maven, and that's why there's a blocker on this bug. I personally get asked about this 2 or 3 times a week now so I am very keen to close it off! Workload-permitting, I would hope to have the maven bundle done within a day or so after that code hitting Git. Thanks very much for your work on the Spring Integration extension, very exciting stuff!
Raising this to "blocker" as it blocks release and automated build setup, as well as impacting on a number of non-Eclipse projects looking to consume the Paho Java client.
It's very annoying for people using build tool. Why you don't simply commit it in the repo, even on the develop branch ? So with the pom.xml in the repo, we could easily integrate the client in our private repository. As today I'll use Nicolas's github fork.
(In reply to comment #25) > It's very annoying for people using build tool. Why you don't simply commit > it in the repo, even on the develop branch ? +1
It will be committed next week. Maven and the like is new to a number of us so has take a little while to get up to speed and understand what we are doing with it.
Currently underway in the develop branch - working with Al S-M on this right now. You can grab the basic source tree + simple pom.xml now, we are working on enhancing it. Also working on automated Hudson builds @ Eclipse. The work is based on the patched from Nicolas and Marco, with a few tweaks to accommodate agreed naming etc. Thanks for all the inputs.
Hi, Thanks to see it,I'll test it tomorrow. Just a quick highlight : your XML file should have a comment header referencing the EPL no ?
Thanks for the feedback - this was a first pass - I will add that in the next commit :-)
works fine for me.
Created attachment 233087 [details] Updated pom.xml to publish to eclipse repo Given Paho now has a repo on the Eclipse Nexus and a Hudson job for building the Java client I have incrementally updated the pom.xml file which should allow the publication of binary, source and doc jars.
I posted this on the mailing list earlier but it's probably worth reproducing here too; Paho now has a Hudson build job and a Nexus repo in the eclipse infrastructure, and building off the work of Andy, Nicolas and Marco there is the start of a maven pom.xml in the java client. Put together (with Ian's assistance) I kicked off a build yesterday evening which successfully built and published the artifacts, which can be found under; https://repo.eclipse.org/content/repositories/paho-snapshots/ There is also a paho-releases repository for when the project is ready to do a release.
Hello, I took a quick look at the latest Maven updates on the "develop" branch. Bug: - the org.eclipse.paho.client.mqttv3.internal.ClientComms class is not filtered. As a result, the VERSION and BUILD_LEVEL are not set at compile time (http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.java.git/tree/org.eclipse.paho.client.mqttv3/src/main/java/org/eclipse/paho/client/mqttv3/internal/ClientComms.java?h=develop#n40) For that, take a look at this commit https://github.com/ndeverge/paho.mqtt.java/commit/c89c1517bfb4fdfc59de790f0fb9d631b8c4a920 Nice to have: - use the "maven-bundle-plugin" to automatically generate the MANIFEST.MF for OSGI (https://github.com/ndeverge/paho.mqtt.java/blob/mavenize/org.eclipse.paho.client.mqttv3/pom.xml#L33) instead of using a hard coded MANIFEST - a top level POM containing metadata about the project (authors, licence...), such as https://github.com/ndeverge/paho.mqtt.java/blob/mavenize/pom.xml - maybe we need to compile with Java 1.2 compatibility mode to keep backward compatibility ? Please let me know which features are important in the list above, and I'll try to deliver a patch later this week. Regards, Nicolas
This is now done, and snapshots are published to Eclipse Nexus.
