You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Sam Stainsby <sa...@sustainablesoftware.com.au> on 2009/07/20 07:03:59 UTC
best or common practice for application plug-ins
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: best or common practice for application plug-ins
Posted by Ben Tilford <be...@gmail.com>.
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 <
sam@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-unsubscribe@wicket.apache.org For
> >> additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > --------------------------------------------------------------------- To
> > unsubscribe, e-mail: users-unsubscribe@wicket.apache.org For additional
> > commands, e-mail: users-help@wicket.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: best or common practice for application plug-ins
Posted by Sam Stainsby <sa...@sustainablesoftware.com.au>.
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-unsubscribe@wicket.apache.org For
>> additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: users-unsubscribe@wicket.apache.org For additional
> commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: best or common practice for application plug-ins
Posted by Olger Warnier <ol...@xs4all.nl>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: best or common practice for application plug-ins
Posted by Sam Stainsby <sa...@sustainablesoftware.com.au>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: best or common practice for application plug-ins
Posted by Olger Warnier <ol...@xs4all.nl>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: best or common practice for application plug-ins
Posted by Sam Stainsby <sa...@sustainablesoftware.com.au>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: best or common practice for application plug-ins
Posted by Linda van der Pal <lv...@heritageagenturen.nl>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: best or common practice for application plug-ins
Posted by Sam Stainsby <sa...@sustainablesoftware.com.au>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: best or common practice for application plug-ins
Posted by Per Lundholm <pe...@gmail.com>.
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.makundi@koodaripalvelut.com> wrote:
> Different form wicket-stuff?
>
> http://wicketstuff.org/confluence/display/STUFFWEB/Home
>
> **
> Martin
>
> 2009/7/20 Sam Stainsby <sa...@sustainablesoftware.com.au>:
> > 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 <sa...@sustainablesoftware.com.au>:
> >>> 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-unsubscribe@wicket.apache.org For
> >>> additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>>
> >> --------------------------------------------------------------------- To
> >> unsubscribe, e-mail: users-unsubscribe@wicket.apache.org For additional
> >> commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: best or common practice for application plug-ins
Posted by Sam Stainsby <sa...@sustainablesoftware.com.au>.
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 <sa...@sustainablesoftware.com.au>:
>> 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 <sa...@sustainablesoftware.com.au>:
>>>> 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-unsubscribe@wicket.apache.org For
>>>> additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org For
>>> additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org For
>> additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: users-unsubscribe@wicket.apache.org For additional
> commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: best or common practice for application plug-ins
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
Different form wicket-stuff?
http://wicketstuff.org/confluence/display/STUFFWEB/Home
**
Martin
2009/7/20 Sam Stainsby <sa...@sustainablesoftware.com.au>:
> 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 <sa...@sustainablesoftware.com.au>:
>>> 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-unsubscribe@wicket.apache.org For
>>> additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>> --------------------------------------------------------------------- To
>> unsubscribe, e-mail: users-unsubscribe@wicket.apache.org For additional
>> commands, e-mail: users-help@wicket.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: best or common practice for application plug-ins
Posted by Sam Stainsby <sa...@sustainablesoftware.com.au>.
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 <sa...@sustainablesoftware.com.au>:
>> 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-unsubscribe@wicket.apache.org For
>> additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: users-unsubscribe@wicket.apache.org For additional
> commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: best or common practice for application plug-ins
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
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 <sa...@sustainablesoftware.com.au>:
> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: best or common practice for application plug-ins
Posted by Sam Stainsby <sa...@sustainablesoftware.com.au>.
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-unsubscribe@wicket.apache.org For additional
> commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: best or common practice for application plug-ins
Posted by Adrian Wiesmann <aw...@somap.org>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org