Community
Participate
Working Groups
After an observant consumer noticed one of our Orbit bundles had no name, bug 346210, I looked at whole repository, and saw there were 10 others that had the wrong name, usually the symbolic name, such as 'bundlename.0' or just 'pluginname' and one case of "Eclipse.org" for the bundle name. In all these cases, the provider name was also incorrect ... that is, non existent or a symbolic name. Not sure if all these are "new in Indigo" ... but, collectively looks pretty bad, so if they can be fixed for our RC3 delivery, I think they should be. I'll attach screen shots of each, which shows exact version/branch ... but, there's the main list: com.sun.xml.bind.source javax.xml.bind.source org.apache.commons.cli org.apache.commons.io org.apache.commons.math org.apache.taglibs.standard.glassfish org.cyberneko.html org.dojotoolkit org.openid4java org.w3c.dom.events.source
Created attachment 196009 [details] com.sun.xml.bind.source
Created attachment 196010 [details] javax.xml.bind.source
Created attachment 196011 [details] org.apache.commons.cli
Created attachment 196012 [details] org.apache.commons.io
Created attachment 196013 [details] org.apache.commons.math
Created attachment 196014 [details] org.apache.taglibs.standard.glassfish
Created attachment 196015 [details] org.cyberneko.html
Created attachment 196016 [details] org.dojotoolkit
Created attachment 196017 [details] org.openid4java
Created attachment 196019 [details] org.w3c.dom.events.source
To cross reference ... we have a long standing enhancement to releng to test for these types of errors; bug 326911 But, until then, I checked just by adding a specific build repository to "available software sites", expanded "all bundles", and visually inspecting the list there. I used the latest I build repo: http://download.eclipse.org/tools/orbit/committers/drops/I20110518142129/repository/
Oh, and remember, if/when you fix the Provider Name for these .... it should be "Eclipse Orbit" ... not "Eclipse.org".
Fixed for org.apache.taglibs.standard.glassfish and the provider name too.
I wrote a small test to check/test the repository directly, to get PROP_NAME and PROP_PROVIDER, check, sort, and list them out to HTML files. It will take a bit of work to integrate this in with the build (it'll be post Indigo) but I'll attach HTML files here and try to fix up at least some of them ... and see how tired I get :) Turns out there's quite a few more than "10" ... 16 bundlenames and 26 provider names are clearly wrong (Some others are questionable, like "Eclipse Mylyn" as provider? .... but .. the ones that are like "Bundle-Name.0" are pretty ugly.
Created attachment 196262 [details] bundle names in repo in I20110519062435 build
Created attachment 196263 [details] provider names in I20110519062435
I've fixed 38 bundles! I didn't count, but about half of those looked "new" (that people would definitely be using for Indigo). Others, admittedly may not be picked up in most "Indigo Builds" ... but, since they are in our repo, they should be correct. And, I figured better to fix now, last minute, than to have churn in a maintenance stream. I'll check next build to make sure it looks ok and if so, that'll be it. It'll be good to get this test automated to catch problems as they are checked in.
Created attachment 196282 [details] For the record ... HTML listing of "final" bundle names
Created attachment 196283 [details] "final" list of provider names in bundles
Thanks David. The three names on my list... org.cyberneko.html org.dojotoolkit org.openid4java ...look correct now.
For the record, just to document it, there was one change, for this bug, that caused a "regression". See bug 346854. In that case, it actually was a good thing, in that it surfaced a important change that had never been released to a build. But ... I (we) should not have have been surprised by it. Therefore, I want back, and checked if there were any other "inadvertent" changes such as to package imports/exports. And there were none, that I could find. I checked by first comparing the map files from download page for our RC2 S-build to map file of current S-build. I diff'ed those to get the set of bundles changed, and loaded up the specific "RC2 versions" in a fresh workspace by using "load from map files". I then used "compare with ...", "a branch ..." picking the branch for that bundle (by looking in its manifest.mf file bundle version). All the changes I could see were these intended for properties, or "bundle localization". I might have missed some (e.g. it took a few passes, since "load from map files" will get only version of a bundle) such as I counted only 34 bundles changed, not the 38 I originally mentioned here ... so not sure if I missed 4 now, or miscounted by 4 the first time ... but in either case, high confidence that having unreleased changes in cvs is not common, and these changes for names didn't introduce other inadvertent changes. Part of the problem, is that the "releng tool" does not work well with Orbit map files (where we have multiple version of same bundle, plus our unique source-folders) so I was not using the releng tool, just tagging projects and copy/paste into map file. But, I'm glad we are clean for Indigo ... looks much better ... much more professional.
