Is there an open-source implementation of OSGi DMT Admin service? Wikipedia lists two implementations, neither of which seems to be open-source, but maybe it is missing one?
I don't believe there is an open source implementation of the DMT Admin spec. BTW, it has been updated to version 2.0 in the forthcoming Residential 4.3 and Compendium 4.3 specs.
Related
Migrating server from microProfile-4.1 to microProfile-5.0 and based on https://openliberty.io/blog/2021/11/26/jakarta-ee-9.1.html, I map wasJmsClient-2.0 to messagingClient-3.0 and wasJmsServer-1.0 to messagingServer-3.0.
<featureManager>
<feature>microprofile-5.0</feature>
<feature>messagingServer-3.0</feature>
<feature>messagingClient-3.0</feature>
</featureManager>
The server seems not able to start reporting some conflicting versions of features.
From what I understand all are Jakarta EE 9.1 compatible but if not what are the best option to replace wasJmsClient-2.0 and wasJmsServer-1.0 ?
Yes this should work. I am not sure how you are installing liberty and the features which could make a difference. There were some issues with installing of features not including all dependent features earlier this year. So I would ask that you include what version of liberty you are using and how you installed it and possibly how you installed the features. I just tried with the latest code and it started up cleanly for me. So if you can also provide details about what the error message looks like that would be helpful.
I am working on a ThreadX based embedded system. I want to include a 4.5 inch graphical UI to this device and hence exploring on the possible GUI library / frameworks existing for ThreadX based embedded applications - I am open for both open source and licensed frameworks.
Please help.
Thanks
Arun
Azure RTOS GUIX is probably your best bet. It's integrated with ThreadX already, has the same license, and comes with lots of examples.
I have an application written on Java SE 8 that was heavily using features for mixing Heavyweight and Lightweight components.
In particular, the function "SetComponentMixingCutoutShape" was used, which was later deprecated in future versions of Java.
Now I have an option to switch to Java 11 - and I run into a problem. Seemingly, there's simply no alternative for this functionality in later versions of Java. Or at least I couldn't find one.
So what does that mean - that I simply don't have access to that feature AT ALL anymore?
Thanks for replies!
As soon as I asked I found the answer.
The functionality has been moved to component class
Before you used to call setComponentMinxngCutoutShape(component, shape);
Now you need to go component.setMixingCutoutShape(shape);
I hope this is not off-topic for SO (I hesitated between SO and programmers.stackexchange) but as far as I can tell this is a "practical, answerable problem that is unique to the programming profession" so it's complying with the FAQ.
Which version of the JVM do you need in order to run which version of Clojure (Clojure on the JVM, this question is not about ClojureScript)?
The page here: http://clojure.org/getting_started states that:
Clojure requires only Java 1.5 or greater
But is this always going to be the case?
And what about the Clojure ecosystem, like Leiningen?
Basically I'd like to know if I can count on Clojure to be able to develop a desktop app that should run on systems, including OS X systems, that are never going to get Java 6 nor more recent versions of Java (for example on some OS X versions Apple stated that no JVM 6 would ever see the light).
I am not on the Clojure/core team, so I don't have inside information, but here is how I would approach this situation.
Take the latest version of Clojure (1.5 as of this writing) and test it against Java 1.5 for the things you need to do and any Clojure libraries you need to use and stick with that. If Clojure 1.5 is Java 1.5 compatable, it will always be so, since that release is immutable.
I would not make the assumption that all Clojure versions after 1.5 will be Java 1.5 compatible and you definitely can't assume that Clojure libraries will be. For example, I just released a Clojure library that requires Java 1.7 (since it uses a java.util.concurrent class introduced in Java 1.7).
Since Leiningen gives you maven-like dependency resolution if you test all your libraries and your chosen version of Clojure against Java 1.5 and they work, then you can stick with that set of versioned dependencies for as long as you want to keep the app running. Your only risk at that point is that some bug fix releases of a non core library might not be Java 1.5 compatible any longer. This risk is proportional to how many non-core Clojure libraries you need to use.
If you are selective about what libraries you use, then targeting Java 1.5 is certainly feasible.
Clojure is very conservative about it's Java version requirements - hence the dependency on version 1.5 only.
Many libraries depend only on Clojure itself, so will run quite happily on the 1.5 JVM
Some libraries require >1.5, these tend to be more advanced libraries that have requirements for interop with specific Java features (e.g. newer concurrency code).
Note: I personally write all my apps/libraries to target Java 1.6, since I think that is a reasonable minimum and the vast majority of Java-based systems are at 1.6 or above. I'm willing to live with the potential loss of a few users who are stuck on 1.5. Also, even if a future version of Clojure does abandon 1.5, I expect it will continue support for Java 1.6 for a long time.
Notably, in Clojure 1.6 they have bumped the version of Java to 1.6:
The Clojure 1.6 Release Notes
include this ticket:
CLJ-1268: Require Java 1.6 as minimum for Clojure
So, "no" is the answer to the original poster's question of "But is [Clojure requires only Java 1.5 or greater] always going to be the case?"
I need to implement a firmware upgrade mechanism where Apache ACE will be used for provisioning and Apache Felix will be used at the Target side. Does Felix has the capability to upgrade Firmware on devices?
As mentioned in the documentation of Apache ACE, firmware upgrade provisioning is possible. But, how to create a bundle for firmware?
Any help would be highly appreciated.
Thanks
The Apache ACE architecture page indeed refers to updating not only OSGi bundles, but also "related artifacts such as configuration data, native code and device firmware." To handle this, ACE relies on Demloyment Admin (section 114 of the OSGi Compendium Specification), which allows plugging in resource processors.
Using Deployment Admin, you have a way to distribute the artifacts you need to your devices, and process them in a way you see fit: put files in some location, install application packages (e.g. rpm or Android apps), or even use the payload to update firmware. You can thus tie into a standardized deployment mechanism, and use its lifecycle.
Note that it is still your responsibility to do something sensible with the data. In other words, if you don't have a bootloader for updating your firmware, ACE cannot help you in that, but if you do, you can ride along on the distribution mechanism.
Disclosure: I am an Apache ACE committer.