You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2007/12/13 00:33:05 UTC
Do Plugins need Prerequisites?
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
Re: Do Plugins need Prerequisites?
Posted by David Jencks <da...@yahoo.com>.
OK, so I agree the prereq feature is useful so I'll stop trying to
remove it :-)
However I ***really*** don't think it should be used for assuring the
correct web server. I want to being install a plugin such as the web
console and have it install the web server as a dependency. To me
this is an obvious use of the dependency facility.
I think we need some other kind of constraint such as "only one
plugin of type X" to handle the "wrong web server" problem. I don't
think its a big enough immediate problem that we need it for 2.1.
thanks
david jencks
On Dec 13, 2007, at 11:38 AM, 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 <da...@yahoo.com> 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 <da...@yahoo.com>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
Re: Do Plugins need Prerequisites?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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. :)
Thanks,
Aaron
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 <pa...@gmail.com> 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 <da...@yahoo.com> 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 <da...@yahoo.com>
> >>> 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
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
>
>
>
Re: Do Plugins need Prerequisites?
Posted by Paul McMahan <pa...@gmail.com>.
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 <da...@yahoo.com> 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 <da...@yahoo.com>
>>> 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
>>>>
>>>>
>>>>
>>
>>
>>
Re: Do Plugins need Prerequisites?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Dec 12, 2007 8:27 PM, David Jencks <da...@yahoo.com> 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 <da...@yahoo.com> 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
> >>
> >>
> >>
>
>
>
Re: Do Plugins need Prerequisites?
Posted by David Jencks <da...@yahoo.com>.
On Dec 12, 2007, at 3:39 PM, Aaron Mulder wrote:
> It was mainly for things like "this plugin needs you to hook it up to
> a database" where we can't reasonably provide a database -- you have
> to set up a DB instance and a connection pool with the right name and
> then the plugin will install. Or it could be a dependency on a
> proprietary driver or product where we can't distribute that product
> as a plugin dependency. I can think of a number of cases where there
> wouldn't be a way for us to provide a one-size-fits-all dependency.
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.
thanks
david jencks
>
> Thanks,
> Aaron
>
> On Dec 12, 2007 6:33 PM, David Jencks <da...@yahoo.com> 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
>>
>>
>>
Re: Do Plugins need Prerequisites?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
It was mainly for things like "this plugin needs you to hook it up to
a database" where we can't reasonably provide a database -- you have
to set up a DB instance and a connection pool with the right name and
then the plugin will install. Or it could be a dependency on a
proprietary driver or product where we can't distribute that product
as a plugin dependency. I can think of a number of cases where there
wouldn't be a way for us to provide a one-size-fits-all dependency.
Thanks,
Aaron
On Dec 12, 2007 6:33 PM, David Jencks <da...@yahoo.com> 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
>
>
>