Thanks for the test case Milos, I'll look at it soon...

FYI this is how my code for opening the web pane looks like:

    @ProjectServiceProvider(service = WebBrowserPane.class, projectType = "org-netbeans-modules-maven/" + AtlassianProject.ATLASSIAN_PLUGIN_PACKAGING)
    public static synchronized WebBrowserPane getBrowserSupport(Project project) {
        WebBrowser wb = findChrome();
        WebBrowserFeatures features = new WebBrowserFeatures(true, true, true, true, true, false);
        WebBrowserPane pane = wb.createNewBrowserPane(features);
        pane.setProjectContext(project.getLookup());
        return pane;
    }
    private static WebBrowser findChrome() {
        for (WebBrowser wb : WebBrowsers.getInstance().getAll(false, false, false)) {
            if (wb.hasNetBeansIntegration() && !wb.isEmbedded()) {
                return wb;
            }
        }
        return null;
    }

I have finally successfully build the attached project.
I got api-1.1.nbm at https://oss.sonatype.org/content/repositories/releases/org/netbeans/contrib/yenta/api/1.1/
and then configured the atlassian repository according to https://developer.atlassian.com/display/DOCS/Atlassian+Maven+Repositories
Maven did not use that repo right away, I've downloaded some artifacts manually and put them to the local repo, but after a bunch of manually downloaded artifacts, Maven finally retrieved the rest from atlassian.

After run of the project I clicked on "jira started successfully in 176s at http://martin-Latitude-E6410:2990/jira" link, but I got these two exceptions:
Caused: java.lang.NullPointerException
        at org.netbeans.atlassian.maven.modules.output.RunResultChecker.getBrowserSupport(RunResultChecker.java:220)
Caused: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:483)
        at org.netbeans.modules.projectapi.LazyLookupProviders.loadPSPInstance(LazyLookupProviders.java:205)
...
and
java.lang.NullPointerException
        at org.netbeans.atlassian.maven.modules.output.RunResultChecker$1.outputLineAction(RunResultChecker.java:177)
        at org.netbeans.core.output2.OutputTab.lineClicked(OutputTab.java:271)
        at org.netbeans.core.output2.OutputPane.lineClicked(OutputPane.java:82)
...

Then I realized, that I did not have HTML5 features activated. The atlassian module should probably have a dependency on HTML5 so that it's activated automatically.

After I activated HTML5, clicking on the link started Easel with the debugger.
I've put a logging in, which printed:
Breakpoint: {"breakpointId":"http:\/\/martin-Latitude-E6410:2990\/jira\/s\/d41d8cd98f00b204e9800998ecf8427e-CDN\/en_USkgvx26\/6331\/3\/1.0-SNAPSHOT\/_\/download\/resources\/org.milos.jir:jir-resources\/jir.js:3:0","locations":[]} => location = null
The breakpoint is in an unresolved/inactive state, because "jir.js" has not been loaded yet.

I'll check if jir.js is loaded after I log in and go to some admin page. I'll check how breakpoints behave and hopefully I'll reproduce and find the problem.

>Then I realized, that I did not have HTML5 features activated. The atlassian module >should probably have a dependency on HTML5 so that it's activated automatically.

what specific module should I include the dependency on?

On web.client.kit IMHO.

It looks like this is out of scope for NetBeans.

The breakpoint was submitted to this URL:
http:\/\/martin-Latitude-E6410:2990\/jira\/s\/d41d8cd98f00b204e9800998ecf8427e-CDN\/en_USkgvx26\/6331\/3\/1.0-SNAPSHOT\/_\/download\/resources\/org.milos.jir:jir-resources\/jir.js

But then we get:

event {"method":"Debugger.scriptParsed","params":{"endLine":11,"endColumn":3,"scriptId":"1529","startColumn":0,"startLine":0,"url":"http:\/\/martin-latitude-e6410:2990\/jira\/s\/d41d8cd98f00b204e9800998ecf8427e-CDN\/en_US-7rn5gq\/6331\/3\/1.0-SNAPSHOT\/_\/download\/resources\/org.milos.jir:jir-resources\/jir.js"}}

