I have been doing some EFM databinding as a part of learning the eclipse modelling framework and one thing that didn't work with window builder was data binding with a TableViewer in th sense that it was fine for reading the data, but not for when you wanted to edit the data. so I am following Tom Shindl's on how to do it...the trouble is with this piece of code:
tableViewerColumn.setLabelProvider(
new GenericMapCellLabelProvider(
"{0}",
attributeMap
)
);
it says that GenericMapCellLabelProvider cannot be resovled...but when I use the GenericMapCellLabelProvider, it can be resolved, could someone help explain why this might be? I don't 'think I am missing any dependencies or packages etc..
Related
I have been researching about this term for so many hours, but I found anything useful yet.
Hope you can help us building this redmine plugin, or provide us some research links to help us find the correct key.
What we want to build
The thing is we want to update one custom field in redmine (let's name it 'Target_CF') whenever another one is created or updated.
We are looking for incrementing possible values of Target_CF, so we can have all custom field's names available to select.
Of course, we want to achieve this without directly editing Redmine's Core, so we thought developing a plugin would be the best approach.
Our plugin also creates and configures a new custom field (the one mentioned above), but I will let this out of the question, because I think it is not relevant for this.
Where we are right now
We have identified some hooks that could be useful for us, as the following:
:controller_custom_fields_new_after_save
:controller_custom_fields_edit_after_save
We have the following directories/files structure so far:
plugins/
custom_plugin/
init.rb
lib/
hooks.rb
The code we have written
init.rb
require_dependency 'hooks'
Redmine::Plugin.register :custom_plugin do
name 'custom_plugin'
author 'author name'
description 'description text'
version '1.0.0'
end
hooks.rb
class Hooks < Redmine::Hook::ViewListener
def controller_custom_fields_edit_after_save(context={ })
#target_custom_field_name = "Target_CF"
CustomField.find_by_name(#target_custom_field_name).possible_values.push(context[:custom_field].name)
end
end
The result of this code is none. I mean, no erros, no updates, nothing at all. There is no change in our possible values after editing/creating another custom field. We are sure there is something we don't know, some concept or workflow, and due to this we are doing something so badly.
Please, help us understeand what we are missing.
Previously we have succesfully developed another plugin that overwrites certain views. So we have kind of little skills in views related plugins, but zero experience at all at controllers ones.
We are using a Redmine 3.2.0 stack by Bitnami and a mysql database.
Well, finally we found out how to extend base controller's methods. I will post it here so hopefully this can be useful to anyone who finds the same doubts we had.
After some more researching, we conclude that it is mandatory to extend base controllers, in order to not directly modify core methods.
This is our final directories/files structures:
plugins/
custom_plugin/
init.rb
lib/
custom_plugin/
issue_custom_field_patch.rb
We previously stated that we could use some hooks to inject our desired functionality, but it seems not to work that way with controllers. On the other hand, we built a patch which will extend target class functionality.
Our final working code
Init.rb
require 'redmine'
ActionDispatch::Callbacks.to_prepare do
require_dependency 'issue_custom_field'
unless IssueCustomField.included_modules.include? CustomPlugin::IssueCustomFieldPatch
IssueCustomField.send(:include, CustomPlugin::IssueCustomFieldPatch)
end
end
Redmine::Plugin.register :custom_plugin do
name 'custom_plugin'
author 'author name'
description 'description text'
version '1.0.0'
end
issue_custom_field_patch.rb
module CustomPlugin
module IssueCustomFieldPatch
def self.included(base) # :nodoc:
base.extend(ClassMethods)
base.send(:include, InstanceMethods)
base.class_eval do
unloadable
after_save :update_possible_values
end
end
end
module ClassMethods
end
module InstanceMethods
def update_possible_values
self.reload
updatedPossibleValues unless self.name == "Target_CF"
end
private
def updatedPossibleValues
#safe_attrs = ['project', 'description', 'due_date', 'category', 'status', 'assigned_to', 'priority', 'fixed_version', 'author', 'lock_version', 'created_on', 'updated_on', 'start_date', 'done_ratio', 'estimated_hours', 'is_private', 'closed_on']
#custom_fields = IssueCustomField.all.select {|cf| !cf[:position].nil?}.collect {|cf| cf.name}
#possible_values = #safe_attrs + #custom_fields
CustomField.find_by_name("Target_CF").update possible_values: #possible_values
end
end
CustomField.send(:include, IssueCustomFieldPatch)
end
Functionality explained
As we stated in the question, we needed to update Target_CF possible values each time the users create/modify/removes a custom field from Redmine.
We extended IssueCustomField's class's instance methods, triggering our new function 'updatedPossibleValues' after each save. This includes creating new custom fields, and of course, updating existing ones and removing them. Because we reload our list of possible values each time, we had to control if its position were nil. If it is, this means that custom field has been removed.
Because of the ultimate action of this patch, which is the updating of another custom field, this also triggered our function, causing an infinite loop. To prevent this, we linked our functionality to every other custom field which name was not 'Target_CF'. A bit rusty fix, but we couldn't find a better approach.
I hope this can be useful to somebody in the future, as they could invest a fraction of time that we spent on this.
Comments, fixes and improvements are very welcome.
Based on: https://www.redmine.org/projects/redmine/wiki/Plugin_Internals which is a bit outdated, but finally could complete the code with help of another resources and forums.
I´m having some problems to create reports in my server without default export engine.
I´m using SpudSoft to create it. I have the following configuration:
Tomcat 7
Birt 4.2.2
uk.co.spudsoft.birt.emitters.excel_0.8.0.201310230652.jar
And i followed this tutorial:
spudsoft-birt-excel-emitters
I haven´t include this file
lib/slf4j-api-1.6.2.jar
because it´s not included in the *.jar file
and either wrote this code:
'if( "XLS".equalsIgnoreCase( outputFileFormat ) ) {
renderOption.setEmitterID( "uk.co.spudsoft.birt.emitters.excel.XlsEmitter" );
} else if( "XLSX".equalsIgnoreCase( outputFileFormat ) ) {
renderOption.setEmitterID( "uk.co.spudsoft.birt.emitters.excel.XlsxEmitter" );
}'
Because I dont really know where to use it.
to run my report i use the following URL
http://127.0.0.1:8090/birt-viewer/frameset?__format=xls&__report=informes/myReport.rptdesign&__emitterid=uk.co.spudsoft.birt.emitters.excel.XlsEmitter
and i get the following message:
org.eclipse.birt.report.service.api.ReportServiceException: EmitterID uk.co.spudsoft.birt.emitters.excel for render option is invalid.
What can i do to run SpudSoft report? I've been reading for a week and I haven´t found any solution!
Thanks a lot for all!
#Dominique,
I recommend upgrading from the emitter included with BIRT 4.3 (and given the lack of responses from the BIRT team I regret letting them put it in there).
Also, you don't need to use a specific IRenderOption type - they are all the same really anyway.
#Jota,
If you are getting that error it means that BIRT hasn't picked up the emitter correctly (you do have the correct emitter ID).
I don't use the BIRT war file, so my instructions aren't aimed at that approach (I just use the report engine in my own service).
The code snippet is no use for you, it's just a way to specify the emitter ID, which you are doing on the query string.
slf4j shouldn't be needed with the version of the emitter that you have - it uses JUL instead (I hate JUL, but it's one fewer dependency).
Can you post a complete listing of the jar files in your war?
It seems because you make use of a generic IRenderOption. With spudsoft emitter you should instantiate your render options like this:
EXCELRenderOption excelOptions = new EXCELRenderOption();
Note if you upgrade to BIRT 4.3 you don't have to set the emitter anymore, it is embedded
For a variety of reasons too convoluted to explain here, I find myself in a position where I need to be able to remove custom code workflows, while leaving the solution there.
I essentially have the same code as the plugin registration tool
Namely
service.Delete("plugintype", new Guid(info));
where info is the workflow id [running on a foreach loop but that's beside the point]
However, while the tool removes the workflows without any issues, my code complains about dependencies.
EM:
Additional information: The PluginType(a0b2dcf7-cf2a-111e-7da9-003021880a42) component cannot be deleted because it is referenced by 1 other components. For a list of referenced components, use the RetrieveDependenciesForDeleteRequest.
which I duly did
RetrieveDependenciesForDeleteRequest req = new RetrieveDependenciesForDeleteRequest();
req.ComponentType = 90; //plugintype
req.ObjectId = new Guid(info);
RetrieveDependenciesForDeleteResponse resp = (RetrieveDependenciesForDeleteResponse)OrgService.Execute(req);
This retrieves an optionvalueset, but there is little I can do with it as I cannot remove it from the solution as the solution is managed.
The only difference I can see is the way the OrganizationServiceProxy gets instantiated. The plugin registration tool includes a way to refresh the securitytoken, but as far as I can tell it's not doing much (I've stepped through the code, but it's possible I missed something)
Are you sure that it is an OptionSetValue that is the dependency? It's much easier to use GUI to determine what the dependencies are. Fire up your solution in CRM 2011, click 'plug-in assemblies', select the relevant assembly then go through each custom workflow/plugin item and click 'Show Dependences'.
In my case I had another workflow (created within CRM) that was referencing a custom workflow preventing removal of the assembly.
You won't be able to remove components from a Managed solution... Are you the author of the solution originally?
As an aside, does your workflow fire on change of the OptionSet that is showing as a dependency?
So I need a few simple pointers with the BIRT chart API.
I am trying to draw a simple line chart of a numeric value over time. I have a vector of (Date,Double) pairs as input. I have read through the examples in org.eclipse.birt.chart.examples but not yet gained enough traction with the API to start making use of it. Just composing a org.eclipse.birt.chart.model.impl.ChartWithAxesImpl has me stumped.
The eventual destination is an Eclipse editor, and that I can do. Is there a tutorial or book anyone can recommend that might get me going with the BIRT chart side?
I should be very grateful
M.
Well. There is this example: http://www.eclipse.org/articles/article.php?file=Article-BIRTChartEngine/index.html
But I am having some problems actually getting it to work myself. All I end up with is an exception like this:
java.lang.NullPointerException
at org.eclipse.birt.chart.device.swt.SwtTextMetrics.getHeight(SwtTextMetrics.java:178)
at org.eclipse.birt.chart.computation.Methods.computeFontHeight(Methods.java:1272)
at org.eclipse.birt.chart.computation.BIRTChartComputation.computeFontHeight(BIRTChartComputation.java:30)
at org.eclipse.birt.chart.computation.EllipsisHelper$SimpleTester.<init>(EllipsisHelper.java:213)
at org.eclipse.birt.chart.computation.EllipsisHelper.createSimpleTester(EllipsisHelper.java:176)
at org.eclipse.birt.chart.computation.EllipsisHelper.simpleInstance(EllipsisHelper.java:183)
at org.eclipse.birt.chart.computation.LabelLimiter.limitLabelSize(LabelLimiter.java:256)
at org.eclipse.birt.chart.computation.LabelLimiter.limitLabelSize(LabelLimiter.java:211)
at org.eclipse.birt.chart.model.layout.impl.TitleBlockImpl.computeBox(TitleBlockImpl.java:288)
at org.eclipse.birt.chart.model.layout.impl.LabelBlockImpl.getPreferredSize(LabelBlockImpl.java:266)
at org.eclipse.birt.chart.internal.layout.LayoutManager$ChartLayout.<init>(LayoutManager.java:111)
at org.eclipse.birt.chart.internal.layout.LayoutManager.doLayout_tmp(LayoutManager.java:1145)
at org.eclipse.birt.chart.internal.layout.LayoutManager.doLayout(LayoutManager.java:1310)
at org.eclipse.birt.chart.factory.Generator.build(Generator.java:1092)
I had the same trouble with the examples from org.eclipse.birt.chart.examples. There are some good java code snippets, but you do not see to what they correspond. This is why I decided to generate all the examples and put them on a web site: BIRT Charts Gallery.
i am pretty new to Jira Development so please be patient
I should upgrade a Plugin that worked with Jira Version 3 to work with Jira Version 4
Most of the thins went pretty well, but now i am kind of stuck
The SearchParameter and the ProjectParameter Class are not available in the new Version and i dont exacly know how to replace them. its really just this few lines of code, where its needed
these Classes are outdated: SearchParameter and ProjectParameter
i looked in the jira doc buts its seems pretty complicated, you would do me a great favor if you could help me
SearchRequest sr = srs.getFilter(ctx, filterId);
...
SearchParameter param = sr.getParam(new ProjectParameter().getName());
...
List columns = columnLayout
.getVisibleColumnLayoutItems(user,
param.getValues(), Collections.EMPTY_LIST);
It would even Help if you could explain what the seccond Line intends
Thanks in advance
I can't help you rewrite the plugin entirely, but I can try help you decipher what those quoted lines of code mean:
SearchRequest sr = srs.getFilter(ctx, filterId);
This line loads a saved SearchRequest with the corresponding filterId.
SearchParameter param = sr.getParam(new ProjectParameter().getName());
This line gets the Project search parameter that was saved in the SearchRequest. As you may know, SearchRequests (or saved filters if you prefer) all you to save a search from JIRA with parameters defined. One possible parameter to define is a ProjectParameter. So if your search is "all issues in project X", then you would have a SearchParameter in your SearchRequest which is a ProjectParameter that knows to search for project X.
List columns = columnLayout
.getVisibleColumnLayoutItems(user,
param.getValues(), Collections.EMPTY_LIST);
This line retrieves the ColumnLayoutItems which are visible to the specified user, for the specified projects of the SearchRequest (by extracting the value from the ProjectParameter of the SearchRequest as retrieved in line 2).
It's a bit unclear what this code is attempting to do without more context, but that's what those lines are doing anyway. You might find the API documentation useful:
http://docs.atlassian.com/jira/3.13/
http://docs.atlassian.com/jira/3.13/com/atlassian/jira/issue/fields/layout/column/ColumnLayout.html