Somehow I cannot find and answer to this in griffon documentation nor googling...
I have created a griffon plugin. It gets packaged as usual with:
griffon package-plugin
Then I can install it locally in my application specifying path to the zip file resulting from packaging:
griffon install-plugin /path-to-plugin/plugin-name.zip
I can even upload it to a remote url and install it from there:
griffon install-plugin address-of-my-site/plugin-name.zip
How can I make installing of this plugin from my url an automatic step during building/running of a griffon application, which uses it?
I work on the application with another developer and don't want to force him to install the plugin manually every time when something changes. It should be downloaded from my site automatically. But I don't want to release the plugin to the griffon official repository either - it's pretty experimental stuff still.
There is a line in application.properties, which tells griffon, that the plugin is needed:
plugins.plugin-name=0.3
But it cannot be installed from griffon central repository, like all the other plugins, because it's not there, obviously.
I looked into documentation of "griffon.project.dependency.resolution" section in BuildConfig.groovy, but I can't find anything useful for my purposes there.
Do I miss something?
The answer you seek is found in sections 12.1 and 12.2 of the guide. The first section describes an example of a plugin being pushed to a local repository. The second section describes the types of repositories supported by Griffon.
Plugins that are available from a plugin repository that can be queried by the build system (i.e, the repository is configured) are instantly available to be installed using the short notation you want.
There's always a local repository configured by Griffon: griffon-local. Pushing releases to it will make them instantly available to install-plugin, list-plugins, plugin-info, etc.
Related
Background
I am working on a simple plugin, and have already deployed to the Plugin Repository once before (successfully).
Since my last successful deployment, I found that I had a lot of issues with the IDE. After completely upgrading, and modifying my plugin's directory structure, I have been able to get the plugin to Run again.
Issue
tl;dr - I have an updated plugin in the JetBrain's Plugin Repository that does not work as intended, and I cannot update it correctly!
When I run the plugin, a second instance of the IDE comes up with my plugin working correctly. I edit my code and run the plugin again - the plugin runs smoothly and the updates are applied!!
With all of this, I decided to deploy my updated plugin to the Repository again. Once that was done, I decided to download the plugin and try it out myself; just to make sure things worked.
The issue is that nothing can be found in the plugin file!! Just the updated plugin.xml file and Manifest.mf file. The total size of the archive file is around 500bytes. I know a correct archive would have more files in it, and in my case, the file size should be around 6kb (based on my first successful archive file).
So how can my local IDE instance find the files correctly, but the deployment feature cannot? How does the deployment feature actually work? I get the feeling I have the structure wrong, eventhough the new IDE instance works perfectly
Plugin
GitHub
JetBrain's Plugin Repository
When you install the plugin, the version is shown as v1.1; however, that is not true, in reality. One of the easiest features to determine the actual version of the plugin is the Folded Text foreground color.
v1.0 - RED
v1.1 - YELLOW
Deployment
Preparing Plugin Module for Deployment + resulting plugin.jar file
Contents of plugin.jar
It seems possible that because of the restructuring an old ChroMATERIAL.xml file was left somewhere in the build output. Somehow this could end up in the plugin jar. An invocation of Build > Rebuild Project should fix this problem.
There could also be problems in the project or module configuration, but the project files are not included in the GitHub repository, so that cannot be checked.
I am new to eclipse. Where can I find the org.eclipse.jdt.core version (e.g., [3.10.0,4.0.0) bundled with each official eclipse release. it would be tedious to find out by installing each eclipse version
I don't know of a versions list. You can download just the 'JDT Runtime Binary' for the various releases from the Eclipse Projects Archives. This is about 27Mb per release. This is just a zip file, you don't need to install it, just examine the contents.
I would recommend a tool like p2-browser. It will allow you to examine the contents of Eclipse P2 Update sites by just downloading the meta data.
Using p2browser
Once you have started p2browser (see below), you should have a screen like this:
Add 1 or more p2 sites to consider and allow the tool to download the metadata.
Press Add
Put the p2 site (e.g. for Mars: http://download.eclipse.org/releases/mars)
Press OK and wait for download
Repeat until you have all the versions you are interested in.
You should now have your added p2 sites listed in the tree viewer:
Now you can add your plug-in or feature you are interested in, e.g. in your case org.eclipse.jdt.core in the filter box:
Another example of what you can filter on, e.g. org.eclipse.jdt.feature.group for the JDT Feature
Download/Install/Build
Java Web Start
To use the p2 browser you may like to simply use Java Web Start, Run:
javaws http://ifedorenko.github.com/p2-browser/javaws/com.ifedorenko.p2browser.jnlp
Or click this link, as docs show, results for using java web start may vary because of tightening security considerations of running arbitrary java downloaded from the web.
Build and Run with Maven
You can build it with maven, as per the docs. These are simplified instructions:
git clone git#github.com:ifedorenko/p2-browser.git
cd p2-browser/
mvn clean package
cd com.ifedorenko.p2browser.rcp/target/products/com.ifedorenko.p2browser.rcp
Linux x64: linux/gtk/x86_64, other platforms, choose the correct directory.
./p2browser
Intel-XDK uses third party Cordova plugins only at build time. Is there a way to implement a third party plugin using Cordova CLI in my local Intel-XDK environment? In other words, can I access the internal Intel-XDK Cordova server in some way?
EDIT (7 Aug 2015): With our EA release local plugins no longer need to be placed inside your source directory (typically www inside your project directory). The Intel XDK EA release manages plugins in a way that is consistent with Cordova CLI. This CLI-compatible plugin management scheme will become part of the mainstream release in the very near future.
Original Post:
You cannot directly access the XDK build server's CLI. However, you can reference a plugin locally (that is, you can submit a plugin that is located on your local disk drive). Unfortunately, you have to locate the plugin inside your www "source" directory, I hope to see that changed in a future revision of the product; this is not where a local CLI would place the plugin...
Placing the plugin into your www directory, and then referencing it using the "import local plugin" on the Projects tab (find the "Plugins and Permission" and then the "Third-Party Plugins" section) allows you to customize that plugin before it gets submitted to the build service. For example, assume you need to change the contennts of the plugin.xml file or change a plist or manifest file that is part of the plugin, you could do that in the local copy and those changes would be part of this "local third-party plugin" that is submitted to the build server with your app when the build server runs.
In essence, the build server does a plugin add on a copy of the plugin that got submitted along with your project when you use the "import local plugin" feature. A copy of your local plugin gets sent with your app source to the build server and, before the build happens, the build server's CLI performs a plugin add with that plugin, so the changes you implemented locally will be included in the plugin when it is built by the build server. Make sense? :)
There are also some useful things you can do with the intelxdk.config.additions.xml file regarding plugins. See these doc pages for some details:
https://software.intel.com/en-us/html5/xdkdocs#517453
https://software.intel.com/en-us/html5/articles/using-the-cordova-for-android-ios-etc-build-option
The checkmarked plugins on the Project tab refer only to what are called "core" plugins and "featured" plugins. They are really just a convenience for selecting plugins. The "core" plugins also include some simulation inside the Emulate, Test and Debug tabs (as well as in App Preview). Other than that, they are standard Cordova plugins that are also "plugin added" by the build server if they have been checked. Take a look at the various intelxdk.config.*.xml files that are automatically generated when you perform a build to see how the checkmarks (and third-party plugins) are communicated to the build server.
I downloaded the source code for the EMF based UML2 Plugin and changed a class in the org.eclipse.uml2.uml.edit project to remove special characters when returning string representations. Now when I export the projects and place the jar files either in the dropins directory or replace my current uml2 plugin jar files in plugins directory, The UML files are no longer recognized, in short my modified plugin does not install correctly (no error is thrown and I can see the files being picked up under Plugins->Target Platform) .
However, When I run the plugin as an eclipse application (from the workspace) I can see the changes I made being reflected in the new instance of eclipse.
What can I do to ensure that the plugin installs correctly?
Is there a documented procedure of how to build the uml2 plugin (or any comparable plugin) after modification?
Select the project and open the context menu. There is an entry PDE near the bottom of the menu. In there, you can find an entry to build the plugin for deployment. This gives you the features and plugins directory with the fixed files. Copy both into your Eclipse install.
Unless the UML2 plugins require some kind of magic build script, exporting the one plugin you changed and overwriting the original in your Eclipse installation should be the easiest solution. One potential problem which comes to mind is conflicting plugin version numbers: make sure you don't have two identical versions of your modified plugin in your Eclipse installation.
When debugging plugins which apparently don't work properly at runtime, I always look at Help > About Eclipse Platform > Configuration Details. This lists all the plugins found by Equinox during startup, along with their status (see the Javadoc of the org.osgi.framework.Bundle interface for explanation).
I faced the exact same problem as you describe here . I dont have any answer to your problem but i am sharing what worked for me .
I created a local update site of the plugin on my system. Create update site for your plug-in article explains very very nicely the steps needed to accomplish this .
After searching around I see that eclipse 3.4/3.5 now allow you to use their 'dropin' folder to manually install plugins.
This works well in a situation where you have already downloaded the feature and plugin files, however in cases where you use the Software Updates feature to simply point to a URL and download a plugin, you don't appear to have control over what folder the plugin is installed into.
Is it possible to force plugins to be installed to an arbitrary dropin folder, or otherwise export a plugin to a location so that it can be shared with other people's eclipse installations?
I'd prefer not to have to comb through the plugin info and manually determine which plugin jars to copy into a dropin folder :P
Thanks
I think the answer in this thread and the mentioned blog post of Michael Scharf can be useful for you, although the procedure is not as simple as it should be :(
The new p2 system in 3.4 is supposed to have a feature called bundle pooling that allows for shared plugins. However, I haven't used it, so I'm not sure about the particulars. I hope this at least points you in the right direction.
When using 3.4.1 you can still enable the "old" update manager in Preferences/ General/ Capabilities. Then you can use the extension points again. But it has been removed in 3.4.2 completely.
You have to remove P2 to get the old update manager.
Note: The P2 team managed to broke everything backward compatible. This tricks does not work with 3.5.