Hi,

 

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

 

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

https://search.maven.org/#search%7Cga%7C1%7Cjavax.json

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

 

As for „javax.security“ https://search.maven.org/#search%7Cga%7C1%7Cjavax.security

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

 

There is a “security-api” from 2008 in the “javax.security” 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 https://search.maven.org/remotecontent?filepath=javax/security/security-api/1.1-rev-1/security-api-1.1-rev-1.pom was ever to be updated to a new convention like “javax.security:javax.security-api” as well?

 

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

 

If the groupId “javax.security” should not be used or shared by any JSR, “javax.security.enterprise” 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.

 

https://search.maven.org/#search%7Cga%7C1%7Cjavax.enterprise used by CDI and a few other standards could in theory also be an option if we were allowed to use “javax.enterprise.security” (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

“javax.annotation.security” 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,

Werner

 

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

 

Hi,

 

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

Thanks for the replies.

Arjan -- what do you mean by javax.security 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 javax.security.enterprise suggestion seems viable (although not all users of the API will be enterprise developers).

·        Arjan's suggestion of javax.security.api is also viable, but it does run into the problem that we're reserving an entire namespace -- all APIs for javax.security -- 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 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".

 

 

·         

·        What do people think about javax.security.jsapi, or javax.security.jesapi, to represent Java EE Security API? This is similar to what JACC did with javax.security.jacc.

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 javax.security.identitystore.credentials package could really come up a level, to javax.security.credentials. 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 javax.security.identitystore.credentials 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 javax.security.context. 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

 

 

Regards,

Will

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

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:

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:

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,

 

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:

Hi,

 

 

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

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

What about javax.security.enterprise? 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 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?

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

-- 

Will Hopkins | WebLogic Security Architect | +1.781.442.0310

Oracle Application Development

35 Network Drive, Burlington, MA 01803

Regards,

Guillermo González de Agüero

 

 

 

 

-- 

Will Hopkins | WebLogic Security Architect | +1.781.442.0310

Oracle Application Development

35 Network Drive, Burlington, MA 01803