Bug 198781 - Wizard to prepare a patched version of a dependency
Wizard to prepare a patched version of a dependency
Status: RESOLVED WONTFIX
Product: projects
Classification: Unclassified
Component: Maven
7.0
All All
: P3 (vote)
: TBD
Assigned To: Tomas Stupka
issues@projects
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-20 22:59 UTC by Jesse Glick
Modified: 2016-07-07 08:38 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2011-05-20 22:59:27 UTC
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.
Comment 1 Jesse Glick 2012-04-03 20:07:52 UTC
4. (Variant of 2 in case the upstream code is not available in source project form, just artifacts.) Unpack the *-sources.jar somewhere, 'hg init && hg ci -Am.' (to make a baseline), edit, javac changed/File.java, install a local JAR based on the official binary artifact but updated with your patches, 'hg di' to produce patch for review, otherwise as #2 for your own project.
Comment 2 Martin Balin 2016-07-07 08:38:27 UTC
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss


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