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
@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
, 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
- 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
On 08/06/2017 07:14 AM, Werner Keil
Check out what I did
for JSR 374 based on that example:
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.
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803