> Citing JDBC, Jxxx, then I agree with you that they are more APIs. Maybe > we can meet in the middle by saying that ones duty as a Java developer > is to split into interface, abstractions, and implementations. > > In AltRMI we hope that interface is exacltly that and includes final > serialiazable classes (pattern book referes to these as ImmutableBeans, > other as 'Value Objects'). The difference between the anstract and > final classes is moot as far as AltRMI (and the bean container that uses > it - Enterprise Object Broker) is concerned. Neither the abstract or > final (impl) classes arrive on the client side. The client only deals > with the interface and the ImmutableBeans. > > EJB is very similar. Client only deals with Home and Remote interfaces > and knows little of how the bean developer put the app together or what > patterns they used. > > >>You have not talked about an equally important test of your seperation. > >> Zip the interface into one jar, the impl into another and a test into a > >>third. Mount the three in different classloaders with only the > >>interfaces visible to both the other two. I.e. it is no good separating > >>if you distribute both in one Jar. > >> > > > >Indeed. Have not looked how you handle it with the three different logging > >components, any one of which can be used, but it is the same problem? Assume, the > >same solution? > > > Three different logging comps? LogKit, Log4J & Commons-Logger? We > only really use the former. >
Sorry, but I was citing this as an example. In a world full of me too's, it was our hope to use Avalon to allow people to bring in and use their favorite components. "You are our only hope, OB1". > >It seems unlikely though, that any of this would really be possible without a > >configurator tool that would let you build your components together as a group > >designed to work with each other. Not just like Maven, but in a addition, with pick > >boxes like pick this logging component, this persistence component, this view > >component, etc. > > > Picker. Hmm sounds like our years old ComponentManager. > Thanks, I shall study that next. Does it address the problem you mentioned earlier, which you mention above in the paragraph ending with *I.e. it is no good separating >>if you distribute both in one Jar.* It is more the build issue that I am trying to wrestle with, in my head. > >There is a bunch of us who are refugees from another very successful framework, but > >one which we considered to be eventually doomed because of it's tightly coupled, and > >commercially sponsored roots. We have, apparently, broken off to start afresh. We > >will be attempting to use Avalon as our starting point. Quite a terrific framework, > >this Avalon! No telling how fast this will move, though, as the old framework is > >working well enough for us that we don't have to slam together a bad product >together > >just for the sake of getting something out the door. It is starting very slowly, so > >far, which is fine. > > > No name? Another commerical effort? Using or competing with Avalon? > Since we're name dropping, are your refugees from one other listed > frameworks on JSR111 ? > No name yet, but only because we are still forming. It would also be discourteous to the other guys to announce before they offer their consent. Another commercial effort? NOT ! We are all open-sourcers, otherwise we would be still with the bad nasty from whence we came. Using or competing with Avalon? Using. We are just trying to build what we need to use. We have already done it before, it just wasn't pluggable, so we dramatically reduced our gene pool. If our goals were not somewhat orthogonal to Avalon, I am sure we would be joining outright, rather than supplementing. But we will have an Apache style license, so probably anything we do would be something that could be incorporated by Avalon, that would be up to Avalon, and not to us. Most of us seem to be dedicated non-political types, something which is hard to do within Apache, if history is any guide. Just look at the Forrest/Maven thing. To heck with that! One Interface (as in contract), and let the market decide which component it wants to use to get the job done. > By the way, I am quite happy with 'Interface/Impl seperation' as the > MEME formerly known as the 'Interface' pattern. I trust you are equally > happy with 'InformingAPI' and that we won't meet in the middle for this. Not so fast, home boy. My only problem with Interface/Impl as a term is that it uses the ambiguous Interface, and thus potentially muddying the waters. But InformingAPI is just a proxy term for the concept. I would much rather have a term that was universally recognized than to start yet another, ugh. Is Interface/Impl universally recognized, as in, a standardized term that can be pointed to as IoC and SeparationOfConcerns is? If so, that's the road I would propose to take. Less is better, when it comes to confusing terms. But if it isn't clear, then let's make it clear, whatever the term ends up being. Your identification of the problem itself is right on the money, my 2c. JSR 111? Not. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
