Hi,
I think asciidoc is a great choice. Since it is plain text it is easy to
diff and collaborate with PRs. Keeping it close to the code also have the
benefit of versioning covered.
Regarding different output formats, we can set up maven profiles to produce
almost every format out there. The current config produce html and pdf if I
remember correctly.
Ivar
On Fri, Oct 28, 2016 at 2:53 AM Will Hopkins <will.hopkins_at_oracle.com>
wrote:
> I'm happy to continue with asciidoc if that's the EG's preference,
> especially since it's already started that way on GitHub. Google docs does
> seem a little easier to collaborate with, though, and to export from in
> different formats.
>
> Arjan, thanks for volunteering to contribute to the "authentication
> mechanism" and "identity store" sections.
>
> Werner, do let us know how zoom works for you; that might be a good tool
> for meetings.
>
>
> Will
>
>
> On 10/25/2016 12:38 PM, Werner Keil wrote:
>
> Hi,
>
> I am fine with either of those. JSR 354
> https://github.com/JavaMoney/jsr354-api/tree/master/src/main/asciidoc
> shows, how this could look like in a Final release using Asciidoc.
> And as Alex mentioned, Bean Validation and CDI also use it (with a few
> tweaks, e.g. finer-grained modularity JSR 363 took some inspiration from
> the CDI TCK, but unless we could get that to be Open Sourced in 375, I'm
> not sure, if it's an option here?;-)
>
> JSR 363 (
> https://docs.google.com/document/d/12KhosAFriGCczBs6gwtJJDfg_QlANT92_lhxUWO2gCY/edit)
> did use Google Docs for the Spec. There was some issue with the formatting
> of Asciidoc which I evaluated, but we had some initial material from JSR
> 275 or the UoM.org project as contributions to the spec which did not
> render well in Asciidoc. While importing those into Google Docs worked
> fine, that was the main reason. JSR 107 (with Oracle as Co Spec Lead) also
> used Google Docs.
>
> For a fresh start with no major import from existing documents, I guess
> Asciidoc works pretty well.
>
> If we continue to use GitHub at least as mirror (or if there's no
> permanent replacement or life extension to java.net after Spring '17)
> then Gitter is worth a thought for a more persistent form of instant
> messaging:
>
> https://gitter.im/unitsofmeasurement/unit-ri?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge
> also see JSR 363 RI, we used it later in 354, so there is less history
> there.
>
> Slack would be an alternative, I'm sure most of you joined channels e.g.
> by Adam Bien (also in this EG;-) or similar.
> HipChat was used by a client last year even inside the corporate firewalls
> (as one of the very few "cloud-based" solutions that really does store its
> data outside the country;-)
>
> Not sure about preferences and policies by Oracle, but especially Gitter
> seems rather easy for GitHub repo owners and admins to add.
>
> We do use Google Hangouts in other cases. JSR 363 rarely did, but we had
> the advantage of 3-4 EC members also in the EG so we met 2-3 times per year
> for a F2F. JSON-B/P Spec Lead Dmitry just invited us to a Zoom voice call
> https://oracle.zoom.us <https://oracle.zoom.us/my/dmitry.kornilov>
> tonight. We'll see how it goes, but it looks like it is officially ordered
> by Oracle, so if e.g. it also records sessions, it may be worth a try even
> if some may not be able to join. A history function similar to those
> persistent chats would be a great advantage. I'll know more after tonight
> how Zoom works.
>
> Regards,
> Werner
>
>
> On Tue, Oct 25, 2016 at 6:14 PM, Alex Kosowski <alex.kosowski_at_oracle.com>
> wrote:
>
> Hi,
>
> +1
>
> One big advantage of a text-based chat from a spec lead perspective is
> that it is self-documenting :)
>
> Alex
>
>
> On 10/25/16, 12:09 PM, arjan tijms wrote:
>
> Hi,
>
> Live meetings (being voice or video based) would not be my first
> preference, but a text based chat would people still be interested would
> not be that bad. For now I think we can move forward via email.
>
> As for the draft document, Alex had already set something up here:
> https://github.com/javaee-security-spec/spec-api/tree/master/spec/src/main/doc
>
> For the tool/format asciiDoc was chosen back then. I think that would
> certainly still be a viable option. The sections are currently mostly
> empty, as it's just a setup really. I think I could contribute to the
> "authentication mechanism" and "identity store" sections, at least put the
> general gist there.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
> On Tue, Oct 25, 2016 at 5:35 PM, Will Hopkins <will.hopkins_at_oracle.com>
> wrote:
>
> Hi All,
>
> Sorry for my silence the last we or so, I was catching up on some other
> work.
>
> On reflection, and given timezone differences, I'm not sure a "live"
> meeting makes much sense -- we should be able to move forward by email.
>
> I think the most important next step is to create the early draft. Looks
> like 11/29 is the date by which we need that submitted.
>
> To that end, a few people volunteered to work on particular sections --
> that will be very helpful. I will create the main document itself,
> contribute what I can for sections without assigned authors, and update
> with material that others produce. I'm looking into what tool to use;
> Google docs might be the right answer -- it certainly facilitates review
> and collaboration -- but it's somewhat limited in terms of formatting.
>
> For those willing to contribute a particular section, please respond to
> this indicating which section(s) you're interested in authoring.
>
> Thanks,
>
> Will
>
> --
> Will Hopkins | Platform Security Architect | +1.781.442.0310
> Oracle Cloud Application Foundation
> 35 Network Drive, Burlington, MA 01803
>
>
>
>
> --
> Will Hopkins | Platform Security Architect | +1.781.442.0310 <+1%20781-442-0310>
> Oracle Cloud Application Foundation
> 35 Network Drive, Burlington, MA 01803
>
>