Re: [orbit-dev] EBR / Recipes Update

[Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>]

Hi David,

> Am 19.02.2016 um 20:27 schrieb David M Williams <david_williams@xxxxxxxxxx>:

> Does it literally have to be "one at a time"? I am think about when several packages that "go together" (such as Lucene). 

The one-at-a-time model is what I was able to implement at the bundle/recipe level. I haven't investigate it at the level above yet. I believe that it would be technical feasible. But in the end, I believe it doesn't matter. I already have an idea for a script that would detect changed recipes between two Git commits (SHAs as delivered by Hudson Git plug-in). This could then be used to build just the changed recipes and aggregate them into a build delta repo, which could then go into a composite Orbit repo.


> I assume that when a bundle has some prereqs, those are still resolved from our current repositories? And that would be how we would 
> know a bundle was "completely" in Orbit. 

Not sure what you mean by "completely". The bundle repository contains just the bundle and its source as produced by a recipe. p2 does not include direct and transitive dependencies. Those are expected to be somewhere else.

> None of this excludes the concept of having I-builds, S-builds and eventually R-builds, right? I would assume the "tiny repos" would be mirrored into the larger repos? 
> That is, we can still "increment" towards the final R-build repository, instead of everything going in the R-build, even if it was wrong the first build or two? 
> [I ask since R-builds are forever ... where as we I-builds and S-builds are temporary.] 

Yes, several strategies are possible. The tiny repos could be mirrored into larger ones. We can still perform full builds - building everything from scratch - if we want (eg., for S builds).

> I assume "moving to the new system" does not depend on this being done first, right? Though, it would be nice. 
> Any outlook on when this work would be done? (Does it eventually belong in Tycho?) 

It would be required because I discovered some limitations in Tycho with aggregating features into a p2 repository. 
https://dev.eclipse.org/mhonarc/lists/tycho-user/msg07036.html

I'm finalizing the implementation of the next few days. I'm already working on a script to automate build and mirroring. All is implemented in EBR. Thus, we don't need to wait for anything from Tycho. 


> I think the thing that is blocking us now is having a place at Eclipse.org for the original artifacts to live. 
> Any progress or word on setting up an "original artifact database"? (Instead of pulling things live from maven. central). 

No. That kind of stalled. I think we should setup a call to get moving again. I think the main point is - who ones the process of publishing the original artifacts. In the case of Orbit it's the Orbit committers. They unpack the original artifacts and commit it to Orbit CVS. That's why I was thinking that Orbit committers should still do it. It's just that the technology changes, i.e. instead of committing it to CVS we would upload it to Nexus.

Thoughts?

-Gunnar

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/