Make lib available in maven central

[francisdb]

Adding jars in lib folders is not the way we do things today :-)

Please make the jar/javadoc available on maven central, a guide can be found on the following url: http://central.sonatype.org/pages/ossrh-guide.html

[ekux44]

Especially now that Gradle (which defaults to maven central) is the Google-sanctioned way forward for Android development

[mcicolella]

Hi, any news about maven availability? Thanks

[SteveyO]

As the Java SDK has only had a couple of updates in the last year, it was not something that was previously considered. However, as there is a community demand this is now under internal discussion. In the next few weeks we expect to release a new 'major' version of the Java SDK so this would be a good time to integrate with Maven. I will post an update as soon as I have more information.

[retog]

looking for hue and maven I stumbled across this: http://mvnrepository.com/artifact/org.ow2.chameleon.fuchsia.base.philips-hue/org.ow2.chameleon.fuchsia.base.philips-hue.huedsk-bundle/0.0.2. This exposes several com.philips.lighting.hue.* packages, haven't had a closer look at it.

[pauxus]

Any updates on this?

[SteveyO]

No updates sorry. Firstly, the link posted by retog is not official, no idea what that is so I wouldn't recommend using it, the /lib folders (in the QuickStart or Java Swing App) will always have the most up-to-date jars.

Next month there will be a new Java SDK release (with some 1.7 bridge features included + bug fixes) and in a couple of months time I will have some news on this.

[ekux44]

Bump

[derjust]

Bump

[SteveyO]

Not forgotten about this. I will push for an answer/decision next week and post an answer then. Apologies for the delay.

[skhaz]

Bump

[SteveyO]

I have had approval to do this so looking at it now. Hope to have an update soon.

Edit - Currently in process, this doesn't seem as easy as it should be. Am getting a variety of errors when trying to upload the .jars to Maven Central so have requested support.

[sheungon]

Bump

[philmatu]

Bump... Your latest hue bridge update broke my entire library I wrote myself a few years ago. This is definitely needed now.

[SteveyO]

A few things here: Firstly bumping an issue I am currently working on (and commented on last week) is not going to speed the process in any way shape or form. I started this last week but had some Maven issues when trying to deploy the jars into the Central Repository, this week I will try a non-Maven approach.

When you say the latest Hue Bridge update broke your entire library, can you elaborate on this please.? What exactly was it that broke your library. Whenever we change something in the bridge that could potentially affect 3rd party libraries or apps we always contact all the developers (for which we have contact information), and post a news items on www.developers.meethue.com.

Also, I can't see how the new bridge firmware and this issue is related. I have not updated the Java SDK for 1.10 API firmware, so nothing has changed. The latest SDK .jars are in the /libs folder (in either QuickStart of JavaDesktopApp).

Steve

[retog]

Hi Steve, my sympathies regarding the bumps... but maybe you could share the maven issues, maybe its something I've seen before.

Cheers, Reto

[SteveyO]

Hi Reto,

Thanks for the offer of help, but it's now back under control. FYI The progress (or lack of it) is publicly visible at the below link: https://issues.sonatype.org/browse/OSSRH-18117

I made some more progress earlier today with the manual staging approach (fake sources.jar issue is now resolved). In retrospect, I should have chosen this approach at first instead of trying to automate it with Maven. However, I have run into a non-technical issue. The .pom file requires licensing information and a few other bits of info which I currently don't have, so I am currently waiting on this. When I get this info I can continue.

This is where we are at the moment.

Steve

[philmatu]

Steve, sorry to put you on the spot, I was quite angry last week after pressing update on my phone and subsequently discovering that my tablets quit controlling the lights (all custom software that I wrote a few years ago to merge Insteon, Zigbee, X10, and other protocols together). I was not a developer until Saturday when I finally got the time to figure out the problem and correct it. Prior, I was using a third party library on github that has not been updated in 2 years, but it seems to have worked well up until the Oct 9 update.

In the end, It seems like I was running a super old version of firmware on the bridge (probably from the old 1.1 branch it seems). The SSDP discovery failed due to a new search string, and there were various changes in the bulb API. I've since imported the Jars that you've created into a custom, local maven repository that works for now. I'm looking forward to seeing this goto the central repository so that I don't have to support a local copy.

Once again, sorry for putting you on the spot. Thanks for being so responsive to the community!

