(4:20:01 PM) ccrouch: does that mean you cant deploy apps to EWS?
(4:20:21 PM) jshaughn: uhm, yes, not through the gui

This is a side effect of https://bugzilla.redhat.com/show_bug.cgi?id=601328. Basically, we should not be prompting for package type or architecture in the first place on the create-new child resource page, since these are both known in advance - "WAR File" and "noarch" respectively (well, I guess we would not necessarily know the architecture in advance for an RPM package resourcetype, so we might need to keep the architecture input to keep it generic). 

As for a workaround , I suppose we could add a bogus package type to the VHost resource type in tomcat plugin's descriptor, but this would be pretty ugly. The better way to go would be to fix 601328 and get rid of the Package Type input altogether.

This is fixed by commit 63ed10cb156bc2a369b068677db8d313906825bb and has been
pushed to master. The page no longer asks for Package Type, since the Package Type is already known (e.g. EAR File or WAR File), and it only prompts for Architecture if the package type supports architecture (so for EARs and WARs, it does not prompt for Architecture). It always asks for Version, which is a required field.    

The same commit also fixes the Content>New>Upload New page, which is used for updating the backing file for an existing EAR or WAR Resource. In the case where the Resource is package-backed, that page prompts for only the Version field and the Architecture field (if appropriate). In the case where the Resource is not package-backed, it also prompts for Package Name and Package Type.

commit 8f86f29ad2a90dab4854f06d39cf794acabdac10 (pushed to master) fixes a couple minor issues with the previous commit that Jay noticed. This is now ready for QA.

QA Verified -- able to upload a war to tomcat;  also able to use the Content > New > Upload functionality as well.

Mass-closure of verified bugs against JON.