I need to create a Hybrid Worklight project but it needs to be physically inside another project.
The reason is that we are using an API that generates a project using grunt and the guide I got (company standards, practices, etc) says: Once the project is in Eclipse, create a wl folder and create the Worklight project inside of it.
When I create a new Worklight project in Eclipse it always goes to Eclipse's Workspace folder. How can I change this?
Thanks
You cannot (at least, not in a standard/supported/known working way); a Worklight project contains Worklight applications but cannot contain other Worklight projects. Worklight projects are always contained directly within an Eclipse workspace (unless working with the CLI tools).
Based upon your clarifying comment, it seems that your containing "(general) project" is just another directory that contains a wl directory - not a real Eclipse project - that in turn contains your Worklight project. It seems you are creating the whole thing using the CLI tools.
In order to work with this project within Eclipse, you'll need to create a new Eclipse workspace elsewhere (the Eclipse workspace itself isn't particularly important and doesn't necessarily need to saved in source control). You can then use File->Import->Existing Projects into Workspace to import the Worklight project from the wl directory. You can either "Copy projects into workspace" (in which case you will end up with two copies), or leave that unticked, in which case your Eclipse workspace directory will just contain a reference to the original directory (I suspect you want the latter).
As a word of advice, generally you should try not to work with both Eclipse and the CLI tools at the same time. Although it may work, you will get conflicts with (for example) the embedded test server, and long term, you'll just cause confusion.
Edit: looks like Andrew says pretty much the same.
Using Eclipse, since what you see in the Project Explorer view is the workspace Eclipse uses, it makes sense to me that when you create a Worklight project in Eclipse, it will be located - in the filesystem - inside the workspace.
If you want to create your Worklight project elsewhere, you'll probably need to use the Worklight CLI tool. From a terminal, navigate to the location of the Grunt project and then, using the CLI commands, generate a Worklight project in that location.
Related
I am building an eclipse plug-in project that acts as a front end. I also have a separate eclipse project that runs as a backend. Right now I can run each of them separately and they communicate just fine using sockets.
I would like the plug-in to create the major components of the back end when it starts but also keep the two projects separate so that I can use other editors to communicate with the back end. So, I added the back end eclipse project to the build properties of the plug-in project and I added some code from the back end driver to the plug-in activator's start(). However, when I run the plug-in project I am getting class not found exceptions for all back end references. It appears to compile fine, but I can't run it. I do not do anything to the MANIFEST.MF file in the plug-in project.
How does one add a second java project to an eclipse plug-in project?
There are several ways you can do this, going from best and most difficult to worst and easiest:
(1) Use a build tool (such as the built-in ANT, or tycho, or (as I'm sure there are) some other). This is by far the best solution, but is quite a bit more involved than the next 2.
(2) Convert your non-plugin project to a plugin project and add it as a plugin dependency in your plugin settings file's dependencies tab
(3) Export your non-plugin to a new .jar in your plugin project directory (e.g. $project_loc/lib/something.jar); go into plugin settings (plugin.xml) and include it in: The Build tab under binary build, and the Runtime tab under Classpath. (Or edit the corresponding entries in manifest.mf and build.properties)
For most cases I'd recommend approach (1); look up a few tutorials online, there are plenty. (3) is the quick-and-dirty non-flexible workaround to your particular situation, good for nothing other than seeing if it actually can run. (2) is somewhere in between -- obviously not ideal, but not as bad as 3.
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)
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.
I have a plugin for an RCP app that uses BIRT. I have a target for building my app which contains only the plugins/features that are required. I recently updated the BIRT plugin versions in my IDE, which created an incompatibility in the design files with previous versions of BIRT. I have the old version of BIRT in my target and need to update to the newer plugins.
In the past I have manually updated plugin jars in the target, but BIRT is a complicated platform with dependencies out the wazoo. Is there any utility or way of organizing my target differently that will make this easier to control in the future?
I would recommend to keep all components separately and not copy them into a single folder. You can use Target Definition editor (see File / New / Other... / Target Definition). So, after downloading all the pieces, you can unpack them locally and assemble your Target Platform using Target Definition editor.
You can also do the same using Window / Preferences / Plugin Development / Target Platform preference page. There you can select previously created target definition or specify base Eclipse install and then use "Add..." button to add additional components from local folders or remote sites.
Also, as far as I know the PDE team is currently working on expanding Target platform support in Eclipse 3.5. I think they are planning to allow to select Target Definition per-launch configuration and per-project.
Im not sure if i understand you right, so please let me know if not.
When i use third party libraries, i create a plugin for every single one.
Example:
xstream library:
Import the jars (also the source code)
Add the jars to the MANIFEST
Bundle-ClassPath
Add all xtream packages to the
MANIFEST Export-Package
When a plugin needs the code of the xstream library it has to depend on the xtream plugin. Because the packages are public, every plugin can use the source code of it.
When a new version of xtream is comming, you only have to update the jars and not the dependend plugins. Sometimes you have to update the export packages of the third party plugin.
All depended plugins you dont have to change.