During system setup and later for automatic testing (whether specific configuration settings are still effective) I am interested in configuring Firefox via CLI. I have seen one or the other command line tool but they would always cover only one aspect of Firefox and are usually bound to a specific version.
To be more clear about this, let me list some of the use cases for the CLI:
create/remove profiles
install/update/remove plugins
list installed plugins incl version
list configuration settings, get/set values (also for plugins)
clear cache/cookies/...
manage truststore
manage bookmarks
Is there no command line interface officially supported?
Firefox command line interface is indeed officially supported, but at this moment in time is under documented. While it's possible to find some outdated documentation, the in-tree documentation is only a stub.
Since you mentioned automated testing, you might also consider the approach currently being used by Mozilla to run tests on Firefox:
Generate a profile to be used for testing.
Tweak the preferences in the profile (e.g. using user.js).
Start Firefox using the generated profile (either using -p or --profile).
Execute your tests (with Geckodriver?).
Related
background
I have designed many tools in the past year or so that is designed to help me program for XPages. These tools include primarily helper java classes, extended logging (making use of OpenLogger and my own stuff), and a few other things that I personally feel I cannot work without. It has been discussed with my employer, and we feel that it might be a good idea to start publishing these items to openNTF. Since these tools are made up of about 3 .nsfs, all designed to use the same java code, key javascript classes, css, and even a custom control or two, I would like to consolidate key items into a plug-in that can be installed at the server and client level. I want to do this consolidation before I even think about publishing any of the work I've done so far. It would just be far too much work to maintain, not just for me, but for potential users. I have not really found any information on how to do such a thing in google searches. I also have to make sure that I am able to make use of the ExtLib libraries, openNTF Domino API, and the Notes API.
my questions
How does one best go about designing such plug-ins? Must a designer
use eclipse, or is this it possible to do this directly in the Notes
Designer?
How does a designer best go about keeping a server and client up to date while designing and updating the plug-in code? Is this why GitHub is often used?
Where is the best place to get material to get started in this direction? I sort of feel lost in the woods, knowing I need to head north, but not having a compass for that first step.
Thank you very much for your input.
In my experience, I found that diving into plug-in development is a huge PITA until you get used to it, but it's definitely worth it overall.
As for whether you can use Designer for plugin development: yes, but you will likely eventually want to not do so. I started out by using Designer for this sort of thing for a while, presumably with the same sentiment as you: why bother installing another instance of Eclipse when I'm already sitting in one all day? However, between Designer's age (it's roughly equivalent to, I think, Eclipse 3.4), oddities when it comes to working sets between the "Applications" and "Project Explorer" views, and, in my case, my desire to use a Mac app, I ended up switching.
There are two major starting points: the XSP Starter Kit (http://www.openntf.org/internal/home.nsf/project.xsp?name=XSP%20Starter%20Kit) and Niklas Heidloff's video on setting up Eclipse for XPages development (http://www.openntf.org/main.nsf/blog.xsp?permaLink=NHEF-8RVB5H). The latter mentions the XPages SDK (http://www.openntf.org/internal/home.nsf/project.xsp?name=XPages%20SDK%20for%20Eclipse%20RCP), which is also useful. In my setup, I found the video largely useful, but some aspects either difficult to find (IBM's downloads are shifting sands) or optional (debugging, which will depend on whether or not you're using Eclipse on Windows).
Those resources should generally get you set up. The main thing to worry about when setting up your Eclipse environment will be making sure your Plug-In Execution Environment is properly done. If you're following the SDK setup instructions, that SHOULD get you where you need to be.
The next thing to know about is the way plugins are structured. Each plugin you want to install in Designer or Domino will also be paired with a feature project (a feature can house several plugins), and potentially an update site - the last one is optional if you just want to import the features into an Update Site NSF. That's how I often do my normal plugin development: export the paired feature to a directory and then import the feature into the server's Update Site NSF and then install in Designer from there using Application -> Install. You can also set things up so that you deploy into the server's plugin/feature directories instead of taking the step of installing into an update site if you'd prefer. GitHub doesn't really come into play for this aspect - it's more about sharing/collaborating with your code and also having a remote storage location for your git repositories (which I highly advise).
And as for the "lost in the woods" feeling: yep, you'll have that for a good while. There are lots of moving parts and esoteric concepts to get a hold of all at once. If you mostly follow the above links and then start with some basics from the XSP Starter Kit (which is itself a plugin project that you can pair with a feature) - say, printing text in the Activator class and making an implicit global variable just to make sure it works - that should help get your feet wet.
It's best done in Eclipse. You can debug your code running on the server from there, as well as run it directly from there. The editors are also more up-to-date. You want:
Eclipse for RCP and RAP developers
XPages SDK for Eclipse RCP (from OpenNTF)
XPages Debug Plugin (from OpenNTF - basically allows you to load the plugins to the Domino server dynamically, rather than exporting to an Update Site all the time)
XSP Starter Kit on OpenNTF is a good starting point for a plugin. There are various references to the library id, which has to be unique for your plugin. Basically, references to org.openntf.xsp.starter need changing to whatever you want to call your plugin. You're also best advised to remove what you don't need. I tend to work in a copy of the Starter, remove stuff, build and if there are errors with required classes (Activator.java obviously will be required and some others), then paste them back in from the Starter.
XPages OpenLog Logger is a good cross-reference, that was built from XPages Starter Kit. It's pretty much stripped down and you'll be able to see what had to be changed. A lot of the elements of the XSP Starter Kit correspond to Java classes you'll probably be familiar with from your XPages Java development.
GitHub etc tend to be used as source control, which is useful for working out what's changed from time to time.
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 making a QuickLook plugin that will be included with my application. It will be used to preview a file type that other applications also have QuickLook plugins for. Every time I attempt to test with my plugin (I put it into ~/Library/QuickLook/) it previews with another app's plugin. I am using qlmanage to preview. Is there a way to force it to use mine, at least for testing?
Generators embedded in applications are always preferred to plug-ins in ~/Library/QuickLook (which are preferred to the ones in /Library/QuickLook, which are preferred to the ones in /System/Library/QuickLook).
There is no way to change this priority. Also if 2 generators at the same level claims the same type of file, Quick Look will prefer one over the other, whichever you can't control.
At least for your test, you can force qlmanage to use the plug-in you want by using the -g option (but you will also have to specify the content-type with -c).
Try qlmanage -h to get all the options for your tests.
While the order of precedence described by #julien is accurate, it is still possible to override a particular application's QL provider. Simply edit the Info.plist file in the .qlgenerator of the offending application. For example, I like the way a certain QL provider handles markdown, but one of the text editors I have installed includes (imho) less than stellar markdown support. My preferred bundle loses... until I edit:
/Applications/BadMarkdown.app/Contents/Library/QuickLook/BadMarkdownQL.qlgenerator/Contents/Info.plist
and remove
<string>net.daringfireball.markdown</string>
And in newer versions of OS X, you don't even need to restart the QL daemon. The preferred QL tool just takes over. =D
I'm in a team that is converting a suite of Java applications to use OSGi. Previously, we used our own home-brew class loader system that has some similarities to OSGi, but it was nothing but trouble; we expect that by moving to using a system like Apache Felix we can have a system that works better while requiring less overall effort on our part to support.
We have been converting the modules that make up the applications into OSGi bundles, a largely painless affair with the use of Spring DM.
However, we — well, I as it's my responsibility in the team — need some way to reliably produce applications from this via a tool like Maven (or Jenkins); having a redistributable application installer that will install everything for the user is an absolute requirement. (We know our userbase fairly well; they want a simple install that won't download extra things after installation, well, not unless they decide to install extra plugins, but that's another story.) We do not wish to have to build the application manually at a console, or by using a GUI, as manual processes are too likely to run into silly human errors; we want to get it right and debugged once.
Moreover, some of the applications in our suite have to take command line arguments “like a conventional application”. (The application in question does significant processing internally, and sometimes needs to be invoked from other processes, such as web portals.) I know this causes some issues with the default Felix main, which only allows command line arguments for its own purposes instead of providing a way by default to export those to the bundles. (I know we could wrap things with a shell script so as to pass them in as properties, but… ewwww… there's got to be a better way. I suspect that making a custom main that exports a service providing access to the command line arguments is the best method.)
So, my question is what is a recommended way of building whole OSGi applications automatically, and am I using a reasonable approach to provide the command line arguments?
I'm guessing your best option is to write your own main that does specifically what you want. Since OSGi R4.2 the launching API is standard and pretty straightforward. You can just start from Felix' Main since it is already generic (i.e., it can launch any R4.2 framework, such as Felix or Equinox) and change it how you wish.
If the command line args represent configuration properties, you could just push them into Config Admin. Otherwise, just expose them how you see fit.
The Apache Sling Maven Launchpad Plugin generates a finished OSGi app from a list of bundles to include, and the Sling installer can be used to include initial configurations as well.
Even though they come from the Sling project, those module do not require your app to use the Sling app model, they are just used to build, launch and configure it.
For your arguments, use metatype. It will allow your bundles to load with default values and when the user configures the bundle via the web console or config files, metatype will inject the values into your variables. An installer would also be able to set these values at install time via the config files.
Is it possible to store the result of a web service/AJAX call into the store element, so that its value can be used in multiple locations.
The reason for this is we would like to have an automated test suite that uses data defined in a database. This would make it much easier to change bulk data in the tests (instead of searching through all of our test cases to change the data).
I understand that we can create a test case at the beginning of our test suite that defines all of this data however, we would like to easily switch between data sets without having to re-type each value.
I'm not sure how you can do what you're asking. It would be cool to learn. But let me give you a different approach which is very easy. I can answer any questions you may have. Create 3 different commands in your Selenium IDE to start things off, where your target for the open command is the path of the page you're automating.
Command: open
Target: --path--
Value:
Command: storeExpression
Target: 123
Value: var_number
Command: type
Target: TextBox1
Value: ${var_number}
Then use the export option in Selenium IDE as Java code (or another language). You won't have the Options > Format > options unless you turn on "Enable Experimental Features" in options. Choose "JUnit 4 (Remote Control or RC)"--Selenium 1. I'm not familiar with "JUnit 4 (WebDriver)"--Selenium 2 yet, but it's a bit newer, and not as much documentation. Then download Eclipse Classic, the Java JDK, the Selenium client driver for Java (on the Selenium site)--dll #1, and download JUnit 4--dll #2. Import both of those dll files into the Library tab (in Eclipse classic) after creating a new project in the project wizard, and open your export code that was exported using the Selenium IDE format export. Eclipse should be configured to automatically compile your code by default. Then just create an loop in the Java code and repeat the commands above. Then connect to your database from Java (with some simple SQL connection code), and read your data from the result set inside of your loop. Then right click in the Eclipse file explorer and choose JUnit on your unit test to launch a Mozilla Firefox instance to have it automate your loop. Or you can launch any other browser to run your JUnit test.. just change "*chrome" (aka Mozilla not Google Chrome) to "*iexplore" (Internet Explorer) or "*googlechrome" (Google Chrome), etc... for a browser of your choice in the Java code.
Pardon my jargon on "dll files". I meant to write assemblies or libraries. In Java, the correct term would be a *.jar. I'm use to writing in .NET code. If you choose to run your unit tests in .NET, then you will need to repeat most of what I have above, but instead download NUnit and use Visual Studio rather than Eclipse. The documentation is much better for JUnit, so that's why I went that route. That statement might not be correct. That's just what I found to be true from observation when I did a proof of concept for my company.
Oh, and because you're using client drivers, you need to have the Java (JUnit Test) program connect to your Selenium Remote Control Server. So you must download the Selenium server also. Then call the Jar from the command line in Windows. It must be running before running your JUnit test. This server won't run unless the JDK is installed on your machine!
java -jar selenium-server-standalone-2.0rc3.jar
The contributed user extension: http://wiki.openqa.org/display/SEL/global makes use of the global array globalStoredVars which you should be able to use.
I started recently to test a multilanguage website using Selenium with javascript, see Testing-a multilanguage website with selenium