I would like to know, if it is possible and if there is a generic way to extend the functionality of a grails plugin.
I recently installed the commentable plugin, but need to do some modifications to it. Since the code is not stored together with the project (but in the user directory) if I modify it, after the plugin is updated (or the project at some other machine installed) these changes are lost.
Does someone have any idea?
Thanks,
Nicolas
If you want to override an artifact (e.g. a domain class) create one with the same name in your project. Plugins are compiled separately from the application classes and their artifacts are registered first, so if there's an artifact in the main app it will replace the plugin's. Just be sure to use the same package for domain classes, although this isn't required for controllers or services.
If you want to modify the plugin completely, you may try to change and then recompile the plugin, and build it into a zip-file with different name.
Then you can install the customized-plugin from source code. You may refer to the question here.
In one project we needed a list of allowed email addresses, that the app was allowed to send mail to, for one environment (QA) so various different parties involved in the project could go testing the app without the risk of any mail be sent to our customers customers (end customers).
It was too big a job to change all code-blocks that did the mailing so I implemented a custom extender for a core class of the mail-plugin (grails.plugin.mail.MailMessageBuilder) that took a list of allowed email addresses from the app's config and overrode a method that resolved the addresses before sending the mail (toDestinationAddresses). I then replaced a factory method (of the plugin), that produces MailMessageBuilders so it produced my custom builders, via Groovy metaClass in Grails bootstrap.
This was a clean, non-intrusive fix and it worked nicely.
Related
I am currently building an application which will allow mini-plugins to aid the use of my application. It is a lot like Slack, allowing user-contributed, custom plugins to aid the user. These plugins will be Swift classes. I will be setting up a system where users can submit their custom plugins to be hosted on a webpage. Users in my application will be able to select a few of these plugins that they need, and the application would import those plugins only, and add the classes containing the plugins to a top-level file so that everything in my application can use these plugin classes. How can I import these selected modules into my application files?
For example, if I have a variable webpageURLContainingPlugin, then is there anything that will allow me to import the class/module at that link?
Also, I wouldn't want to download all those plugins when creating my XCode project, as I feel it would take too much unnecessary space to store all of the possible plugins, whereas a user may only choose upto five of those to use.
If it is not possible to import a file from the internet containing these modules, please can you suggest a workaround to this issue?
Edit: I am not looking for a way to create the plugin architecture, and I have an idea of how I'd like to do that, my question is more about accessing Plugins hosted online on a webpage and putting it onto my top level files so I can access them. However, if there is a specific plugin architecture that I must follow to be able to do this, then please suggest it.
You can't. IAPs might be an option worth exploring.
AppStore review guidelines
2. Performance > 2.5 Software Requirements
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code, including other apps. Apps designed to teach, develop, or test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user.
Inherited a moodle project that never had any kind of VCS, with some plugins installed from third parties, and a few modules developed in-house.
Problem is, I want to update moodle, and can't just use a brand new copy, since in moodle custom code lies within the "moodle" directory.
In other CMS/frameworks, that code would be physically separated from the core code, and you could mostly update the core files by pulling from the appropriate repo, and checking out the approriate branch (with custom code living in a different repo, and third party code either living in that repo or managed as a dependency).
Is there a way to organize custom moodle development (or downloads from third parties) so it's easy to separate "core" code from installed modules/themes?
We're using the .git/info/exclude file and list there all plugins which are third-party or developed in-house.
However, Moodle has awesome documentations for handling plugins using git in general, check it out: https://docs.moodle.org/32/en/Git_for_Administrators
I'm not aware of a so smart (and elegant) way of separating custom code from a default Moodle instance, even with GIT.
In a custom Moodle instance you may have:
new plugins (self developed or from third parties). You can see the list of additional plugins here:
your_moodle_systemadmin/plugins.php?contribonly=1 (or here: Home->Site administration->Plugins->Plugins overview).
In case you want an upgraded version of Moodle, you install it somewhere and then install on it the list of additional plugins. I would suggest here to check if the plugins have a new available version and consider installing it.
Custom code (that is to say: someone made core changes on Moodle). I would here compare the old code with the new one, or, even better:
a) compare the old customized system (MoodleOld Cust.) with a brand original old system (MoodleOld orig.)
b) Track all the core differences in your MoodleOld Cust with some inline comments
c) Compare MoodleOld Cust with your new system and pay attention only on differences marked by you on MoodleOld Cust.
d) Try to report the customizations on your new system, if wanted and / or necessary.
This is my situation: We have a third party feature in our Eclipse environment. The feature contains several plugins. The plugin contains a bunch of classes. One of the classes contains a bug.
We have been able to find a solution to the bug, so we have a working version of the class with the bug.
Unfortunately this plugin is covered by a 55 page long EULA (by IBM) so I think it's pretty safe to assume that decompiling the jar, exchanging class files, recompiling and distribute is legally out of the question. I'm no legal expert, but I'd guess we cannot tamper with the jar files in any way.
So this means I have a single class file that I want to be loaded instead of a class in a plugin, is this at all possible?
This page suggests using fragments, but this requires modifying the manifest in the plugin.
This question has the same problem as me, but in that case there is access to the source code and he is able to build a plugin.
This blogpost shows how use feature patches, but they require that I'm able to build my own plugin, which I cant since I have just the one class.
I would not try using a fragment. In my experience, the cleanest thing to do would be to use a feature patch. I have successfully used feature patches to do exactly what you are looking to do. It's not simple, but it is robust. You need to do the following.
create a plugin that encapsulates your single class file
create a feature patch that includes your new plugin and that patches the feature that you are targeting.
export your feature patch and create the p2 metadata (to create an update site).
Install into your Eclipse using the install manager
Rejoice!
(optional) Feature patches by default only target a single version of the target feature. So, if the target feature bumps up its version number, the feature patch will silently no longer be applied. However, it is possible to relax the version constraints on the feature patch. This process is described in detail here: http://aniefer.blogspot.com/2009/06/patching-features-part-2.html
More information:
http://aniefer.blogspot.com/2009/06/patching-features-with-p2.html
http://aniefer.blogspot.com/2009/06/patching-features-part-2.html
The benefit of using a feature patch over a fragment is that anyone can install the patch and get the patch working, but things are more difficult with a fragment in that end users must muck with manifests.
So this means I have a single class file that I want to be loaded instead of a class in a plugin, is this at all possible?
Your first sentence is the answer. You can use a fragment, but that requires modifying the manifest in the plugin. Otherwise, Eclipse would have no idea which class to load.
My suggestion is that you write IBM with all of this information, including the patch. IBM should be able to release a maintenance fix which would solve your problem.
In the mean time, you could pursue the fragment option, which would require you to unpack the jar, add your fragment, modify the manifest, and repackage the jar. Whether or not this is legal is beyond my ability to determine.
The problem we have are as follows:
We are using ANT to build our application. However, the application is built multiple times, once for each client (they have different skins / cms / i18n etc). Up to now, we had no need to compile them all at once (usually just work on one client at a time). Now, we want our build server to build all permutations for all clients in all languages. In other words, we need to create a war file for each client, each containing their own compilation.
At the moment, the client name is read in from the application's .properties file.
My question is this. Is there any way that the client.name property (from the application's .properties) be overridden in the build.xml used by ant? Or is the only way to create a different target for each client and hard-coding the name?
Thanks.
If you use Hudson to do your build, and have more than one parameter to change, you should be able to do a Matrix Build. There is more detail in this answer.
If it is just one parameter, you should be able to do a properties file and use Ant to read this properties file and iterate through it - I'm not sure precisely how, but you won't be the first person to have this problem, and if you are it wouldn't be difficult to create your own task. Or if not use Macros.
We're looking into setting up a proper deployment process.
From what I've read there seems to be 4 methods of doing this.
Copy & Paste -- We don't want to do this
Using the "Package" mechanism built into the Salesforce Web Interface
Eclipse Force IDE "Deploy to Server" option
Ant Script (haven't tried this one yet)
Does anyone have advice on the limitation of the various methods .
Can you include everything in a Web Interface package?
We're looking to deploy the following items:
Apex Classes
Apex Triggers
WorkFlows
Email Templates
MailMerge Templates -- Can't seem to find these in Eclipse
Custom Fields
Page Layout
RecordTypes (can't seem to find these in Website or Eclipse)
PickList items?
SControls
I recommend the Force.com Migration Tool.
For reference:
Force.com Migration Tool Documentation
Migration Tool Guide
The Migration Tool allows you to use ant targets to move your metadata between salesforce.com organzations.
I can speak to this from recent painful experience.
Packaging: this is a very old method that predates the metadata API on which both Ant and Eclipse rely. In our experience, packaging's only benefit is in defining your project. If you're using Eclipse (which we do, and I recommend), you can define your project as being based on a particular package. As long as you remember to add new components to your package, your project hangs together
One thing that baffled us for a while, btw, are the many uses of package. We've noted the following:
Installed packages: these come in managed and unmanaged flavors and are really, in the words of a recent post on the SFDC boards, for ISVs to deploy their stuff into various unknown orgs "out there". Both managed and unmanaged packages have limitations that make them unsuitable and unneeded for deployment from development to production within an org, or in any case where you're doing custom development and don't intend to distribute code to a large anonymous base.
Non-installed packages: this is what you see when you click "Packages" in the web UI. These, that we sometimes call "development packages", seem to be just a convenient way to keep a project definition together.
Anyway, the conclusion I'm coming toward is that our team (custom development, not an ISV) does not need packages in any form.
The other forms of deployment, both Eclipse and Ant, rely on the Metadata API. In theory they are capable of exactly the same things. In reality they appear to be complementary. The Force.com migration tool, built into the Force.com IDE for Eclipse, makes deployment as easy as it can be (which is not very) and gives you a nice look at what it intends to deploy. On the other hand, we've seen Ant do some things the IDE could not. So it's probably worthwhile to learn both.
The process we're leaning toward is to keep all our projects in SVN, and use the SVN structure as the project definition (Eclipse will work with this and respect it). And we use Eclipse and sometimes Ant for migration. No apparent need for packages anywhere.
By the way, one more thing to be aware of -- not all components are migratable. Some things must be reconfigured by hand in the target environment. One example would be time-based workflows. Queues and Groups also need to behand-created, I think. Likewise the metadata API can't directly process field deletions so if you deleted a field in your source, you need to delete it by hand in the target. There are other cases as well.
Hope that's useful --
-- Steve Lane
As of Spring '09, mail merge templates are not supported in metadata but record types are. You will find record types as an XML element in the file for the object they belong to. Everything else on your list is supported with a small exception. Picklist values for standard fields cannot be edited in Spring '09. Stay tuned for news on Summer '09 feature announcements.
Update: Standard picklists on standard objects are now metadata exposed (as of API v16):
http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm
Otherwise, Steve Lane's response is pretty accurate. The advantage of using unmanaged packages (what Steve calls non-installed packages) is that when you add metadata to a package, the metadata it depends on will automatically be added. So it's easier to grab a full set of metadata containing all its dependencies. If you are repeatedly moving metadata from one org (sandbox) to another (production), Steve's approach is probably the best way to go and certainly the most common today. I frequently use unmanaged "developer" packages to move something I've developed in one org to another unrelated org. For my purpose, I like to have the package defined in the org as opposed to an Eclipse project / SVN. But that probably doesn't make sense if you are doing team development across many dev/sandbox orgs and are using SVN already.
Jesper
Another option is to use Change Sets if you want to move meta data from a sandbox to production.
There are currently some limitations on how change sets can be used:
Sending a change set between two organizations requires a deployment
connection. Currently, change sets can only be sent between
organizations that are affiliated with a production organization, for
example, a production organization and a sandbox, or two sandboxes
created from the same organization.
From the docs:
A package must be managed for it to be published publicly on AppExchange, and for it to support upgrades. An organization can create a single managed package that can be downloaded and installed by many different organizations. They differ from unmanaged packages in that some components are locked, allowing the managed package to be upgraded later. Unmanaged packages do not include locked components and cannot be upgraded. In addition, managed packages obfuscate certain components (like Apex) on subscribing organizations, so as to protect the intellectual property of the developer.
Advantage to managed package would be that it allows you to easily version and distribute things across multiple SFDC organizations.