Re: Do Plugins need Prerequisites?

[David Jencks]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>  
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