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 <[email protected]>:
> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to