I want to have one Eclipse Plugin.
Note that multiple context files from different plug-ins can be
associated with the context ID. This allows one plug-in to extend the
context help provided by another.
But this doesn't seem to work as expected. I defined them like this.
<extension
point="org.eclipse.help.contexts">
<contexts
file="context_help_A.xml"
plugin="com.a.a">
</contexts>
</extension>
<extension
point="org.eclipse.help.contexts">
<contexts
file="context_help_B.xml"
plugin="com.a.b">
</contexts>
</extension>
When debugging only the com.a.a context turns up and the com.a.b context doesn't work. I don't want to deploy a plugin just to put the context file into.
I realize this sounds lame, but did you try defining your contexts like the following? That's how the JDT user doc plugin (org.eclipse.jdt.doc.user) does it.
<contexts file="..." plugin="..." />
Related
If I understood correctly, DNN widget is a way to add a js to every page on the website using module or theme. Right?
My goal evantually is to add a js to every page on a portal and preferably to do that via module that has no need to be added to every page manually.
My plan B is adding module and using setting "Display Module on All Pages", but widget seems to be a better way to do that.
At first I've tried to use this instruction. I've added the YourCompany.Widgets.SampleWidget.js file to root of existing DNN module. Also in the .dnn manifest file inside components tag I've added another component like this:
<component type="Widget">
<widgetFiles>
<basePath>YourCompany</basePath>
<widgetFile>
<name>YourCompany.Widgets.SampleWidget.js</name>
</widgetFile>
<widgetFile>
<name>license.txt</name>
</widgetFile>
<widgetFile>
<name>releasenotes.txt</name>
</widgetFile>
</widgetFiles>
</component>
I've got this error on module installation:
Failure File specified in the dnn could not be found in the zip file: - D:\Projects\website.com.ua\Host\Install\Temp\vp1vioj1\YourCompany.Widgets.SampleWidget.js
vp1vioj1 part is changing every time (seems like it's some unique id that is generating on module install).
Then I tried to place this widget component inside another package tag after checking this article. Like this:
<dotnetnuke type="Package" version="5.0">
<packages>
<package name="ModuleName" type="Module" version="00.00.01">
<!-- some module content here -->
</package>
<package name="YourCompany.SampleWidget" type="Widget" version="00.00.01">
<components>
<component type="Widget">
<widgetFiles>
<basePath>YourCompany</basePath>
<widgetFile>
<name>YourCompany.Widgets.SampleWidget.js</name>
</widgetFile>
</widgetFiles>
</component>
</components>
</package>
</packages>
</dotnetnuke>
But I still got the same error on install. I didn't find any other instructions or documentations regarding widgets. When I tried to check the DNN source code - it seems to be also very time consuming and hard way.
So could you please help me to clarify this?
Support for Widgets in DNN Platformnwas dropped a number of years ago.
Your best option if you want something ok all pages would either be to look at a SkinObject, like the breadcrumb or Login for example. Or a traditional module but marking it “display on all pages”
First, you might want to take a look at the concept of DNN Extensions and how they are built and packaged.
If examples of versions DNN extensions, https://github.com/WillStrohl/dnnextensions. The examples include a widget. So check it out.
Now, what you posted looks like a .dnn file, which the the manifest file that is intended to be a part of a packaged DNN extension. Code and other bits and pieces go into the packaged extension (really a specially named zip file). The packaged extension is installed into your DNN installation via the Extensions Persona Bar page (click the Install Extension there).
From my experience with DNN (2006 to now), I believe that I can say that a DNN Widget is something that I've never had anything to do with. So, you may be barking up an old any dying tree in the project.
If you want something included on every page, it makes more sense to include it in the theme (skin). If you want a javascript file, add that to your theme project and have the .ascx files include it, probably using https://docs.dnncommunity.org/api/DotNetNuke.Web.Client.ClientResourceManagement.html (see https://docs.dnncommunity.org/api/DotNetNuke.Web.Client.ClientResourceManagement.html)
But, if you are determined to use a widget, start with https://www.kalyani.com/blog/2009/12/25/dotnetnuke-widgets-guide-part-1-of-4/
I found out it is possible to create custom regions folding in java files with nice line comments as descibed here: http://www.jetbrains.com/idea/webhelp/folding-custom-regions-with-line-comments.html but I can see this only works for java files. Is it somehow possible to make it work in xml files like in pom.xml.
What I would like to achieve is to introduce custom regions in dependencies to make it easier to navigate between them.
You can create regions in XML like this:
<!-- region This will show when folded -->
Your XML goes here.
<!-- endregion -->
XML and HTML custom folding regions will be a new feature introduced in upcoming IDEA 2016.3 release (see IDEA-93649).
If you want to use these features now, you can download the IDEA 2016.3 EAP release now.
Is there a command line option to change the stylesheet file created by javadoc?
I would like to use my own css file.
The default blue one is boring. I tried a -stylesheet option, but it's not supported.
Yes, it's possible and actually quite straightforward. If you look for example at Mockito's javadoc:
http://docs.mockito.googlecode.com/hg/org/mockito/Mockito.html (you can see that they have changed the default appereance just using this stylesheet)
If you are using Maven, you can do that by adding some config in the maven-javadoc-plugin:
http://maven.apache.org/plugins/maven-javadoc-plugin/examples/stylesheet-configuration.html.
In case you are using ant, there is a way to inject the parameter to the javadoc tool:
http://ant.apache.org/manual/Tasks/javadoc.html
For more information, there are some discussion topics about that in stackoverflow: JavaDoc Style Sheets
For the maven-javadoc-plugin, you can also use:
<configuration>
<addStylesheets>our-stylesheet.css</addStylesheets>
</configuration>
which keeps the primary stylesheet, but then also adds the custom one, so that all you need to do is override the rules you want.
Put our-stylesheet.css in the src/main/javadoc directory.
I've developed a quick and simple plugin that adds line markers for lines containing the text "TODO", based on the "Plugin with an incremental project builder" template.
It works, but markers are not persisted between Eclipse sessions (restarts).
I have the following element in my plugin.xml:
<extension
id="todoTask"
name="TODO Task"
point="org.eclipse.core.resources.markers">
<super type="org.eclipse.core.resources.taskmarker">
</super>
<persistent value="true"/>
</extension>
Again, the plugin works fine, so this is processed, but it doesn't seem to matter if I set the persistent value attribute to true or false, it just doesn't persist the markers.
Why aren't the markers persisted and how can I fix this? Do I need to perform additional programming/configuration to persist them? Thanks.
I found out what the problem was through trial and error. The marker id needs to have a dot in it in order to actual be counted as a marker type. So in your case try setting id="todoTask.marker" for example and then calling someResource.createMarker("todoTask.marker"). Oh, and maybe write the id with lower case letters, just to be on the safe side
I have never worked with plug-in fragments before. I thought that by creating a new class within a fragment and exporting the package that contains it in the fragment's manifest, I'd be able to access that class from another plug-in that already has a dependency on the host plug-in. However, I cannot seem to make this work. Are the contents of a fragment ever visible to any plug-in besides the host plug-in? If so, is there something special I have to do to allow this?
The problem is not, that the contents of the fragment aren't visible to another plugin: They are - just try loading e.g. a properties file from the classpath, it still works if that properties file is provided by the fragment.
But what you don't have, is compile-time information about the fragment's contents. That's the principle of a fragment: You can't have a dependency on it. And you don't know, if somebody has fragments installed or not.
It's also not only a problem that just "any plug-in besides the host plug-in" has. It's a problem, that even the host-plugin itself has. It doesn't know about the fragment's existence at compile-time.
You also can't reliably use a fragment to override parts of the host plug-in's classes: FAQ Can fragments be used to patch a plug-in? , if that's what you want to do. The page also describes, how it can be done.
Hope this helps.