> -----Original Message----- > From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] > Sent: Sunday, August 17, 2003 7:51 PM > To: [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] Move Torque related classes to > seperate turbine > module. > > > "Eric Pugh" <[EMAIL PROTECTED]> writes: > > >Henning, > > Hi, > > yes. I'm all +1 for this, however I'd prefer to go with some sort of > "turbine-components" repository in the near future. Actually, I > neither like the "fulcrum" name, nor do I think that we should've > opened up another namespace like org.apache.fulcrum. I agree, however I think the idea with many of the fulcrum components was that they are not Turbine specific. It seems to me that something like the DVSL service or Localization are really just a component, with no dependencies on turbine. However, others that maybe have a reference to rundata or something then are clearly turbine components and should be in turbine-components. I actually think that to reduce all the cvs modules, we would have jakarta-turbine-2/src for turbine and jakarta-turbine-2/components for the components that are Turbine specific.
> > Before you actually delete code from src/java, please talk with > jmcnally and the other t3 developers/users, I know that they actually > deploy/use Fulcrum and it wouldn't be nice from us (that we don't even > use Fulcrum) to break code that they use. Good point, I may just not worry about it for now. > > Personally, I'd prefer org.apache.turbine.components.<componentname> > to make clear that this is really _turbine_ code. For other stuff, > like the quartz scheduler: I wouldn't integrate this into the turbine > repo itself. If this is a component that implements a scheduler and > works in our context without changes: Fine. We put a "3rd party > components that work with Turbine" on the web site, add a link and are > done. Techinically, any Avalon component is Turbine compatible. However, I can see something like Quartz being third party, and then adding something that makes Quartz work smoothly with Turbine in the Turbine cvs. For instance a Turbine configuration -> Quartz configuration adapter.\ > > >Did you get a chance to read my follow up email and look at > the changes I > >made in Fulcrum? After spending a stack of time trying to understand > >Fulcrum, I think I ended up at the same point you are at, > about the Avalon > >components, and ditching the ServiceBroker stuff... > > Yes, I'm fine with this. But IMHO this is not really relevant to > Turbine 2.3 but to future stuff. If you have time to work on this, > cool. > > >So, in preperation for the post 2.3 future.. Should I > continue down the > >path I am? I am happy to slap in a quartz version of the > scheduler as well. > >(might throw in the wrapper to my JCrontab one as well ;-) ). > > The quartz scheduler has its own home page (don't know where, would > have to look) and I'm fine with where it is. We should work with its > author so it can be used with the AvalonComponentService in 2.3 (hint, > hint. ;-) ) and in further Turbine stuff. > > >If we are happy with what I am doing, then I will start > deleting code out of > >/src/java and replacing it with the components. My only > other question > >though is should all the services become components? And > any suggestions on > >order... > > Reworking fulcrum is a nice thing, even if all we do in the future is > just salvaging out the good bits. I don't even know whether there are > good bits left. The turbine-2 code has a solid year more work in it, > so it might have actually fallen behind turbine in some aspects. My goal is to have solid unit tests for anything I port. So, I will try and compare the Turbine-2 and fulcrum versions and try and pick up the best of both. However, I may need extra eyes for this! > > The reactor build is cool, too (once we get a maven version to be > actually usable with the reactor), but I'd like to still be able to > build the various components separately if only for debugging. If you > want to see an interdependence nightmare, try building a single Avalon > package like "excalibur-component" from source. You will end up with > almost everything from the avalon project checked out and building > before you actually get what you want. I'd like to build a single > component which fetches all of its dependencies from ibiblio. The way the reactor is set up, you can build each individual component seperatly. If it requires an earlier dependency, then that is versioned in the project.xml, and can be retrieved from iBiblio. > > BTW: I'd prefer that we call jars of the various components broken out > of fulcrum to be called fulcrum-<whatever>-<version>.jar. So there is > clear where they come from. I think they are! > > If you really have time on your hands ;-) , there was some suggestion > on the avalon-dev list, that if we want to use an avalon container > with the AvalonComponentService, ECM might not have been the best > choice. Some developers proposed that we switch to Fortress which > seems to have more advantages and the switch from ECM doesn't seem too > big. > > With the rifts that opened inside the Avalon project lately and all > the bad blood going on between the various authors, I'm not sure that > using anything beyond the Avalon Interface stuff would be a wise > decision. I have just skimmed the various discussions but I don't like > the fact that there seems to be no clear idea where to head with > Avalon in the future. There has been even talk about "redoing the > interfaces" and "split up the development", so I don't feel too good > about Avalon currently. > I know what you mean about not being sure about ECM. I have been perusing some competing IoC containers like picocontainer, and some the Avalon containers. I am somewhat of the opinion that while ECM may not be the best, it does seem to work. And eventually we may want to jump to Fortress/Merlin/Picocontainer/name your favorite container! I think for anything complex, what we want to do is what you did with the Torque component and the spice project does, which is to split the container wrapper from the core code. I may dig in a little on the other containers, but I have a feeling which ever one we pick will be the wrong one in a years time... So, to sum up, I am going to plow forward on converting some more of the core Turbine components in fulcrum. I am going to write some more unit tests. Try and port the best of Turbine-2 to fulcrum. And any unit tests I write I may try and put back into Turbine. Then, as soon as we get 2.3 out of the way we can evaluate which fulcrum components to either move into the Turbine-2 cvs or to leave in fulcrum, which becomes a repo for avalon components. Sound good? Eric --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
