You need Maven, that‘s all. Then go to the source root directory and run mvn clean install and there you go. Unit tests are run during the build.
Testing in a live environment depends on what you actually develop: addons, core, ui, …
There are many options for the maven build, just look at the documentation. Most important are probably -pl <dir> for building only a specific bundle and -fae which lets the build continue after an error and fail only at the end. Most important openHAB specific options are -DskipTests and -DskipChecks which skip the execution of tests and the static code analysis during the build.
While it’s true that you can “build and test” from the command line, debugging is another storey altogether. The command line will run the static tests, and compile your code, but there is really no substitute to the IDE when it comes to working through code, observing variables and watching the program flow.
Yes, it’s true that this can be done through printing logging statements, but that’s an extremely painful and inefficient approach as instrumentation needs to be done manually.
If all you want to do is make a small change, then the IDE can probably be avoided - if you want to add larger features, then there’s really no substitute to using a good IDE.
Unfortunately as you say there are a lot of problems with the IDE now - there is a github issue discussing these and I’d recommend discussing your issues there so that they can be resolved.
Thanks, Jan. I’ll give that a shot and see if it lets me make some progress.
I would love to do that, because I’m having some difficulties understanding how the modules are loaded and used in the framework. I think I get it, but to step through the code and watch the system run would be a huge boost to my understanding. A good IDE is a wonderful thing, when they work.
Sadly, it seems I’ve spent more time in environments where there is no IDE and no good debugger than ones where there is. Many years ago, I was a Windows developer, and Visual Studio was a great set of tools. Since then I’ve wound up in strange environments, or cross-compiling, or remote debugging, or running code on near-inaccessible servers, and have had to live and die by logging and print statements.
You’re right, it’s slower going, and you have to work harder. But at this moment I’ll take “slow progress” over “no progress” because that’s where the IDE is leaving me.
I saw your suggestion to do that on the other thread. I’m a bit hesitant to because I’m having trouble following their conversation in that long set of issues, and don’t know if I can reply usefully to any questions they might ask. I have no idea how much of my problems are issues with the system and how many are my own inexperience with the toolset having led me to make a mistake. If that’s the best place, I’ll go there and see how it comes out.
Sure - I suspect we’ve all had o do it over the years, and 20 or 30 years ago it was about the only option. However, things have moved on and we shouldn’t have to step back into the dark ages .
It is of course up to you, but I really think it’s important for people to express their concerns/opinions etc, otherwise nothing will change. The linked thread has been open 6 or 7 weeks, and has had no updates for 11 days so I don’t know that too much will change unfortunately.
Just a suggestion - I’d definitely try VSCode. I’ve been using it for my sony binding development for the last 2 months or so and it’s worked out fantastic. Fast, the debugger is really good and has a decent amount of plugins (refactorings, etc). Biggest downside right now is lack of Nullable attribute support (you only see those errors when do a maven build) and I’d like some better javadoc plugins - but beyond that its worked great.
Note: I haven’t tried it on VS Pro - VSCode is actually ahead of VS in terms of java development but it would be interesting experiment…