Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 335229 - bundles with compile errors are pushed to the repo
Summary: bundles with compile errors are pushed to the repo
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Releng (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-Releng-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-24 13:32 EST by Kim Moir CLA
Modified: 2019-11-14 03:25 EST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kim Moir CLA 2011-01-24 13:32:04 EST
This shouldn't happen. I haven't changed any settings around this lately, not sure what happened.
Comment 1 Kim Moir CLA 2011-01-24 14:41:40 EST
Looks like p2.publishonerror=true is set for the master feature which means that bundles with compile errors will be published to the repo. 

I looked at the history and it seems this has been set since we switched to using the publisher.  I seen to recall some discussion around this in an arch call.  Something like we wanted the build to proceed if there were compile errors in one component. A compile error in one component doesn't necessarily break the build, today it did.

Anyways, I'll raise this as a discussion item at this week's arch call.
Comment 2 Markus Keller CLA 2011-01-27 05:50:37 EST
I see that this is a problem for I-builds, but is it also a problem for N-builds? I-builds should not be published with compile errors, but it would be nice if N-builds could proceed.

This assumes that N-builds are compiled completely from scratch (without using data from previous builds). If N-builds also don't recompile all bundles, then we would also run into trouble there, unless you can prune the broken repository for the next build.
Comment 3 Kim Moir CLA 2011-01-27 13:52:25 EST
From John

Investigate the possibility of only publishing the parts of the build that have no compile errors. For example if there is a compile error in the AIX fragment only, then only the AIX zips would be missing from the downloads page. But, if there was a compile error that affected all zips (such as core.resources), then effectively the whole build would abort (no zips would get created). If it's not too difficult, this sounds like a good compromise.
Comment 4 Markus Keller CLA 2011-01-28 06:50:41 EST
(In reply to comment #3)
I agree, but I just wanted to add that apart from the platform axis, there's also the features axis: E.g. a compile error in a test bundle should still let the SDK builds proceed, and a compile error in PDE would ideally not block RCP and SWT builds.
Comment 5 Gunnar Wagenknecht CLA 2011-01-28 07:15:55 EST
I know this is out-of-scope of this particular request and involves a huge amount of work. But I think it would be good to refactor the single Eclipse build into smaller, separate builds. This would not only solve the issue mentioned in comment #4 it would also offer a much better scalability. For example, Equinox would be build first. Then the platform, then JDT, then PDE, etc. Some builds could run in parallel on different build machines.
Comment 6 Lars Vogel CLA 2019-11-14 03:25:58 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

If the bug is still relevant, please remove the "stalebug" whiteboard tag.