|
I definitely wasn't suggesting delaying
the TCK contributions; they're taking long enough as is.
I was suggesting that we could decide what to do before
the TCK contributions are made. If you think it will take months
to decide this, then we'll just contribute the TCKs per the
current plan. If you want to change the current plan to a
different, intermediate, plan and put all the TCKs in a single
project, we need to take that to the Steering Committee.
Kevin Sutter wrote on 5/31/18 6:17 AM:
> 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
|
