Depending on the JSR that is often done in one place (especially since
"asciidoc" where chosen for the Spec is simply another folder under a Maven
or Gradle structure) but to make it easier to only build API or Spec, it's
certainly possible. At least in JSR 354 the default build chain for the
Java SE 8 API usually builds the spec, too every time the API is generated.
I copied Reza (not sure, if he's also on the EG mailing list here) since he
could point you/us to the right people at Oracle/JCP for that. I suggested
on previous occasions, that several of these best practices should also go
into something like the "Spec Lead Guide". Maybe we can help to get some of
these documented for new Spec Leads to make their lives and that of their
expert groups easier;-)
Kind Regards,
Werner
On Tue, Mar 1, 2016 at 10:47 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> Okay, I'm convinced ;) Let's drop the uber repo idea.
>
> Coherent naming conventions would still be a good idea I guess. E.g.
>
> https://github.com/[SPEC-NAME]-spec
> /[SPEC-NAME]-proposals
> /[SPEC-NAME]-examples
> /[SPEC-NAME]-API
> /[RI-NAME]
>
> What about a separate repo for the spec document, or put it in
> /[SPEC-NAME]-API?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
> On Tue, Mar 1, 2016 at 10:04 AM, Werner Keil <werner.keil_at_gmail.com>
> wrote:
>
>> Hi,
>>
>> My "50 cent" from running or helping a few rather succesful JSRs like 354
>> or 363 on GitHub.
>> The one orga per JSR strategy sounds better. GitHub has a very distinct
>> and good memory. Every PR you merge makes the person who raised it a
>> "contributor" to that codebase. Before JSR 364/EC even made sure, that type
>> of member even exists (it should be when 364 goes final) Thus in a "Uber
>> orga" for all of Java EE it would be much harder to follow who is in what
>> EG and who isn't if there are PRs.
>>
>> Werner
>>
>> On Tue, Mar 1, 2016 at 7:55 AM, Ivar Grimstad <ivar.grimstad_at_gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I agree. The limitation in GitHub that only allows for one github pages
>>> site per org/account also favors separate orgs.
>>>
>>> Regarding migrate the spec from word to asciidoc, what if we set up the
>>> structure at JavaLand next week and start to migrate section for section.
>>> The we can encourage the community to help by converting a part and sending
>>> PRs? Just a thought... there's a *lot* of pages...
>>>
>>> Ivar
>>>
>>>
>>> On Mon, Feb 29, 2016 at 11:51 PM David Blevins <dblevins_at_tomitribe.com>
>>> wrote:
>>>
>>>> Hello from an airport!
>>>>
>>>> Chiming in to show support for the proposal. In reference to one big
>>>> org for all of EE, I'd be in favor of separate orgs to
>>>>
>>>> 1) give spec leads the most control. Aggregating control/authority to
>>>> a center usually slows things down.
>>>>
>>>> 2) more closely matches current java.net org for easier migration
>>>>
>>>> That said there still could be a javaee repo with forks of the other
>>>> repos. Though perhaps not worth the overhead.
>>>>
>>>> The other item that would be great to see is converting the word spec
>>>> to asciidoc using the same setup as CDI
>>>>
>>>> -David
>>>>
>>>> On Monday, February 29, 2016, Ivar Grimstad <ivar.grimstad_at_gmail.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> What do you think of using this unfortunate "quiet period" to move
>>>>> from Subversion to Git?
>>>>>
>>>>> The way the java.net svn repo is organized does not allow for easy
>>>>> migration to Git, but here is a suggestion that should be feasible:
>>>>>
>>>>> - Migrate the jms2.1 folder to a new Git repository as the master
>>>>> branch.
>>>>> - Migrate the www folder to a new Git repository (separate from
>>>>> the above)
>>>>> - Keep the rest in the Subversion repo as is
>>>>>
>>>>> Why GitHub and not java.net?
>>>>>
>>>>> - GitHub offers better support for collaboration and pull requests
>>>>> - I don't have access to create repositories on java.net
>>>>> - The future of java.net is uncertain (rumor has it...)
>>>>> - When and if we have a java.net Git repo, we can move everything
>>>>> there, treat as master and use the GitHub repo as a mirror.
>>>>>
>>>>> Any objections? Or suggestions otherwise?
>>>>> I will be happy to fix this and for the purpose I have created a
>>>>> GitHub group/organization:
>>>>> (we have done the same thing with JSR 371 and JSR 375)
>>>>>
>>>>> https://github.com/jms-spec
>>>>>
>>>>> I will add all of you to this group if I can find your github user.
>>>>> Please email me your username if you don't get an invitation.
>>>>>
>>>>> Ivar
>>>>>
>>>>>
>>>>
>>>> --
>>>> Sent from Gmail Mobile
>>>>
>>>
>>
>