Re: [cross-project-issues-dev] New "repository reports": Eclipse-SourceR

[Hugues Malphettes <hmalphettes@xxxxxxxxxxx>]

On Fri, Jun 3, 2011 at 11:31 AM, David Carver <d_a_carver@xxxxxxxxx> wrote:
> 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.
>
+1 : not a Should Do
For an illustration of what Dave listed above,
Eclipse-SourceReferences with the jetty projects would not be useful:
The jetty code follows a different set of best practices.
Namely: "thou sources shall be independent of the IDE":
1- no .project, no .classpath, no build.properties checked in the
source control
2- no META-INF/MANIFEST.MF checked in source control either.
Unless I mistaken: this would prevent the import from working.

This is the set of best practices that most of the apache and codehaus
projects follow.
In this case, producing Eclipse-SourceReferences is more complexity on
the build and the output is going against their best practices.

I do understand how it makes complete sense for the majority of the
projects at eclipse.

Hugues.

> Dave
>
> 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:
>
> 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
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>