Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Jetty Plugin Functionality / Getting rid of Jetty Hightide release at codehaus

the only downside is the dependencies on whatever technology is used
for the reader and writer imo, either xpp3 or stax or whatever the
case may be

typically jetty is very careful in creating dependencies on other things...

worst case using modello to handle the lifting for model create and
reading/writing the plugin descriptors might speed up the development
and then we iron out a more jetty way down the road...

I only mentioned it because I have had a lot of success with it in the
past as a tool for rapidly getting a model going and refining it

jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Wed, Feb 1, 2012 at 08:40, Thomas Becker <tbecker@xxxxxxxxxxx> wrote:
> Hi all,
>
> the proof of concept (poc) work is continuing and currently I'd like to
> discuss how and where I plan to store the list of available plugins. As said
> I'm trying to keep the code modular and easy to refactor. So we neither need
> to cover every use case in the beginning nor do we have to stick to the
> solution we start with now. Until we end the proof of concept phase we're
> free to change the architecture as needed.
>
> Right now the poc uses a pseudo maven module which is downloaded from a
> maven repo at execution time. This module contains a single dependency per
> available plugin. These dependencies are the output of "java -jar
> jetty-plugins.jar --list-available-plugins". This works fine, but is kinda
> dirty as it is a misuse of maven dependencies for forming a list of plugins.
>
> I've had a nice discussion with Jesse about this topic and what we've got in
> mind right now to replace this is:
>
> - use a modello DataModel: http://modello.codehaus.org/index.html
> - generate java sources based on that model which can be used by
> jetty-plugins.jar
> - have an xml file containing the data to create the actual instances stored
> somewhere where jetty-plugins.jar can download it at runtime (maven repo,
> github, for example)
>
> This will provide an easy way to generate and maintain the underlying data
> model, the corresponding java classes and a simple xml file providing all
> information about plugins (name, available versions, license, ...) we need.
> The content xml can be stored externally or even on github. The latter will
> allow plugin contributers to add new plugins there and create a pull
> request. It'll be easily extensible in the future.
>
> In the current phase I don't want to discuss every implementation detail,
> but agree on using modello and then get something very simple working and
> then work out the details (where to store the content xml, etc.) with you.
> So I'd like to know if you have any reasonable objections against using
> modello or if you have any other suggestion about how and where to store the
> plugin list and plugin metadata. It needs to be publicly available, so
> jetty-plugin.jar can download it at runtime.
>
> Cheers,
> Thomas
>
>
>
>
> On 11/2/11 5:15 PM, Thomas Becker wrote:
>
> Hi all,
>
> as you might already know, we maintain two jetty releases at the moment. The
> core jetty is hosted at eclipse and additionally we maintain the "Jetty
> Hightide" release hosted at codehaus:
> http://docs.codehaus.org/display/JETTY/Hightide+Documentation.
> We'd like to get rid of hightide and all the maintenance work caused by it.
> To do so, we evaluate a plugin/module concept for jetty and wire up the
> remaining hightide features as plugins for eclipse jetty. In a later phase
> it can be extended to contain plugins not from hightide (e.g. cometd) and
> even plugins contributed by the community. We'd like the community to take
> part in the design decisions and discuss the setup with all interested
> developers.
>
> In the first phase we want to achieve the following milestones:
>
> - discuss and write down a directory structure for plugins
> - wire up and run a proof of concept with the hightide activemq module
> - tweak jetty-start to be able to load everything belonging to the POC
> plugin which is installed manually at this phase
>
> In the second phase:
>
> - some kind of ModuleManager to activate/deactivate plugins and
> install/remove plugins
> - use aether to fetch plugins from maven central
>
> In the third phase:
>
> - create more plugins (cometd, etc.)
>
> The first thing to think about is the directory structure for plugins. Jesse
> McConnell and I had a discussion and the following structure is what I've in
> mind after the chat with Jesse:
>
> (some standard directories are omitted for readability)
> $JETTY_HOME
>    |-bin
>    |-contexts
>    |-contexts-available
>    |-etc
>    |-lib
>    |-plugins
>    |---activemq
>    |-----context
>    |-----etc
>    |-----lib
>    |-----webapps
>    |-resources
>    |-webapps
>
> So basically everything belonging to a plugin is installed in a single
> directory: $JETTY_HOME/plugins/[pluginname] and thus can be
> installed/removed easily. It's also nicely separated from everything else.
>
> As you can see a plugin is supposed to be able to have config files,
> additional jar files and even webapps (at least in a later phase). First of
> all we need to tweak jetty-start to pickup and enable installed plugins.
> Then we need to think about something like a PluginManager responsible for
> installing/removing plugins from maven central and a config file for the
> plugin-manager "jetty-plugins.xml" enabling/disabling plugins.
>
> Plugins could be installed on the commandline using something like:
>
> java -jar start.jar -list-plugins
>
> to retrieve a list of available plugins. And:
>
> java -jar start.jar -install-plugin [pluginname]
>
> to install a plugin.
>
> I will now start with hightide activemq and fit it into the directory
> structure as shown above. However this is all open for discussion and if
> you've better ideas, like another structure/approach more, please let us
> know. I will be able to refactor at any time.
>
> Cheers,
> Thomas
>
> --
> thomas becker
> tbecker@xxxxxxxxxxx
>
> http://webtide.com / http://intalio.com
> (the folks behind jetty and cometd)
>
>
> --
> thomas becker
> tbecker@xxxxxxxxxxx
>
> http://webtide.com / http://intalio.com
> (the folks behind jetty and cometd)
>
>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>


Back to the top