Wayne, 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) LinkedIn: https://www.linkedin.com/in/kevinwsutter
Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> To:
EE4J PMC Discussions
02/26/2018 02:37 PM Subject:
projects with dependencies on other EE4J projects... Sent by:
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
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.