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

[Eirik Bjørsnøs <eirbjo@xxxxxxxxx>]

Simple is hard :-)

One use case to consider is that some people (like us), create Jetty
"distros" ourselves. In our case, we grab the jetty distro, unpack it,
add some configuration and libraries, and then repack it. This
functionality is packaged into a reusable Maven plugin which takes a
war as input and outputs a complete RPM package with operations
scripts, standardized logging setup etc.

In this case, tooling with start.jar isn't very useful, but a clean
and simple overlay model is.

So for adding configuration to etc/ and jars to lib/<module>, an
overlay model works well. (We don't care much if it is lib/module or
module/lib).

Enabling modules once they're added is not as easy, because we have to
modify start.ini. So every time that file changes upstream, we have to
merge our changes. (Not that this happens very much, but anyway, we
have to modify it from the vanilla distribution).

We would prefer a solution where we could add modules (jars,
configuration) AND enable them using just overlays.

Could the start.ini be replaced / augmented by an options.d/
directory? Here we could add a file for each service we wanted to
enable. Either the file could just be an empty file, a signal that the
module with the same name should be enabled. Or the file could have
the lines that would otherwise be added to start.ini. Then the OPTIONS
value would need to be additive.

start.ini is currently a single point of configuration, which makes
life just a little bit harder for integrators like us.

Thoughts?

Eirik.


On Fri, Nov 11, 2011 at 5:30 AM, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
>
> All,
>
> I've been mulling this over for a few days and I still think that we should
> stick with our existing disk layout and not add a new plugins structure (at
> least not for libs and configs).
>
> I see no need for creating $JETTY_HOME/plugins/foobar/lib when we already
> well support $JETTY_HOME/lib/foobar.   The current distro already has lib
> modules for
>
>   annotations
>   jndi
>   jsp
>   jta
>   monitor
>   policy
>
> The hightide distro add the extra lib modules
>
>  jdbc,
>  setuid,
>  spring
>  jta/atomikos
>
> This modular system is well supported by start.jar.  For example if you
> mkdir libs/wibble, then wibble is listed as an available OPTION when you do
> "java -jar start.jar --help"
>
> Similarly, --help lists the available configurations in etc and then lists
> the defaults for both OPTIONS and configs listed in start.ini
>
> While this mechanism is perhaps not perfect, i do not think we are able to
> discard it as it has been established for a while.  So any module system is
> going to either have to extend on this existing mechanism or run in parallel
> to it.    I think having parallel module systems will just be totally
> confusing, especially if one of the module systems ends up being a module
> inside the other module system.
>
> My strong preference is to improve the capabilities of the existing module
> system -  specifically add the ability to download new modules.
>
> For the module download feature, I think the maven repository is the obvious
> place to download modules from, which gives us the benefit of being able to
> use the existing foobar-VERSION-config.jar artefacts to download and apply
> configuration.    Ie we already have modules, we don't need to invent new
> module packaging, we just need a way to download and unpack the modules that
> we already have.
>
> I do understand the elegance of having all the files related to a module
> under a plugin/foobar directory, but I just do not see that as a good enough
> reason to throw away the existing modularisation and to duplicate that
> effort.
>
> cheers
>
>
>
> cheers
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
>