Re: [jetty-dev] Jetty Plugin Functionality / Getting rid of Jetty Highti

[Jan Bartel <janb@xxxxxxxxxxx>]

Can we clarify what is the lifecycle of a plugin and how it relates to
a jetty distro?

I assumed that plugins would NOT be distributed with the distro, but rather that
they would be fetched as needed from a remote repo:

java -jar start.jar --fetch-plugin foo

Users would have to be able to see what plugins are available to get:

java -jar start.jar --list-plugins

Users would want to be able to update plugins (this will require some thought
as to how to update possibly user-modified xml files, and possibly difficulties
with determining compatibility):

java -jar start.jar --update-plugin foo
or
java -jar start.jar --update-plugins

Then once they have been downloaded, then its an issue of how do they get
incorporated into the jetty installation.

Having a separate /plugins directory is good for encapsulation, but not ideal
for users trying to work out where to look for config and libs (ie is it in
$JETTY_HOME/etc, $JETTY-HOME/lib (or subdir thereof), in start.ini
or in $JETTY_HOME/plugins/foo/etc, $JETTY_HOME/plugins/foo/lib etc).

I think it is important that we recognize the central importance of start.ini.
We have this mechanism which determines what jars go on the classpath
and which xml files take effect, so I think it also has to be the central place
where plugins are put onto the classpath.

At some point, users may want to remove a plugin completely:

java -jar start.jar --remove-plugin foo

Or users may want to temporarily prevent a plugin from being used:

java -jar start.jar --disable-plugin foo (or maybe edit start.ini?)

And then start using it again:

java -jar start.jar --enable-plugin foo (or maybe just edit start.ini?)

And our start.jar --dry-run should also list which plugins are enabled.

Jan


On 5 November 2011 11:35, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> 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
>