Solved: Distro OH240 MoJo Maven exception org/objectweb/asm/ClassVisitor


Please assist or guide me in resolving goal org.codehaus.mojo:exec-maven-plugin:1.5.0:java which suffers a class. org/objectweb/asm/ClassVisitor exception while recompiling my (too) old 2.4.0 ESH Distro environment.

Summary Background & (my) reasons

I need to regenerate this ESH-R240 environment for my also too old QNAP TS509 which only can run java8 and so on. I can compile (offline mode) all requirements like ESH10.0.0-oh240, AddonsR240, Addons R113 and HabpanelR240.
Despite many tries, I ḿ no smart enough to understand Eclipse as a whole and more specifically Maven and let alone the incomprehensible use for Tycho. Somewhere on the road (FWIW) this became even more difficult for me when OH-developers since 2020 introduced BND which suited a “majority” better.
Too say the least, I seriously wonder if one ever was successful in a flawless built of openHAB (without CI/Jenkins) using manually executed Maven. Also using Eclipse-IDE turn out to be e no-go option for me as that would require to learn the Eclipse religion which is definitely not my goals in life.

The final activity before installing the code-result, is generating the installation by building “openhab-distro-2.4.0” with (offline) mvn -o clean install -DskipTests=true -Dcheckstyle.skip in building the installation.
Unfortunately this fails doing the packaging of “openhab” with message:
ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.5.0:java (default) on project openhab: An exception occured while executing the Java class. org/objectweb/asm/ClassVisitor: org.objectweb.asm.ClassVisitor

Note: Online built is no longer possible as Jfrog/JCenter has abondoned (the since 2.5.0 to openhab refactored namespace) the old EclipeSmarHhome environment. Using release 2.5.0 is also not an option as that is heavily changed from a mqtt-configuration POV by the developers. And yes, some day and somehow I will have to dump my QNAP, swallow the PIA in migrating to newer things. However, not now :kissing_heart:.

For any details, visit my GitHub - ptrooms/openhab-distro at 08mar24 and view file mvn_install_output_03apr24_17u10.txt for details of the error situation.

Thanks in advance for trying to make me a bit smarter at Home using the fabulous architect-ed openHAB approach.


I can’t help with any of the rest but IIRC the MQTT configuration didn’t change, a new and separate MQTT binding was added. But the MQTT 1.x binding remained usable and unmodified. The addition of the new 2.x MQTT binding did not mean you cannot continue to use the old 1.x MQTT binding.

Is the introduction of the new and separate 2.x MQTT binding what you are referring to with " is heavily changed from a mqtt-configuration POV by the developers"? Because if that’s what’s stopping you from using 2.5 realize you don’t have to use the 2.x MQTT binding. You don’t have to change anything.

And frankly, updating your MQTT configs will be way less work than trying to build all the 2.4 stuff from scratch. And, given the troubles you’ve had you are more likely to be successful too. But, like I said, you don’t have to change your MQTT configs, not unless and until you upgrade to OH 3.0+.

As for the rest, it’s been years since anyone currently working on OH has touched 2.4 code so you might be largely on your own.

1 Like

:+1: Thx Rich, for your response here and your (longtime) support elsewhere.
tldr; I do hope :roll_eyes: someone can me put on a track of remember where to start solving or better understanding what exactly where is happening… TIA.

yes, I’m on my own and hope nonetheless someone can shine en little light on the issue why the distro-built refuses just before finish, to continue ??

  • For weeks, not to say months an in a way years, I’m searching for hints to walk this walk. .
    Problem here is my lack of understanding on how openHAB is to be built or developed (offline).
    Part of this that sometimes the “way of waters” are changed and influenced by a new climate.
    For example compiling 2.4 is different then doing this for 2.5. Somewhere in the past, developers changed from Tycho to BND. Unimportant for users but for me difficult to comprehend while in transition (“on my own path”).

I can understand the simple error - class not found issue - but cannot figure out where or what may have caused that, let alone were to begin in investigating for a solution.
Some (generated?) Java class is somewhere running which is not on shown on any display ???

Regarding the MQTT, I’ve indeed a need to continue the old method.

  • As far as I’ve had/did understand, the new releases of OH would longer would support this as the underluying item-things/core-structure would block this.
    back in the days, this was the primary reason for me to stick on 2.4. instead of going beyond 2.5.0.M2. Nonetheless, compiling 2.5.x will give other headaches.

