Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-pmc] EE4J projects with dependencies on other EE4J projects...

I think it depends on what is the first milestone.

 

If it is Eclipse GlassFish is JavaEE8 compliant AND that Eclipse GlassFish will consume Eclipse versions of the many Oracle donated apis and RI projects then I believe the assumption is correct.

 

However there is an alternative way to get Eclipse GlassFish JavaEE 8 certified and that is take the donated source code for GlassFish and build a version of Eclipse GlassFish that uses the Oracle hosted reference implementations and apis. In which case the assumption isn’t valid.

 

So it depends on how we get to that first milestone.

 

Steve

 

From: ee4j-pmc-bounces@xxxxxxxxxxx <ee4j-pmc-bounces@xxxxxxxxxxx> On Behalf Of Wayne Beaton
Sent: 26 February 2018 20:37
To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Subject: [ee4j-pmc] EE4J projects with dependencies on other EE4J projects...

 

I want to run something past you before trying to disseminate it out to the community.

 

For background, please see my recent blog post on Third Party Content.

 

According to the IP Policy, an Eclipse project can just make use of the content produced by an other Eclipse project without having to connect with the Eclipse IP Team (i.e. a "Contribution Questionnaire" (CQ) is not required).

 

Many of the EE4J projects have other current and future EE4J projects as dependencies. We're in a bit of a weird state right (corner case) right now, were some of these dependencies are currently third-party, but will eventually be Eclipse projects.

 

At this point, I assume that the first release of the EE4J projects will use content produced by other EE4J projects where possible. 

 

I assume that either upstream projects will release before their EE4J consumers, or that related groups of projects (all?) will coordinate the timing of their first release.

 

Further, I assume that we prefer for downstream projects to consume the content produced by their EE4J siblings rather than the content as it exists today.

 

Are my assumptions valid?

 

I'd like to optimize everybody's time. It takes energy to create a CQ and energy to process it. In this spirit, we can accept an "invalid intermediate state" while we're bootstrapping.

 

Let's think about this in terms of the projected state at the time of the first release. If, at the time of release (as defined by the Eclipse Development Process), a dependency for an EE4J project will be served by a release version from another EE4J project, then no CQ is required.

 

e.g. Let's assume that Eclipse Grizzly has a dependency on content produced by Eclipse Project for JAX-RS (I have no idea whether or not his makes sense). If the Eclipse Project for JAX-RS engages in a successful release before (or concurrent with) Grizzly, Grizzly does not require a CQ for any version of JAX-RS.

 

Does this make sense?

 

Wayne

 

--

Wayne Beaton

Director of Open Source Projects

The Eclipse Foundation


Back to the top