Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Create a WAR Resource (e.g. helloworld.war) 2. Go to the WAR Resource's Content>New subtab. 3. Click the Upload New Package button. 4. Click the Upload File button and upload a new version of the WAR (e.g. helloworld_v2.war) 5. Try to click the Continue button. Actual results: You'll get an error that says "A repository deployment option must be specified." (see attached screenshot) Expected results: The original WAR package associated with the WAR Resource is not associated with a repo or a content source. I verified this by peeking at the DB using dbvis. So the package for the updated v2 WAR really should not require a repo be specified either. I propose we add a 4th radio button labeled "None" to the select repository options, and have this radio button selected by default. We could also potentially not require selecting a repository at all in the case where the Resource is a package-backed Resource such as an EAR or WAR (this would assume that a package-backed Resource would never have other poackages associated with it, besides its backing package).
Created attachment 411669 [details] screenshot showing the issue
Made suggested changes to add None option for repo selection and select by default. Available in successful master build >= 307, and commit hash: ce0d8ab908a52df1bc7826de06d848c8300a343f
Verified on jon build#154 (Revision: 10620) Observed that now there is a 'None' option for repository selection and the 'None' option is selected by default. However, when clicked on 'Continue' button after uploading a .war file and selecting null option, it displays below message on the screen: Failed to associate package [rhq-postinstaller.war] with repository ID [null]. Cause: java.lang.NumberFormatException:null. Please find attached the screenshot for more details.
Created attachment 415091 [details] Screenshot for the message
Yep. This was caused by a curious reversion of the applied fix after checkin. I'm calling it a gitastrophy. I re-applied the fix and the error message from the screenshot should be fixed now in successful build of master >= 355, and git hash: bd8ee1ee291e656dfec223110ed51d0cb24d2219.
Verified on Jon build170 (Revision: 10621) Observed that there is a 'None' option for repository selection and the 'None' option is selected by default. No exception is observed after clicking on 'Continue' button after uploading a .war file. New package is deployed successfully.
Mass-closure of verified bugs against JON.