On Wed, Sep 28, 2011 at 11:38 PM, Bill Shannon <bill.shannon_at_oracle.com>wrote:
> Jason T. Greene wrote on 09/28/2011 08:32 PM:
>
> On Sep 27, 2011, at 4:57 PM, Bill Shannon <bill.shannon_at_oracle.com>
>> wrote:
>>
>> Jason T. Greene wrote on 9/27/11 1:51 PM:
>>>
>>>> On 9/27/11 2:56 PM, Bill Shannon wrote:
>>>>
>>>> -snip-
>>>>
>>>> We have considered several
>>>>> alternatives moving forward, including delivering Java EE 7 with the
>>>>> remaining content as planned, or splitting the Java EE 7 release into
>>>>> smaller Java EE 7 and Java EE 8 releases, with only a small time gap
>>>>> between those two releases, and with Java EE 8 containing only
>>>>> modularity support and any remaining original content from Java EE 7.
>>>>>
>>>>> I know this will be a disappointment to all of us, but I'm sure you'll
>>>>> understand the constraints and agree that alignment with the upcoming
>>>>> Java SE module system is essential.
>>>>>
>>>>
>>>> Hi Bill,
>>>>
>>>> I definitely think this was the right decision to make, and relay Red
>>>> Hat's
>>>> support. Due to the massive impact modularity will have I think it's
>>>> more
>>>> important that EE and SE be cleanly aligned, then for us to be early.
>>>>
>>>
>>> Thanks for the support.
>>>
>>> The idea you mention above of fast tracking EE7 is interesting. Does
>>>> this imply
>>>> revisiting the main goals? We would love to see some more work on
>>>> unifying the
>>>> specs (e.g. common services like tx, sec, and so on), and that seems
>>>> more
>>>> achievable in a short time frame.
>>>>
>>>
>>> At this point we're just collecting input.
>>>
>>> It sounds like you're suggesting that we scale back some (unnamed) goals
>>> and doing more work to unify specs. We're still considering the resource
>>> impact of the various possibilities but at this point we think we'd
>>> likely
>>> have to remove more than just modularity to make a significant difference
>>> in the EE 7 schedule.
>>>
>>
>> That's correct. I was assuming that a shortened schedule would mean
>> shifting or
>> splitting other major items. For example, perhaps some of the PAAS work
>> could be
>> split between 7 and 8?
>>
>
> The only obvious choice there is to defer the limited SaaS support we're
> planning to EE 8. I'd be a little worried about doing that, however,
> since we've already seen that there's an interaction between the metadata
> we need for PaaS and the metadata we need for SaaS. The nice simple
> solution we envisioned for PaaS can become quite complicated when we
> factor in the SaaS requirements. I'm concerned that if we don't
> consider them from the beginning we'll end up with a mess if we have
> to retrofit them later.
>
>
> Still, I'm interested in what additional spec unification you'd like to
>>> see.
>>>
>>>
>> Well I think we could continue to build on the "unified component model"
>> notions
>> we introduced in 6. More specifically taking things like EJB transactional
>> annotations and making them common EE services that can be consumed by
>> managed
>> beans, and by extension any EE framework.
>>
>
> Doing that for transactions is already on our list.
>
> Anything else?
>
If we could at least get some of the configuration and staging right that
would make EE7 attractive and simpler to use, even with some other features
defered. That also is subject to unification, at least JSF 2 has a very
simplified approach to staging, but if at least that or an improved form was
applied to more than just this JSR that'll provide staging and help deploy
and configure applications.