| Re: [ee4j-pmc] module names |
I would prefer #1 for the consistency. This is my personal opinion and not an official from the PMC as it has not been discussed there yet.Ivar--On Wed, Oct 3, 2018 at 3:58 PM Raymond Auge <raymond.auge@xxxxxxxxxxx> wrote:Bill, just clarifying but, #3 means that every single java.* name would have to be predefined, i.e. hard coded, into the license?- RayOn Wed, Oct 3, 2018 at 3:56 AM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:As JAX-RS has already published under a java.* module space, we have to
stick with that one for Jakarta EE 8 as time is too short to switch now. For
the long term, I think it would be accepted by customers, if we switch over
to a Jakarta namespace. Speaking about preferences, it would be preferred if
all, including new, specifications would use the java.* namespace, as it
indicates better the fact that we produce an official Java standard and not
just some Eclipse-specific bundle of libraries.
If I have to select from your choices, it will be definitively #3.
-Markus
-----Original Message-----
From: ee4j-pmc-bounces@xxxxxxxxxxx [mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On
Behalf Of Bill Shannon
Sent: Mittwoch, 3. Oktober 2018 00:24
To: EE4J PMC Discussions
Subject: [ee4j-pmc] module names
The Java trademark license we're working on will allow the future evolution
of Java EE specifications using the javax package namespace, with some
limitations. It may also need to define the use of the new module
namespace.
The "Java EE" specifications that were included in Java SE 9 had
java.* module names defined for them. The implementations of some other
Java EE specifications have started using java.* module names, even though
such names are not yet defined by any specification.
It seems likely that future versions of these specifications that are
defined through the Jakarta EE specification process will define the module
names to be used by these specifications. I don't expect these updated
specifications to be approved until some time after the Java trademark
license is complete. Unfortunately, that means we may need to agree on
module names to be included in the Java trademark license without the help
of a formal specification process, depending on which approach we take.
There's several approaches I can see for defining module names for Jakarta
EE specifications:
1. Use jakarta.* for all Jakarta EE module names. This is consistent
with the use of Maven groupIds. To avoid breaking compatibility for
any applications using the existing module names defined by Java SE
we would need to create aggregator modules to allow these modules to
be available with both the java.* and jakarta.* module names, e.g.,
"module java.transaction { requires transitive jakarta.transaction; }"
2. Use jakarta.* for all Jakarta EE module names except for those
modules already defined by Java SE. This preserves compatibility
with the Java SE modules without the need for aggregator modules,
but results in an inconsistent module namespace.
3. Use java.* for all Jakarta EE module names for existing Java EE
specifications (those licensed to use the javax.* package namespace).
This will result in some future specifications using different module
names (as well as package names). This would require us to decide
on the java.* module names to include in the Java trademark license.
Which would the PMC and Project Leads prefer?
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-pmc
--_______________________________________________Raymond Augé (@rotty3000)Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-pmc
Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader