Date   

Re: Improving the JSR 375 website

David Delabassee
 

On Sun, Aug 6, 2017 at 07:17 pm, Will Hopkins wrote:
These are all great ideas, and I'd love to see the web site improve, BUT ... the priority for the next couple of days needs to be fixing RI bugs by Tuesday (the GF RI code freeze). The work I did Friday/Saturday needed to be done, but the reason I did it then was because the project site was referenced by the transparency checklist I submitted for FAB, and I wanted to make sure there was actually something there if someone visited the site while evaluating the FAB submission.
I agree with Will. And in fact, we have many things to do between now and JavaOne... including finishing Java EE 8! ;-)
If one want to improve the site, that's more than welcome but may I suggest to stick to the current layout for now?
 
This layout is not super fancy but it's common to many sites. There are a few things that each site needs to have (e.g. license, contributing.md) and there are various moving parts that we don't really have time to document now.
 
Some standard links can be configured in https://github.com/javaee/security-spec/blob/gh-pages/_config.yml
I also like the JSON-B landing page so maybe the current landing page should be improved to be more 'to-the-point'? Maybe add a Doc page too?
 
--David


Re: Improving the JSR 375 website

David Delabassee
 

On Mon, Aug 7, 2017 at 01:10 am, Werner Keil wrote:
I should be able to get an OCA to PMO soon, but it might take a little while to process.
It might indeed take time to process it... as the PMO is not managing OCAs ;-)
OCA should be send to oracle-ca_us(at)oracle(dot)com, see http://www.oracle.com/technetwork/community/oca-486395.html

--David


Re: Improving the JSR 375 website

Werner Keil
 

Will,

At least JSON-B also has only a spec repository: https://github.com/javaee/jsonb-spec
Everything else is at Eclipse in its case, the API and spec document actually seem in the same repository. So either the API (because that would bring the term into the web address) or spec sounds best. Soteria could have its own page if it was worth the effort. At least under java.net I remember both the spec/API and RI did have two different pages for JSON-P. JSON-B does not seem to use more than the statistics pages by Eclipse.

I should be able to get an OCA to PMO soon, but it might take a little while to process. So maybe not so easy to actually merge a PR, but I'll also review them where I can.
If the release is out and there's enough time for a site, I am happy to help with that based on my experience with JSON-P which I did almost by myself.

Regards,
Werner


Re: Improving the JSR 375 website

Will Hopkins
 

Hi All,

These are all great ideas, and I'd love to see the web site improve, BUT ... the priority for the next couple of days needs to be fixing RI bugs by Tuesday (the GF RI code freeze). The work I did Friday/Saturday needed to be done, but the reason I did it then was because the project site was referenced by the transparency checklist I submitted for FAB, and I wanted to make sure there was actually something there if someone visited the site while evaluating the FAB submission.

I would encourage anyone who wants to help over the next few days to take one of the Soteria issues tagged with "bug" and "tck" and work on it.

@ggam and @arjantijms, specifically -- Guillermo has a number of outstanding pull requests. One was just updated with a requested change, and I've merged it. Most of the rest are either waiting for Arjan to review/make a recommendation on, or are waiting for requested changes, I think. I would be good to clean those up, and either get them merged or close them. A few of them are basically refactoring test code, which isn't a bad thing, but short term we need to focus our time/energy on the functional issues/bugs.

I would also note Issue #131, which is for bugs in pom.xml. The most egregious of those is that all the test jars (and poms) get deployed along with the RI jars. That means they get published to maven.java.net whenever Soteria is published. We should fix that before the RI is final. (Thinking about it now, there might possibly be a way for me to manually remove them from the set of published artifacts during the release process, but I'll have to test that, and manual processes are error prone.)

Regarding the particulars of the web site(s):
  • I think it would be great to improve the layout. The currently layout is pretty ugly, but it's the standard/default layout for the Java EE GitHub organization. Judging from the JSON-B and JSON-P sites it seems like we have some flexibility there, but I'd like to check with the EE folks internally to see if there's any guidance or constraints on what sites should look like, or on what aspects of a site (licensing/contributor info, etc.) might be mandatory.
  • Whatever we do, I think we should do it in an organized way; i.e., driven by issues, and with some planning/discussion taking place before major design/content changes are made.
  • I do have a copy of Sword Duke that is not cropped so tightly, but I haven't been able to find one with better than 105x150 resolution. I also noticed that the uncropped image has a "TM" symbol, so I've been trying to track down its origins -- a task made more difficult by java.net going dark -- but it seems likely it was originally produced by Sun. I'm going to ask the Java SE PM's if they have a better (higher res) image we can use.
  • I do have all the documents that were posted at java.net, and will upload them to the site when I get a chance (probably after RI code freeze).
  • Regarding examples, I'm thinking we should move the security-examples repo under Java EE as well, and make those examples official. Note that there's a team at Oracle working on developing examples for GF doc and the Java EE tutorial, so we'll want to coordinate any example work we do with them, to avoid duplicating effort.
  • At the risk of stating the obvious, we've got three repos (four including examples), each of which can theoretically host a site, but we should probably focus on just one main site (currently, the security-spec site), and put up other sites only to host repo-specific content, like javadoc. Anybody know if it's possible to publish a "pure" html site using gh-pages (i.e., like bare javadoc), or is it mandatory to have a _config.yml file and basic markdown content like a README.md file?
Regards,

Will

On 08/06/2017 07:14 AM, Werner Keil wrote:
Check out what I did for JSR 374 based on that example:
https://javaee.github.io/jsonp/

Since JSON-B and JSON-P deal with a similar domain, I changed very little, also keeping the JSON-style title or color scheme.
Check out the sources: https://github.com/javaee/jsonp/tree/gh-pages

Since these are sub-projects of an organization, the gh-pages branch has to be used.

Kind Regards,
Werner

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


Re: Improving the JSR 375 website

reza_rahman <reza_rahman@...>
 

That website is community-contributed. If needed, I can get in touch with the original author.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Arjan Tijms <arjan.tijms@...>
Date: 8/6/17 4:56 AM (GMT-05:00)
To: javaee-security-spec@javaee.groups.io
Subject: Re: [javaee-security-spec] Improving the JSR 375 website

Hi,

Nice! :) I was just about to suggest the very same thing ;)

The json-b one is a nice example too: http://json-b.net

I'd definitely agree with going ahead on this.

Kind regards,
Arjan Tijms

On Sun, Aug 6, 2017 at 8:40 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

I just noticed you Will already did some work on the website [1] yesterday! That's fantastic as I was about to propose doing some work on it now that the spec is basically finalized.

Basically, things I'd like to see on the page are:
- The spec logo that was available on the original GitHub repository [2]
- Some simple examples of the APIs. Not a full documentation, but just a small showcase on how to use the spec.
- The old java.net project page contained some documents I'm not sure have been preserved. But any additional material (e.g. presentations, early proposals, etc) should be available.

The JMS spec [3] website is the most complete I've seen. I could start working on some of this if you agree.


Regards,

Guillermo González



Re: Improving the JSR 375 website

Werner Keil
 

Check out what I did for JSR 374 based on that example:
https://javaee.github.io/jsonp/

Since JSON-B and JSON-P deal with a similar domain, I changed very little, also keeping the JSON-style title or color scheme.
Check out the sources: https://github.com/javaee/jsonp/tree/gh-pages

Since these are sub-projects of an organization, the gh-pages branch has to be used.

Kind Regards,
Werner


Re: Improving the JSR 375 website

Arjan Tijms
 

Hi,

As the json-b website is (c) Oracle, I assume Java EE Security can just copy it? Check to be sure of course, but otherwise might be a nice and simple approach to copy that and replace the json-b code samples and names etc with that of Java EE Security?

Kind regards,
Arjan

On Sun, Aug 6, 2017 at 11:06 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:
JSON-B website looks definitely better than the default template, but I think we might need a designer to get that level.

I'll start writing some examples then. Btw, does anybody have the full logo? The one on GitHub seems to be cropped.


Regards,

Guillermo González de Agüero

El dom., 6 de agosto de 2017 10:56, Arjan Tijms <arjan.tijms@...> escribió:
Hi,

Nice! :) I was just about to suggest the very same thing ;)

The json-b one is a nice example too: http://json-b.net

I'd definitely agree with going ahead on this.

Kind regards,
Arjan Tijms

On Sun, Aug 6, 2017 at 8:40 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

I just noticed you Will already did some work on the website [1] yesterday! That's fantastic as I was about to propose doing some work on it now that the spec is basically finalized.

Basically, things I'd like to see on the page are:
- The spec logo that was available on the original GitHub repository [2]
- Some simple examples of the APIs. Not a full documentation, but just a small showcase on how to use the spec.
- The old java.net project page contained some documents I'm not sure have been preserved. But any additional material (e.g. presentations, early proposals, etc) should be available.

The JMS spec [3] website is the most complete I've seen. I could start working on some of this if you agree.


Regards,

Guillermo González




Re: Improving the JSR 375 website

Guillermo González de Agüero
 

JSON-B website looks definitely better than the default template, but I think we might need a designer to get that level.

I'll start writing some examples then. Btw, does anybody have the full logo? The one on GitHub seems to be cropped.


Regards,

Guillermo González de Agüero


El dom., 6 de agosto de 2017 10:56, Arjan Tijms <arjan.tijms@...> escribió:
Hi,

Nice! :) I was just about to suggest the very same thing ;)

The json-b one is a nice example too: http://json-b.net

I'd definitely agree with going ahead on this.

Kind regards,
Arjan Tijms

On Sun, Aug 6, 2017 at 8:40 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

I just noticed you Will already did some work on the website [1] yesterday! That's fantastic as I was about to propose doing some work on it now that the spec is basically finalized.

Basically, things I'd like to see on the page are:
- The spec logo that was available on the original GitHub repository [2]
- Some simple examples of the APIs. Not a full documentation, but just a small showcase on how to use the spec.
- The old java.net project page contained some documents I'm not sure have been preserved. But any additional material (e.g. presentations, early proposals, etc) should be available.

The JMS spec [3] website is the most complete I've seen. I could start working on some of this if you agree.


Regards,

Guillermo González



Re: Improving the JSR 375 website

Arjan Tijms
 

Hi,

Nice! :) I was just about to suggest the very same thing ;)

The json-b one is a nice example too: http://json-b.net

I'd definitely agree with going ahead on this.

Kind regards,
Arjan Tijms

On Sun, Aug 6, 2017 at 8:40 AM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

I just noticed you Will already did some work on the website [1] yesterday! That's fantastic as I was about to propose doing some work on it now that the spec is basically finalized.

Basically, things I'd like to see on the page are:
- The spec logo that was available on the original GitHub repository [2]
- Some simple examples of the APIs. Not a full documentation, but just a small showcase on how to use the spec.
- The old java.net project page contained some documents I'm not sure have been preserved. But any additional material (e.g. presentations, early proposals, etc) should be available.

The JMS spec [3] website is the most complete I've seen. I could start working on some of this if you agree.


Regards,

Guillermo González



Improving the JSR 375 website

Guillermo González de Agüero
 

Hi,

I just noticed you Will already did some work on the website [1] yesterday! That's fantastic as I was about to propose doing some work on it now that the spec is basically finalized.

Basically, things I'd like to see on the page are:
- The spec logo that was available on the original GitHub repository [2]
- Some simple examples of the APIs. Not a full documentation, but just a small showcase on how to use the spec.
- The old java.net project page contained some documents I'm not sure have been preserved. But any additional material (e.g. presentations, early proposals, etc) should be available.

The JMS spec [3] website is the most complete I've seen. I could start working on some of this if you agree.


Regards,

Guillermo González


Re: Poll for deciding Acronym

Rudy De Busscher
 

Will,

Yes, the latest suggestion JSEC is included.

And of course, we can let it run for a week or more.

Already 7 people gave their opinion and there are 2 clear favorites ...

Best regards
Rudy

On 5 August 2017 at 16:11, Will Hopkins <will.hopkins@...> wrote:
Rudy, thanks very much for setting this up. Did you include the last suggestion that came in (JSEC, I think)?

FAB is actually scheduled to start next Tuesday, on August 8th, but Werner is right that there's no hurry about this. We won't make any changes to the spec until the ballot is complete. There are people starting to work now on Glassfish doc and the Java EE tutorial, but they won't be done for a while (weeks, at least).

A week or so seems fine for the poll.

Regards,

Will

On August 5, 2017 5:42:17 AM EDT, Werner Keil <werner.keil@...> wrote:
Thanks.

I am not sure, if there's such a hurry to find one. Since it is also holiday and some people may be on vacation, why not keep it a week or so?
The FAB has not even started yet, but an acronym is not likely what we need in the EC to vote on it. Since PFD Review will probably go on for 30 days we should see a FAB the week after next week, at least that would be around the 14th.

Regards,
Werner

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



Re: Poll for deciding Acronym

Will Hopkins
 

Rudy, thanks very much for setting this up. Did you include the last suggestion that came in (JSEC, I think)?

FAB is actually scheduled to start next Tuesday, on August 8th, but Werner is right that there's no hurry about this. We won't make any changes to the spec until the ballot is complete. There are people starting to work now on Glassfish doc and the Java EE tutorial, but they won't be done for a while (weeks, at least).

A week or so seems fine for the poll.

Regards,

Will


On August 5, 2017 5:42:17 AM EDT, Werner Keil <werner.keil@...> wrote:
Thanks.

I am not sure, if there's such a hurry to find one. Since it is also holiday and some people may be on vacation, why not keep it a week or so?
The FAB has not even started yet, but an acronym is not likely what we need in the EC to vote on it. Since PFD Review will probably go on for 30 days we should see a FAB the week after next week, at least that would be around the 14th.

Regards,
Werner

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


Re: Poll for deciding Acronym

Werner Keil
 

Thanks.

I am not sure, if there's such a hurry to find one. Since it is also holiday and some people may be on vacation, why not keep it a week or so?
The FAB has not even started yet, but an acronym is not likely what we need in the EC to vote on it. Since PFD Review will probably go on for 30 days we should see a FAB the week after next week, at least that would be around the 14th.

Regards,
Werner


Poll for deciding Acronym

Rudy De Busscher
 

Hi all,

I have created the poll with the proposed values.


Since it is weekend, I propose to keep the poll running until Monday evening (American time) or longer if possible (Will, when do we need to know the acronym?)

best regards
Rudy


Re: ACTION REQUIRED: JSR-375 Expert Group

Bill Shannon
 

Arjan Tijms wrote on 08/ 2/17 02:05 PM:
As a reminder, the API Javadoc is also an integral part of the spec text.

In particular this means that after the submission this is totally frozen too and not even things like typos, formatting or even line endings can be changed anymore.
As Will explained, the materials submitted to the JCP aren't exactly the final versions since at least things like the license and the version number will change, and we have to allow for the possibility that the vote will fail and larger changes will be required.

We use our best engineering judgment when deciding whether to fix other "trivial" bugs such as typos, formatting, or line endings.

That said, many of the comments in this thread go beyond trivial obvious fixes, and would require at least a JCP errata MR to update the document without changing the spec requirements or version.

See my definition of errata in my JCP Processes writeup.


Re: What's our Acronym?

Will Hopkins
 

We can add it to the list.

On 08/04/2017 01:58 PM, Saeed wrote:
What about JSec? 

On 4 Aug 2017 16:59, "Will Hopkins" <will.hopkins@...> wrote:
The problem with an email tally is someone has to spend an hour or two compiling the answers and analyzing the results.  ;)

Werner's suggestion of a Doodle poll sounds good to me -- set to allow three choices. Can someone set that up?

Two data points/comments on the choices:
  • I used "SECAPI" as the abbreviation for our spec in the bibliography. I'm not sure it's actually referenced anywhere in the spec, though, and we could change that without affecting the meaning of the spec.
  • "Servlet API" works pretty well for servlet, but servlet is a very narrow technology area. Everybody knows exactly what servlets are, and do, and how the API is structured. It does essentially one thing, and is well understood. By contrast, "Security API" could mean almost anything. There are so many aspects to security -- ranging from codebase permissions, to authentication and authorization, encryption, auditing, and user account management -- and there are many different technologies and APIs that implement all of that. My point is that "security" is a very broad and generic term, relative to "servlet", and therefore "Security API" might not work as well as "Servlet API" as the name of a specific and fairly narrow set of APIs. (But we can definitely still vote on it.)

Will



On 08/04/2017 12:45 PM, Guillermo González de Agüero wrote:
Given that we are only a few people, I think the mailing list would suffice here.

In that case, my votes would be:
1- EE Security
2- Security API
3- JSECAPI


Regards,

Guillermo González de Agüero

El vie., 4 de agosto de 2017 18:34, Arjan Tijms <arjan.tijms@...> escribió:
With the terminology voting we just did a simple vote on the java.net mailing list ;)

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

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


Re: What's our Acronym?

Saeed
 

What about JSec? 

On 4 Aug 2017 16:59, "Will Hopkins" <will.hopkins@...> wrote:
The problem with an email tally is someone has to spend an hour or two compiling the answers and analyzing the results.  ;)

Werner's suggestion of a Doodle poll sounds good to me -- set to allow three choices. Can someone set that up?

