Re: [jakarta.ee-spec.committee] Is using the same group/artifacts coords

["Kevin Sutter" <sutter@xxxxxxxxxx>]

Wouldn't the axiom
of just introducing another level of indirection help with this problem?
 Maybe not.  But, if you introduced additional layers that brought
in the separate API versions, then could your app server process both versions?
 Maybe I'm not appreciating the extent of this issue.

But, from a practical
viewpoint... I would be quite hesitant on introducing a change like this
so late into the Jakarta EE 9 schedule...

---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:
       Scott
Stark <sstark@xxxxxxxxxx>
To:
       Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:
       09/18/2020
20:50
Subject:
       [EXTERNAL]
[jakarta.ee-spec.committee] Is using the same group/artifacts    
   coords as EE8 the right thing for EE9
Sent
by:        jakarta.ee-spec.committee-bounces@xxxxxxxxxxx

---

Normally it makes sense that
the group/artifact coordinates are stable across...

This Message Is From an External Sender

This message came from outside your organization.

Normally it makes sense that the group/artifact
coordinates are stable across versions, but since EE9 is under a new package,
I was looking into incorporating a more dynamic mapping of legacy
EE8 components into the EE9 API usage. To this point we have done this
via build time transformations, but I was looking at a more dynamic mapping.
With the approach I was looking at, I needed both the EE8/EE9 aps available
to the container.

This does not work however under either
maven or gradle as they only load a single version of a dependency, so
even though:

<dependency>
  <groupId>jakarta.enterprise</groupId>
  <artifactId>jakarta.enterprise.cdi-api</artifactId>
  <version>3.0.0</version>
</dependency>
<dependency>
  <groupId>jakarta.enterprise</groupId>
  <artifactId>jakarta.enterprise.cdi-api</artifactId>
  <version>2.0.2</version>
</dependency>
this could pull in non-conflicting apis
under different packages, the build system won't do it.
So, the question is, would it be better
to have a new groupId prefix or something to differentiate these APIs?
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee