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?)
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.
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.
"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.