Two data points/comments on the choices:
  • I used "SECAPI" as the abbreviation for our spec in the bibliography. I'm not sure it's actually referenced anywhere in the spec, though, and we could change that without affecting the meaning of the spec.
  • "Servlet API" works pretty well for servlet, but servlet is a very narrow technology area. Everybody knows exactly what servlets are, and do, and how the API is structured. It does essentially one thing, and is well understood. By contrast, "Security API" could mean almost anything. There are so many aspects to security -- ranging from codebase permissions, to authentication and authorization, encryption, auditing, and user account management -- and there are many different technologies and APIs that implement all of that. My point is that "security" is a very broad and generic term, relative to "servlet", and therefore "Security API" might not work as well as "Servlet API" as the name of a specific and fairly narrow set of APIs. (But we can definitely still vote on it.)

Will



On 08/04/2017 12:45 PM, Guillermo González de Agüero wrote:
Given that we are only a few people, I think the mailing list would suffice here.

In that case, my votes would be:
1- EE Security
2- Security API
3- JSECAPI


Regards,

Guillermo González de Agüero

El vie., 4 de agosto de 2017 18:34, Arjan Tijms <arjan.tijms@...> escribió:
With the terminology voting we just did a simple vote on the java.net mailing list ;)

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


Re: What's our Acronym?

Will Hopkins
 

The problem with an email tally is someone has to spend an hour or two compiling the answers and analyzing the results.  ;)

Werner's suggestion of a Doodle poll sounds good to me -- set to allow three choices. Can someone set that up?

Two data points/comments on the choices:
  • I used "SECAPI" as the abbreviation for our spec in the bibliography. I'm not sure it's actually referenced anywhere in the spec, though, and we could change that without affecting the meaning of the spec.
  • "Servlet API" works pretty well for servlet, but servlet is a very narrow technology area. Everybody knows exactly what servlets are, and do, and how the API is structured. It does essentially one thing, and is well understood. By contrast, "Security API" could mean almost anything. There are so many aspects to security -- ranging from codebase permissions, to authentication and authorization, encryption, auditing, and user account management -- and there are many different technologies and APIs that implement all of that. My point is that "security" is a very broad and generic term, relative to "servlet", and therefore "Security API" might not work as well as "Servlet API" as the name of a specific and fairly narrow set of APIs. (But we can definitely still vote on it.)

Will



On 08/04/2017 12:45 PM, Guillermo González de Agüero wrote:
Given that we are only a few people, I think the mailing list would suffice here.

In that case, my votes would be:
1- EE Security
2- Security API
3- JSECAPI


Regards,

Guillermo González de Agüero

El vie., 4 de agosto de 2017 18:34, Arjan Tijms <arjan.tijms@...> escribió:
With the terminology voting we just did a simple vote on the java.net mailing list ;)

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


Re: ACTION REQUIRED: JSR-375 Expert Group

Will Hopkins
 

Werner,

Just to make sure I've captured the net result of your feedback after discussion, the one change you'd now propose is to add a referenced to JDBC 4 in Section 3.5, in relation to the @DatabaseIdentityStoreDefinition?

Can you be more specific about the version? To Arjan's point about CDI, using a a version that's supported in EE 7 makes Soteria more portable. Looking at the JSR-221 page, looks like an MR is in process now that wants to be JDBC 4.3, and the EE 7 platform spec seems to reference JDBC 4.1 (the way the spec is written doesn't make it easy to see at a glance which versions of various specs it requires; all I found is that JDBC drivers used with EE 7 must be JDBC 4.1 compliant).

I've add this to the issue I have tracking these potential changes: https://github.com/javaee/security-spec/issues/62, so please confirm I've got it correctly.

Will

On 08/03/2017 06:33 AM, Werner Keil wrote:
I saw, these exist in multiple places, so Servlet and EJB are mentioned in different chapters like 4.5

Nevertheless, I believe JDBC 4 should be mentioned and a reference added in 3.5 as the  @DatabaseIdentityStoreDefinition.
is part of chapter 3.

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


Re: What's our Acronym?

Guillermo González de Agüero
 

Given that we are only a few people, I think the mailing list would suffice here.

In that case, my votes would be:
1- EE Security
2- Security API
3- JSECAPI


Regards,

Guillermo González de Agüero


El vie., 4 de agosto de 2017 18:34, Arjan Tijms <arjan.tijms@...> escribió:
With the terminology voting we just did a simple vote on the java.net mailing list ;)

121 - 140 of 736