Only templates and classes. Flux was the first project to be packaged this way. Velocity can read the templates from the jar. My tr.props is a regular tr.props, but the module.packages= line is pretty long, and at the bottom I have a bunch of 'include fooapp.properties' lines to pull in the properties files from my sub applications. It is a pain since these need to be copied into the same directory as tr.props ( at least thats how we are doing it ) and aren't read from the jar. We just copy all the additional stuff into the main turbine apps tree ( props, images, javascript, etc ). It isn't ideal, but was the best we could do with turbine and breaking up our applications.
Real support for Sub-applications would include full life-cycle management of the sub-app and stuff. Maybe the avalon containers will help. ================================================================= Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com > -----Original Message----- > From: Miessbrandt Gunter [mailto:miessbrandt@;ixtern.de] > Sent: Thursday, October 17, 2002 9:08 AM > To: 'Turbine Users List' > Subject: AW: Modular Application Design? > > > Hi Jeff, > > i'm very interested about packaging sub-applications in a jar-file. > Can you send me your TR.props file? > What kind of files contains the jar-file? Images too, or only > templates and java files? > > Thanks in advance > Gunter M. > > > -----Ursprüngliche Nachricht----- > > Von: Brekke, Jeff [mailto:Jeff.Brekke@;qg.com] > > Gesendet: Donnerstag, 17. Oktober 2002 15:59 > > An: 'Turbine Users List' > > Betreff: RE: Modular Application Design? > > > > > > This is what we are currently doing for our sub-applications. > > Each project packages up the code and templates into a jar. > > The jars are pulled into a main turbine application along > > with the sub applications configuration file. We just add an > > 'include' to the bottom of tr.props for the subapps config. > > The module.packages line is also updated. > > > > It works, but what would really be nice is to extend the > > functionality to, as you mention below, allow the jar to be > > dropped in real time, and the turbine app auto pick it up. > > This would need to have the config packaged into the jar, the > > module.packages auto-updated, and dynamic updating of > > TurbineResources. > > > > ================================================================= > > Jeffrey D. Brekke Quad/Graphics > > [EMAIL PROTECTED] http://www.qg.com > > > > > > > -----Original Message----- > > > From: Scott Eade [mailto:seade@;backstagetech.com.au] > > > Sent: Wednesday, October 16, 2002 6:01 PM > > > To: turbine-user > > > Subject: Re: Modular Application Design? > > > > > > > > > I believe what you are suggesting is possible. Classes can > > > be loaded from > > > jar files by default and turbine provides > > ClasspathResourceLoader for > > > retrieving templates from a jar file. If the classes and > > > templates for a > > > module are provided in a jar file and a configuration file > > is added to > > > inform the main application about the module (so it knows how > > > to integrate > > > it) then all that should be required is a restart of the > > > webapp to kick the > > > new module off. Note that a new module might also need the > > > resource loader > > > paths and module.packages to be updated in TR.props to work > > properly. > > > > > > HTH, > > > > > > Scott > > > -- > > > Scott Eade > > > Backstage Technologies Pty. Ltd. > > > http://www.backstagetech.com.au > > > > > > > > > > From: Ian Beatty <[EMAIL PROTECTED]> > > > > Reply-To: "Turbine Users List" <[EMAIL PROTECTED]> > > > > Date: Wed, 16 Oct 2002 14:09:00 -0400 > > > > To: [EMAIL PROTECTED] > > > > Subject: Modular Application Design? > > > > > > > > Greetings. > > > > > > > > I'm checking out Turbine as a possible base for a major web > > > application I'm > > > > starting to design. I see a lot that I like, but I am > > > concerned about one > > > > aspect. Perhaps readers of this list could help to resolve > > > the question for > > > > me. > > > > > > > > It's important that the finished application be easily > > > extensible, in the > > > > sense that someone else could develop a "module" that would > > > add to the > > > > application. A module would get inserted into the website's > > > page hierarchy > > > > at a particular location, supplying an entire new branch. > > > For example, it > > > > might define a directory "http://localhost/myapp/module3/"; > > > and all contents > > > > of that directory. Or perhaps it would get inserted into > > an existing > > > > directory (supplied by the base app or an already-installed > > > module) such as > > > > "http://localhost/myapp/somepart/module5/";. > > > > > > > > As I understand the Turbine framework, this would require > > > files to be > > > > separately inserted into some or all of the application's > > > > templates/app/screens, templates/app/navigations, and > > > templates/app/layouts > > > > hierarchies. In addition, appropriate class files would > > > have to be inserted > > > > at the right places in the application's WEB-INF/classes > > > hierarchy, and > > > > various configuration and properties files might need > > > altering as well. > > > > > > > > What I'd really like is a way to just drop a folder or JAR > > > containing all > > > > the module's classes, templates configuration information > > > and properties > > > > into a directory somewhere, and have the Turbine app > > > recognize it. Perhaps > > > > I'd have to specify in an app-global configuration file > > > where that module's > > > > root should be located in the application's existing > > > hierarchy (as it > > > > appears in URLs). Then installing a module is as simple as > > > drag-and-drop, > > > > and edit one file. > > > > > > > > (I realize I'd also need to have any back-end support for > > the module > > > > installed separately, such as EJBs or DB tables, but I'm > > > not worried about > > > > that part here.) > > > > > > > > Is this possible in the Turbine framework? Anybody got any > > > neat ideas? > > > > > > > > Thanks, > > > > > > > > ..Ian > > > > > > > > -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- > > > --- -- --- -- > > > > Dr. Ian Beatty [EMAIL PROTECTED] > > > > Physics Education Research Group voice: 413.545.9483 > > > > Department of Physics fax: 413.545.4884 > > > > Univ. of Massachusetts > > http://umperg.physics.umass.edu/idb/ > > > Amherst, MA 01003-4525 USA > > > -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- > > --- -- --- > > > -- > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:turbine-user-unsubscribe@;jakarta.apache.org> > > > For additional commands, e-mail: > > <mailto:turbine-user-help@;jakarta.apache.org> > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:turbine-user-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:turbine-user-help@;jakarta.apache.org> > > > > -- > > To unsubscribe, e-mail: > > <mailto:turbine-user-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:turbine-user-help@;jakarta.apache.org> > > > > > -- > To unsubscribe, e-mail: <mailto:turbine-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:turbine-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:turbine-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:turbine-user-help@;jakarta.apache.org>
