This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Add the ability to have maven and plugin sources available while debugging maven builds. | ||
|---|---|---|---|
| Product: | projects | Reporter: | rptmaestro <rptmaestro> |
| Component: | Maven | Assignee: | Milos Kleint <mkleint> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | mentlicher, MikeJansenNEC, puce |
| Priority: | P2 | ||
| Version: | 7.0.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Bug Depends on: | 200910, 48750, 209251 | ||
| Bug Blocks: | |||
|
Description
rptmaestro
2011-09-07 15:15:58 UTC
I should clarify that when I am debugging my maven plugin, I am running it on a project that doesn't have compilation dependencies on maven. The project I want to debug is just configured to execute my maven plugin during a phase of the build. AFAIK it works if the plugin was open as a source project (as well as your regular project). I suppose there is a use case for debugging the plugin even if you do not have its source checked out (though you would be unable to fix any bugs you encountered in this case). I just added #203536 yesterday which is related to this issue to some degree.
>> I suppose there is a use case for debugging the plugin even
>> if you do not have its source checked out (though you would
>> be unable to fix any bugs you encountered in this case)
I am writing plug-ins for Atlassian JIRA. JIRA is not open source but because we have a license, we get the source code. It is possible I would debug JIRA but not likely. However, when debugging my plug-ins, it would be very valuable to step into the JIRA source code which I have already added to my local Maven repository. In fact, I am currently attempting to make an open source JIRA plug-in compatible with the newest version of JIRA and the inability to step into (and as expressed in #203536, navigate to) the JIRA source code at this point is really slowing me down. Not a complaint, just a reality that this is a valid use case.
Also in this case, I cannot check out the source code because I don't have access to the SVN repo for JIRA. I only have access to an archive file.
I have the same issue here. The sources of my custom Maven plugin (which is open as a source project) is correctly added as source root, but not its dependencies! This is very inconvenient! a simple workaround/solution is to execute mvnDebug.bat on cmd line, and use the Attach debugger... action to connect the IDE to the build execution. Then the debugger will use all opened projects as possible sources for classes found in the running application. So it should be enough to just open the maven plugin's source in the IDE. in other cases, debugger requires the full sourcepath upfront, which is close to impossible to get for the entire build. We would need to identify the jars in maven installation, map them to artifacts in local repository, download source jars. And then somehow know what plugins are about to be executed and do the same for these.. (In reply to comment #5) > debugger requires the full sourcepath upfront Is this really true? At least <nbjpdastart> (used in Ant-based debugging) accepts a binary <classpath>, in which case SourceForBinaryQuery will work for *-sources.jar which are already downloaded; and (given bug #200910) SourceJavadocAttacher should work for *-sources.jar available remotely. > We would need to identify the jars > in maven installation, map them to artifacts in local repository Note that the Maven SJA automatically maps any JARs by SHA-1 hash, so (if just a binary classpath is needed) just listing $MAVEN_HOME/lib/*.jar would suffice. > know what plugins are about to be executed This is of course trickier. Bug #48750 would give us this for free (in addition to not needed to list JARs in the Maven installation). adding sources for maven core libraries as found in maven installation should be fairly easy and even the UI asking people could me simple, just make it an option when setting new maven installation. sources for plugins are a bit trickier.. I can imagine adding sources for open maven-plugin projects in this case on debugger source path. however binary plugin sources residing just in local repository are rather obscure usecase and hard to crack on top of it, we would need to perform the build or some sort of lifecycle mapping evaluation before running the build itself. nasty, costly both in resources and time. one aspect I'm a bit worried, not sure if really applicable and how often: the debugger source path is flat, if project's own dependencies don't have sources to be found, the binary class in version 1.A could be found through usage by maven in version 2.B effectively providing wrong sources. the unknowns are dependencies used by debugged project and maven plugins opened. anything coming plexus, maven, guice, http commons etc. are likely candidates for this setup just FYI, debugging a project with jpda.listen=maven property set in execution dialog will correctly stop at breakpoints in your plugin, if the plugin in the current version is open in the IDE. http://hg.netbeans.org/core-main/rev/77ab2a36e3d1 debugging maven plugins available from the "Show build overview" maven build toolbar action. once the dialog shows, right click the plugin goal you want to debug and select the debugging action in the popup. The maven build will be re triggered, this time with debugging on and all maven plugin and maven core source jars on debugger sources path. Integrated into 'main-silver', will be available in build *201310010002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/77ab2a36e3d1 User: Milos Kleint <mkleint@netbeans.org> Log: #201754 make debugging maven plugin executions easy. |