Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 335229

Summary: bundles with compile errors are pushed to the repo
Product: [Eclipse Project] Platform Reporter: Kim Moir <kim.moir>
Component: RelengAssignee: Platform-Releng-Inbox <platform-releng-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: daniel_megert, dj.houghton, gunnar, markus.kell.r, pwebster, remy.suen
Version: 3.7   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard: stalebug

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.