[SteveyO]

Hi Phil, Thanks for clarifying. Its no problem, we all get angry when technology stops functioning as it should, have all been there. We always try to minimize any changes to the Bridge API that could affect 3rd party apps. There have been very few since my time here. Of course we add new API fields for most new bridge firmware versions, but any half-decent JSON parser shouldn't cause this to stumble. The SSDP discovery issue wasn't one which we anticipated would cause too many problems, but I did write the below page and add it as a news item. Obviously the impact depends on how the developer wrote his M-SEARCH response parser. Maybe this was the issue here. I don't remember emailing all the developers for this one so maybe it was missed.

http://www.developers.meethue.com/documentation/changes-bridge-discovery

Anyway, deviating slightly off course. I will post and update when I make further progress on the Maven issue. Steve

[pauxus]

Hi Steve,

not wanting to bump, but is there any progress here?

Cheers,

Stephan

[kimble]

This should be a no-brainer for Philips! Such a simple things to make it easier for developers to make contributions for free to their proprietary ecosystem.

[BaN4NaJ0e]

Seems that Philips stopped to put any effort into this library. Over 2 years and no progress on this.

[mmathys]

sad thing

[pauxus]

@SteveyO Just for the sake: Anything new here?

If you need assistance in getting the libraries uploaded, I can help.

[SteveyO]

Hi there, Just to let you know I left the Hue team in 2015 (my contract ended and decided to pursue other projects). I will message the guy in charge to see if he can provide an update. Steve

[andresgomezfrr]

Any update?

[BartoszKaszewczuk]

It seems like Philips' repository exists in Sonatype Nexus but it's artefacts are stale as the latest version of Hue SDK available through it is 1.8.3 from October 13th 2015. For those interested:

<repository>
<id>sonatype</id>
<url>https://oss.sonatype.org/content/groups/public/</url>
<name>Sonatype OSSRH</name>
</repository>

<dependency>
<groupId>com.philips.lighting</groupId>
<artifactId>huelocalsdk</artifactId>
<version>1.8.3-SNAPSHOT</version>
</dependency>

Distributing jars as downloads is a not the way to go. It may seem easier to understand for novices but it makes managing dependencies of a bigger project very cumbersome. It amazes me how stubborn/careless Philips is in this area but considering that current (1.8.11 at the time of writing) JavaDoc "artefacts" available to download through their portal are uncompiled directories named huelocalsdk-javadoc.jar and huesdkresources-javadoc.jar rather than actual jars really does say a lot about state of their internal processes. It's even worse considering that distributing libs through Maven is exactly what would help them avoid this kind of issues. I imagine that Philips' will to have devs register at Hue Developer Program in order to access necessary assets is there to give them some control over it but at the same time is probably part of the issue, however if you consider Philips' general developer friendly approach and free access to the program then it does seem strange why that would be keeping them from pusing artefacts to Maven repo. It just goes over my head why addressing trivial issues like this, to ease life of devs who add value to Hue ecosystem and products and whom Philips directly benefits from, is not of high priority.

[briceambrosiak]

+1

[tpietsc1]

Is hue dev already dying? Dependencies in repos and not in lib folders is absolutely necessary for professional development! Especially the new versions. Please do some CI + publish to maven repo.

[ThisWillGoWell]

Bump

[anton-johansson]

Just discovered this project and will definitely try it out. However, as others has already stated, this really must be deployed to Maven Central. That is the standard way these days. Any news from the Philips team?

The only commits after Steve stopped working on this seems to update the JARs directly. No modifications to the code in the repository. Hard to see what's going on.

[amedranogil]

On the mean time, I created a mavenization project, so you can install it and at least use it locally:

https://github.com/amedranogil/PhilipsHueSDK.maven

It is not tested fully. huelocalsdk.jar and huesdkresources.jar are bundled into a single artifact.

if anyone who can deploy in maven central (or compatible repo) can use this to deploy.

[TobseF]

⚠️ The Philips HUE SDK was deprecated on July 1st 2019. So it won't get any updates anymore. But there is another -better - option.

They favor the REST API of the bridge. The offical Get Started guide shows the easy usage of this API.

And if if you want a simple modern typesafe Java API which you can include as Maven / Gradle dependency try the : :point_right:yetanotherhueapi.

So there is no need anymore to include this PhilipsHueSDK jars in your current projects.