after upgrade from 5.0 to 6.1.2 the jira plugin checkup shows the error in extended class (below) MultiSelectCFType#<init> (OptionsManager, CustomFieldValuePersister, GenericConfigManager, JiraBaseUrls):void According to current documentation, the <init> constructor of the class has changed to from 4 to 6 parameters as following: public MultiSelectCFType(OptionsManager optionsManager, CustomFieldValuePersister valuePersister, GenericConfigManager genericConfigManager, JiraBaseUrls jiraBaseUrls, SearchService searchService, FeatureManager featureManager) ) So I have added nulls for two additional parameters, updated references to use current version of the class and resolved all compilation errors. Export finishes without errors and .jar file structure is identical to original). However, while attempting to process the file, plugin checkup shows the same issue with wrong number of parameters. looks like i am missing some other reference/ pointer. Please advice… Note: I do not know java or eclipse, so any help running, debugging or troubleshooting the issue would be appreciated.

1 answer

0 votes

So you have a plugin that needs rewriting wiht more than just a couple of parameters.

I'm afraid you need to understand your code, it's not just a case of whacking in what might be the right parameters.

no an option (unfortunately). java guy left and no one knows the language. I am sr.dev in vb.net, c# and thus was chosen for a task (i know what you are going to say!!!)... if i understand correctly, passing null for added parameters should or work or error out with wrong value/type exception. yet it looks like the parsing script (exe?) does not see them at all. meaning that some file w/ class definition is old or missing..XML?

I'm sorry, but "not an option" is not an option you have the luxury of here.

If you're going to rule out understanding the code and recompiling it properly, then your only other valid option is to remove the plugin. It's not working, it's not going to work, so you can't use it.

Passing in <null> instead of what is expected really isn't going to help you in the slightest - the best result you get from any real language is going to be "I expected you to pass me a valid object of type <what you already had from the api>". Oh, and coding to accept null gracefully is generally a bad idea too - it tells us you haven't thought through problem very well (just because a lot of people do it, doesn't mean it's clever - think about drinking, homeopathy or overeating...)

Which means you need to write the code to get the right object. It's not a case of trying to pull in other references or pointers, it's a case of changing the code to work out and pass in the right thing. Sticking random nulls in really is not an option either - the parameters are there for a reason.

Bother, I've just realised, I kept saying "you" there. You can, of course, find someone who knows java. Or better, someone who knows Jira's API well enough.

Posting the function call you're making here might prompt someone to point you in the right direction,

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,717 views 17 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you