Sorry it's taken me so long to respond to your excellent proposal Vincent, the holidays have been very busy for me.
On 12/24/03 4:21 AM, "Vincent Massol" <[EMAIL PROTECTED]> wrote: > Hi cactus committers, > > As every day goes by, I am more and more excited about Cactus v2 (see > http://blogs.codehaus.org/people/vmassol/archives/000520_cactus_v2_archi > tecture_proposal.html). I'd like to start pumping some cactus v2 code. > > Before going on, I'd like to know what you think about Cactus v2 and to > decide on how we progress. I believe we have several options: > > 1/ create a jakarta-cactus/sandbox/cactus2 directory and write cactus v2 > code in there > 2/ request the creation of a jakarta-cactus2 CVS module (It will still > be under the umbrella of the Cactus project - it's not the creation of a > new project). I think I prefer solution 2 as well--if only because it would be nice to work in a clean area without all of the Cactus1 baggage. > > I personally much prefer solution 2/ as it is cleaner (and it works > better with Eclipse projects too). > > We have also the option to request the creation of a > [EMAIL PROTECTED] mailing list. If not, then all traffic > will go to the existing cactus-dev ML. I also prefer to request the > creation of such a list. Nah, let's keep the discussion here as Chris suggests. > > I'm also curious to know how many of you are interested in participating > to Cactus 2 (or is it too early at this stage for you to know)? I've > been talking to Jonas Boner (AspectWerkz author) and Chad Woolley > (VirtualMock author) and I'd like to invite them to participate to the > Cactus2 project if they're interested (it will be easier to do if we > have separate jakarta-cactus2 CVS module I think). More interested than I am in participating in Cactus1--if only because there's more work/more fundamental work to do on Cactus2. However, my limiting factor (as always) is time. I find it extremely hard to scare up the 6 hours it takes to get some momentum behind Cactus development. (Perhaps a minor goal for Cactus2 could be a lighter-weight build process?) Still, there's always room for someone to write docs and provide thought... I've been talking to VMS (my company) about donating some time to the Cactus project, perhaps that will help. On the subject of new team members. I think Chad would be an excellent addition to the Cactus team. He has intelligence, a passion for the subject, and way more time than I do :) I recommend him highly. If Chad should join VMS (a subject currently under discussion), we could actually have a live pair on the Cactus project. That would be cool. As for Jonas, his creation of AW is credentials enough for me. If he does join, we are likely to get AW tailored to our needs which is great. > > Anyway, I'm interested in any feedback you have! As for the proposal itself, I have 3 areas of feedback. 1) AW vs. AJ I think I prefer the stability and maturity of AspectJ, but I understand that it requires more tool support. One question I have, how well do AspectJ and AspectWerkz play together? Personally, I am planning on integrating AspectJ into our production system in the near future. I would hate to be shut out of Cactus2 because of that decision. (I'm not convinced that AspectWerkz is mature enough to use in production.) I would actually cite AspectJ's tool support (crosscut browsing, for instance) as a bonus for users committed to the idea of AOP. The only users I would worry about would be those who did not wish to do AOP except for Cactus. We could consider a dual implementation approach (AspectWerkz and AspectJ) as Chad Wooley did for EasyMock. This could be a lot of trouble, but might be manageable if we delegate a lot of the actual code to POJO's. 2) I'm not sure I like the idea of forcing the user to call their component externally using HTTPUnit or another tool. Most of the time that I use Cactus nowadays, I simply need to be in the container. I use ServletTestCase merely because it is legal to instantiate local EJBs and call their methods within the container. I believe Chris reported a similar usage pattern. The ease of Cactus is in not needing to go through all the trouble of stimulating the code as if a client had done it. For testing actual HTTP protocol behavior this idea could be good. However, for testing EJBs I see less purpose. 3) Obviously, bringing in Aspects opens up whole new realms of unit testing possibilities. The question is, what will Cactus contribute on top of those? Will we have our own mocking framework that uses AOP? I haven't yet fully thought through this feedback, but I preferred getting it out tonight to polishing my response. Cheers, Nick --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
