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

[Carlo de Wolf]

Another concern has cropped, which has to do with the size (and speed of 
building) of the code base.

As an example (and case) the CalendarBasedTimeoutTestCase is now disabled.
https://github.com/jbossas/jboss-as/commit/2d04329f4c7ae790e711

We could enable this test during an allTests run, but that would move 
the burden to somebody checking the Hudson runs.

Ultimo having too many tests in a single code base leads to issues like 
https://issues.jboss.org/browse/AS7-1689. Which brings back fond 
memories of the AS4 code base. ;-)

How are we going to deal with this in general?

Carlo

On 08/31/2011 10:56 AM, Carlo de Wolf wrote:
> On 08/30/2011 06:31 PM, Jason T. Greene wrote:
>> On 8/30/11 3:08 AM, Jaikiran Pai wrote:
>>> 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.
>> It should be possible using git filter-branch and a limited merge. We
>> would just replace the files. It's a pretty small number (70). Although
>> really old history may not be all that useful since the context has
>> completely changed twice over.
>
> The older the history the less chance it is really useful. Mostly it 
> just a couple of commits of that single code block. But that 
> ultimately can lead down to a long time ago. Especially pieces that 
> haven't changed much.
> This is mostly used during support, to figure out why a piece of code 
> is there.
>
>>> 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?
>> Yeah I think separating JPA, CMP, and EJB3 into separate subsystems is a
>> good example of this. Anytime we want to make some particular component
>> optional it makes sense to break it into some kind of sub module. We
>> have to be careful about having too many subsystems though, or having
>> incompatible combinations. So for example I could see the ejb3 tx
>> integration being optional IF the tx subsystem is not active
>> (interceptors don't get installed or something like that). However, I'm
>> not sure if it needs to be it's own artifact, it's only a handful of
>> classes. Maybe it would help if there was a proposal for how the
>> dependency breakdown would look?
>>
> A module becoming it's own artifact is a side-effect of Maven. The 
> real criteria for a separate runtime-artifact is like you said, 
> whether the functionality is enabled in certain configurations or not.
>
> What I've seen in the past is that concerns get mixed. So instead of 
> isolating complexity people would hack in a piece of code to make 
> things work. By isolating tx we can make sure it doesn't do anything 
> untoward with other API/SPIs for example. So we can make sure it 
> doesn't abuse jboss-metadata to operate.
> A similar example would have been annotation via reflection scanning, 
> but we can't isolate out the JDK API in favor of the Jandex API.
>
> Carlo