I worked through the ApacheCordovaPlugin example. Its nice to see that creating a new plugin is possible, and I successfully replicated the HelloWorldPlugin in a WL project of my own just to make sure I could get all the plumbing to work. It is tricky, you have to make entries in the right XML files, name your Java and .js files appropriately, know how to include them and call the functions, etc. If you make a mistake there is very little information visible that you can use to debug it. The entire process is very fragile.
Now I would like to have access to the large library of existing Cordova plugins. My primary development target is Android. I downloaded a plugin zip file from a git repository and extracted it. Looking at the files and the directory layout it is not at all clear how to integrate this into a WL project. Cordova has a 'plugin.xml' file that appears to supply all the glue, but there is no such thing in WL. I was not able to determine where to put files and what edits to make in the Worklight project that would cause the Cordova plugin to be recognized and accessed from my application JavaScript.
Surely this process is possible and is documented somewhere? Ideally there would be a utility that we use to import Cordova plugins, but next-best would be a step-by-step procedure description. I saw one somebody did for getting plugins into the iOS application environment, but not Android.
Most probably you've downloaded a plugin for cordova 3.0+. Since latest WL contains Cordova 2.6 you need to download plugin for this (or similar) version. E.g. if you're talking about barcode scanner plugin the most suitable version would be 2.2 (https://github.com/phonegap/phonegap-plugins/tree/master/Android/BarcodeScanner)
Related
I am setting up smartsheet SDK for Java, and running into problems trying to use it in IntelliJ IDEA. I am fairly unfamiliar with setting up decencies, modules, and such in IntelliJ, and am just looking for guidance on setting this up to work with Smartsheet SDK.
I'm currently using the Windows version with JDK13 (I also have JDk12). I've tried downloading the JAR file and pointing to that as a dependency, but it doesn't even understand the imports.
I would start with the Smartsheet Sample App for Java, which will already have the code in it for loading dependencies and libraries. https://github.com/smartsheet-samples/java-read-write-sheet
I can't figure out how to add the Intellij SDK plugin development source files to be able to navigate the files.
Right now I am only getting a decompiled list. I'd like the comments as well.
Note, I know there is https://github.com/JetBrains/intellij-community/blob/master/platform/platform-impl/src/com/intellij/openapi/editor/actions/
But shouldn't these already be included?
Can someone explain how to add the sources? I tried from module settings but couldn't get that to work.
If you're developing a plugin, or viewing/modifying an existing one, I suggest you take a look at the IntelliJ SDK docs, especially the prerequisites section, which explains how to set up a proper development environment.
Basically, you should clone IntelliJ community using
git clone git://git.jetbrains.org/idea/community.git idea
Then configure an IntelliJ SDK, and in the Sourcepath tab, add the local git repo to attach the source code.
Is it possible to migrate a WL 5.0.6 project into WL 6.1 studio. The project uses dojo, and Cordova. Initial results are obviously that dojo is not found, and for the java based Cordova code it is not able to find ::import org.apache.cordova.api.CallbackContext;
import org.apache.cordova.api.CordovaPlugin;
Apprecaite any suggestions of steps tpo accomplish this migration, or perhaps the best appraoch is to create a new 6.1 project and manually move in the logic from the 5.0.6 project.
Thanks for any helpful advice.
I cannot imagine for a Worklight 5.0.6-based app with Dojo and Cordova plug-in, to properly migrate to Worklight 6.1.0.x
As you mention, Dojo library is missing, which makes sense. Dojo library is a separate entity from the Worklight project. You will need to import it as well.
Worklight 5.0.6 is based on some very olden version of Cordova 2. Worklight 6.1.0.x uses Cordova 3.1.
In Cordova 3, the structure of config.xml as well as the way you call a Cordova plug-in has changed (if memory serves me right), so I suggest that here too you will consult with the Getting Started training module for creating Cordova plug-ins (also check out the sample project) and verify that in the migrated project you now follow these changes. I believe the migration process should update the config.xml file, but not any code you write... this is not something Worklight can do for you (as this is user-code).
As for the error mesage, I suspect this very much relates to 2 above; take a look at the sample project and see how the Java class (or .m and .h files for iOS) of the Cordova plug-in is done; pay attention to the imports and alike. Compare the two...
I'm just starting to develop a new eclipse plugin where I want a web application server running in Eclipse. I found a nice blog, OSGi as a Web Application Server, that describes how to do this. The author suggests creating a target environment for my bundle requirements, and some of those bundles get pulled in from the Equinox Project SDK (now called Equinox Target Components in Juno). I notice that the tutorial project runs fine when my target platform is the platform I created in the tutorial, but fails to start when it is the default platform. So, now for my question...
If I need bundles that are not part of the default, how will my plugin project get access to those bundles? Will I need to deploy them along with my plugin? How would I know if the user's eclipse does or does not already have those required bundles?
You was not much clear about what kind of application you are developing. Running a web server in an Eclipse IDE as a plugin don't make any sense to me. This kind of server application is best just running on top of Equinox.
Anyway, the right path is to create a "Product Configuration" file and add categories that contains the needed bundles (go to File/Plug-in Development/Product Configuration).
With this file you can run an instance of the product (inside the IDE) and can export it (create a zip containing all needed bundles)
And if you want to able your user to install plugin inside his IDE you must create a P2 repository (using a Target Definition File) and expose the exported directory within a Http server. You could research about Tycho to build this kind of components in a maven style.
Well, I'm not sure if re-inventing the wheel again is really sufficient.
You might take a look at Pax-Web for inspiration on how to do it, or take a look Apache Karaf as a OSGi-Container (using Pax-Web). Or even better start contributing to one of the two :-)
I have an Eclipse Feature that I'm building that contains a few plugins. One of the plugins uses the import package statement to declare a dependency on another plugin.
The other plugin has platform specific code and exists in another feature that I'm building. I have two plugins in this feature that have the platform specific code. One for os=win32 arch=x86 and the other for os=win32 arch=x86_64
Both features are being built and using Tycho and they both have p2 repositories that are successfully available.
So, I made a composite repository that points to both of these repositories, and then I use the "Install New Software..." command in my RCP app and point to the composite repository to install the first feature I mentioned.
The issue is that when the installation is done, the plugin that has the platform specific code has failed to install correctly. Specifically, the plugin for the x86 system shows up on my 64bit machine.
In your feature.xml, choose the plugin with platform specific code and add a platform filter. the filters are available on the right side (once you select the plugin). You can choose filters such as:
OS
WS
Language
Architecture
When your feature is published, p2 will generate the appropriate filters.
I found the answer.
I needed a p2.inf file sitting next to my feature.xml file in the first feature I mentioned in the question.
And in that p2.inf file, I needed this text...
requires.1.namespace=org.eclipse.equinox.p2.iu
requires.1.name=com.myplatform.specfic.bundle.win32.x86
requires.1.filter=(&(osgi.os=win32) (osgi.arch=x86))
requires.1.namespace=org.eclipse.equinox.p2.iu
requires.1.name=com.myplatform.specfic.bundle.win32.x86_64
requires.1.filter=(&(osgi.os=win32) (osgi.arch=x86_64))
I added this file to the build.properties as well to make sure it was included in the deployed feature
Then when I deployed the p2 repository and performed the install into my RCP application, the correct plugin was placed onto my 64 bit machine.
UPDATE: I was wrong here. This is NOT the correct answer. The incorrect plugin still gets installed on some machines.