geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: Do Plugins need Prerequisites?
Date Thu, 13 Dec 2007 23:16:11 GMT
I will just conclude by saying it's not my feeling that we currently
have the best possible solution -- I just want to make sure things
don't move backward.  It would be possible to provide special handling
for Tomcat/Jetty at the level of JVM versions and take that issue out
of the picture.  It would be possible to have the logic that inspects
plugin metadata draw out unavailable dependencies for particular
attention.  ("Plugin X.  Status: cannot be installed without first
installing: 1) Configuration 'Oracle JDBC Driver' 2) Configuration 'DB
Pool for Plugin X'  Note: This may require manual installation and/or
configuration.")  Then maybe the prerequisites as such could go away.

But for example, I'm not sure if the logic that currently lists plugin
status will actually query the plugin repositories for dependencies
when rendering the status -- it might make that operation slower and
more annoying if it had to calculate what was available in order to
tell you what the "prerequisites" were.  That was supposed to be
easier when the whole world switched over to Archiva with fancy
indexing for the Maven repositories, but as far as I know that hasn't
happened yet.  :)


P.S. I believe you can currently arrange for a web server to be a
regular dependency instead of a prerequisite if you really want to --
you just have to figure out what to do when a second one is to be
installed by accident.

On Dec 13, 2007 2:38 PM, Paul McMahan <> wrote:
> Thanks Aaron for the thorough explanation.  I agree that the prereq
> relationship provides useful information and functionality beyond
> what the dependency relationship provides.  The plugins portlet in
> the admin console will currently inspect the prerequisites for the
> plugins listed in a remote catalog and will designate any plugins
> that have missing prerequisites as being not compatible with the
> server.  (Incompatible server or JVM versions are handled the same
> way.)  I think that designation is useful as it prompts the user to
> inspect the plugin's properties to get further details on what steps
> they might need to take to prepare or reconfigure their server --
> e.g. manually create a db pool, replace a conflicting component,
> etc.  I also think the prereq relationship is especially useful
> because webapp plugins are not compatible between tomcat and jetty
> assemblies, and like you say we don't want the plugin installer to
> automatically install a second web container into an assembly if the
> user picks the wrong plugin.
> Best wishes,
> Paul
> On Dec 13, 2007, at 1:21 PM, Aaron Mulder wrote:
> > On Dec 12, 2007 8:27 PM, David Jencks <> wrote:
> >> I must be missing something... how does the prerequisite system work
> >> better than dependencies here?  I'm not 100% sure of what currently
> >> happens when you try to install a plugin that has an unavailable
> >> dependency, but it certainly won't start even if its downloaded.
> >
> > Originally I think, the plugin would refuse to download and install.
> > The idea was that if something was a dependency it was more or less
> > guaranteed to be available, whereas a prerequisite pretty much always
> > required manual intervention (except for Jetty/Tomcat, which I mention
> > below).
> >
> > Dependencies and prerequisites could be combined, but my concern would
> > be how to clearly convey the directions for what the user needs to do
> > to get get plugin to work.  Like, if a plugin has 20 dependencies, and
> > one of them is something that the user has to manually deal with, how
> > do you emphasize to the user that in order to install the plugin, they
> > need to take that action?  If it's just in the dependency
> > "description", it seems like it would be lost among the 20
> > dependencies...  Unless we have some logic to detect which
> > dependencies can't be installed and emphasize those somehow.  I really
> > want to avoid the case where you identify the perfect plugin, install
> > it, and then confusingly, it's not running afterward.  You go to start
> > it, and it won't start, perhaps with a confusing error ("Dependency
> > foo wasn't installed?  Why not?  I thought this was supposed to be
> > automatic?  Crappy product!")  Again, so long as the user experience
> > is good, the plumbing doesn't matter so much.
> >
> > I guess the other usage was to ensure you didn't install both Jetty
> > and Tomcat in the same environment.  As in, you have the Tomcat stack,
> > and you accidentally click a web app built against Jetty, we don't
> > want it to automatically download and install Jetty (because, among
> > other things, if the default ports conflict the server won't start,
> > and web app deployments suddenly get a lot more confusing if the
> > "wrong" engine handles it).  Also, it would be really unexpected that
> > you click a web app plugin link, and suddenly it's installing a new
> > Web server.  So I'm not sure we want Jetty or Tomcat to appear as
> > normal dependencies of a web app. Strike that, I'm pretty sure we
> > don't want it, unless web app deployments change to be
> > web-container-neutral so it would only install a Web container if one
> > wasn't already there.
> >
> > Thanks,
> >        Aaron
> >
> >>> On Dec 12, 2007 6:33 PM, David Jencks <>
> >>> wrote:
> >>>> Aaron included a prerequisite feature for plugin metadata which is
> >>>> supposed to prevent you from installing a plugin if some
> >>>> prerequisite
> >>>> plugin is missing.  After some thought I can't think of a reason
> >>>> this
> >>>> would possibly be useful or more useful than a dependency, where
> >>>> the
> >>>> needed plugin is simply installed for you.
> >>>>
> >>>> I disabled this functionality but forgot to discuss this point, but
> >>>> now that Jarek has re-enabled it I think it's time for a
> >>>> discussion.
> >>>>
> >>>> I do think there is some use for some feature that e.g. prevents
> >>>> installing jetty if tomcat is present, but I don't think
> >>>> prerequisites implement that in any useful way.
> >>>>
> >>>> comments?
> >>>> thanks
> >>>> david jencks
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>

View raw message