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

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