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'd like to keep this as simple as possible and have plugins separated from anything else. This makes it easier for the enduser to differentiate between core jetty functionality hosted at eclipse and additional plugins. On top it has all the benefits already discussed like easy remove/install, clear separation, etc.
I like the idea Joakim brought on the table. But without the symlinks as used at apache. It can be even simpler. A single directory containing all plugins as described in my initial email about that topic: 

$JETTY_HOME/plugins

A plugin is installed via:
java -jar start.jar -install-plugin <pluginname>
Everything belonging to that plugin is put into $JETTY_HOME/plugins/<pluginname> and the plugin is enabled by default. As plugins should be as easy installed/removed as a single command execution, we could even think about having plugins which are installed are always enabled. So there's no way to disable a plugin, but to remove it. The user of course has to take care to backup customizations (config changes, etc.) of plugins.
Having that I'm not even sure that we need an additional config file in $JETTY_HOME/etc/ as jetty can just scan the plugins directory for plugins and enable everything installed there by default during startup.
A variant in between might be to go the symlink route if we want to keep the ability to disable plugins without removing them, having the benefit of customized configs, etc. will be kept.
$JETTY_HOME/plugins/enabled_plugins could contain the symlinks to all plugins which are enabled. That way we can still skip the additional config file, but plugins can be disabled. However this comes at the cost of a little additional complexity. Users have to understand that there needs to be a symlink, etc.
I think I personally prefer the most simple approach and have the user be responsible of keeping plugin customizations at a safe place when removing plugins. The normal use case is that a user needs a standard jetty installation. Whenever he needs a plugin he installs it with a single command. The plugin is then enabled by default. He should only need to remove the plugin if he doesn't need it anymore and in that case he doesn't need his customizations anymore. 

On 11/5/11 1:35 AM, Jesse McConnell wrote:

If that is the case greg then we already have this the core of this
functionality in place, its what we use for building the distribution
right now, see the jetty-*-*-config.jar artifacts...they get unpacked
over the distribution, we would just have to rejigger it into a build
so it can drop in the files under the lib dir as well...

I don't see that as getting us very far in terms of this being a
friendly system though, its not really convention rich

joakim had mentioned another idea on irc while we were discussing this
that I liked as well that was related to this, just modeling this on
how apache httpd itself works, having an available-modules directory
and then symbolically linking in the ones we wanted to enable, same
basic concept

I rather like that idea as jetty-jndi and jetty-jmx could work that
way as well...just as modules that you either copy or link in and they
get picked up, I just can't help but think if we keep following the
overlay model its going to get more out of hand then it is now, a mess
of configuration files that mostly are not used.

Also, if we do this right and convention based, I don't see the
start.ini file needing to be changed at all, except to make sure that
jetty-modules.xml is in there, the OPTIONS line can be constructed by
looking in the modules directory for each plugin present under the
'lib' directory for system libraries, just make that a convention

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Fri, Nov 4, 2011 at 17:56, Greg Wilkins<gregw@xxxxxxxxxxx>  wrote:

I understand the benefits of having a module contained in a single
directory, but I'm not sure that the benefits are worth the extra
complication.

The start.jar mechanism (while simple enough) already causes some
confusion because lib/foo/foo.jar  is not automatically put onto the
classpath, unless the OPTIONS=foo is included.     Having yet another
location to mix in modules, is only going to increase that confusion.

I'd really like the module utility to be about how a jetty is
assembled and not about how jetty runs.

I also don't see why remove is any harder with using the lib
directory.   Essentially the tool will have to do

   rm -fr lib/foo etc/jetty-foo.xml

instead of

  rm -fr plugins/foo

In either case, the tool doing the remove will need to update
start.ini to reflect the change.   I'm also kind of partial to having
meta data about all the files of a module, including a checksum - so
if you go to remove a module and the jetty-foo.xml file has been
modified, then you will get a warning about that and have to confirm
the deletion.


cheers
_______________________________________________
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


--
thomas becker
tbecker@xxxxxxxxxxx

http://webtide.com / http://intalio.com
(the folks behind jetty and cometd)

Back to the top