Hello,
I searched through previous questions and couldn't find an answer that fit closely to what I'm trying to do, so I thought I'd ask here.
I am working on a project (Project A) that uses JIRA for bug and story tracking.
My project works alongside three other projects (Project B, Project C and Project D), all of whom are supposed to be using JIRA in the same manner.
All projects do work on epics that are similar across the projects. Meaning Projects A & C may implement Epic 'UI update', but they work on it independent of each other, and don't require one to be done before the other can begin.
All projects do work on epics that are not relevant to any other project (ex Project B working on Epic 'New B-style').
All projects on occasion must integrate work from a 3rd party, and ideally at the same time.
My question- is there a way to track all of this at a higher level? Meaning, is there a way to create 'Master Project' that monitors a) progress and issues of the epics of individual projects (A, B, C, D) and b) progress and issues of epics that are similar across the projects?
Ideally, I'd like to make some sort of dashboard that can monitor the health of the individual projects as well as the overall health of the environment that the individual projects make up together. And then track any issues blocking the progress of the common epics.
Bonus points for helping figure out how to also track the incoming/progress of integration of the 3rd party pieces.
Sorry for the convoluted question, as you can see, it's hard (for me) to wrap my head around.
This issue is resolved with JIRA 4.4.3 and Greenhopper 5.8.1
Francis
IMHO this class was doing something very iffy: http://docs.atlassian.com/greenhopper/5.6.1/com/atlassian/greenhopper/dev/Reloader.html - it caused me problems too. Removed from 5.7 and above.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It is problem I met since long time with my customfield and alos my listener.
Similar issues may also occurs with MercuryListener from Go2Group and Gantt plugin.
These plugins access to CustomfieldManager, ServiceManager or init Listerner, before Plugin System is ready.
This causes a failure of your components if your customfield, Service or Listener have dependencies on other part of your plugins.
The only workaround is to remove direct dependencies (in constructor) and resolves the dependencies on demand (by calling getComponentOfInstance for V1 or getOSGiComponentOfInstance for V2) ... You will gain an IllegalCallException (or something like that) as Warning from JIRA that a naughty call has bee done, but your component is enabled and working.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Interesting but to me that doesn't explain how when greenhopper 5.7 is out of the picture, everything works normally.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
When GH uses CustomFieldManager (before that Plugin System has loaded all plugins), DefaultCustomFieldManager loads all Customfield defined in Database. In most case, their are loaded whitout issue, but if they have direct dependencies (in Constructor), if these dependencies are provided by a not yet loaded Plugin, then the customfield is disabled (due to missing dependencies), since CustomfieldManager is defined to load customfield when Plugin System is ready, not before.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
There is bug found by me today. When Plugin System perform start (ComponentRegistrar performs during calling quickStart() method) it broadcasts PluginEnableEvent. It may be processed by some listeners and produce too early initialization. For example RankService of GreenHopper plugin calls CustomFieldManager during processing this event. CustomFieldManager instantiates all the registered at this time CustomFieldTypes, but they can have dependencies, which are located not in loaded yet plugins.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
JIRA 4.4. But i think simmilar problems could be found in any version with different plugins, especially with static calls as mentioned by you
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Right now i made a test, which show what without GreenHopper my customFields plugins starts normaly
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jamie,
Yes the plugins are enabled.
I found some references where plugins who instantantiate a customfieldmanager statically got into troubles.
Francis
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Mmm, can you go into the logs in more detail? And maybe turn up the logging levels a bit?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Nic,
I'm trying to narrow down the root cause by doing a step by step. I will bring up logging also to debugging level and see if this reveals something.
Francis.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Is it definitely "enabled" after the restart? I have seen some plugins that persistently disable themselves on startup, for no obvious reason.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.