[jboss-as7-dev] Moving EJB3 code into the AS7 source tree

[Jaikiran Pai]

Carlo and I had a chat about this yesterday. For the benefit of those 
who are following this thread, EJB3 team is *not* opposed to moving that 
code from a separate repo/project into the AS7 codebase. That's fine.

Some of the points that we discussed included the loss of history over 
that code. I don't know if it's possible to somehow get back the history 
on those files (now that the upstream already contains these files). But 
it would be good to have the history since those files (like the tx 
interceptors) have been around since AS 4.x days and have some good 
amount of commits linked against JIRAs.

One other point was having finer grained modules like ejb3-tx (within 
the AS codebase) instead of clubbing everything under the jboss-as/ejb3 
module. That way each such module can have the right set of limited 
module dependencies. Ofcourse, just creating a module for the sake of it 
wouldn't make sense. So if there is a clear separation for creating a 
module, then perhaps that would be a good idea. Thoughts?

-Jaikiran

On Thursday 25 August 2011 11:12 PM, Jason T. Greene wrote:
> On 8/25/11 3:09 AM, Carlo de Wolf wrote:
>> http://community.jboss.org/people/wolfc/blog/2010/11/26/strategies-for-separation-of-concern
>>
>> The only objection I have is putting everything in a single module and
>> just separate concerns on a package level.
>
> There is also some logical separation in that ejb3 is still a separate
> subsystem, and therefore a separate module. The code is just in the same
> place and versioned with all other subsystems. I think it's fine to
> break things into separately versioned external components when we have
> reuse (or great potential of reuse). The ejb3 timer implementation
> though is unlikely to be useful to anyone other than our impl. So using
> package separation for that case seems more than adequate (at least now)
>
>>
>> As I've pointed out a couple of times, in the AS 7 code base we're not
>> vigilant enough nor does the review process catch design issues. For the
>> review process to do a proper design check would form an unwanted choke
>> point. So we still need to find ways to guard the code against design
>> regression.
>
> We certainly could improve here in various areas. We need to make sure
> we capture designs in wikis or in javadoc or in code comments. This is
> done in many cases but not others. Ideally we start with an agreed upon
> requirements doc, then a set of docs detailing the abstract design. Then
> when code is created we try to reflect the doc information in comments
> and javadoc.  Any significant refactor then can be reviewed against that
> information.
>
> Right now we certainly discuss all major EE refactors, and we validate
> they introduce no test regressions and no TCK regressions before we
> merge these kind of patches.
>
> As to preventing choke points, I think this has to do with what the
> patch touches. The burden is ultimately on the person sending in the
> pull request / patch to break up changes in such a way that they are
> applied in reasonable time frames. For example simple bug fixes require
> much less review than a complete re-architecture of EE proxies.
>