There are some features like inheritdoc which are not supported natively by Visual Studio. How to convert input xml file with unsupported tags to its post-processed version so it can be included into release package?
Intellisense Only plugin should do the job for you. You can find it under project properties in plugins tab (see Intellisense plugin doc).
Related
I'm using postsharp and would like to know if these files .pssym are required for our product build/install process ?
Thanks!
Pssym files are not required for build or as part of a production installation.
Pssym files contains information about aspects applied to your code. PostSharp Tools for Visual Studio uses them to underline source code elements enhanced by an aspect and for source code analysis.
How can I convert Eclipse template file to IntelliJ template file. I do not want to add plugin to use the Eclipse file. I want to convert it.
Though not strictly respecting your question (no plugin), the built-in plugin Eclipse integration of IDEA 13 can import Eclipse templates quite accurately:
http://blog.jetbrains.com/idea/2014/01/intellij-idea-13-importing-code-formatter-settings-from-eclipse/
As stated in that post, the result cannot be 100% accurate as IDEA does not support all of the template options present in Eclipse (and the opposite might be true too).
I intend to customize Openmeetings and am wondering if there is a GUI editor available for Openlaszlo.
There was apparently a plugin called IDE4Lazlo, mentioned both at IBM and Eclipse.org, but both links are dead. If the plugin has been definitely pulled, then is there a way to at least preview layouts?
The IDE4Laszlo is on old IBM project, which has not been maintained for a long time (since 2005/2006). Laszlo had been working on an Eclipse based plugin in 2008, which was unfortunately never released.
Spket works, but compared to IDEs like Flash Builder the functionality is relatively limited, since the IDE is not capable of scanning your application files to recognize new classes and methods.
An option is to use an XML editor with XSD support. Sebastian Wagner of OpenMeetings has created a build script which generates an XSD schema file from the OpenLaszlo classes and the custom classes in your application. The source code can be found here:
http://code.google.com/p/openlaszlo-schemagenerator/
There are two Eclipse IDE plugins that support OpenLaszlo, IDE4Laszlo and the more recent Spket.
I'm mystified: I'm using Visual Studio 2008 with C++ (non-CLI), and I can't for the life of me work out how to build the help file with Sandcastle.
Once its installed, and its generating an .xml file, shouldn't there be a menu option somewhere to switch on the build of the docs? Or at least a menu option to trigger the build of the docs?
I don't believe sandcastle works with doxygen.
Sandcastle actually has nothing to do with managed or unmanaged projects. Sandcastle works against a set of XML documents that are typically generated during the build process. If you manually built the xml, you could make it generate docs for Smalltalk.
That said, while its most common usage is in the managed world, it is certainly supported for native C++ as well. The key is that the visual studio supports pulling xml documentation out of C++ compiled without the /clr switch, and those same XML files can be provided to Sandcastle for your document generation.
How do I externalize strings in my Eclipse plugin's plugin.xml?
Right-clicking on the plugin project > PDE Tools > Externalize Strings does not show up my plugin.
I'm trying to do this manually now. I added entries in plugin.properties and replaced the equivalent string in plugin.xml with a % sign followed by the string key. But that does not seem to work. What am I missing here?
I finally figured out how to manually externalize the plugin.
Eclipse, it turns out, externalizes plugin.xml this way:
In the plugin manifest (META-INF/MANIFEST.MF), add the following line
Bundle-Localization: plugin
where you intend to store the externalized strings in a file called "plugin.properties" (Turns out this was the missing piece).
Add the externalized string key-value pairs in plugin.properties.
Replace the actual strings in plugin.xml with the keys from plugin.properties (prefixed with %).
If your working set have plugin projects in it, the Externalize Strings wizard to help externalize strings in your Manifest and plugin.xml files should be available.
Externalizing manifest files extracts translatable strings and stores them in a properties file for multi-language support.
The wizard is available under the PDE Tools menu in the context menu of a PDE project's MANIFEST.MF or plugin.xml files.
(source: eclipse.org)
Be aware that there were some bugs related to detecting all non-externalized attributes/values of the <extension-point> and <extension> elements, or showing up un-externalized names of extension(-point), which are only solved in 3.4 or very recent 3.5M4.
However, if the "Externalize Strings" menu does not show up at all on your plugin projects, may be its "project nature" is corrupted somehow, may be your former Java project is not properly converted to a PDE project ?
So two suggestions:
try with a fresh install of an eclipse3.5M4
import your plugin project and check its nature
And then tell us if that menu is still unavailable.
As you mention in your own answer, the externalization process is declared by the string
Bundle-Localization: plugin
in the MANIFEST.MF file, as mentioned in this message.
A bug has been created, but:
The localization is not something specific to PDE but instead the OSGI specification
that line is not always in the MANIFEST:
Prior to 3.3, we created all our manifests by creating a plugin.xml and then
converting it. The converter always added "Bundle-Localization: plugin" to the
Manifest, since that is the default location if the plug-in has no Manifest.
If a plug-in had no translations files, this header was unnecessary bloat.
In 3.3, we created plug-in projects by creating Manifest directly, which means we
decided to create only the headers necessary for project creation.
it is likely to be an issue for those that have created bundles with
externalization < 3.2, and then not being able to see them when running in 3.3.