Link type: Superset, Source: JBPAPP6-661, Destination: JBPAPP6-732 project_key: JBPAPP6 There are many invalid versions of artifacts in mead repo for DR10. This must be solved before ER1 when all jars should be productized and their version should reflect expected format [1]. http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Repository/job/eap-60-repository-maven-check-valid-versions/3/testReport/ http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Repository/job/eap-60-repository-maven-check-valid-versions/3/ invalid-versions.txt + valid-versions.txt My test is follows strictly OSGi versioning defined in OSGi specification and in https://docspace.corp.redhat.com/docs/DOC-39079 :: for example version 1.0.1-redhat-1 is not valid because there is a dash "-" in the micro field. [1]Expected format: <baseversion>redhat-<buildnumber> + must be OSGI compatible, see https://docspace.corp.redhat.com/docs/DOC-39079
I can see from DOC-39079 that {noformat}<baseversion>-redhat-<buildnumber>{noformat} is correct instead of {noformat}<baseversion>redhat-<buildnumber>{noformat} as you mentioned in description.
The question is OSGi compatibility ... "According to the OSGi standard, the version 1.0.1-redhat-1 is not valid because there is a dash "\-" in the micro field which only accepts numeric values. This should instead be 1.0.0.redhat-1 which is valid. Therefore, JBoss artifact version strings should be padded with zeros to meet the OSGi specification. And a dot "." or a "\-" should be used to start the redhat qualifier depending on whether there is an existing version qualifier." So version 1.0.0.redhat-1 is OSGi compatible but don't reflect <baseversion>\-redhat\-<buildnumber> :( Should it be renamed to 1.0.0.-redhat-1 or 1.0.0.Final-redhat-1 or what? We need agreement how to deal with versions 1.0, 1.0.0 without Final or GA at the end. Will we add some unified suffix to them? Something like 1.0.0.abcd-redhat-1?
We are not strictly following OSGi version standards currently out of convenience. According to the project wolf standards, the versions should look like this: Upstream 1.0.0.Final -> 1.0.0.Final-redhat-1 (we are doing this) 1.0.1 -> 1.0.1.redhat-1 (we are not currently doing this) I will follow up with product management to see the impact of meeting this requirement.
How would be upstream versions like 2.4 or 3.15.0-GA transformed into redhat format? We won't follow major.minor.micro versions? I can see versions like 0.3-redhat-1 or 1-redhat-1.
Here are the OSGi conversions: 2.4 -> 2.4.0.redhat-1 3.15.0-GA -> 3.15.0.GA-redhat-1 Examples like these demonstrate why for simplicity we decided to just append -redhat-1 instead of doing the conversion for each version.
An important note: a change in this convention this late in the process will move everything into RED. And delay the EAP 6 release for good. There are hundreds of builds with the -redhat-1 already, almost the whole contents of the shipped repo AFAIK. This will require some changes in vman (perhaps to create OSGi-zed versions from whatever versions projects use) and run it again in the whole lot of hundreds of things we have. Also note that Oracle has some versions like 1.2_b1 and such that are not obvious to convert and that is a general problem with all non-JBoss libraries. I suspect this may not be feasible. Perhaps we can have a different (OSGi-zed) version in bundles when they are created (very few upstream projects create them ATM).
Resolving this as won't fix because I believe this is not a hard requirement, and it is unlikely we will have time to fix these versions.
This requirement is not mentioned in EAP nor PRD. It's mentioned in JBoss Maven Artifact Identifier Standard [1] document. Do you think jar naming will go near this OSGi like standard or it will be the same for all EAP6 releases? [1] https://docspace.corp.redhat.com/docs/DOC-39079
OSGi is back in game. What about OSGi like naming? I think we should push prod team to take it more seriously. Currently number of failures decreased from 460 to 261 comparinf DR12 and ER1 http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Repository/job/eap-60-repository-maven-check-valid-versions/9/
Thomas, what's the impact of this issue for OSGi users. If jars with invalid OSGi versions are run in the OSGi container, will that cause problems?
Paul, from the OSGi perspective the artefact name is irrelevant - you can name it as you like. With {code} BundleContext.installBundle(String location, InputStream input) {code} for example, you can give the installed bundle an arbitrary location (name). What is important however are version strings that appear in certain manifest headers (e.g. Bundle-Version, ExportPackage, etc) By convention, many bundles carry the value of the Bundle-Version header in the artefact name and use it as the maven version. Stating the obvious, you do however want to make sure that changes to an artefact are not only reflected in its artefact name but also in its associated OSGi metadata. So if you patch stuff and repackage you must also increment the versions (according to semantic versioning rules) in the manifest. If you just repackage the upstream artefact this does not apply. The OSGi version rules do only apply to version values in the manifest.
Looking at the latest test results, there are appear to be some incorrect failures. Due to only accepting single digit version components, I believe the OSGi spec allows two digits for a single version component. Here are some examples of valid OSGi versions marked as failures: {noformat} 4.16.2.Final-redhat-1 1.0.13.Final-redhat-1 {noformat}
Patch to allow multiple digits in OSGi version components.
Attachment: Added: 0001-Allow-multiple-digit-version-components-when-testing.patch
Another patch to make it easier to see which jars have the invalid versions.
Attachment: Added: 0001-Print-the-jarname-for-invalid-OSGi-verisons-to-make-.patch
Attachment: Removed: 0001-Print-the-jarname-for-invalid-OSGi-verisons-to-make-.patch
Attachment: Added: 0001-Print-filenames-for-invalid-OSGi-versions-to-make-it.patch
Both patches applied, thanks! Run #12 is with patches http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Repository/job/eap-60-repository-maven-check-valid-versions/12/
Link: Added: This issue relates to JBPAPP-8510
18 failures from 487 for EAP 6.0.0 ER 4.1 166 failures for more strict test (OSGi naming) http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Repository/job/eap-60-repository-maven-check-valid-versions/13/artifact/test-output.txt
Link: Added: This issue incorporates JBPAPP-8664
Labels: Added: eap6_need_triage
All the jars in the repo should now follow the standard format <upstream-version>-redhat-1. The only known exception is the jboss-common-beans jar which has a duplicate version with the -todo. The -todo jar has been removed from the latest repo build and will not be present in CR.
We can try to enforce stricter OSGi versioning for 6.0.1.
Verified on EAP 6.0.0 ER7 http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Repository/job/eap-60-repository-maven-check-valid-versions/
Docs QE Status: Removed: NEW