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


I'm really cautious about dependencies.

I really like convention over configuration and really don't see a using the maven repo as a repository of plugins being that bad.

Currently we already have the convention that a module is added to jetty-distribution by:

 a) unpacking the artifactId-config-version.jar  into Jetty Home - this gives all the etc/*, context/* files
 b) moving the artifactId-version.jar into a specific location inside lib/*

We could generalise this into a plugin convention by:

 0) A plugin must have a artifactId-config-version.jar.  Lists of plugins can be made by scanning a groupId for such jars
 1) adding a start.d/artifact.ini file to the -config jar, so start.ini need not be modified
 2) always move artifactId-version.jar into lib/artifactId/  so modules get their own OPTION ids
 3) adding a convention that any WAR artifact is moved to webapps, so webapps can be deployed as plugins

The issue then is how do we fetch any transitive dependencies, and should they go into lib/artifactId or lib/ext
If transitive dependencies are likely to be used by multiple modules, then they should go into lib/ext

I'm not in favour of having a complex tool on the client side that resolves the location of the transitive dependencies.  I'd much rather have a mvn plugin that fires when the plugin module is built and generates a URL list of the transitive dependencies and where they can be fetched from.


cheers









On 2 February 2012 09:35, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> wrote:
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
>
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev


Back to the top