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...

You are correct.  We're in unique state right now...  Until we have a version of Eclipse EE4J and Glassfish that is Java EE 8 compliant, we will have these external dependencies.  For example, all of the Java EE 8 APIs are officially housed in maven central.  So, if an Eclipse project has a dependency on JAX-RS 2.1, then the maven central version of the API should be used.  imho.

Once we have Java EE 8 compliance nailed down, then we should consider updating the dependencies to pull in the EE4J equivalents.  Maybe this is a version 8.1?  Or, 8.0a?  I don't think we would want to call this v9 yet since I wouldn't expect any new capability to be defined.

I can understand how skipping this interim step would make everybody's life easier.  I just don't know if we want to introduce that variable while we are trying to nail down Java EE 8 compliance.  Maybe I'm just being overly conservative...

Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    

From:        Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
To:        EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Date:        02/26/2018 02:37 PM
Subject:        [ee4j-pmc] EE4J projects with dependencies on other EE4J projects...
Sent by:        ee4j-pmc-bounces@xxxxxxxxxxx

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 Beaton
Director of Open Source Projects
The Eclipse Foundation_______________________________________________
ee4j-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top