Bug 782217

Summary:	Content upload and discovery of RPM, war, etc. should populate content version, store metadata, etc.
Product:	[Other] RHQ Project	Reporter:	Elias Ross <genman>
Component:	Content	Assignee:	Nobody <nobody>
Status:	NEW ---	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	4.3	CC:	hrupp
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Elias Ross 2012-01-16 21:06:15 UTC

It doesn't make sense to require users to input information on uploaded (or discovered) packages that already contain metadata themselves.

There are tools in Java to extract this for RPMs: http://redline-rpm.org/

For Java packages, Maven-built projects contain a pom.xml. If not, very often jars also have manifest information regarding version and other details. So it doesn't make sense to require users to enter this.

The UI should then ask for metadata at the end; to correct data if need be or add it if entirely missing.

The following fields are entirely missing from the upload UI:
1. short_description
2. long_description
3. display_version
4. license_name
5. license_version
6. metadata -- Used for Yum repository but not always found. See Bug 781651

For discovery RPM:
1. short_description
2. display_version
3. licensing

For .war discovery:
1. display_name (could be project name from pom)
2. short_description (could be the artifact name or groupId:artifactId:packaging:classifier:version )
3. long_description (pom description)
4. display_version (version minus classifier ?)
5. license_name, _version (if available, take the first one (?))
6. metadata (pom.xml contents perhaps?)

Comment 1 Charles Crouch 2012-01-23 16:13:48 UTC

Stefan, can you review this wrt to the content changes you have made. to be clear RPMs are outside of the scope of your change.

Comment 2 Stefan Negrea 2012-01-25 00:26:06 UTC

RHQ retrieves and uses only a small subset of all the available metadata for Java archives or RPM files. The current content system is used only for simple deployments and retrievals. Such metadata would be nice but would not enhance the core functionality of the system. 

With regards to versions, there is a discovery process that attempts to retrieve versions for JAR, WAR, and exploded Java application deployments based on the manifest. The two fields used from the manifest (if not null) are implementation version and specification version. If this information is discovered, it is stored in the display_version field. In a sense, this is the kind of process you described but it is NOT used for any other portion of the metadata available.

Taking a step back, I totally agree that users should only be required to upload a file, have code to discover as much information as possible, store this information for later retrieval, and allow users to update it as necessary. This being said, the current content system does not have this capability. The content system would probably require a complete overhaul not only from a discovery perspective but also from a query and analysis perspective.

Comment 3 Charles Crouch 2012-03-06 21:21:11 UTC

"The content system would probably require a complete overhaul not
only from a discovery perspective but also from a query and analysis
perspective."
That is not on the roadmap in the short term.