The URLs are different.
There is "en_USkgvx26" in the first one, but "en_US-7rn5gq" in the second one.

The URLs are provided by org.netbeans.atlassian.maven.modules.output.ServerUrlMappingImpl

I do not see what I could do about this in NetBeans.

(In reply to Martin Entlicher from comment #6)
> It looks like this is out of scope for NetBeans.
> 
> The breakpoint was submitted to this URL:
> http:\/\/martin-Latitude-E6410:2990\/jira\/s\/
> d41d8cd98f00b204e9800998ecf8427e-CDN\/en_USkgvx26\/6331\/3\/1.0-SNAPSHOT\/_\/
> download\/resources\/org.milos.jir:jir-resources\/jir.js
> 
> But then we get:
> 
> event
> {"method":"Debugger.scriptParsed","params":{"endLine":11,"endColumn":3,
> "scriptId":"1529","startColumn":0,"startLine":0,"url":"http:\/\/martin-
> latitude-e6410:2990\/jira\/s\/d41d8cd98f00b204e9800998ecf8427e-CDN\/en_US-
> 7rn5gq\/6331\/3\/1.0-SNAPSHOT\/_\/download\/resources\/org.milos.jir:jir-
> resources\/jir.js"}}
> 

where do you get this snippet from? How can I enable it locally on my computer? I've been having both ends of ServerUrlMappingImpl the same and still exposing the same issue.. (I'm printing both directions to IDE log)

Hmm.. I've done some more experimenting and I must confirm that the jira plugin case is borked and fault of my plugin (well, I just query a rest endpoint of the app and apparently that one is lying to me).

I've also tried to a confluence plugin. There the urls DO match and the breakpoint doesn't break and IDE stops in js file. Great.
Then for a bamboo plugin (I use these most), I get correct matching urls AND a broken breakpoint but interestingly when I browse to the actual page containing the js with breakpoint, the breakpoint magically turns back into non-broken state and stops there. 
(this is not the case with the jira plugin)

Thanks a lot for taking time to investigate, I will try to get back to the jira devs to ask why thee is the url discrepancy. I'm not sure if it's worthwhile to follow the bamboo plugin mystery.

Re. bamboo - I think this might be correct behaviour if breakpoint is in JS file which is loaded dynamically. Once the JS file is loaded the breakpoint is resolved by Chrome and marked as valid. Until then it is unresolved. I hope I sill remember this right though.

I'm surprised to hear that some 3rd party NB modules are implementing ServerUrlMappingImplementation. :-) I do not think I ever thought of that usecase. But if it works that's awesome! :-) Good luck Milos.

(In reply to David Konecny from comment #9)
> I'm surprised to hear that some 3rd party NB modules are implementing
> ServerUrlMappingImplementation. :-) I do not think I ever thought of that
> usecase. But if it works that's awesome! :-) Good luck Milos.

well, there was no other way I suppose. The default implementation would never work. Just to give you overall picture of what's possible. The js files are by default batched and minified for the given page or set of pages.(thus you never actually see the right file and linenumber on the browser). There's some special parameters to be passed to the server (and yes, these are different for each app apparently)
Then there is this long url with hash and other parameters in the path that I first tried to replicate manually without success and ended up querying the rest end point. However I believe under certain circumstances these urls can still change during the lifetime of the app, I'm silently hoping they don't for the debugging short lived instance. Because the js files are actually transformed on the fly - one such transformer being localization.

Another way for you possibly could be "sourcemaps". It is a maps from source file to "compiled" one, eg. sass/coffeescript/minification/etc tool generates sourcemap which allows to map garbled JS/CSS into the source. Chrome is capable of using such sourcemaps during debugging. In NB we looked into sourcemaps few times but I think (I cannot remember) never did anything with them (to support them etc).

When you start NetBeans with -J-Dshow.webkit.protocol=true, you can see the debugger communication in WebKit Protocol output tab. There you can see the URLs.

Some problem with the breakpoints is probably still there. I'll try to reproduce again. If you can find some unique steps that lead to the breakpoint issue, please provide them here. Thanks.