Using Felix / Equinox, what do the following do under the hood?
osgi:install
osgi:refresh
osgi:resolve
osgi:restart
osgi:update
Is there a state-machine diagram or more concise documentation somewhere?
The best documentation for this is the OSGi Core Specification. The section and page numbers below refer to Release 4.3 (April 2011) of the spec.
osgi:install means install a bundle from a file or stream, and it maps to the BundleContext.installBundle method in the API. Refer to section 4.4.3 on page 90.
osgi:refresh performs a "refresh packages" operation, which allows exports/imports to be rewired after installing or updating a set of bundles. For example, bundles that are currently wired to a particular exporter of a package may be rewired to a newly installed bundle that exports the same package. See section 7.6.1, page 148.
osgi:resolve is similar to refresh, but it only wires up bundles that are currently in the INSTALLED state. I.e. it will not rewire existing wires belonging to bundles that are already in the RESOLVED sate.
osgi:restart stops and restarts a specific bundle. This does not cause the bundle implementation to be updated, it simply stops and starts. See section 4.4.5 page 91 and 4.4.7 page 95.
osgi:update requests for a single bundle to be updated (i.e. reloaded from its original location). This may involve stopping, re-resolving and starting the bundle, depending on what state it was in before the update. See section 4.4.9 page 95.
The state diagram for all the OSGi bundle states is in section 4.4.2 (Figure 4.4) page 90.
For the details of what the Felix shell commands do, you might just look at their source code, at http://svn.apache.org/repos/asf/felix/trunk/shell/src/main/java/org/apache/felix/shell/impl/ - most of them are short and simple.
Related
In a past question, Is there a CAS for Pharo?, I asked about a Computer Algebra System for Pharo, and people pointed to Domains, a port of Mathematics from CUIS smalltalk, that is part of PolyMath project. I suceeded installing PolyMath in Pharo 8, running the following code in the playground, as adviced in https://github.com/PolyMathOrg/PolyMath:
Metacello new
repository: 'github://PolyMathOrg/PolyMath:v1.0.2';
baseline: 'PolyMath';
load
The problem is, it appears Domains is not installed by default with PolyMath, as I didn't find the corresponding classes in the class browser, and the Domains subpage has no similar instructions on installation.
EDIT (March 2, 2021): I tried to follow the sugestion of EstebanLM, and load from iceberg, having PolyMath installed beforehand. But I only see the following packages in the iceberg screen:
It is in a separate github repo (PolyMathOrg/Domains), without a baseline. So you need to just clone the repo from github in Iceberg, and then load the packages in the right order from hand. Iceberg will complain if you try to load a package with unloaded dependencies (Mathematics-Kernel is a good starting point), and you can just reload after loading the missing dependency.
If you note down the needed loading order, you can provide a PR with a baseline
Once you load polymath, you will have all packages available to load.
The tool used to load/save packages in Pharo is called iceberg (is a git client). You can find it in the menu "tools" in Pharo 8 or in "browse" in Pharo 9.
It looks like Google has changed the App Engine Ruby Standard runtime in some way that has messed up GAE deploys for a large number of people so I am reporting it here. Deploys that were working two days ago now fail when deployed.
The error is always:
Bundler::GemNotFound: Could not find nokogiri-1.10.7 in any of the sources
This occurs regardless of the local state of your code and seems to have nothing to do with bundler configuration, gem versions, or anything like that. If nokogiri is in your app, it won't deploy to gae ruby standard environment right now, period.
This issue has been reported on Japanese stackoverflow but has not yet received any attention from Google.
We've finished root cause investigation. For the curious, here is what happened:
The Ruby runtime for the App Engine Standard Environment uses ruby-build to build/install MRI (the standard "Matz" Ruby runtime). On Oct 30, ruby-build changed its behavior to set --enable-shared when building recent versions of MRI. However, MRI built with the --enable-shared setting is not binary-compatible with MRI built without. This can manifest when loading C extensions (such as Nokogiri)... C extensions compiled against MRI built with one setting, will not load successfully in MRI built with the opposite setting.
Prior to the week of Dec 9, the live Ruby runtime was from a build prior to Oct 30, and was thus not built with --enable-shared. Then, that week, App Engine started rolling out a new Ruby runtime build that was built with --enable-shared. The new runtime was incompatible with the old runtime, and thus also with existing applications that included C extensions that were originally compiled against the old runtime, resulting in the symptoms described.
On Dec 11 we rolled the release back as soon as we determined that there was an issue with it. If anyone is still seeing issues, just redeploying your app should resolve them.
To retain compatibility with your existing apps, we will disable --enable-shared for all future updates of the ruby25 runtime, and we've put in tests to detect future changes to the runtime compile flags to prevent this from happening again. Note that this does mean that the ruby25 runtime will always be compiled without dynamic libraries. We are aware that there are a few gems that require dynamic library support, and these will not be supported under the ruby25 runtime. However, any upcoming ruby26, ruby27, and later Ruby runtimes, will be built with --enable-shared.
Finally, just a note that the official channel for reporting App Engine issues (assuming you do not have a GCP support plan) is to file an issue in the App Engine Issue Tracker. (You can find a link from https://cloud.google.com/support/docs/issue-trackers). We're not always checking stack overflow, but the issue trackers feed directly into the internal queues at Google.
updating all the bundle things... Could solve this kind of
could not find _______ v ___ in any of the sources error
Just try to run ....
bundle update --all
Thinking may this solve all bundle problems accordingly..
I'm trying to use the Debugger with elm-reactor but I get this error:
`Debug` does not expose `watch`.
I'm importing the Debug package:
import Debug
as per the mouse example
As of 0.17.0 release, Debug package no longer exposes watch function.
Debug.watch only makes sense in the context of Time-Travel Debugging, which is not available in 0.17.0 release.
The example you are referring to is written using Elm 0.16.0, any examples using Signal package are not relevant anymore.
See more details on the latest release in the official blog post from Evan: A Farewell to FRP
watch was removed from Debug prior to the release of 0.17.
Here is a discussion about the decision which oscillates between moving watch and watchSummary to a new Reactor module (since they were only useful within elm-reactor), or replacing them altogether with log and logSummary. Neither of these resolutions have happened as of 0.17, so we are left without them for now.
This is a continuation of a question I asked a few days ago regarding a designer connection for Domino OSGI dev and testing.
In eclipse, I do have the "debugging plug-in" installed (as mentioned by stwissel), and I am fairy certain that it is configured properly.
In a second attempt, I tried to export my plug-in in an update site.
1. import plug-in to feature
2. import feature to update site
3. build update site
I first tried to install using My Widgets in the notes sidebar. I did not get the thing to run with that so, then went into designer and installed it there directly, also nothing.
current stand
I built the update site and deployed using an nsf Update Site as a widget. I use this for openNTF Domino API, the ExtLibs -- it is comfortable and I like it.
I can verify that the feature is available in the application Management window of designer.
3 I expect to see those libraries in the xsp.properties page generation tab, but do not.
questions
1. Am I missing something?
2. Must I add some sort of class/code/flag in order to choose this library/plug-in in designer?
3. How can I best verify that the plug in and not just the feature is installed?
if your XspLibrary is not a 'global' one you probably won't see the activator run until the first nsf that uses it activates it.
seeing as you can't select it in an nsf this is probably why no nsf is ever activating it
can I ask have you correctly defined the library as an extension of com.ibm.commons.Extensions
as type
com.ibm.xsp.Library
if you don't define the extension you will not see it in the list of libraries.
also you must make sure you set the plugin settings to export the XspLibrary class (or package of the class) otherwise designer can't use the class
see this article on the domino designer wiki for an overview of necessary steps to correctly set up the XspLibrary plugin. the manifest.mf / plugin.xml settings are important.
another thing to double check, is to inspect the actual built plugin jar, using something like 7zip. you can open it up like a zip and have a look to make sure the .class files are actually included in the jar. if your build settings are incorrect it may not include them in the jar properly. also make sure the manifest.mf and plugin.xml are in there properly
EDIT from Greg
This should be the link for a non-mobile user
When you setup the debug plugin, it should create an entry in the workspace directory of the Notes client and Domino server (I think down in the RCP directory). This entry points back to the Eclipse workspace. So you don't need to deploy the plug-in. You also should see a warning when loading Notes ( with rparams -console) or Domino on the console about the debug.
Also what I found: auto deployment via Widget works when the update site sits on a server via http or nrpc. It doesn't when it is specified as file:/// so I run a Apache http on local (I need it for other stuff too, so no big deal for me).
I'll check the exact settings when I get back to my Dev workstation
You can identify if a plugin is installed via Help > About IBM Domino Designer, then clicking on the Plug-in Details button in the dialog.
Help > Support > View Log and View Trace should give more details. Trace is more detailed and allows you to write content, as we do for the OpenNTF Domino API. It may allow you to see how far through the code it's going.
That first message is in the XspLibrary class, in the constructor, just using a sysout
/**
* Constructor
*/
public XspLibrary() {
System.out.println("Loading org.openntf.domino.xsp library");
}
Hopefully that should help you see where it's failing.
I am having a hard time trying to build my javafx app into .app (for mac).
I found a legit way to do that, here is resource for that:
http://docs.oracle.com/javafx/2/deployment/deploy_quick_start.htm
However, it is far from what I'm looking for. By following that tutorial, I managed to build an app from my javafx project, however the size of file was just ridiculous and it is because the whole JRE is being bundled inside. I am now looking for a way to deploy .app file with dependencies (it's important) ONLY and without JRE. (JRE should be pre-installed by user). Is there a way to do that? I really tried to find one, but faild. Hope you, guys, help me.
Instructions for packaging a JavaFX application as a native installable app without including a JRE:
JavaFX packaging tools update - Self-Contained Applications: Create Package without Java Runtime.
The tools used are the same as from the deployment quick start you mention in your question. You just set the fx:platform basedir="".
I'll just quote the article here:
This may sound a bit puzzling at first glance. Package without embedded Java Runtime is not really self-contained and obviously will not help with:
Deployment on fresh systems. JRE need to be installed separately (and this step will require admin permissions).
Possible compatibility issues due to updates of system runtime.
However, these packages are much much smaller in size. If download size matters and you are confident that user have recommended system JRE installed then this may be good option to consider if you want to improve user experience for install and launch.
Technically, this is implemented as an extension of previous feature. Pass empty string as value for 'basedir' attribute and this will be treated as request to not bundle Java runtime, e.g.
<fx:platform basedir=""/>