On Mon, 2003-08-18 at 16:01, Humberto Hernandez Torres wrote: > I liked most of the discussion. But there are a few points that are either > not very clear to me or I disagree. > > It is nice to separate the components, but with too much separation in the > components they may become more difficult to use. It is far easier to deal > with a single turbine-components.jar than to have to select the ones you > like with their proper versions. We already have too many jar names in the > project.xml.
What do you do when you want to use only the scheduler, but must add a 500Kb jar file that includes other components to your dependencies ? > > Question: Is there a distinction betweem services and components or for our > purposes are the same thing.? I thing they are the same thing. > > If we are going towards Avalon components lets focus on migrating the > turbine-2 services. If there is something usefull in fulcrum it can be > integrated on demand by the interested party. As it was mentioned before the > turbine-2 services have matured in dependently from flucrum for many months. > > -- > Humberto > > > > > > "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] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Leandro Rodrigo Saad Cruz IT - Inter Business Tecnologia e Servicos (IB) http://www.ibnetwork.com.br http://db.apache.org/ojb http://xingu.sourceforge.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
