On Tue, 2002-03-05 at 23:15, Warner Onstine wrote: > > I've been trying to pay attention to Maven, but am still unclear as to the > overall purpose of it (I guess) or its fit within turbine. From what I can > gather Maven is supposed to be some kind of code metrics system, this (I > assume) will be moved into commons when ready.
I would like Maven to replace Alexandria. Maven is basically a project management and navigation tool. Maven will generate a build system based on a project descriptor and the only requires the project descriptor to work. So the build files for Turbine will be exactly the same as the build files for Fulcrum. From that project descriptor the build can be performed, source cross referencing, cvs log changes transformed into a web viewable form and the metrics it provides. It will also be a repository for development processes. We were chatting this morning about an article Jeff found regarding the criteria for a release. I have also integrated Ceki's dirlayout document which describes a standard project layout (this is what maven generates), Morgan has a great document regarding versioning. We are also planning on making some continuous integration tools: a tool for massive builds like Gump and a tool like cruise control. Jauncarlo Arnez has donated an RCS ,v file parser so we can do CVS analysis and Tom Copeland has donated tools that help find dependencies in projects using byte code analysis (using BCEL). We are close to finishing the first iteration and then I'm going to try and use Maven for the Turbine projects and see where the holes are. Jeff and Pete have done some preliminary trials and they were successful. There is actually quite a bit of documentation primarily because of Pete's great effort. Geir helped with the DVSL system and Pete has extended to provide DVSL transformation for the JDepend output (what we're using for metrics though Stephane is working on his own tools) and for the JUnit tests. Things are looking good. There is also a full Java parser in the package. I took the basic grammar from the JavaCC distribution and extended it, in the same way I did with the Velocity parser, to make it reusable and I've added JavaDoc parsing and I will work on indexing the javadoc output. There is a lot in the works but if I can use it to unify the build mechanism for all the project then I will be happy and this is pretty much done. If you want to make your own project descriptor it will work now but I'm trying to make a tool to aid in making an accurate project descriptor. Again, there are a lot of docs on the Maven site. Maven will be used in the TDK and there will be extension provided for Turbine. > > On the status report I said we are shooting for a beta in the next two > > weeks (Martin, could you please update the site). The last remaining > > issue is getting Fulcrum to work with Turbine 2.2. > > Cool, if Fulcrum is going to be in 2.2, what will be the big change in 3? The code is very different and things like the view mechanisms will be simplified, the security has been decoupled (in a t3 branch) so that you can use whatever security model you want and the pipeline is now working well. I also hope to add BSF scripting (something Dave Bryson and I talked about over 18 months ago) and have a process where working with an application model is easier. So you have your application model and it is accessible via servlets, xmlrpc, SOAP, a GUI. This is more long term but now that everything is decoupled in t3 it can be added later without affecting the core. > > > Just something brief and why it was necessary to do it this way for > > > decoupling services. > > > > I don't understand the question: are you asking why we decoupled the > > services? We want the services framework to be generally useful. > > Hopefully something that can go to the commons as well. > > Now, re-reading it, I'm not sure what I was asking =). I understand the need > for de-coupling the services as there is a demand for being able to use the > services independent of the framework. > > If a service is reliant on the database (ie - a particular table or schema), > how will this need be met within the framework? How does reliance on one > service from another get met in the new framework (another way of phrasing > it)? You mean inter-service dependencies? There is a graph package in the commons that Markus Dahm donated that I've been working on along with David Peugh (the author of Quilt: quilt.sourceforge.net) and I will use that to resolve dependencies between services so that they are loaded and unloaded in the correct order. > > > Also, what decoupled services are going to be available > > > for things like Struts (I will be presenting to a struts-heavy crowd). > > > > Anything that is currently in the fulcrum repository will be available > > for use with any application. It is no longer dependent on Turbine at > > all. > > Cool, is anyone working with Fulcrum and Struts right now, or looking into > how these two will fit together? I've seen people using Torque in struts but I've seen no mention of Fulcrum. > -warner > > > > Thank you all for your time and a truly great web framework, I learn > more > > > about it each time I want to build something. > > > > > > -warner > > > > > > +warner onstine+ > > > > > > > > > -- > > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > > jvz. > > > > Jason van Zyl > > [EMAIL PROTECTED] > > > > http://tambora.zenplex.org > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
