users@javaee-security-spec.java.net

[javaee-security-spec users] [jsr375-experts] Re: JSR 375 Next Steps

From: Werner Keil <werner.keil_at_gmail.com>
Date: Tue, 29 Dec 2015 18:41:57 +0100

Well observed.

JSR 354 aiming at both Java 6/7 and 8+ has an even slightly more complex
structure.
With "api" (also including Asciidoc spec) and "api-bp" (no spec there;-) as
well as
"ri" (codename "moneta") and "ri-bp"
Only the TCK is platform-neutral, so it only exists once.
Beside examples and mentioned other repos like "shelter".

There is no definitive template or guideline, though it's probably
something a future "Spec Lead Guide" at JCP may contain some day. Guess it
simply requires best practices and some volunteers to help;-)

The repo-names containing "javaee-security" once more could be made
shorter, though I understand the idea was well-intended, e.g. checking out
to a git-home you may end up with several "proposals" or "examples" folders
by default;-)

JSR 107 with minor tweaks or differences (it makes little difference if a
demo section is called "demo", "demos", "samples" or "examples";-) contains
most of the basic folders.
Again like 354 or 363 it follows an all Open Source approach, so RI and TCK
are completely open. Unless we see that for MVC 1.0 (is there a "tck" repo
somewhere?;-) this may not be entirely the case here either. That I suppose
only Alex and Oracle can tell. David and others know, there is some history
with Java EE TCKs and unless the latest JSRs including that one do not
change it that remains to be seen how it unfolds.

Changing repo names can only be done by a few admins like David or Alex I
assume (somebody mentioned that before) but for harmonizing them a bit,
maybe dropping the "javaee-security" prefix was OK. Except for "spec-api" I
don't see any of the others mirrored or connected here:
https://java.net/projects/javaee-security-spec/sources So I assume we have
a bit more freedom within the GitHub organization. As soon as a RI gets its
name and place, there shall be a mirror either with the main java.net
project or see "orzac" and others a separate java.net one.

Kind Regards,

Werner

On Tue, Dec 29, 2015 at 6:13 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:

> Hi,
>
> Looking at some inspiration at other specs, I see that jsr 107 just has
> "jsr107" at github, and then jsr107spec, jsr107tck and just "ri" as repos.
> See https://github.com/jsr107
>
> For Java EE specs it would be nice perhaps if there's some kind of
> template for guidance. Currently every project does something totally
> different (at github).
>
> So while jsr 107 has
>
> jsr107
> jsr107spec
> jsr107tck
> ri
> demo
>
> We now have:
>
> javaee-security-spec
> spec-api
> javaee-security-proposals
> javaee-security-examples
>
> On top of that spec-api has a java.net hurdle, see
> https://github.com/javaee-security-spec/spec-api
>
> PRs can be done, but the spec lead has to merge them to java.net. I think
> it would be easier of java.net was the mirror, and github.com the "place
> to commit". That way all Oracle internal build jobs could still target
> java.net and almost nothing of the infrastructure would have to change
> should github.com for some reason or the other disappear.
>
> JSF has yet another setup on github:
>
> javaserverfaces
> mojarra
> samples
> extensions
>
> Where AFAIK only mojarra is really used. In the case of javaserverfaces
> it's strictly a mirror and no PRs or commits are accepted. Mojarra
> committers exclusively use java.net. The mojarra project includes the
> API. The spec text itself is not on github.
>
> MVC has again another setup:
>
> spericas
> mvc-spec
> ozark
> [some JAX-RS forks that don't seem to be related to MVC]
>
> So for the spec repos we have:
>
> "jsr107spec", "spec-api" and "mvc-spec"
>
> While for the ri repos it's:
>
> "ri", "mojarra", "ozark"
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Dec 23, 2015 at 6:05 PM, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
>
>> Hi,
>>
>> On Wed, Dec 23, 2015 at 4:44 PM, Werner Keil <werner.keil_at_gmail.com>
>> wrote:
>>
>>> Then of course Ozark also isn't so easy to pronounce. Ozark Mountains (
>>> https://en.wikipedia.org/wiki/Ozarks) might have been taken as a
>>> synomym for "layer" in MVC, not sure, who suggested or picked the name.
>>>
>>
>> It was the co-spec lead Manfred who choose that name. It comes from
>> "Ozark Zephyr", which the logo on the Ozark website hints at ;) See
>> https://ozark.java.net/
>>
>> >Here's another one, from the "aquarium", since the RI will likely go
>> under "org.glassfish" as most other EE JSRs:
>> "Placoderm"
>>
>> Not the easiest of names, but not that bad either ;) Would have my vote.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>