Re: Discussion: Artifact Group Id and PackageNames

Bill Shannon

"javax" was originally for "extensions" that were not part of the JDK.  Obviously that hasn't been the case for quite some time.  It was never intended only for Java EE.

I agree that we shouldn't put anything directly in  Pick a sub-package name and put everything under that, including sub-sub-packages as needed (but not too many). would be fine.

I'm not as thrilled with or or

I agree with avoiding abbreviations when possible.  If you can come up with another word (not abbreviation) instead of "enterprise" to use after, that would be worth considering.

The use of in the JSR was a proposal, not a requirement.  Yes, it would've been better if this had been worked out before the Public Review, but it's still not too late.

None of our specs say anything about Maven groupIds or artifactIds, but I did write up a set of rules that we've been trying to follow for our work.

Werner Keil wrote on 05/26/17 11:35 AM:



As for the groupId, I am not sure, if Bill or others are worried about „“ being used by other Standards?


JSR 374 and 367 (the first Version of that new Standard) share „javax.json“

but JSON-B adds a „bind“ to the groupId.


As for „“

There have been many changes. After using the top Level groupId for some time, Things like or evolved.


There is a “security-api” from 2008 in the “” namespace, maybe that’s what Bill or others could be worried about? The new common naming convention adding the “javax” in front of every artifactId, would not cause a conflict, unless was ever to be updated to a new convention like “” as well?


It does however Sound like an older Version of JACC from the POM, so it is likely an older Version of anyway.


If the groupId “” should not be used or shared by any JSR, “” could be a good suggestion. I would not call a groupId “api” because every other JSR also pretty much defines that. With multiple packages only the Batch JSR ever even called a package “api”, but the groupId is “javax.batch” there for all artifacts. used by CDI and a few other standards could in theory also be an option if we were allowed to use “” (the reverse of above) but that would slightly differ from the JSR proposal.


Package-wise, without feeling a need to split the JARs (the Batch JSR did, but not sure, if we or users of the JSR would benefit from 2 API/SPI JARs here) could we also use” or sub-packages

As proposed in the JSR detail page for annotation types?


Would that package be an option or what does Bill think about it?


Kind Regards,



From: Arjan Tijms
Sent: Friday, May 26, 2017 18:32
Subject: Re: [javaee-security-spec] Discussion: Artifact Group Id and PackageNames




On Fri, May 26, 2017 at 6:01 PM, Will Hopkins <will.hopkins@...> wrote:

Thanks for the replies.

Arjan -- what do you mean by is "the package we were given"? In what sense was it given?


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.



With respect to the base package name:

·        The suggestion seems viable (although not all users of the API will be enterprise developers).

·        Arjan's suggestion of is also viable, but it does run into the problem that we're reserving an entire namespace -- all APIs for -- for ourselves, for all time. My main concern here is not to paint ourselves into a corner that constrains future JSRs.


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 would be another option after 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".




·        What do people think about, or, to represent Java EE Security API? This is similar to what JACC did with

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.



·        It seems like the package could really come up a level, to If the credentials classes are really general purpose, they can and should be used by lots of code, not just by IdentityStore and consumers of IdentityStore.


I'm a bit impartial about that too and could live with both options ;) If I remember correctly was originally proposed by Alex.



·        Similarly, I'm not a fan of having classes in the "root" package -- I'd like to see SecurityContext and related classes moved to The CallerPrincipal class might warrant a "principals" package, or maybe it could live in "credentials".

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.


Thoughts? I apologize if I'm revisiting issues that were discussed and decided before, but as I'm looking at this stuff I feel like I need to at least ask the question(s).


I'm fairly sure the classes in the JSR root were discussed earlier as well,  but fair enough ;)


Kind regards,

Arjan Tijms





On 05/26/2017 07:05 AM, Rudy De Busscher wrote:



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



On 26 May 2017 at 12:49, Arjan Tijms <arjan.tijms@...> wrote:



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 We could perhaps move everything to*? 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* and* 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:



A sub package of  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




On 26 May 2017 at 08:38, Arjan Tijms <arjan.tijms@...> wrote:



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:




On Fri, May 26, 2017 at 1:24 AM, Will Hopkins <will.hopkins@...> wrote:


As part of getting ready to publish our artifacts to, I've been looking at the following naming guidelines:

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 "" package, which also implies an artifact groupId of "".

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 "".

Previous JSRs, including JACC and JASPIC, have chosen to use packages under, but not place any classes in 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 for our exclusive use for all time. Moving everything under some common sub-package of seems like a good idea -- although I'll grant that no obvious name for that sub-package springs immediately to mind ...

What about The word enterprise is already used in CDI (e.g.: javax.enterprise.context)

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 and packages and eliminate the sub-packages?

Lastly, would a shorter-but-still-specific name for make sense? Perhaps Or a slightly shorter package name for Identity Store: And should we make a package so that SecurityContext and related classes can move out of

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.

Appreciate any and all feedback on this.


Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Guillermo González de Agüero





Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Join to automatically receive all group messages.