[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ee4j-pmc] implementation module names, groupIds, etc.
|
Markus, we go through this every time. I ask for or suggest some guidelines
and you say you don't want to follow any rules. We hear you. We agree that
each project can make its own decisions. If the overall EE4J project comes
up with some guidelines, but you feel that there's a good reason for your
project to do it differently, that's fine. And if you just have a better
idea for how to do it, please share your suggestion so we can all benefit
from your insight.
Even if you see no benefit in these guidelines, other projects do. Many
projects will have no strong opinion about how things should be done and
will be happy to follow the guidance provided. And for those of us working
on multiple projects, having some consistency between projects makes it
much easier to do our jobs. You may not see this if you're only working
on one or two projects, and that's fine. But please understand that other
people have a different perspective that is also valid.
For the particular issue of the names described below, there *is* a legal
impact on the choice of names, and that's why I'm asking the PMC these
specific questions.
Thanks.
Markus KARG wrote on 10/05/2018 10:43 PM:
> As per EF rules all projects are self-governed, so I would plea for not
> regulating anything in that direction at all, until there is an essential
> technical or legal need to. For Maven users, file names play no role at all,
> because these change on downloads anyways. And for Maven artifacts of
> implementations, applications will pull a lot of non-jakarta dependencies in
> additions, so aligning anything brings no measurable benefit.
>
> -Markus
>
> -----Original Message-----
> From: ee4j-pmc-bounces@xxxxxxxxxxx [mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On
> Behalf Of Bill Shannon
> Sent: Samstag, 6. Oktober 2018 02:08
> To: EE4J PMC Discussions
> Subject: [ee4j-pmc] implementation module names, groupIds, etc.
>
> While you're thinking about what to do about the standard module names,
> there's a similar issue with the names of implementation modules, the Maven
> groupIds used for these artifacts, their OSGi bundle names, etc.
>
> My questions to the PMC are at the bottom.
>
>
> I described the conventions we used for Java EE here:
> https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.h
> tml
>
> Here's two examples excerpted from that:
>
> JSF:
>
> API jar file: javax.faces-api.jar
> OSGi Bundle-SymbolicName: javax.faces-api
> Maven group ID, artifact ID: javax.faces:javax.faces-api
> jar Extension-Name: javax.faces
> API javadoc jar file: javax.faces-api-javadoc.jar
> API source jar file: javax.faces-api-sources.jar
>
> Implementation jar file: javax.faces.jar
> OSGi Bundle-SymbolicName: org.glassfish.javax.faces
> Maven group ID, artifact ID: org.glassfish:javax.faces
> jar Extension-Name: javax.faces
>
> JavaMail:
>
> API jar file: javax.mail-api.jar
> OSGi Bundle-SymbolicName: javax.mail-api
> Maven group ID, artifact ID: javax.mail:javax.mail-api
> jar Extension-Name: javax.mail
> API javadoc jar file: javax.mail-api-javadoc.jar
> API source jar file: javax.mail-api-sources.jar
>
> Implementation jar file: javax.mail.jar
> OSGi Bundle-SymbolicName: com.sun.mail.javax.mail
> Maven group ID, artifact ID: com.sun.mail:javax.mail
> jar Extension-Name: javax.mail
>
>
> What names should we use for the implementation jar files?
>
> Eclipse now owns GlassFish, so continuing to use org.glassfish might be
> fine.
> This would take care of many of the implementation jar files.
>
> What about the components that have used (e.g.) com.sun.*? Should we switch
> to "org.eclipse.ee4j.*" or perhaps just "ee4j.*"?
>
> The above examples might change to:
>
> JSF:
>
> API jar file: jakarta.faces-api.jar
> OSGi Bundle-SymbolicName: jakarta.faces-api
> Maven group ID, artifact ID: jakarta.faces:jakarta.faces-api
> jar Extension-Name: jakarta.faces
> API javadoc jar file: jakarta.faces-api-javadoc.jar
> API source jar file: jakarta.faces-api-sources.jar
>
> Implementation jar file: jakarta.faces.jar
> OSGi Bundle-SymbolicName: org.glassfish.jakarta.faces
> Maven group ID, artifact ID: org.glassfish:jakarta.faces
> jar Extension-Name: jakarta.faces
>
> JavaMail:
>
> API jar file: jakarta.mail-api.jar
> OSGi Bundle-SymbolicName: jakarta.mail-api
> Maven group ID, artifact ID: jakarta.mail:jakarta.mail-api
> jar Extension-Name: jakarta.mail
> API javadoc jar file: jakarta.mail-api-javadoc.jar
> API source jar file: jakarta.mail-api-sources.jar
>
> Implementation jar file: jakarta.mail.jar
> OSGi Bundle-SymbolicName: org.eclipse.ee4j.mail.jakarta.mail
> Maven group ID, artifact ID: org.eclipse.ee4j.mail:jakarta.mail
> jar Extension-Name: jakarta.mail
>
> Likewise, the Java platform module system names might be
> org.glassfish.jakarta.faces and org.eclipse.ee4j.mail.jakarta.mail,
> or something like that.
>
>
> Note that none of this is suggesting that we change the Java package names;
> doing so would have a significant hit on compatibility for applications
> using the EE4J implementations. Still, these other proposed changes will
> disrupt or confuse some users, and we should consider whether such changes
> are "worth it".
>
>
> Finally, my questions for the PMC:
>
> 1. Should we change the implementation Maven groupIds and OSGi bundle names
> (and choose corresponding Java platform module system names)?
>
> 2. If so, what new naming convention should we use?
>
> 3. Should we continue to use org.glassfish, or change it as well?
>
> Thanks.
> _______________________________________________
> 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
>
