Bug 440480 - Investigate and make consistent recommendation for "source" in test bundles
Summary: Investigate and make consistent recommendation for "source" in test bundles
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Releng (show other bugs)
Version: 4.4   Edit
Hardware: PC Linux
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-Releng-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-26 10:26 EDT by David Williams CLA
Modified: 2014-07-28 09:51 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Williams CLA 2014-07-26 10:26:52 EDT
+++ This bug was initially created as a clone of Bug #438659 +++

I'm opening this bug as a clone of 438659 but this is not directly related to it ... that's just when "discrepancies" were found. 

The policy, as stated by Dani, in bug 438659, is that test bundles do not need corresponding source bundles, and should not have the source of the tests included in the test-time code bundle (though, many of the test bundles do include some form of 'source', which is used as part of the test (such as "formatting java files"). 

BUT, the reason for this bug is many test bundles do include a "src.includes" statement in build.properties, and many do not. 

PLUS, there are a few cases for test bundles where "SNAPSHOT-source jars are produced by the build ... but simply not used or included anywhere. Hence, if nothing else, is a tiny bit of "extra processing" that is probably not measurable ... but ... might be someday as build improves and get's "broken up? The thing that takes investigation is why this seems to happen for some bundles, but not others. I bet it will be obvious, once I know what it is :) ... but could not find explanation for it after several hours of looking and experimenting.
Comment 1 Dani Megert CLA 2014-07-28 03:24:47 EDT
(In reply to David Williams from comment #0)
> (though, many of the test
> bundles do include some form of 'source', which is used as part of the test
> (such as "formatting java files"). 

This is not considered usual source but rather (test) resources necessary to run the bundle, similar to images or plugin.xml files that are also part of the binary bundle.
Comment 2 David Williams CLA 2014-07-28 07:42:28 EDT
(In reply to Dani Megert from comment #1)
> (In reply to David Williams from comment #0)
> > (though, many of the test
> > bundles do include some form of 'source', which is used as part of the test
> > (such as "formatting java files"). 
> 
> This is not considered usual source but rather (test) resources necessary to
> run the bundle, similar to images or plugin.xml files that are also part of
> the binary bundle.

Right, of course. I mentioned it since it makes it hard to "check" by simple "greps", and similar, if anyone is "accidentally" including source -- the src.includes kind. 

I assume the reason not to include the source is simply to save download size?

And if someone was going to "debug" a test ... they'd be expected to load from the repository. 

I opened this bug, though, since I'm not sure the policy is documented? And if it is or isn't, seems as a project we are slightly inconsistent (that many do include "src.includes" statements, ususally for "about.html" ... and worst of all, it seems like our current build produces it in some cases and not others. 

Nothing urgent, but thought it worth an enhancement request to track the issue.
Comment 3 Dani Megert CLA 2014-07-28 09:51:25 EDT
(In reply to David Williams from comment #2)
> I assume the reason not to include the source is simply to save download
> size?

No, the reason is that one should never mix runtime and source code. If we provide source at all, it should be in a separate bundle - just good practice. And another reason is the next one.

 
> And if someone was going to "debug" a test ... they'd be expected to load
> from the repository. 

Yes.

 
> I opened this bug, though, since I'm not sure the policy is documented?

I don't think it is. It's just monkey see monkey do.