What do you do to find development information?

For example, I recently had to find out how to change the memory for the refapp that runs when running atlas-integration-test. I gave up and opened a forum topic.

A Google search was useless, as it only returns results on how to change it in production - not how to set it via maven with the sdk during integration tests running the refapp.

It doesn’t matter if my search includes “atlassian sdk” or “atlassian development”, I constantly get results from stack overflow and community.atlassian.com that are completely unrelated to app development.

This has been a MAJOR problem for me over the last month as I have been getting into app development. I have never had such trouble finding basic information on any other new technologies that I have begun using.

How do you guys deal with this problem?

To be honest… I think most successful vendors are the ones that stick around long enough to have clocked the hours required to either actually know by experience, have seen the product change historically, are aligned with Atlassian product development and have become really really good at searching for clues in either Google, documentation or the host product source code. Additional resources are: Atlas Camp and developer day talks, one-on-one conversations with peers in the Slack channel (we had a very nice discussion about dealing with backwards compatibility using OSGi just yesterday) and this community forum.


Second on getting comfortable reading the Source Code. I find that by far most of my concrete answers have come from discovering exactly how Atlassian did something.

I cannot build the source jars due to Atlassian deciding not to publish some of the artifacts that are required - there is an open issue. Adding them 1-by-1 as needed, so not too much of a problem.

Oh! For info on doing things using Java, I search for “scriptrunner {my search}”. There is plenty of information on how to do things using ScriptRunner, but barely anything for native. So, you just get the info from there, use DI instead of ComponentAccessor, and you are good to go. Would have been nice to know that the *Service classes are essentially deprecated and that I should have used the *Manager classes, but that was quick to discover and fix. A couple helper services of your own and it’s not that hard to work with, really. After the first week or two, the coding was a breeze and is going very quickly.

My main issue has been with the infrastructure. I had to give up on developing in Windows due to several errors in their scripts - some of which have had open issues since 2016. Switched to Linux, set everything up again, and it was working within a couple hours. It really feels like they don’t care.

When I noticed that the last updates to some of their projects geared towards outside developers were back in 2015…the same year they went public… Let’s just say that I didn’t feel welcomed.

You can get access to the full source code of all Atlassian products when you buy a license. As an app developer, spending $10 on a starter license is the best investment you can maken.

I do have the source code for my target JIRA version (atlassian-jira-software-7.13.8-source).

The page that describes how to download it from my.atlassian.com says it is best to build the source jars from it and they provide the command. This command fails (you can work around a few of the problems with it, see Yarn link below), but they didn’t bother to make several artifacts public that the build relies on. There has been an open issue for this since Oct 2017 (https://jira.atlassian.com/browse/JRASERVER-66224).

You simply cannot build certain versions of JIRA.

They must never have even tried the build from an external IP on a clean machine; otherwise, these issues would have been noticed (and, hopefully, addressed).

This is annoying, but does not prevent me from using the source code in my IDE. It’s just another place where Atlassian doesn’t care enough to prioritize a fix. I have run across other issues, where the community has provided the exact changes needed to fix the issue - and they still don’t do anything.

Yarn problem with the build that eventually led to me finding the missing dependency issue:

I have never built Jira from scratch – I only suggested the Source Code for understanding how to accomplish things in the SDK. Plenty of things aren’t documented but when you read the source code become very clear. So that was simply a suggestion on how to become more familiar or to answer questions that are otherwise unanswerable.

For instance, I would search CreateIssueDetails (which is the JAVA class that corresponds to the CreateIssueDetails!default.jspa webwork action) to determine how Jira uses IssueService to create issues.

I want all my packages to be plugins, so building the actual source code isn’t important to me.

1 Like

+1 for not trying to compile/built/run Jira from source. I’ve never even tried that in the 6+ years I’ve been doing app development. Not sure what you would want to accomplish by building Jira from source?

1 Like

Not sure how to make this any more clear… I have no wish to and am not building JIRA (the war file) from source. I was explaining the problem with building JIRA source jars from the JIRA source code.

Source JARs - like the ones you normally get from repositories. They are *-source.jar files. They make it easy to download and view source code from repositories and tie in nicely with IDEs.

There is a documented process for building these from the source code to make using the source code easier and more integrated with how you are used to dealing with most dependencies - you can even send them to your local maven repo after building them. Unfortunately, the process to build the source jars uses a bunch of the same steps as are used when building JIRA from source (the war file) - and since that is broken, so is building the source jars. This process has been broken since JIRA 7.4.0 (https://confluence.atlassian.com/jirakb/download-source-code-for-jira-server-800307235.html).

Like I said, having access to the raw source code is great and helpful. But, it’s the bare minimum.

It would just be nice if they would fix their bugs so we could do things more structured, more modern, more integrated. Things like using Find Implementations, as opposed to the old-school way of searching through a large directory of files for a string.

This got way off topic :wink:

@DerekWhite as a “workaround” you could try using -Dskip.yarn and -Dskip.grunt while building sources.

I also use the following search for developer docs https://developer.atlassian.com/search/ , in your case you want to select the Atlassian SDK as product and search for “build” as keyword .


I could have searched for “integration tests” or “memory” , but I decided to be less specific and search for a keyword that depicts my current task / main purpose / context . My understanding from your post is that you need to run integration tests and give your instance more memory, and I am assuming it is in the context of a build that requires a certain configuration.

That search will lead you to https://developer.atlassian.com/server/framework/atlassian-sdk/amps-build-configuration-reference/

In there you can poke around, and ultimately find jvmArgs property , which you can use to give your java process (aka server/instance) more memory.

So you want something of the sort , this is a confluence specific example , but you can adapt it to the other products too

        <jvm.args.custom /> <!-- Allows to specify custom arguments in build scripts -->
        <jvm.args>-Xmx${jvm.args.xmx} ${jvm.args.custom}</jvm.args>

Thank you for providing a detailed solution. You are using jvm.args.custom for custom arguments in build scripts. This seems like a code smell and bad workaround. What about working on: https://ecosystem.atlassian.net/projects/AMPS/issues/AMPS-1341

Interested in hearing about why it seems like a code smell , aren’t build configurations just code smell ? :smiley:

I am familiar with https://ecosystem.atlassian.net/projects/AMPS/issues/AMPS-1341 already, considered implementing it, but then kept debating what the expected behaviour should be.

Relying on jvm.args.custom is a workaround, yes, I agree, but it favours simplicity over an unclear override/merge/maybe-concatenate logic that we would need to document … and according to this post, finding relevant docs isn’t as easy :smiley:

Happy to hear your thoughts around AMPS-1341 , it has been couple years since I’ve looked into it , maybe I am missing a piece of the puzzle ?

Seems like a code smell because we have the --jvmargs option for some atlas- commands, which exactly replicates your jvm.args.custom solution, just does not work if jvmArgs are defined in pom.xml. :thinking:

I agree that a clear and simple solution is better than some hard to understand / find logic.
This is what the current help text states, e.g. altas-run -h:

–jvmargs [value]
Additional JVM arguments if required.

According to that I’d append the additional JVM arguments to the JVM arguments of the pom.xml. We should have such a discussion on the corresponding ticket. :smiley:


Oh I see the code smell now :face_with_monocle:
I personally always go with configuring things in pom.xml and use maven profiles when I need to run with specific settings
Yes, let’s discuss on AMPS, if there are any other tasks in there that you think are important, let me know, happy to take a look