Date
1 - 16 of 16
Discussion: Artifact Group Id and Package Names
|
Will Hopkins
EG:
As part of getting ready to publish our artifacts to maven.java.net, I've been looking at the following naming guidelines: https://javaee.github.io/glassfish/wiki-archive/Maven%20Versioning%20Rules.html. As well, one of Bill's comments on the EDR spec was that he thought there were too many different packages. As a result, I wonder if we should rethink the current package structure. In particular, I'm concerned about our use of the "javax.security" package, which also implies an artifact groupId of "javax.security". This package name is the "root" of all Java EE and Java SE security packages, with the exception of a few Java SE packages at and below "java.security". Previous JSRs, including JACC and JASPIC, have chosen to use packages under javax.security, but not place any classes in javax.security itself. I think that makes sense, as it doesn't "hog" the namespace. It's true that JSR-375 is meant to be the home for all things Java EE security, but as a practical matter we might not want to reserve java.security for our exclusive use for all time. Moving everything under some common sub-package of java.security seems like a good idea -- although I'll grant that no obvious name for that sub-package springs immediately to mind ... To Bill's comment about the number of packages, how would people feel about consolidating the "annotation" sub-packages with their parents? I.e., move the annotations into the javax.security.authentication.mechanism.http and java.security.identitystore packages and eliminate the sub-packages? Lastly, would a shorter-but-still-specific name for javax.security.authentication.mechanism.http make sense? Perhaps java.security.http.authmech? Or a slightly shorter package name for Identity Store: javax.security.idstore? And should we make a javax.security.context package so that SecurityContext and related classes can move out of javax.security? Appreciate any and all feedback on this. Will -- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803
|
|
|
|
On Fri, May 26, 2017 at 1:24 AM Will Hopkins <will.hopkins@...> wrote:
If we can find a meaningful sub-package name, I guess that would be alright. Otherwise, javax.security seems to be the most obvious place for this JSR.
This is done differently from spec to spec, so I am fine with either. Would be nice to have some common guideline from the umbrella spec on this though.
I think we should be careful abbreviating the terms we are defining in the spec. As I remember Auth Mech was one of the alternatives we was one of the alternatives we disregarded when we went for Authentication Mechanism. I am usually wary of abbreviating package names, and in this case I think we should stick to the term we define in the spec.
-- Java Champion, JCP EC/EG Member, JUG Leader
|
|
|
|
Guillermo González de Agüero
Hi, On Fri, May 26, 2017 at 1:24 AM, Will Hopkins <will.hopkins@...> wrote: Regards,
What about javax.security.enterprise? The word enterprise is already used in CDI (e.g.: javax.enterprise.context)
I strongly prefer longer but self-explanatory package names. I see they easier to find, and once they are imported, I only have to deal with the class name anyway, so a long package name is not a problem at all.
Guillermo González de Agüero
|
|
|
|
Hi, I remember there was quite some discussion about the package names in the EG and the current ones are the results of a broad consensus including a vote. Indeed, the longer non-abbrivated names are probably better. They give the API IMO a more fresh and modern feel. Abbreviating to (very) short names reminds me quite a bit of old AS/400 code. "AuthMech" in particular sounds a bit like a Japanese robot suit :P Kind regards, Arjan Tijms
On Fri, May 26, 2017 at 7:56 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:
|
|
|
|
Rudy De Busscher
Hi, A sub package of javax.security is maybe a better idea. We don't do the *complete* security. I agree that we need to avoid abbreviations as they are not as clear as the full name. Best regards Rudy
On 26 May 2017 at 08:38, Arjan Tijms <arjan.tijms@...> wrote:
|
|
|
|
Hi, We indeed don't do the complete security yet, although I think the plan was that we eventually would. The package we were given was javax.security. We could perhaps move everything to javax.security.api.*? As the current other packages (jaspic and jacc) are an spi. Jaspic even has it in its name: Java Authentication *SPI* for Containers. We can't change it now anymore, but javax.security.api.* and javax.security.spi.* with the latter containing jaspic and jacc would have been awesome. Curious what Werner has to say though, I remember him being most vocal about the current package arrangement. Kind regards, Arjan Tijms
On Fri, May 26, 2017 at 9:51 AM, Rudy De Busscher <rdebusscher@...> wrote:
|
|
|
|
Rudy De Busscher
Arjan, With my remark, We don't do the *complete* security. I was referring to the fact that we only do it for Java EE, not SE for example. So we don't do the *complete* security for the JVM was a better comment. So subpackage is then more clear. best regards Rudy
On 26 May 2017 at 12:49, Arjan Tijms <arjan.tijms@...> wrote:
|
|
|
|
Will Hopkins
Thanks for the replies.
Arjan -- what do you mean by javax.security is "the package we were given"? In what sense was it given? With respect to the base package name:
With respect to the package structure, one person replied that they were OK with moving the annotations in with their parent packages, but nobody else commented on that directly. Does that mean people are OK with it, or does the comment "we like long names" imply keeping the annotations separate? Two other comments/questions while I'm at it:
Regards, Will On 05/26/2017 07:05 AM, Rudy De
Busscher wrote:
-- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803
|
|
|
|
Hi, On Fri, May 26, 2017 at 6:01 PM, Will Hopkins <will.hopkins@...> wrote:
By the original JSR submission. It listed the packages we could use. So the JSR was filed with that and the EC signed off on it.
The problem is perhaps that "javax" is basically seen as Java EE package, but Java SE in fact uses it too. IMHO Java EE should have been given its own exclusively package a long time ago, but it's no use arguing about that now as this ship has sailed. The name of the JSR is "Java EE Security API", so it says "all APIs for Java EE security". But the question is whether we're taking "javax" to mean "java ee" or not. If we're not, and in fact it is not, then perhaps javax.security.ee would be another option after javax.security.enterprise. That not all users may be enterprise users is perhaps not that important, it just reflects on the name of the JSR which is "Java EE Security API".
Not really a big fan of "jesapi" I have to say, as it sounds a little cryptic, but if other people like it I won't be against it either.
I'm a bit impartial about that too and could live with both options ;) If I remember correctly javax.security.identitystore.credentials was originally proposed by Alex.
There are examples in EE both for and against that. FacesContext lives in a .context package, but ServletContext lives in the root. My preference would be for the root though, as for a user facing API the SecurityContext would be the entry point. Then again, I would not be strongly against moving it out of the root.
I'm fairly sure the classes in the JSR root were discussed earlier as well, but fair enough ;) Kind regards, Arjan Tijms
|
|
|
|
Guillermo González de Agüero
Hi, On Fri, May 26, 2017 at 6:01 PM, Will Hopkins <will.hopkins@...> wrote:
I personally don't like abbreviations in general. I proposed "javax.security.enterprise" as this is a Java EE spec. "javax.security.ee" could also be used but that is even more coupled to the "enterprise" concept you try to avoid.
Sorry I missed that part of your mail. I'm +1 for moving annotations to the parent level as the "annotation" element on the package name doesn't really express too much.
+1
I'd leave this as it is. In the same way that putting annotations in a specific "annotation" package doesn't add any value for me, I don't see the benefit of moving a context class to a specific "contexts" package just for one class that will not have more implementations. I'm not sure about the CallerPrincipal case. Do you expect more principals to be provided by the API in the future?
Regards, Guillermo González de Agüero
|
|
|
|
Will Hopkins
The root package name discussion has now forked to a different
thread, but I want to follow up on the other issues.
On 05/26/2017 01:40 PM, Guillermo
González de Agüero wrote:
OK, two votes for moving "annotation" packages into their parents.
And one for moving "credentials" up.
Potentially. Separately, we're having a discussion about how to handle caller principals. I would note that there are actually two classes now for SecurityContext, if you include the AuthenticationStatus class. Also it's possible we may end up with more (I plan to start a separate email thread related to SecurityContext). Where the principal class goes is an interesting question. If we had more than one, it might warrant its own package, or it could go in the credentials package, or stay with context. I think the main reason I'm not a fan of having classes in the root package is that it doesn't seem like a clean way to encapsulate functionality. A reference to a package name often implies a reference to everything underneath it in the package hierarchy, even if the language doesn't actually treat packages that way. Classes at the root often seem like they're there just because there wasn't anyplace better to put them -- why not a package like, "core", or "common", or "general", or "util", if that's what it really is? And if the classes at the root are just miscellaneous, not really related, then putting them all at the root becomes problematic if we ever want to break things out into multiple jars, since the package might end up split across multiple jars. Granted, that seems like a remote possibility, but not impossible. A package with just one or two classes in it, if that package is clearly defined in terms of a unit of functionality, doesn't bother me. As far as past practice, JACC made do with a single package. JASPIC has javax.security.auth as its root, but has no classes in that package -- all classes are in sub-packages underneath java.security.auth. That approach just seems cleaner, somehow. Anyway, that's my thinking. I can live with classes at the root if that's the consensus, but wanted to see what others thought. Will -- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803
|
|
|
|
Bill Shannon
Will Hopkins wrote on 05/26/17 02:49 PM:
Assuming you own the root package (e.g., javax.security.enterprise), classes at the root are fine, maybe even good. That's where I would expect to find most of your classes, except for maybe spi classes and classes specialized for some use case.
|
|
|
|
Will Hopkins
I agree w.r.t. classes that are truly common, and that strategy
works well for something like JACC, which doesn't have a lot of
classes, and which is focused on a single, narrow area
(authorization).
Having classes at the root here may also be fine, but there are a several discrete functional areas covered by JSR-375, with more likely in follow-on JSRs. Will On 05/26/2017 06:22 PM, Bill Shannon
wrote:
Will Hopkins wrote on 05/26/17 02:49 PM:Anyway, that's my thinking. I can live with classes at the root if that's the consensus, but wanted to see what others thought.Assuming you own the root package (e.g., javax.security.enterprise), classes at the root are fine, maybe even good. That's where I would expect to find most of your classes, except for maybe spi classes and classes specialized for some use case. -- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803
|
|
|
|
Hi, Well let's at least start with moving everything to javax.security.enterprise, as there seems to be consensus about that. Kind regards, Arjan Tijms
On Tue, May 30, 2017 at 7:54 PM, Will Hopkins <will.hopkins@...> wrote:
|
|
|
|
Will Hopkins
Agreed.
On 05/30/2017 01:57 PM, Arjan Tijms
wrote:
-- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803
|
|
|
|
Will Hopkins
I think we have consensus on moving the "annotations" to the parent
packages as well?
On 05/30/2017 03:00 PM, Will Hopkins
wrote:
Agreed. -- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803
|
|
|