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 .
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.
Thx Rich, for your response here and your (longtime) support elsewhere.
tldr; I do hope 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 .
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 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 'ClassPathUtilPatcher.javaâ whoâs mainclass is called by âorg.codehaus.mojo:exec-maven-plugin::javaâ .
What I, until now , 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.
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?
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.
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 - rock-solid mvn339.
.
Thx Rich, for your response here and your (longtime) support elsewhere.
someone can me put on a track of remember where to start solving or better understanding what exactly where is happening⌠TIA.
.
here is, that this artifact- requirement (amongst others) is no where mentioned.
, did not understand that the install-built is actually executing in-line âJavaâ-routines for doing the install-phase.
- rock-solid mvn339.