New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make lib available in maven central #3

Open
francisdb opened this Issue Jun 3, 2014 · 31 comments

Comments

Projects
None yet
@francisdb

francisdb commented Jun 3, 2014

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

This comment has been minimized.

ekux44 commented Jul 3, 2014

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

@mcicolella

This comment has been minimized.

mcicolella commented Aug 17, 2014

Hi, any news about maven availability?
Thanks

@SteveyO

This comment has been minimized.

Contributor

SteveyO commented Aug 27, 2014

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

This comment has been minimized.

retog commented Mar 9, 2015

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

This comment has been minimized.

pauxus commented Apr 22, 2015

Any updates on this?

@SteveyO

This comment has been minimized.

Contributor

SteveyO commented Apr 23, 2015

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

This comment has been minimized.

ekux44 commented Sep 9, 2015

Bump

1 similar comment
@derjust

This comment has been minimized.

derjust commented Sep 28, 2015

Bump

@SteveyO

This comment has been minimized.

Contributor

SteveyO commented Sep 30, 2015

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

@skhaz

This comment has been minimized.

skhaz commented Sep 30, 2015

Bump

@SteveyO

This comment has been minimized.

Contributor

SteveyO commented Oct 7, 2015

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

This comment has been minimized.

sheungon commented Oct 15, 2015

Bump

@philmatu

This comment has been minimized.

philmatu commented Oct 17, 2015

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

@SteveyO

This comment has been minimized.

Contributor

SteveyO commented Oct 19, 2015

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

This comment has been minimized.

retog commented Oct 19, 2015

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

This comment has been minimized.

Contributor

SteveyO commented Oct 19, 2015

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

This comment has been minimized.

philmatu commented Oct 19, 2015

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

This comment has been minimized.

Contributor

SteveyO commented Oct 20, 2015

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

This comment has been minimized.

pauxus commented Mar 16, 2016

Hi Steve,

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

Cheers,

Stephan

@kimble

This comment has been minimized.

kimble commented May 4, 2016

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

This comment has been minimized.

BaN4NaJ0e commented Jun 28, 2016

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

@mmathys

This comment has been minimized.

mmathys commented Sep 13, 2016

sad thing

@pauxus

This comment has been minimized.

pauxus commented Oct 11, 2016

@SteveyO Just for the sake: Anything new here?

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

@SteveyO

This comment has been minimized.

Contributor

SteveyO commented Oct 11, 2016

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

This comment has been minimized.

andresgomezfrr commented Nov 12, 2016

Any update?

@BartoszKaszewczuk

This comment has been minimized.

BartoszKaszewczuk commented Jan 15, 2017

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

This comment has been minimized.

briceambrosiak commented Jan 22, 2017

+1

@tpietsc1

This comment has been minimized.

tpietsc1 commented May 27, 2017

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

This comment has been minimized.

ThisWillGoWell commented Sep 25, 2017

Bump

@anton-johansson

This comment has been minimized.

anton-johansson commented Dec 29, 2017

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

This comment has been minimized.

amedranogil commented Feb 2, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment