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

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

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
>