Thx for the tip and I will (re)investigate if and to what extend, I can run both MQTT1+2 methods simultaneously on newer OH releases. Migrating to 2.5.0+ would be a better option to stay in more compliance with others.

  • Not sure how other will do and feel, but imho the architectural MQTT since 2.5 change is (for me) complex. Though I understand the reasoning from an architectural view; driving items via top-down channels of things, is more clean. However coming from a bottom up (items are my key), migrating top the things-view is a major hurdle for my environment. Of course I do realize there will come a moment leaving my furnished house, crossing the Bridge to other ways.

  • Example, all my, about 300-400 items, are basically item’ized via:
    Switch BedRoom { mqtt=">[mosquitto:...state:default] <[mosquitto:...:state:default]" } ... ...
    which is imho far mar easy to maintain then doing this via channels of related things with items:
    Bridge mqtt:broker:myBroker [ host=“MyIP”…]
    { Thing topic BedRoom… { Channels:
    Type switch : Button1 [ stateTopic=“…” , commandTopic=“…”, on=“ON”, off=“OFF” ] }
    and having the 1:1 related item:
    Switch BedRoom{ channel="mqtt:topic:BedRoom:Button1", autoupdate="false"}

Note: Doing tjhings by Web like using PaperUI (and REST) are great for starters and users but not so much for me where a configuration to detail is to be maintained in large quantities and different combinations. Modifying 100’s of items moving the mouse is no fun when things for more easily is done by a textual oriented edit/update.
Again, I do understand why “communities” like GUI’s as stepstone which is not my way climbing the mountain. Users, use an IT system for their purpose and I see myself partially as “developer” who feels the need to understand a purpose before I use IT.

And because that was done years ago and they’ve been using BDN since then there might not be anyone around who knows the old way. But at the time there were very concrete and technical reasons to make the switch, and making the switch actually delayed the release of OH 3.0 by six months. It was not a decision made lightly and it was quite some work.

Yes, but “new” means OH 3.0 and above. 2.5 still supports the old 1.x style bindings, including MQTT.

You don’t have to compile 2.5. It is available on JFrog and Github along with all the other more recent releases of OH. You can even install it through apt or yum if you want or download it from Download openHAB | openHAB. (Be sure to download the add-ons .kar file and drop that into the addons folder so if 2.5 ever disappears online you’ll still be able to install add-ons.)

You can for 2.5. You cannot for OH 3.0 and above. All support for OH 1.x bindings was dropped in OH 3.0.

However, you could continue to run those in OH 2.5 and use the openHAB Remote binding to mirror those Items in a newer version of OH.

I guarantee it’s less complex than trying to get OH 2.4 to build. And you have people around who can actually help you get that working where with trying to get the buid to work :person_shrugging: .

All it really means is moving your existing MQTT config stuff from the Items to the Things and then linking the Things to the Items. It’s mainly just a move, not a complete and total redo.

Ultimately, you’ll have to move over eventually. Or stay with OH 2.5 (or 2.4 if you get it to build) forever.

Who says you have to move the mouse or even do it through the UI itself. The UI is just a GUI on an API, an API which can be accessed and uses in a number of ways.

Heck, a minority of users don’t use .things files nor the UI. They programmatically create their Things and Items in rules or in scripts/programs external to OH.

Thanks for giving this so much of your thoughtful attention and great to reflect on your experience, I appreciate it very much.

Good to talk about in/outs for (not) doing things (otherwise) but I do hope one can eventually have an(y) idea why the “org.codehaus.mojo:exec-maven-plugin:1.5.0:java” produces a org/objectweb/asm/ClassVisitor exception when I try to rebuilt the OH distribution using mvn.

Yes, I’m aware of some of technical (design) reasons which back in the days, took the team a massive amount of work. Kudo’s to all involved in progressing things from Tycho to BND etc.etc… I’m not in de position to judge things and from MPOV, BND is just another steeple run for make “things” work, which I just barely touch to understand. That things are made more easy, depends on expectations and how to manage operations.

Thanks for the tip that the API might be used in a number of ways. Until now I’ve not considered this as (he’re we go again) to do things which I with ease do by modifying text files.

I’m aware I can install the complete OH package as binary via yum/apt but I want to compile the modified source in order to use the result as new “source” for my QNAP-packager which uses a totally different package method (.qpkg).
Aside for OH220 and OH240, I once was successful to built OH257 which now also no longer compiles either due to the same failure as I’ve experience for 2.4.0.
Aside from rebuilt, OH257 gave all sorts of other madness which during the days, drove me back to OH240 (using ESH-0.10.0-oh240 as its core).

You’re absolutely right, that someday and somehow I have to migrate to new worlds, thus accept new conventions and adopt other outlooks. But not yet and not know because it would require new hardware, new procedures and so on … … for things that are working.

One of reasons I want to recompile is primarily to arrange that some of the bundles can be duplicated (with a new name) to support more than one of the same device in the smarthouse.
F.e. the AVM/DE FritzBox bundle, by design, only support one router per bundle instance. Reprogramming the bundle-source to a multiple support version goes beyond my capabilities.
The solution to adress multiple “singleton address” devices, is running them by their own isolated & full-fledged OH instance. Adding OH instances for new devices has reached the (memory) resource limit of my old 32bit-QNAP.

Have a look at maven versions used around time when ESH 0.10 and OH 2.4.0 was released. Error you see might be caused by too recent (or rather old) tool.
Tomorrow I will try to have a look on stacktraces you provided.

IIRC it would have been a lot of work to be able to support the older releases after the JCenter sunset so we stopped supporting them.

If there is a Zulu 11 or Zulu 17 JDK that works on your old QNAP it maybe easier to create your own openHAB package/installation using that. Then you can still keep using your old hardware with newer OH releases and build custom code using online repositories.

Thx . Adding JDK17 (32bit) let alone JDK11 (64) on my EOL QNAP/32bit/4GB is not really an option. Other things will come into play as my “QNAP” is doing much more and many other (java) things. Modifying its Java set-up - as I’ve tried - in favour of OH breaks other functions. Rebuilding the Java-base of QNAP, myself, is a challenge which I preserve for another ‘future’.

FWIW about Jcenter, basically as I compile R240 fully offline, I just need to supply my local ~/.m2 repo with the correct “artifacts” in order allow compilation. One of the challenges here, is to (try) understand the intrinsics how openHAB is to be built. Itś as like having alle the tools en materials for making a car but lacking the knowledge - of Maven and Eclipse - in which order things has to be done. However, slowly but steadily, making something.

This way of water, aside from doing a OH-Dstro, is pretty succesfull. I can compile all of OH240 locally, except doing the mvn-install- for the “openHAB” distribution which flunks on the class-exception of MoJo.

In between, I’ve solved the specific exception by pulling GitHub - openhab/openhab-util: Util for patching pax-web and installing this to my local ~./m2.
After this the ‘org.openhab.patch.ClassPathUtilPatcher’ is found within via artifact …/org/openhab/util/pax-web-patch/1.0.0/pax-web-patch-1.0.0.jar.
Magic :exploding_head: here is, that this artifact- requirement (amongst others) is no where mentioned.
I could discovered this by "simply’ doing a gitHUB search of ’ ClassVisitor’ which via-via pointed me to GitHub - openhab/openhab-util: Util for patching pax-web where openHAB forks GitHub - dvanherbergen/openhab-util: Util for patching pax-web ; containing '’ who’s mainclass is called by “org.codehaus.mojo:exec-maven-plugin::java” .
What I, until now :face_with_raised_eyebrow:, did not understand that the install-built is actually executing in-line “Java”-routines for doing the install-phase.
Problem two is that the error message of Maven was very Vague in pointing to the actual cause of basically missing call-object problem.

This for here, solves the exception TS problem.

However, while this specific issue step is solved, an other issue showed up: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (archive) on project openhab: Execution archive of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single failed: A required class was missing while executing org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single: Lorg/apache/maven/shared/filtering/MavenReaderFilter; ; which I will try to solve.

FWIW: For exact steps how I rebuilt R240, see GitHub - ptrooms/openhab-distro at 08mar24

Hi Lukas, feel free to have a look but be notief that the actual exception issue looks to be solved by installing GitHub - openhab/openhab-util: Util for patching pax-web to my local ./m2.

Glad you made it working, I did not remember that OH was doing some class-level processing in distro. It come to me as a surprise. :slight_smile:

In case if you miss some of jcenter artifacts you might try (this is URI for maven configuration). It collected some of its artifacts prior mentioned sunset.

Issue which you now face - missing class for maven-assembly-plugin, it is internal maven issue. Can you try with Maven 3.5.4 and see if it will go any forward?

1 Like

tldr; The latest issue was caused by maven-assembly-plugin version 2.5.5, when I downgrade this in the pom.xml to 2.4.1 things goes flawless. :tada: :partying_face:

Thx2all for giving this your attention. Slowly I get some (unwanted) experience with maven but it still feels like in undiscovered country.
Update 05apr24: I appears to me, the problem is in the org.apache.maven.plugins:maven-assembly-plugin version 2.4.1 and above that fail on all kinds (and different) exceptions and dependencies.
Using version 2.4.1 which require additional artifacts org.codehaus.plexus:plexus-archiver:jar:2.4.4 & org.codehaus.plexus:plexus-io:jar:2.0.9 , nicely generates a full fledged zip file. This zip wile is basically used to do an OH installation.
Strange here is that within my “mvn” environment the “tar.gz” format does not seem to be supported. Taken this format generation out in control file .../-openhab-distro/distributions/openhab/src/main/descriptors/archive.xml , things goes 100% flawless.

Problem(s), for me, are fully solved and I can happily do a full offline compile of my “unsupported release 2.4.0” and thus also have no need yet, to upgrade (yet).

Why and how this “assembly” problem is/was caused by the unwilling version 2.5.5 which did not find classes, is up to others. Perhaps, others did not experience this issue as they may (have likely) used the online Eclipse IDE which hides (or solves) many things.

Please, if possible, elaborate how/if/why my latest challenge " A required class was missing" of the “org.apache.maven.plugins:maven-assembly-plugin” might be or is related to a specific maven (plugin?) version issue ?

I’m a bit hesitating to introduce myself into “try this too” elements by using a different mvn-version and see what happens, without some understanding (or explanation for own lack of confidence) why.
Aside I know my problem installing and integrating a new version here is complex which I like to avoid in my (I know, again “too old”) environment. Almost all things in source (like other items on my QNAP and other embedded systems) were built using - imho :face_exhaling: - rock-solid mvn339.