Re: best or common practice for application plug-ins
Thanks Adrian for sending through the details. We are now also looking at Apache Geronimo that has some interesting features for plugins. Thanks all, Sam. On Mon, 20 Jul 2009 17:26:03 +0200, Adrian Wiesmann wrote: > Ping me offline for details since this is very much non-Wicket stuff. > > Cheers, > Adrian > > - To > unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional > commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
Hi Sam > I'm probably revealing my inexperience with J2EE environments in asking > this, but how do Wicket programmers typically handle application "add- > ons" (or "plug-ins" or "modules"). What I (we) did was to imitate what Eclipse does. Defining hooks and having plugins attach to these hooks (and even define new hooks). We did this using a mixture of XML, Java, Script and DB tables. While we started with Swing, we "ported" this to Wicket as well. Our reason for doing so sounds similar to your thoughts: Deploying a core application and having other (third party) developers add, change and enhance to the core application. Ping me offline for details since this is very much non-Wicket stuff. Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
I think maven 3 is supposed to allow using OSGi bundles for versioning etc.. On Mon, Jul 20, 2009 at 8:12 AM, Sam Stainsby < s...@sustainablesoftware.com.au> wrote: > Thanks Olger, that gives me some ideas. I wonder if a maven could somehow > be coerced to do the dependency/downloading part, perhaps with some new > plugin. > > On Mon, 20 Jul 2009 13:39:10 +0200, Olger Warnier wrote: > > > Hi Sam, > > > > How we do it with that service: > > > > We have a file listener class that checks if OSGI based jar files are > > put in a directory. > > If so, these are automatically deployed to the OSGI runtime by the > > BundleDeployer class. > > We miss a download / version updates part, but you could add that by > > downloading to the directory specfified by the FileListener. > > > > There is no need to restart, OSGI updates the whole automatically (we > > use embedded felix for this). > > Something to keep in mind, be careful with the OSGI versioning in this > > as that puts versions next to eachother. > > > > This is used to provide custom, for our project - wicket based, user > > interface functionality. > > > > Kind Regards, > > > > Olger > > > > > > On 20 jul 2009, at 12:51, Sam Stainsby wrote: > > > >> OK, so I am an sys admin running some sort of OSGI-based application > >> and > >> now I want to add your questionnaire service and any other modules that > >> it depends on. I also want to occasionally check for version updates. I > >> want these updates and dependencies to be downloaded and put in the > >> correct place for me so that when I restart the application, they are > >> loaded. How do I do that? If it were Zope, I would add one line to a > >> 'buildout.cfg' file and run the 'buildout' script, and restart Zope. > >> > >> On Mon, 20 Jul 2009 10:33:45 +0200, Olger Warnier wrote: > >> > >>> In our project we use OSGI to get a plugin structure. Interfaces > >>> defined > >>> in the 'core' layer are implemented in OSGI modules. For a simple > >>> example see: http://www.joiningtracks.org/svn/his/trunk/ > >>> questionnaire/ > >>> (SVN code repo) > >>> It's a questionnaire service that uses OSGI to load the question forms > >>> (based on wicket) > >>> > >>> Our whole platform is constructed like that, the questionnaire service > >>> is the most simple one and easily adapted for your own use. > >> > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For > >> additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > - To > > unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional > > commands, e-mail: users-h...@wicket.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: best or common practice for application plug-ins
Thanks Olger, that gives me some ideas. I wonder if a maven could somehow be coerced to do the dependency/downloading part, perhaps with some new plugin. On Mon, 20 Jul 2009 13:39:10 +0200, Olger Warnier wrote: > Hi Sam, > > How we do it with that service: > > We have a file listener class that checks if OSGI based jar files are > put in a directory. > If so, these are automatically deployed to the OSGI runtime by the > BundleDeployer class. > We miss a download / version updates part, but you could add that by > downloading to the directory specfified by the FileListener. > > There is no need to restart, OSGI updates the whole automatically (we > use embedded felix for this). > Something to keep in mind, be careful with the OSGI versioning in this > as that puts versions next to eachother. > > This is used to provide custom, for our project - wicket based, user > interface functionality. > > Kind Regards, > > Olger > > > On 20 jul 2009, at 12:51, Sam Stainsby wrote: > >> OK, so I am an sys admin running some sort of OSGI-based application >> and >> now I want to add your questionnaire service and any other modules that >> it depends on. I also want to occasionally check for version updates. I >> want these updates and dependencies to be downloaded and put in the >> correct place for me so that when I restart the application, they are >> loaded. How do I do that? If it were Zope, I would add one line to a >> 'buildout.cfg' file and run the 'buildout' script, and restart Zope. >> >> On Mon, 20 Jul 2009 10:33:45 +0200, Olger Warnier wrote: >> >>> In our project we use OSGI to get a plugin structure. Interfaces >>> defined >>> in the 'core' layer are implemented in OSGI modules. For a simple >>> example see: http://www.joiningtracks.org/svn/his/trunk/ >>> questionnaire/ >>> (SVN code repo) >>> It's a questionnaire service that uses OSGI to load the question forms >>> (based on wicket) >>> >>> Our whole platform is constructed like that, the questionnaire service >>> is the most simple one and easily adapted for your own use. >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For >> additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - To > unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional > commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
Hi Sam, How we do it with that service: We have a file listener class that checks if OSGI based jar files are put in a directory. If so, these are automatically deployed to the OSGI runtime by the BundleDeployer class. We miss a download / version updates part, but you could add that by downloading to the directory specfified by the FileListener. There is no need to restart, OSGI updates the whole automatically (we use embedded felix for this). Something to keep in mind, be careful with the OSGI versioning in this as that puts versions next to eachother. This is used to provide custom, for our project - wicket based, user interface functionality. Kind Regards, Olger On 20 jul 2009, at 12:51, Sam Stainsby wrote: OK, so I am an sys admin running some sort of OSGI-based application and now I want to add your questionnaire service and any other modules that it depends on. I also want to occasionally check for version updates. I want these updates and dependencies to be downloaded and put in the correct place for me so that when I restart the application, they are loaded. How do I do that? If it were Zope, I would add one line to a 'buildout.cfg' file and run the 'buildout' script, and restart Zope. On Mon, 20 Jul 2009 10:33:45 +0200, Olger Warnier wrote: In our project we use OSGI to get a plugin structure. Interfaces defined in the 'core' layer are implemented in OSGI modules. For a simple example see: http://www.joiningtracks.org/svn/his/trunk/ questionnaire/ (SVN code repo) It's a questionnaire service that uses OSGI to load the question forms (based on wicket) Our whole platform is constructed like that, the questionnaire service is the most simple one and easily adapted for your own use. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
OK, so I am an sys admin running some sort of OSGI-based application and now I want to add your questionnaire service and any other modules that it depends on. I also want to occasionally check for version updates. I want these updates and dependencies to be downloaded and put in the correct place for me so that when I restart the application, they are loaded. How do I do that? If it were Zope, I would add one line to a 'buildout.cfg' file and run the 'buildout' script, and restart Zope. On Mon, 20 Jul 2009 10:33:45 +0200, Olger Warnier wrote: > In our project we use OSGI to get a plugin structure. Interfaces defined > in the 'core' layer are implemented in OSGI modules. For a simple > example see: http://www.joiningtracks.org/svn/his/trunk/questionnaire/ > (SVN code repo) > It's a questionnaire service that uses OSGI to load the question forms > (based on wicket) > > Our whole platform is constructed like that, the questionnaire service > is the most simple one and easily adapted for your own use. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
On Mon, 20 Jul 2009 10:25:17 +0200, Linda van der Pal wrote: > Seeing how it looks like you want to create your own CMS, you might want > to have a look at Hippo CMS. They've built it in Wicket AFAIK. I've seen Hippo, but my main aim is not to create a CMS. One of my goal applications is more to do with identity management, but that's another story. However, I used CM as an example of something that could be added to the core framework. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
Hi Sam, It could well be more than web-tier, but I thought if anyone has done this is would be a Wicket user :-) I looked at OSGi before I started my framework. I didn't see anything about deployment of add-ons/plug- ins. I already have a framework that incorporates IoC as a fundamental feature. Its the actual deployment of add-on functionality that interests me. ESB on first glance looks way too complicated, and I'm not sure it even does what I want. In our project we use OSGI to get a plugin structure. Interfaces defined in the 'core' layer are implemented in OSGI modules. For a simple example see: http://www.joiningtracks.org/svn/his/trunk/questionnaire/ (SVN code repo) It's a questionnaire service that uses OSGI to load the question forms (based on wicket) Our whole platform is constructed like that, the questionnaire service is the most simple one and easily adapted for your own use. Kind Regards, Olger - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
Seeing how it looks like you want to create your own CMS, you might want to have a look at Hippo CMS. They've built it in Wicket AFAIK. Regards, Linda Sam Stainsby wrote: On Mon, 20 Jul 2009 09:10:57 +0200, Per Lundholm wrote: Well, plug-ins, are they compile-time or run-time? Sounds like compile-time from your description. Runtime I think if I understand you correctly. Suppose a sys admin has already deployed the war file for the core application and wants to add some functions. Also, from your description, it sounds that it is more than web-tier. Remember Wicket is web-tier only. There are solutions for the server tier for plug-ins. Look att OSGi http://www.osgi.org and ESB. It could well be more than web-tier, but I thought if anyone has done this is would be a Wicket user :-) I looked at OSGi before I started my framework. I didn't see anything about deployment of add-ons/plug-ins. I already have a framework that incorporates IoC as a fundamental feature. Its the actual deployment of add-on functionality that interests me. ESB on first glance looks way too complicated, and I'm not sure it even does what I want. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.20/2249 - Release Date: 07/19/09 17:59:00 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
On Mon, 20 Jul 2009 09:10:57 +0200, Per Lundholm wrote: > Well, plug-ins, are they compile-time or run-time? Sounds like > compile-time from your description. Runtime I think if I understand you correctly. Suppose a sys admin has already deployed the war file for the core application and wants to add some functions. > Also, from your description, it sounds that it is more than web-tier. > Remember Wicket is web-tier only. > > There are solutions for the server tier for plug-ins. Look att OSGi > http://www.osgi.org and ESB. It could well be more than web-tier, but I thought if anyone has done this is would be a Wicket user :-) I looked at OSGi before I started my framework. I didn't see anything about deployment of add-ons/plug-ins. I already have a framework that incorporates IoC as a fundamental feature. Its the actual deployment of add-on functionality that interests me. ESB on first glance looks way too complicated, and I'm not sure it even does what I want. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
Yes, different because I'm not talking about a collection of components per se, but how add-on components are deployed to an already running application by systems administrators, not developers, as per my initial post. On Mon, 20 Jul 2009 09:08:38 +0300, Martin Makundi wrote: > Different form wicket-stuff? > > http://wicketstuff.org/confluence/display/STUFFWEB/Home > > ** > Martin > > 2009/7/20 Sam Stainsby : >> Providing modules for others. And also providing an environment for >> third- party modules. See for example: >> >> https://svn.plone.org/svn/collective/ >> >> On Mon, 20 Jul 2009 08:29:51 +0300, Martin Makundi wrote: >> >>> What are you aiming at? Providing modules to others or building >>> software to your client/own company? >>> >>> In my opinnion modules are good for the public but not for internal / >>> sophisticated (=educated) use. >>> >>> ** >>> Martin >>> >>> 2009/7/20 Sam Stainsby : I'm probably revealing my inexperience with J2EE environments in asking this, but how do Wicket programmers typically handle application "add- ons" (or "plug-ins" or "modules"). I'm interested in emulating what happens in the Zope/Plone world (which is where I've come from). In the case of Zope, you have a tool called 'buildout' and configuration file (buildout.cfg) where you can, among other things, tell buildout what modules/plug-ins you want to install. You then run the buildout script, which will take care of finding dependencies, downloading your modules and dependencies and installing them into the right place. Then the next time you run Zope, those modules are available. Buildout used in this way is a tool used by sys admins after you have deployed your Zope instance. A concrete example might be to add LDAP authentication to Zope - this would involve using buildout to install the correct modules, and then going into Zope and configuring the LDAP components. I know it sounds very much like maven, and perhaps maven can be used in this way. But generally I have considered maven to be a developer tool - at least that is how I use it. In my current case, I have created a web application framework built using Wicket. I want to have a core component and the add-ons/plug-ins such as LDAP authentication, CMS components, etc. that can be installed easily into a generic Granite deployment. Does that makes sense? How have Wicket people approached this? Buidlout can also build and install modules you are developing, as well as configure parts of Zope (such as the timezone). Sometime you just use buildout to upgrade your modules. I'm interested in approaches that encompass that as well. I'm not to fussed about having to restart the server. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For >>> additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For >> additional commands, e-mail: users-h...@wicket.apache.org >> >> >> > - To > unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional > commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
Well, plug-ins, are they compile-time or run-time? Sounds like compile-time from your description. Also, from your description, it sounds that it is more than web-tier. Remember Wicket is web-tier only. There are solutions for the server tier for plug-ins. Look att OSGi http://www.osgi.org and ESB. /Per On Mon, Jul 20, 2009 at 8:08 AM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > Different form wicket-stuff? > > http://wicketstuff.org/confluence/display/STUFFWEB/Home > > ** > Martin > > 2009/7/20 Sam Stainsby : > > Providing modules for others. And also providing an environment for > third- > > party modules. See for example: > > > > https://svn.plone.org/svn/collective/ > > > > On Mon, 20 Jul 2009 08:29:51 +0300, Martin Makundi wrote: > > > >> What are you aiming at? Providing modules to others or building software > >> to your client/own company? > >> > >> In my opinnion modules are good for the public but not for internal / > >> sophisticated (=educated) use. > >> > >> ** > >> Martin > >> > >> 2009/7/20 Sam Stainsby : > >>> I'm probably revealing my inexperience with J2EE environments in asking > >>> this, but how do Wicket programmers typically handle application "add- > >>> ons" (or "plug-ins" or "modules"). > >>> > >>> I'm interested in emulating what happens in the Zope/Plone world (which > >>> is where I've come from). In the case of Zope, you have a tool called > >>> 'buildout' and configuration file (buildout.cfg) where you can, among > >>> other things, tell buildout what modules/plug-ins you want to install. > >>> You then run the buildout script, which will take care of finding > >>> dependencies, downloading your modules and dependencies and installing > >>> them into the right place. Then the next time you run Zope, those > >>> modules are available. > >>> > >>> Buildout used in this way is a tool used by sys admins after you have > >>> deployed your Zope instance. A concrete example might be to add LDAP > >>> authentication to Zope - this would involve using buildout to install > >>> the correct modules, and then going into Zope and configuring the LDAP > >>> components. I know it sounds very much like maven, and perhaps maven > >>> can be used in this way. But generally I have considered maven to be a > >>> developer tool - at least that is how I use it. > >>> > >>> In my current case, I have created a web application framework built > >>> using Wicket. I want to have a core component and the add-ons/plug-ins > >>> such as LDAP authentication, CMS components, etc. that can be installed > >>> easily into a generic Granite deployment. > >>> > >>> Does that makes sense? How have Wicket people approached this? > >>> > >>> Buidlout can also build and install modules you are developing, as well > >>> as configure parts of Zope (such as the timezone). Sometime you just > >>> use buildout to upgrade your modules. I'm interested in approaches that > >>> encompass that as well. I'm not to fussed about having to restart the > >>> server. > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For > >>> additional commands, e-mail: users-h...@wicket.apache.org > >>> > >>> > >>> > >> - To > >> unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional > >> commands, e-mail: users-h...@wicket.apache.org > > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: best or common practice for application plug-ins
Different form wicket-stuff? http://wicketstuff.org/confluence/display/STUFFWEB/Home ** Martin 2009/7/20 Sam Stainsby : > Providing modules for others. And also providing an environment for third- > party modules. See for example: > > https://svn.plone.org/svn/collective/ > > On Mon, 20 Jul 2009 08:29:51 +0300, Martin Makundi wrote: > >> What are you aiming at? Providing modules to others or building software >> to your client/own company? >> >> In my opinnion modules are good for the public but not for internal / >> sophisticated (=educated) use. >> >> ** >> Martin >> >> 2009/7/20 Sam Stainsby : >>> I'm probably revealing my inexperience with J2EE environments in asking >>> this, but how do Wicket programmers typically handle application "add- >>> ons" (or "plug-ins" or "modules"). >>> >>> I'm interested in emulating what happens in the Zope/Plone world (which >>> is where I've come from). In the case of Zope, you have a tool called >>> 'buildout' and configuration file (buildout.cfg) where you can, among >>> other things, tell buildout what modules/plug-ins you want to install. >>> You then run the buildout script, which will take care of finding >>> dependencies, downloading your modules and dependencies and installing >>> them into the right place. Then the next time you run Zope, those >>> modules are available. >>> >>> Buildout used in this way is a tool used by sys admins after you have >>> deployed your Zope instance. A concrete example might be to add LDAP >>> authentication to Zope - this would involve using buildout to install >>> the correct modules, and then going into Zope and configuring the LDAP >>> components. I know it sounds very much like maven, and perhaps maven >>> can be used in this way. But generally I have considered maven to be a >>> developer tool - at least that is how I use it. >>> >>> In my current case, I have created a web application framework built >>> using Wicket. I want to have a core component and the add-ons/plug-ins >>> such as LDAP authentication, CMS components, etc. that can be installed >>> easily into a generic Granite deployment. >>> >>> Does that makes sense? How have Wicket people approached this? >>> >>> Buidlout can also build and install modules you are developing, as well >>> as configure parts of Zope (such as the timezone). Sometime you just >>> use buildout to upgrade your modules. I'm interested in approaches that >>> encompass that as well. I'm not to fussed about having to restart the >>> server. >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For >>> additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >>> >> - To >> unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional >> commands, e-mail: users-h...@wicket.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
Providing modules for others. And also providing an environment for third- party modules. See for example: https://svn.plone.org/svn/collective/ On Mon, 20 Jul 2009 08:29:51 +0300, Martin Makundi wrote: > What are you aiming at? Providing modules to others or building software > to your client/own company? > > In my opinnion modules are good for the public but not for internal / > sophisticated (=educated) use. > > ** > Martin > > 2009/7/20 Sam Stainsby : >> I'm probably revealing my inexperience with J2EE environments in asking >> this, but how do Wicket programmers typically handle application "add- >> ons" (or "plug-ins" or "modules"). >> >> I'm interested in emulating what happens in the Zope/Plone world (which >> is where I've come from). In the case of Zope, you have a tool called >> 'buildout' and configuration file (buildout.cfg) where you can, among >> other things, tell buildout what modules/plug-ins you want to install. >> You then run the buildout script, which will take care of finding >> dependencies, downloading your modules and dependencies and installing >> them into the right place. Then the next time you run Zope, those >> modules are available. >> >> Buildout used in this way is a tool used by sys admins after you have >> deployed your Zope instance. A concrete example might be to add LDAP >> authentication to Zope - this would involve using buildout to install >> the correct modules, and then going into Zope and configuring the LDAP >> components. I know it sounds very much like maven, and perhaps maven >> can be used in this way. But generally I have considered maven to be a >> developer tool - at least that is how I use it. >> >> In my current case, I have created a web application framework built >> using Wicket. I want to have a core component and the add-ons/plug-ins >> such as LDAP authentication, CMS components, etc. that can be installed >> easily into a generic Granite deployment. >> >> Does that makes sense? How have Wicket people approached this? >> >> Buidlout can also build and install modules you are developing, as well >> as configure parts of Zope (such as the timezone). Sometime you just >> use buildout to upgrade your modules. I'm interested in approaches that >> encompass that as well. I'm not to fussed about having to restart the >> server. >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For >> additional commands, e-mail: users-h...@wicket.apache.org >> >> >> > - To > unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional > commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
What are you aiming at? Providing modules to others or building software to your client/own company? In my opinnion modules are good for the public but not for internal / sophisticated (=educated) use. ** Martin 2009/7/20 Sam Stainsby : > I'm probably revealing my inexperience with J2EE environments in asking > this, but how do Wicket programmers typically handle application "add- > ons" (or "plug-ins" or "modules"). > > I'm interested in emulating what happens in the Zope/Plone world (which > is where I've come from). In the case of Zope, you have a tool called > 'buildout' and configuration file (buildout.cfg) where you can, among > other things, tell buildout what modules/plug-ins you want to install. > You then run the buildout script, which will take care of finding > dependencies, downloading your modules and dependencies and installing > them into the right place. Then the next time you run Zope, those modules > are available. > > Buildout used in this way is a tool used by sys admins after you have > deployed your Zope instance. A concrete example might be to add LDAP > authentication to Zope - this would involve using buildout to install the > correct modules, and then going into Zope and configuring the LDAP > components. I know it sounds very much like maven, and perhaps maven can > be used in this way. But generally I have considered maven to be a > developer tool - at least that is how I use it. > > In my current case, I have created a web application framework built > using Wicket. I want to have a core component and the add-ons/plug-ins > such as LDAP authentication, CMS components, etc. that can be installed > easily into a generic Granite deployment. > > Does that makes sense? How have Wicket people approached this? > > Buidlout can also build and install modules you are developing, as well > as configure parts of Zope (such as the timezone). Sometime you just use > buildout to upgrade your modules. I'm interested in approaches that > encompass that as well. I'm not to fussed about having to restart the > server. > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
