As the 1.8 release is out now, it is time for all your developers to look what comes next. As mentioned in my blog post, I would like to ask you all to move over to the new runtime and make sure that your add-ons work on 1.8 as well as on 2.0. Since the runtime bundles will vanish from the 1.x repo very soon, this is the right time to use the new IDE setup that I have prepared. This should allow you to work on the code as you worked before (with a few exceptions), regardless whether it is openHAB 1, openHAB 2 or Eclipse SmartHome.
@teichsta will prepare a PR on openHAB 1 to globally apply the new code formatter - so until then, it is probably time to take a rest and continue working until the repo is updated accordingly.
If you have any questions regarding the new IDE setup, please ask right here!
I installed the OH2-ide with your provides eclipse installer about a week ago and read somewhere, that you planned some updates. Will those automatically appear in the Eclipse installation or should I better do a reinstall?
I actually do not know exactly myself… So the safer option is to do a new install. Anyhow, this will be quick, because all Eclipse stuff is shared between different installations, so they won’t be downloaded again and also won’t require any additional space on your hard drive.
Just one comment on the new ESH code formatter: in …GenericBindingProvider.java, I added a bunch of valid item configuration examples to javadoc of the class. Now the formatter forces line-breaks and the item-examples are now spread over two lines per item, which reduces readability a lot. So just to let you know…
I imported OH1 and OH2 addons into the same workspace, as supposed in the IDE-Setup article. Now I created an OH2 skeleton for RWE Smarthome with the same name as the OH1-binding (the latter already already exists in the workspace). Eclipse unfortunately does not import the OH2-binding because of the same OH1-binding-name.
Any idea how to fix this? Options could be:
create separate workspaces for OH1 and OH2
change name to rwesmarthome2
somehow get Eclipse to import it anyway <- my favorite!
Thanks, however I have to admit I do not like the “guided ide setup” you documented.
You write “the project build is completely mavenized” with very normal prerequisites: git, mvn and oracle jdk8.
You also write that other IDE like netbeans, intellij, … could potentially be used (being the project a normal maven one).
Well, the 100% of us (that is developers, people using the repo) already have their own eclipse environment, with their own plugins, …
Why not just add the manual setup procedure that i guess is just: “import as maven project from this github repo”?
Or may be other stuff related to formatters …
I guess that the 100% of us do not need to reinstall eclipse with the automated installer (that I very personally totally dislike, as I disliked the yoxos setup, even if that is not very relevant … may be many other do like the automated setup)
The required plugins should be already installed with all the last versions, luna & mars included.
P.S. The video of the IDE Setup is no more valid, the “openhab 2 development” project shown in the video is no more present in the OpenHAB project list in the github group
well … that is exactly why the workspaces exist.
Yes, you should use a different workspace (on my machine i have about 20 to 30 workspaces … (just edited after check … 59 workspaces), it is very common to use different workspaces for different “environments”)
Very easy: Simply remove the openHAB 1 project from your workspace and import the openHAB 2 one. You will notice that whereever an OH2 version already exists, the OH1 binding isn’t imported in the workspace either.
Because is it not that simply. Please feel free to add a tutorial for setting up your individual IDE - it would be nice to have that documented as well of course.
But as this will end up in probably 20 manual steps with many possible errors that beginners can make, this is not what helps people to quickly become contributors and that’s what the automated IDE setup is meant for. The real techies like you can of course do it any way they like.
That’s why I had already added a note there. If you have the time, feel free to produce a new screencast showing the latest version.
I decided to reinstall the environment with the new system. I’ve installed all the working sets - this looks nice
However… I then tried to import the OH2 zwave binding. I created a new branch in the OH2-addons repo and pulled my repo off Github. I then went to Eclipse and expected to be able to import this project into the workspace, but I can’t - Eclipse tells me that the workspace is already included! If it is, it’s hiding, and since I’ve not included it previously (this being a completely new install) I was a little surprised…
So, my first question - how does Eclipse decide this workspace is already installed? When I first started the OH2 ZWave development, I copied the OH1 binding - even though it was in another folder, Eclipse wouldn’t let me import it into the workspace as it had the same namespace / project name as the OH1 binding and I needed to rename it before I could import it! Am I running into the same issue here - having imported all the repos (OH1 and OH2) into the workspace (which I understood from your instructions was ok?) am I now unable to import the OH2 Zwave as Eclipse says I already have a project of this name? If so, how have you got around this with the other projects that are in the same situation (I guess if this is the problem, then they were imported into an IDE that didn’t have both the OH1 and OH2 working sets?).
Another thing that makes me think that this is the issue is that if I look in the working set contents, there is only the OH1 zwave binding…
Any thoughts? Is this supported, or is having both the OH1 and OH2 addons sets in the same IDE unsupported?
Let me try to explain:
If you select all options in the IDE setup (what you seem to have done), it will checkout all the repos in the git folder of the installation. So physically, ALL projects are then on your harddrive.
Next, the setup imports projects and arranges them in working sets. Not all projects are imported, you can see the filtering for the openHAB1 projects here. My criteria were:
the whole workspace should have no errors (so there are a few projects that are excluded, because they do not yet compile against the new runtime)
if an OH2 version of a binding exists, this is chosen over the OH1 one.
Note that this is only the default workspace setup. You are now completely free to remove projects from the workspace and import others (e.g. if you want to work on an OH1 binding that isn’t automatically imported).
In your case, the OH1 ZWave binding is already in the workspace. If you delete it there (or rename it), you should be able to import your OH2 ZWave binding into the workspace with no problems.
No, it is perfectly possible to work on a mix of OH1 and OH2 bindings - this is exactly what it is made for.
The only thing not possible by default is to have the same binding in two versions, but it also would not make any sense to launch a runtime with ZWave1 and ZWave2 on it at the same time, right? But as explained, if you simply rename one of the projects, even this is possible.
Yes, file->rename does the same as F2.
Sorry, I didn’t see that this also changes the manifest. Simply revert this change and you are all fine. The only change that will locally remain is the .project file.