Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] New "repository reports": Eclipse-SourceReferences

I am so glad that someone asked! From the low use of that directive, it appears lots of people still need to learn about it.

short answer: It is not a "must do" or anything  ... but, I think next year it might be a "should do", to help remind people of such a great coding practice. It is so handy and so helpful to the community.

long answer:

This was first mentioned on this list late in the Helios cycle:

http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg04001.html

And well described in

http://wiki.eclipse.org/PDE/UI/SourceReferences

I have found this to be a great innovation in Eclipse!

I recently was looking at a bug related to this function (bug 347394) and wanted to see how wide spread the problem might be ... I discovered the bug was not wide spread, partially, unfortunately, because this directive was under utilized. And .... since I'd already written the scanning code to peek in the jar files, I decided to include it in this collection of repository reports for your reading pleasure.

It is pretty easy to implement the basics: if you are using PDE build (at some level) and CVS map files, you just need to include
generateSourceReferences=true
in your build properties, and you'll get it automatically. (I am not sure what the status with git and svn support is ... maybe others do and can inform us all if those "fetch factories" have that support?)

Even though easy to do,  I would not suggest anyone do it now, for Indigo because  

a) we really need to be focused on blocking/critical problems directly related to shipping, etc. at this late date, and

b. this is one of those "changes in your build" that can cause your built jars to be different from previous builds, without changing their qualifier. So, you need to make sure to retag your projects to make sure the qualifier changes. In Orbit, for another approach, we set things up so that only when someone touches a bundle (tags the module) the version with Eclipse-SourceReferences gets included in the build. Not so easy, but see bug 338447 for more detail.

Thanks for asking! We'll get those numbers up next year!







From:        Daniel Pastore <kpqb38@xxxxxxxxxxxx>
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        06/02/2011 03:38 PM
Subject:        Re: [cross-project-issues-dev] New "repository reports"
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx




Hi all,

Once again here we come with a newbie question: we did not understand what would be:
 
Use of Eclipse-SourceReferences
List those bundles which are, and which are not, using the highly recommended Eclipse-SourceReferences directive.

Any clarifications are highly appreciated.

On Thu, Jun 2, 2011 at 14:45, David M Williams <david_williams@xxxxxxxxxx> wrote:
Just in time for Indigo ... or way early for Juno, depending on your perspective  ... I've been working on consolidating some of the "releng tests" that some projects use, and that are occasionally used in isolation for the Simultaneous Release. For the results on the latest staging repo, see

http://build.eclipse.org/indigo/simrel/

I know most of these report will be too late to do much good for Indigo (I would not suggest mass updates, just to correct plugin names, for example) but some of them are important for Indigo.  I'd suggest everyone take a look at the first four:


Bundles missing required files
This report lists bundles and features that are missing important, required files. It looks directly at jars in the common repository. (Currently, does not check those "trusted repositories" we point to via composite indirection). Missing legal files are usually considered a "stop ship" issue, since Eclipse is well known for its IP quality.

Unsigned bundles
This report lists bundles and features that are that are not signed. Pretty serious issue, though there are a few exceptions. (well, only one code exception is known ... see below).

Bundles not using 4 part versions
To have p2 update correctly and OSGi to resolve bundles as expected, it is essential that bundles and features use the required 4 part versioning rules. Every build.

Consistent, current licenses (SUA) in features
Check to make sure features use the current, correct license. The report also lists features in repository with no license (SUA) in the content metadata. This report uses the repository's content metadata, instead of the jar files themselves, in contrast to the "missing files" report, above. Both are important to be correct, as different parts of Eclipse code use one or the other to present information to the user depending on the task.



Some bugs have been opened a few weeks ago on some of these issues in Indigo, and these reports are just an initial attempt to get this testing centralized, and ran more frequently and automatically.


I've opened a bug already to discuss errors in these initial reports:


Bug 347882 - Improve Software Repository Reports  

You can suggest improvement there too ... but, be forewarned ... what we really need are volunteers to do the work, not to make suggestions :)





_______________________________________________
cross-project-issues-dev mailing list

cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




--
Thanks,

Daniel Pastore

Sequoyah Team
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top