Re: [incubation] continuous integration of another Eclipseproject...

["Mark Stoodley" <mstoodle@xxxxxxxxxx>]

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
e-mail:	mstoodle@xxxxxxxxxx
We cannot solve our problems with the same thinking we used when we created them - Albert Einstein

From:      
 Kevin Sutter <kwsutter@xxxxxxxxx>
To:      
 Discussions for new
Eclipse projects <incubation@xxxxxxxxxxx>
Date:      
 2017/07/27 04:17 PM
Subject:    
   Re: [incubation]
continuous integration of another Eclipse        project...
Sent by:    
   incubation-bounces@xxxxxxxxxxx

---

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 <mstoodle@xxxxxxxxxx>
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
incubation@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation

_______________________________________________
incubation mailing list
incubation@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation