Hi all, I did a fresh checkout of Fulcrum.. And there are errors all over the place.. I am somewhat of the opinion that if we can make the consensus that using components via Avalon is the way forward, then we should delete all the components that don't compile in Fulcrum, and then start moving components over from Turbine-2 as a fresh start. While is seems like all the code in /src/ is some what trashed, it seems like someone (Quinton?) was setting Fulcrum up to use the maven reactor setup, because there are /pull, /testcontainer, and /xmlrpc subprojects.
This follows somewhat the pattern of the Xingu project that uses a reactor to build each component. It means you have lots of little jars, and seems to help with breaking up all the components, so that Fulcrum doesn't end up as one "super build"... To see where this would lead me, I converted the various components that had unit tests into reactor driven subprojects. Converted: /dvsl /localization /crypto I was basically following the style that Quinton established with testcomponent, pull, and xmlrpc. I fixed a stack of small bugs with those as well. The whole fulcrum container with the whacky ServiceBroker/ServiceManager stuff brought over from Turbine core I just couldn't figure out. So, at this point there are now 5 components that run as Avalon components, and don't have any dependencies on Turbine. I ended up not converting the Facade classes for dvsl, localization, and crypto, as I just could not get my head around them. To see the build happen, from jakarta-turbine-fulcrum/ run maven build to see the reactor work. For some reason the reactor can't build the docs, but you can from each individual directory. I think this is a viable path forward. I think getting anything that works in Fulcrum is miles better then the current amazingly sophicsticated and amazingly broken, hard to grok code in /src/java and /src/test. I don't know what the deprecation rules are.. But I can't imagine anyone is successfully using Fulcrum, at least judging by the state of CVS head. Any feed back would be much appreciated... Sincerely, Eric Pugh -----Original Message----- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 11:34 PM To: 'Turbine Developers List' Subject: RE: [PROPOSAL] Move Torque related classes to seperate turbinemodule. I think though that the shortterm path needs to be removing all the extranous service from Turbine, and getting them all to run as Avalon components in the Fulcrum cvs... I think we talked about this a while ago, but it kinda fell by the wayside.. Eric -----Original Message----- From: Leandro Rodrigo Saad Cruz [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 2:25 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Move Torque related classes to seperate turbinemodule. Not a commiter, but here goes my +1. I think turbine should concentrate on routing the process to fulfill the request (Say, using the pipeline metaphore, request dispatcher, etc) and provide a configurable container for components using an arbitrary component model, ala Avalon. The basic configuration should support today's turbine specification (http://jakarta.apache.org/turbine/fsd.html) This is much easier to customize and extend. Do you want a JMX enabled container ? you can ! Do you want another scheduler ? you can ! Do you want another user manager ? you can have it.. Basically the Turbine servlet would initialize the container, the pipelines, etc and route the requests through the right pipeline. The pipeline manager itself could be a component inside the container. The same goes to the request dispatcher, etc ! I've never worked with T3, but I think that was the general idea, and I think it was right, but all services on fulcrum could only be used on turbine+fulcrum (not sure). I think all components developed to be pluged into turbine should be used by other applications too ! On Fri, 2003-08-15 at 08:59, Eric Pugh wrote: > Hi all, > > I have been watching the large numbers of posts about not being able to > build Turbine due to the Torque plugin problems. And while granted, it is > an issue with Maven, I also want to remove the torque jars from my > project.xml since I don't use Turbine's security or the scheduler service. > However, this causes problems because Turbine needs Torque, even when you > don't use it. > > What is stopping us from removing the security code and scheduler service > from Turbine, and putting them in Fulcrum's core? Is it because we are > trying to get to 2.3? Or because no one has tackled the effort? it seems > that now that Torque has been Avalonized (thanks henning) that we should do > the same with the components that use Torque. > > I am willing to signup my name next to this, but I need some confirmation > that this is the path we want, and that we will remove the code from Turbine > that is in Fulcrum. > > As an aside, the duplicated code in Turbine and Fulcrum means that in > Eclipse, when I popup my imports, I am constantly guessing which jar to > import my classes from, Turbine or Fulcrum! > > On a related note, when can we remove the Criteria object from the > interfaces for security like UserManager? I would be willing to live with > Criteria just being an Object, not a criteria, and casting it one way in > DBUserManager, and another way in PassiveUserManager. Heck, then if we had > HibernateUserManager then the criteria object could be a Hibernate HQL > query! > > Frustrated with polluted interfaces, > Eric Pugh > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- 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]
