Is it a good practice to avoid Spring Scanners in Jira add-on…?
In some answers, it was told to remove the usage the Spring scanners from pom.xml to avoid errors.Is it necessary to use Spring Scanners in Jira add-on…?
If Spring scanners are necessary, Which version we should use either 1 or 2 ?
The default Jira command atlas-create-jira-plugin creates plugins with Spring scanners with version 1+ . Is it good to develop addon with Spring scanner version 1…?
Spring Scanner has several pros (and a couple of cons):
Pros
- The add-on starts up a lot faster (which is the main reason for it and makes admin happier which makes Atlassian happier and so forth).
- The add-on code is much much cleaner - no more declaring things in the atlassian-plugin.xml - it ends up just having web-panels, web-resources and so forth (and you can get away from that as well if you want).
Atlassian will tell you about #1 being the most important reason to do it - but from my perspective #2 is so much more of a reason to use it.
Cons
- It’s a pain to get set up and working. It really is.
- Once you have it set up you have to remember to annotate things EVERYWHERE!! (I’ve seen anti-patterns of people having a single class where they annotate everything - just for the purpose of doing the annotations - kinda defeats the purpose of #2 for me).
- Once you have it set up, you have to remember the right annotations (there are conflicts with Spring’s annotations).
Me personally, I used Spring Scanner for all of my new projects. I’m slowly trying to migrate the old ones to it as well. As far as SpringScanner1 versus SpringScanner2 - obviously 2 is more future proof but 1 is a bit more stable (or at least from my experience).
3 Likes