I've got a plugin for mvvmcross using nuget.
When I try and use the plugin it tells me that an interface under the namespace of the plugin hasn't been registered.
Is there anything else after adding the plugin to my project via nuget that I need to add into my solution?
You'll want to read this.
Specifically:
Each plugin load is normally initiated from a bootstrap class. These bootstrap classes are added in your UI projects and generally look something like:
public class ColorPluginBootstrap
: MvxPluginBootstrapAction<Color.PluginLoader>
{
}
Related
Is there a way to call another artifactory plugin from an artifactory plugin?
We use artifactory user plugins a lot in our company and it works fine but sometime we could see the need to call directly another plugin instead of copying the code around...
If your goal is reusing logic between plugins, you can encapsulate this logic in Java classes and import them in your plugins. You can package the reusable code in a java archive (jar) and place it as a library under the ${ARTIFACTORY_HOME}/etc/plugins/lib directory.
I want to include the workflow of the Ember CLI into a Play! application. I decided to write an sbt plugin that, when enabled in the play applications build, will do a few things:
Add a task to run "ember new" to create the UI project in a sub directory.
Add a PlayRunHook so that when run is executed from the activator shell, it also starts the node server serving the EmberJS application by setting the proper proxy such that the api calls are proxied to the Play! application.
When the package is called, it also packages the EmberJS application.
Properly sets up the UI Assets to include the EmberJS application.
The problem is I am not able to find out how to add a dependency so that I can use the PlayRunHook trait and PlayKeys in my sbt plugin.
I want to use the plugin route because in the future I may have more services that will have the same kind of workflow.
Update:
I could not find out a way to create this plugin as I was not able to access PlayRunHook from that plugin. But, I have implemented what I wanted as a seed project. Link: https://github.com/dipayanb/play-ember-seed
While writing the sbt plugin I was not able to write a class similar to https://github.com/dipayanb/play-ember-seed/blob/master/project/EmberRunner.scala as I was not able to compile the code from inside the plugin.
Without seeing the code you're using to try and implement the plugin, this will be hard to answer, but in short you need to add the Play! plugin to your plugin's build definition. That is added in the same way as usual, inside your plugin's project/plugins.sbt:
addSbtPlugin("com.typesafe.play" % "sbt-plugin" % playVersion)
Because SBT is recursive, it is not sufficient that your project has the plugin you're trying to access: your plugin needs to load the plugin itself.
I want to extend angular-cli via a custom plugin. I want to write this plugin by myself. How can i do this? If i write an ember-cli plugin, can i use this one in angular-cli? I read that not all ember-cli plugins are working in angular-cli. I would like to have an example, or some information about the architecture of angular-cli.
I created a new Java app from scratch in IntelliJ IDEA. Now I want to use a jar library, e.g. OpenJPA. I added the library using Project Structure -> Libraries like this:
then I tried to use annotations from that library in my Java code, but I don't get the option to import these classes. It looks like IntelliJ IDEA is not known about my library yet:
What am I doing wrong when adding this library? Is there anything more that I have to do to get it working?
After adding this library, it looks like it is automatically added to "Modules":
You have created a library, but you haven't said IntelliJ that the module must use it. Click *Modulesµ in the project structure, then select the module you want to add this library to, go to the Dependencies tab, and add the library.
EDIT:
It's simply that the annotation is not part of the jar. You need to add the jpa api jar, not only openjpa.jar
You have to add library to Module dependencies, pls check here:
Configuring Module Dependencies and Libraries
I am trying to extend a third-party Eclipse plug-in by using a fragment project. The major reason is that the third party plug-in contains classes having the default (package) modifier and I need to extend them.
Thus, my extensions class must be located in exactly the same package. I create a fragment project containing the same package and put my class into it. Everything works fine when I am using a runtime workspace.
However, if I try to deploy my fragment (e.g., deploying it into the dropins folder of my Eclipse distribution), I am not able to execute the code. Extensions and stuff like that work fine (e.g., I use extensions for a new Run Configuration. However, if I try to instantiate this run configuration I get an error message that the third-party root plug-in was unable to load the class to display my configuration tab group.
Any experience with this kind of problems?
Sorry, but that does not work. Unless the host bundle has been crafted specially for it, you cannot override a class in the host from a fragment. The reason is that resources - including classes - are retrieved from the host before any fragment.
See org.eclipse.osgi.baseadaptor.loader.ClasspathManager for the implementation..
Actually, this is the extension code I am using:
<extension point="org.eclipse.debug.ui.launchConfigurationTabGroups">
<launchConfigurationTabGroup
class="com.android.ide.eclipse.adt.internal.launch.jouleunit.AndroidJouleUnitTabGroup"
id="com.android.ide.eclipse.adt.jouleunit.AndroidJouleUnitLaunchConfigTabGroup"
type="com.android.ide.eclipse.adt.jouleunit.launchConfigurationType">
</launchConfigurationTabGroup>
Of course, there are further extensions definig the launch configuration type etc. but this is the one leading to the class which Eclipse can not find.
Actually I found the problem now for myself. The problem was a wrong configured build properties file which excluded the Java byte code from my fragment JAR. Very itchy, as the classes were in the JAR but in a wrong subdirectory.