Doh! Of course... I only had my Java hat on and forgot about the other supported runtimes. Thanks for the re-explanation, Mark.
*> **I wonder: would the fact that these projects are both Eclipse projects (again, thinking positively since OpenJ9 hasn't yet passed its creation review!) help with the IP concerns?* You would think so, but that's a question for the EMO... I certainly agree with your original issue -- you don't want to be submitting CQs on a continual delivery basis. Unless you could bake the creation of the appropriate CQ into your Jenkins build process. JK! :-) -- Kevin On Thu, Jul 27, 2017 at 3:30 PM, Mark Stoodley <[email protected]> wrote: > Hi Kevin, > > > Is there any reason why these two projects need to be independent > Eclipse projects? > > The Eclipse OMR project has components that can be used to build any kind > of language runtime (currently we have Java, Javascript, Lua, Swift, Ruby, > Smalltalk, Rosie Pattern Language, and some "example" projects that are > based on the Eclipse OMR project). > > OpenJ9 is "just" the Java-specific code that uses Eclipse OMR (though it's > also the most comprehensive consumer of OMR and the original source for the > components in the Eclipse OMR project). > > So, while the two projects are "pretty tight" and we want OpenJ9 to > aggressively leverage advances made in OMR, the two projects are really > separate entities with very different goals and different communities. > > I wonder: would the fact that these projects are both Eclipse projects > (again, thinking positively since OpenJ9 hasn't yet passed its creation > review!) help with the IP concerns? > ------------------------------ > *Mark Stoodley* 8200 Warden Avenue > Senior Software Developer Markham, L6G 1C7 > IBM Runtime Technologies Canada > Phone: +1-905-413-5831 <(905)%20413-5831> > e-mail: [email protected] > ------------------------------ > We cannot solve our problems with the same thinking we used when we > created them - Albert Einstein > > > > > > > > From: Kevin Sutter <[email protected]> > To: Discussions for new Eclipse projects <[email protected]> > Date: 2017/07/27 04:17 PM > Subject: Re: [incubation] continuous integration of another > Eclipse project... > Sent by: [email protected] > ------------------------------ > > > > 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]* > <[email protected]>> wrote: > The OpenJ9 project proposal is in its creation review at this point ( > *https://projects.eclipse.org/proposals/eclipse-openj9* > <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]* <[email protected]> > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > *https://dev.eclipse.org/mailman/listinfo/incubation* > <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 > > > > > _______________________________________________ > 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
