Mark, Is there any reason why these two projects need to be independent Eclipse projects? Could a single Eclipse project encompass both efforts, with each component (openj9 and omr) just be separate efforts with separate repositories? From your description, it sounds like these two "projects" are pretty tight. Just wondering why they need to be separate.
Even if these components exist within a single project, each component could still release it's own artifacts and versions. For example, if OMR still wants to produce independent releases, they could do that. And, then have those results feed into the openj9 component or project. We're doing a sort-of similar thing with the MicroProfile project. We have several components within MicroProfile, each with it's own release cycle -- Config API, Fault Tolerance API, JWT RBAC propogation, OpenTracing, etc. And, then the results of these independent efforts will feed into the overall MicroProfile releases. -- Kevin On Thu, Jul 27, 2017 at 2:25 PM, Mark Stoodley <[email protected]> wrote: > The OpenJ9 project proposal is in its creation review at this point ( > https://projects.eclipse.org/proposals/eclipse-openj9). This project will > be consuming the Eclipse OMR project on a regular (actually, continuous, is > what we would like) basis. These two projects are quite closely linked (in > that Eclipse OMR provides Virtual Machine technology components, like > garbage collection and JIT compilers, that are then "specialized" by OpenJ9 > to implement a Java Virtual Machine). > > What we're imagining is that OpenJ9 will maintain its own private "fork" > of Eclipse OMR (an openj9.omr repository alongside the primary openj9 > repository we're optimistically expecting to be created at GitHub) that we > want to mirror commits from the upstream Eclipse OMR project when they > happen. We really do think we want to be at the bleeding edge on both > projects at the same time (because life isn't challenging enough, I guess). > One motivating reason for that is so that OpenJ9 can immediately test and > react to the impact of Eclipse OMR commits in the context of a Java Virtual > Machine (i.e. leveraging tests written in Java). > > I'm wondering primarily how this kind of consumption model should interact > with the CQs one normally files when the "version" of a dependent project > is being updated: if OpenJ9 pulls in every Eclipse OMR commit, which could > mean up to 40+ commits per week, I'm *really* *really* hoping that will not > require a CQ each. Another possibly relevant wrinkle is that, despite lots > of activity, Eclipse OMR hasn't done a release yet (yeah, we're proud :( ). > > Does any other project do this kind of thing already? > > Any advice or, especially, feedback on how we can pragmatically use this > kind of model and meet our IP tracking requirements? > > Is there anything Eclipse OMR needs to do to facilitate this consumption > model, and is there anything we need to ensure in the construction of > OpenJ9 (or its private fork of OMR) to make this work and be practical? > > --mark > > > _______________________________________________ > incubation mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/incubation > >
_______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation
