Bugzilla – Full Text Bug Listing
| Summary: | Investigate on how to split the repo and the build | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Pascal Rapicault <pascal> |
| Component: | Releng | Assignee: | Platform-Releng-Inbox <platform-releng-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | dj.houghton, gunnar, irbull, kim.moir, krzysztof.daniel, pwebster, remy.suen |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | stalebug | ||
|
Description
Pascal Rapicault
It seems to me that each repo would need at least 2 passes to build, possibly even 3. In my case: pass 1: build most of Platform UI pass 2: build the tests and some examples pass 3: build the rest of the tests/examples that depend on the whole SDK PW I view this a little differently. Each component (JDT, PDE, Equinox, p2, etc...) would have a self contained build (with a set of pluginPaths / contextRepos for the dependencies). They would build and run their own unit tests and publish their bits for others to consume (if the build is successful). The "platform build" would then just be a (set of) director calls to assemble the final pieces, plus the integration tests. The challenge comes when a change spans multiple components (new SWT widget needed for the p2 UI for example). Also, I'm not sure who runs things like API tools. (In reply to comment #2) > > The challenge comes when a change spans multiple components (new SWT widget > needed for the p2 UI for example). Also, I'm not sure who runs things like API > tools. This case happens during development for us, especially when a component (like Resources) evolves new API to be consumed by IDE, because they have to change together. I do like the idea of building and publishing the component for other components to consume, but it seems to me there has to be the flexibility to control the build inputs at all downstream points. For example, you have to build an M5a and take the second last p2 published build while re-building all downstream components. Anything is do-able, but at least in the past this has been a complicated, manual process that would have to be solved. Ref: the 4.1 SDK had to float with the current 3.7 I builds and Indigo EMF, except around milestones where we had to peg specific 3.7 I builds and select the "next" EMF contribution, or when we needed to go back one I build to avoid a problem. PW (In reply to comment #3) > I do like the idea of building and publishing the component for other > components to consume, but it seems to me there has to be the flexibility to > control the build inputs at all downstream points. For example, you have to > build an M5a and take the second last p2 published build while re-building all > downstream components. That does sound a bit like a crafted composite repo pointing to specific component builds (or a target definition). 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. |