When developing a project with a release dependency on some module, it is common to find some bug or missing API in the latest available release that you wish to work on immediately while testing the effect in the main project. Currently this is rather cumbersome. The IDE should provide a wizard (perhaps launched as a context menu item on the dependency node?) to set up your development environment for this, perhaps taking advantage of maven-scm-plugin to perform some operations. Possible setups include:

1. You develop the dependency and are authorized to make releases of it, but you wish to first use the downstream project to verify your changes. Assuming you already have a source checkout of the dependency in a snapshot version, it should suffice to open it, and switch the dependency version in the upstream project to use the snapshot. After releasing the upstream artifact, there is already some GUI available to update the dependency version downstream (POM editor hint), but this may need to be made more prominent.

2. A third party develops the dependency but you want to file a patch and test that in your own code, later shelving your changes unless and until the patch is accepted and a new release made. The dependency needs to be checked out as a source project (if it has not been already), and the POM updated to include some version qualifier such as a bug ID, e.g. <version>3.0.3.MNG1234</version>. (This can be nontrivial in case <version> in inherited from <parent>, or ${project.version} is used in the POM to refer to siblings.) Then the downstream dependency version needs to be switched to this. A subsequent step is to create a diff patch from the upstream project (minus the version changes!) for submission, create a patch for shelving (or branch?) on the downstream project (again minus dependency version change), and finally revert both sets of working copy modifications.

3. You want to fork the upstream project. A fresh copy should be made, starting from the release tag. Upstream and downstream version qualifier changes made as in #2, but never shelved & reverted.

3a. scm:export can be used if the forked sources should be added without history to the local SCM tree.

3b. If upstream uses a DVCS you may prefer to make a real fork, permitting subsequent merges of upstream releases. TBD whether an IDE GUI can be useful here; typically you would want to host the fork somewhere official.