I am in the process of trying to migrate an old Kepler RCP app to an up-to-date platform. The old configuration was based on plugins but I now want to use features and have now grouped the pluging into feature groups. I have also created a Target Platform based on Eclipse 2019-03, BIRT 4.7 and a few other items which are required.
The project configuration is defined to use features and I added the following features (followed by Add Required):
When I try to test the product (from the Product Editor) I get a long list of missing constraints:
When I open the generated Launch Configuration, I can see on the Plug-ins tab that 95 out of 547 plugins are selected. Without changing any settings, if I simply click Add Required Plug-ins the total jumps to 226.
My question is: what am I doing wrong so that the Product Configuration cannot resolve the required plug-ins but the Launch Configuration can?
The org.eclipse.e4.rcp feature only contains the plug-ins for an e4 based RCP. This type of RCP is very minimal and does not contain any of the plug-ins for the 3.x compatability mode RCP - which are the plug-ins being listed as missing.
You will need to use one of the features which contain the 3.x compatability mode code (maybe org.eclipse.platform or org.eclipse.sdk).
Related
I installed the Productivity Power Tools extension in Visual Studio VS2017.
This extension installed other extensions for me as designed, amongst others Custom Document Well.
I would like to configure Custom Document Well, but I cannot seem to find its configuration page any more.
It used to be under Tools|Options|Productivity Power Tools in previous version of the extension (where all others were bundled into one extension), but the makers of Productivity Power Tools say "there is no longer a need for the page" any more in their market place page.
How can I now configure Custom Document Well extension ?
I've just installed this extension and had the very same doubt. After a little digging I found that the configuration is still under the very same route you describe:
Tools => Options => Productivity Power Tools => Custom Document Well
Maybe it was added in a more recent version (and wasn't there at the time of posting the question). The missing page is the one you select all the active functions, that where separated into individual extensions, so that page doesn't makes sense anymore. But the configuration of each individual component is still there as it always was when the extension was complete.
Can we use component one studio enterprise to create stand alone HTML5 web application ?
It seems like "wijmo javascripts/html5 widgets" belongs to "Studio for ASP.Net" of "Studio enterprise package". After installed it, we cannot find the related things to "wijmo javascripts/html5 widgets" in "C:\Program Files (x86)\ComponentOne\Studio for ASP.NET Wijmo" folder. (it shows ASP.NET MVC tools, bin, c1pdf and etc..) How can we use the things of "wijmo javascripts/html5 widgets" in our HTML5 applications from the insatlled machine (if the machine already had license activated).
Yes, you can use Wijmo widgets to create HTML5 web application and can refer to the following link for more details:
http://wijmo.com/
http://wijmo.com/5/
The issue is the following: I have developed an app which has to be tailored to multiple customers (actually, just string/color/UI-related resources need to be customized). It should also be noted that other customizations may be implemented on the webservice-side.
The result of such an operation has to be a new app (with a new name) to be submitted to the store.
Is this contemplated by Windows Store policies?
What approaches can I follow?
A first approach which comes to my mind is straightforward but error-prone and verbose:
creating an app which performs the following operations:
Makes a copy of the solution
Retrieves all the solution resources
Allows the user to customize the resources
Builds in output the new app version (solution) with the overrides
If the "user" that will do the customization is a developer, meaning someone who knows how to use Visual Studio, I'd suggest creating a Visual Studio template project.
You can easily export your existing app project as template (Microsoft provides a basic step-by-step explanation at How to: Create Project Templates, and I've once written a blog post that contains a more detailed tutorial: Creating template projects).
Either way, the result is a .VSIX file that can be installed as Visual Studio Add-In. With that, any developer that has the project template installed can choose it from the File -> New -> Project... dialog in Visual Studio - a new project will be created including all the files from the original project, the developer can then adapt the resource files and build the project into a new App.
I created a plugin for sublime and I called it "sublimecastling".
The main idea is to replace 2 selected fields.
So I'll be glad to know whether it's possible to add it to your Sublime repository in order users could install the plugin via package-control.
The github link is provided below,
https://github.com/unknownuser88/sublimecastling
If you want to make a plugin available via Package Control, visit the documentation page on the Package Control website and click on Submitting a Package. There are a number of steps, which can be summarized as follows:
Search Package Control to ensure your package fulfills an unmet need, or greatly improves upon an existing package - don't create a new one (especially a very simple one) when you could work with the author of an existing one to add a particular feature.
Pick a name - there are several requirements here.
Decide how to host - Github? Bitbucket? Your own SSL server?
my own note here: Github is easiest
Pick a versioning strategy using semantic versioning. Note that all new packages must release by using versioning tags, not by branches or commits.
Prepare your repo - several things to do here.
Fork the Package Control Channel on Github and add your repo to the default channel - detailed instructions included.
Run the ChannelRepositoryTools package in Sublime to make sure everything is OK.
Note: Test your package with both ST2 and ST3 to make sure it works with both versions of Sublime. If you can only support one version due to the language differences between Python 2.6 and 3.3, pick ST3 - it is the future of Sublime, has a very large user base already, and will get you maximum exposure. If you haven't personally upgraded to ST3, now is the time to do so. If you are a registered user—which you should be :)—test with both the public beta and the latest dev build.
Finally, you can submit your pull request.
Be patient, it may take a little while for it to be reviewed, and it is not uncommon at all for changes to be requested. It is by following strict procedures that the community maintains the high quality of the packages available for users.
I'm writing a plugin but I need a specific implementation for each Windows Phone version.
The problem is that the plugin system will try to load the platform plugin assembly based on a convention. In this case, "WindowsPhone".
We may try to override CreatePluginManager but then it will affect the rest of the plugins you may need.
I'm thinking of generating two different projects with different names but the same assembly and namespace. This, I think, would solve the problem of loading the specific plugin but I don't really know how to face an eventual publication to Nuget.
Best regards,
Roberto.
Generating assemblies with the same name is a viable way to go - it is something that the Microsoft Pcl teams do quite frequently - it is how the reference assemblies work.
The nuget distribution of these shouldn't be an issue - but would be a "faff" - as the nuget zip file would use different folders for the different files. There might, however, be some work to do at the .targets level if you want a single project to build both wp7 and wp8 configurations (this is similar to the effort needed for x86/x64/arm variants of assemblies in winrt nuget packages).
In fact, the main reason I can think for not using the same name is the very simple reason that it's far too easy to get in a muddle that way.
If for this one plugin, you wanted to override the plugin manager during setup, you could provide custom loading functionality based on
inheriting from https://github.com/slodge/MvvmCross/blob/v3/CrossCore/Cirrious.CrossCore/Plugins/MvxFilePluginManager.cs
and then overriding protected virtual string GetPluginAssemblyNameFrom(Type toLoad) to add a special based on some property of toLoad - eg if (toLoad.Name.EndsWith("Foo")) toReturn += PlatformPostfix
If this pattern becomes common - whether for wp or for the other versioned platforms - then we could include something back into the framework - it would be easy enough to try a version-neutral load followed by a version-specific load for every plugin.
There are also other ways you could go about this too...
E.g. Another possibility/opportunity is that your plugin core file could try loading multiple platform adaptions itself - eg using code like
public void EnsureLoaded()
{
var manager = Mvx.Resolve<IMvxPluginManager>();
manager.TryEnsurePlatformAdaptionLoaded<PluginLoader>();
manager.TryEnsurePlatformAdaptionLoaded<Sub1.PluginLoader>();
manager.TryEnsurePlatformAdaptionLoaded<Sub2.PluginLoader>();
}
This would try loading three child assemblies for that plugin - MyPlugin.WindowsPhone, MyPlugin.Sub1.WindowsPhone and MyPlugin.Sub2.WindowsPhone although you would only package one of these on each platform.