(Difference between revisions)
(Static analysis result display)
(Hyperlinks for test failures, warnings, ...)
Line 36: Line 36:
XXX describe current state
XXX describe current state
==Hyperlinks for test failures, warnings, ...==
==Failed test display==
XXX describe current state
XXX describe current state

Revision as of 16:57, 14 June 2012



General setup and view

See Hudson Builders in the Services tab.

Connect to one or more Hudson servers by giving the URL and a display label. (Jenkins will also work though it is not tested or formally supported.)

Set a refresh interval in minutes. If zero, after a restart the server will initially be left unconnected - you can manually "synchronize" when you want to. You can always manually synchronized rather than waiting. If synchronizing hangs (server not responding, ...) the task can be canceled and resynchronization should be suppressed for the rest of the IDE session.

All jobs in the default view are shown; you can select an alternate view if you like. Each job shows its current workspace, and a list of builds (shown with their status color - stable, unstable, failed, aborted - plus a badge if currently running). Completed builds show a list of artifacts; builds of native Maven jobs show a list of modules, each of which may have its own artifacts.

Most nodes permit you to open the corresponding URL in an external web browser for more information and control. Job nodes let you open the config.xml (Hudson's persisted job configuration file) in the IDE's editor as a convenience, though currently this is read-only.

Jobs may be started manually from the context menu.


You may use the Log In... action to supply credentials to a controlled server. For publicly browsable servers it is unnecessary - if and when you take some action which requires a login, such as creating or starting a job, you will be prompted automatically. Less commonly a server may be configured to simply hide some jobs when not logged in, in which case you need to do so explicitly. Credentials are remembered using the secure keyring, though currently you are not logged in automatically after restarting the IDE.

Supported authentication types (as of 7.2):

  • username/password in Hudson's own database (the default mode)
  • servlet container authentication
  • API token (currently Jenkins only)


XXX describe current state

Changelogs and diffs

XXX describe current state

Workspace/artifact browsing

XXX describe current state

Failed test display

XXX describe current state

Stack trace hyperlinking for e.g. unit test failures in a completed build.

Version skew is a potential problem.

Build log browsing

XXX describe current state

Display of build log in IDE's Output Window, with hyperlinks to remote workspace (or local workspace equivalents) for any files mentioned by name.

Version skew is a potential problem.

Quick search

XXX describe current state

Automatic setup of CI

Can take an IDE project, or project tree, and set up a new CI job for it. (Team > Create Build Job...)

For an IDE-managed Ant project (e.g. j2seproject), this means a "freeform" job (i.e. job's config.xml lists every build step and file location explicitly) invoking build.xml with targets like jar/test/javadoc, collecting dist/*.jar, test result artifacts, and/or Javadoc.

For a freeform or automatic Ant project, this is likely impossible - the user would have to set everything up themselves anyway.

For a Maven project (possibly consisting of multiple modules), this is handled by using Hudson's native Maven 2+ support. (Note: Hudson after the Jenkins split supposedly deprecates this job type, but it still seems to work fine, and is much more convenient for the IDE's purposes.)

PHP projects are also supported, using a semistandard PHP setup system for Hudson.

SCM handling

The job can only be set up if the IDE can determine the location of the version control repository used by the job, based on metadata in your current project's checkout. The contents of the local project tree are ignored thereafter - to trigger new builds, you need to commit (and, if applicable, push) changes. The job config will include a simple default SCM configuration, polling for changes at some interval.

Currently Subversion (pre-1.7), Git, and Mercurial are supported for this purpose. For the DVCS, it is supported to start from a project repository with no remote server location, if you are running the Hudson server on localhost (i.e. solo development or just giving a demo); then the job config will use a file-protocol URL, and just committing locally will trigger builds.

Project/job associations

When a Maven project is set up, the IDE will also populate the standard ciManagement field in pom.xml, so that if the project is opened again by a NetBeans user this Hudson server will automatically be registered (with this job being "watched"). The IDE will also recognize ciManagement (of type hudson or jenkins) defined manually in any POM, which well-maintained projects may already have.

For other project types (Ant/PHP), the server link is added to project metadata too.

Servers registered as a result of a project being opened are marked as "transient" (a label is shown in the UI) and are unregistered when the project is closed. You may choose to persist the server configuration so it will be shown even after closing the project.

You can also manually associate a job with a specific project, useful if you set up the job manually in the web UI.

Static analysis result display

XXX describe current state

TBD. Open questions:

  • Should we use the task list for this?
  • How to deal with version skew?
  • How can the user keep the task list manageable if there are 7000 FindBugs warnings?
  • How should analysis warnings be rejected? Annotations?

Plugin development

XXX describe current state


Originally a third-party plugin by Michal Mocnak (mmocnak).

Feature set as of original integration into NB official distro: NewAndNoteworthyMilestone3NB67#HudsonIntegration

Original HudsonInNetBeansUI spec.

ContinuousIntegrationHOWTO is obsolete (relies on Kenai).


In hudson* modules.

Use the connecteddeveloper component in Bugzilla. Create issue; Open issues

How to develop

Source setup

Build the IDE with at least


Now create a project group containing at least these NB modules:


and optionally also:


Commit to core-main; NB-Core-Build will run tests for those modules which have any. Set up hudson*/* notifications in .hgmail.

Running in devel mode

Now run Debug Project on Hudson. This debug target is set up to enable verbose console logging in Hudson-related modules. (It is also suitable for setting as "main project" since its debug target rebuilds all the submodules too.)

Originally "Try Hudson on Localhost" was the easiest way to get started, though this is currently disabled (#214210), so just download the latest WAR and java -jar it (will open at http://localhost:8080/ by default).

Install the Mercurial plugin from the update center if you want to test this integration (though the version available on the Hudson UC is quite old; the Jenkins UC has the latest). Subversion and Git plugins should be installed by default.

For testing projects using Ant or Maven, you will need to configure at least one installation of the relevant tool: go to Manage Hudson, and ask to automatically install the latest version from Apache (beware that this list is sometimes out of date or even broken).


Various pieces of code have unit tests, which should all be stable. There are no functional tests currently that would confirm that interaction with a particular version of Hudson using the remote API actually works, though this would be possible.

Working with non-IDE sources

Useful to have checkouts of:

git:// (3.x)
git:// (2.x)
git:// (etc.)
git:// (subdir hudson.indexerinstaller; experimental)

To build and run Hudson from sources, just open the top aggregator project and Build Project (probably want to suppress tests for non-test-related executions in Maven settings). Then open the hudson-war module and Run Project, which should automatically call hudson-dev:run. Theoretically you can make incremental changes to Java and Jetty will automatically restart, though this seems to break things. Can edit Jelly XML (HTML templates) and the results should be live upon save.

To build and run plugins from sources, just open them and Run Project. This will run the plugin using Jetty against its configured baseline Hudson (or Jenkins) version. Or, just Build Project to create a *.hpi, and then install this manually into a running Hudson instance (see Manage Plugins / Advanced).

Remote API

XXX how it works in Hudson/Stapler, how /xml/api is used by NB (XPath & tree=)

Internal APIs



Other Hudson IDE plugins:

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo