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

Personally, I wouldn't make it a Should Do.  There are other ways to get the sources.  If a project is using maven, and deploying it's sources as part of the build.  M2Eclipse provides a very easy way to get the source for a project.

I'd rather try to get away from anything that is tied to a particular version control, or a particular set of build technologies, and let projects choose the best way they want to provide source to their user community.   Too much at eclipse has been tied in the past to CVS, and now that CVS is going away (yes it is going away), how useful will that Eclipse-Source directive be when CVS is no longer available or moves to a different location than what the original plugin specified.


On 06/02/2011 04:35 PM, David M Williams wrote:
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:

And well described in

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
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

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



Daniel Pastore

Sequoyah Team
cross-project-issues-dev mailing list

_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx

Back to the top