Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=HSr0fm2clxg1dWUckBJjEyJotuxXq7TSq7V1tj/5XsCwZb5nQo5mDDx8SvQCrnJivBJ8Q+LqV1qNDj/XO+cMAKGfxQHPX0im+xgMOCuTZATfBmcUKLbwvp2ye/5DS8zJ+bmMz6VjLKR7To6vlQVWaxcrSRzo0l87G44kl6IuqHk=
  ;
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <A4C79F3E-6405-4362-97B1-DC9D7ED38629@gmail.com>
References: <9BFFBBCA-920D-4123-9A85-B7130F1E308D@yahoo.com>
 <74e15baa0712121539o3890fb6cy5230ffe8deea486e@mail.gmail.com>
 <83761E4B-FA0A-4EE7-A317-54665D64E776@yahoo.com>
 <74e15baa0712131021t47858f6djb95528e96749d230@mail.gmail.com>
 <A4C79F3E-6405-4362-97B1-DC9D7ED38629@gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F5CF2AED-79C0-4AB6-A619-ADED528D6AE7@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: Do Plugins need Prerequisites?
Date: Thu, 13 Dec 2007 15:09:14 -0800
To: dev@geronimo.apache.org

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 <david_jencks@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 <david_jencks@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
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>