[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ee4j-pmc] implementation module names, groupIds, etc.
|
If you read my questions to the PMC, they were all "shoulds", not "musts".
The legal issue here is the use of company and product names by Eclipse.
That is, should Eclipse be publishing artifacts under (e.g.) com.sun.*,
because if so we would need Oracle to give Eclipse permission to do so.
Markus KARG wrote on 10/ 8/18 12:52 PM:
> Bill,
>
> actually I do see the benefit of common guidelines, and I appreciate if there are general recommendations.
>
> What I keep asking for (as more and more rules are discussed) is to respect the independence of the projects, i. e. to clearly separate the COULDs and SHOULDs from the MUSTs.
>
> There will be more understanding in the community for new rules if first the actual legal reason for the new rule is explained.
>
> -Markus
>
>
> -----Original Message-----
> From: Bill Shannon [mailto:bill.shannon@xxxxxxxxxx]
> Sent: Montag, 8. Oktober 2018 20:46
> To: EE4J PMC Discussions; Markus KARG
> Subject: 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%20R
>> ules.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
>>
