Re: [jakarta.ee-spec.committee] Interaction Between Code-First and Speci

[Mark Little <mlittle@xxxxxxxxxx>]

+1

On Thu, May 31, 2018 at 2:17 PM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
>>  Well, maybe. But I don't think there is a consensus on the correct
>> approach. And delaying those TCK contributions until that consensus it
>> established seems like a bad idea. Doing a restructuring review and moving
>> these repos into other projects later is a pretty simple process.
>
> +1, Mike.  If we delay the TCK contributions until we figure out the
> "proper" organization, then we'll miss the goal of something ready by
> JavaOne.  Just like we've made concessions around the combination of API and
> Impl, let's make concessions around TCK organization.  Once we get this
> nailed down as a group, then we can re-organize at a later time.
>
> ---------------------------------------------------
> Kevin Sutter
> STSM, MicroProfile and Java EE architect
> e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
> phone: tl-553-3620 (office), 507-253-3620 (office)
> LinkedIn: https://www.linkedin.com/in/kevinwsutter
>
>
>
> From:        Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
> To:        Bill Shannon <bill.shannon@xxxxxxxxxx>
> Cc:        Jakarta specification committee
> <jakarta.ee-spec.committee@xxxxxxxxxxx>
> Date:        05/30/2018 09:57 PM
> Subject:        Re: [jakarta.ee-spec.committee] Interaction Between
> Code-First and Specifications
> Sent by:        jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
> ________________________________
>
>
>
> On 2018-05-30 10:40 PM, Bill Shannon wrote:
> Mike Milinkovich wrote on 05/30/2018 05:19 PM:
>
> Personally I would recommend sticking to the current plan of putting all of
> the TCKs into one project. That at least puts the TCK code into a different
> project. The refactoring can happen later naturally.
>
> I've explained this several times but it doesn't "stick".
>
> A small number of TCKs are already refactored.  Or rather, they were never
> integrated with the CTS.  We plan to submit those as separate repositories
> under
> the API projects.
> Humorously, I drafted a long-winded response failing to understand this yet
> again. Good thing I re-read this before hitting send.
>
> It would be good to understand what we want to do in the future if/when the
> CTS
> is refactored.  Where should the refactored TCKs go?
> I think that the end game will be to have individual TCKs, each in their own
> projects. That is just my opinion, and reasonable people can and will
> disagree. But the project teams and contributions to the TCKs are different
> enough from the specifications that I think they need to be different.
>
> We should follow the same
> model with the existing TCKs that are already separate.
>
> Well, maybe. But I don't think there is a consensus on the correct approach.
> And delaying those TCK contributions until that consensus it established
> seems like a bad idea. Doing a restructuring review and moving these repos
> into other projects later is a pretty simple process.
>
>
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
>
>
>
>
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
>