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.
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?
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat