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