Re: Fw: Joe Walnes feedback on "ComponentHaus now does full dependency trees"

There are some interesting ideas here.  Couldn't the RECOMMENDS 
directive be eliminated in favor of just using DEPENDS?  And I think it 
would make sense to replace SUGGESTS with SUPPORTS, while adding some 
kind of priority to supported libraries. One could even allow the user 
to specify his own library preferences.

-- System config
* DOM
  * PREFER Xerces 1.1
  * PREFER Crimson 1.4
  * PREFER Java 1.4
* Servlet Container 2.3
  * PREFER Jetty 4.2
  * PREFER Tomcat 4.1

-- Component Descriptor
* XStream 0.4
  * DEPENDS XMLParser
     * SUPPORTS XPP3 "Higher performance than DOM implementations"
     * SUPPORTS DOM

Another idea might be to include some kind of PROVIDES directive like in 
Gentoo packages.  The idea here is that components would not need to be 
aware of all implementations of their dependencies.  Commercial XML 
Parsers and servlet containers come to mind.

Some complications that might arise are
- when to silently use what you've got and when to ask the user for input
- how to handle version ranges
- I have two levels of PROVIDES hierarchy above: XMLParser -> DOM -> 
Xerces.  How far can that go?

Lots of complexity in these ideas, but I'd like to see guided 
installation like Joe describes.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

Mike Hogan wrote:

>----- Original Message -----
>From: "Joe Walnes" <joe-xGvoirzvwgBWk0Htik3J/[email protected]>
>To: <[email protected]>
>Sent: Monday, January 19, 2004 12:04 PM
>Subject: [personal] Re: ComponentHaus now does full dependency trees
>
>
>  
>
>>Mike,
>>
>>Very nice!
>>
>>What do you think about specifying component dependency metadata inside
>>the archive? It is the role of whoever packages up the component to
>>specify this information.
>>
>>The Debian package management system has a very effective way of
>>determining how it relates to other packages using the following types
>>of relations:
>>- DEPENDS (must be present)
>>- RECOMMENDS (would always make sense to have this package)
>>- SUGGESTS (typically enhances the use of a package)
>>- REPLACES (is used instead of another package)
>>- PROVIDED-BY (provides a specific function).
>>See http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html#s-depends for
>>more details.
>>
>>An example:
>>
>>* MyWebApp
>>  * DEPENDS: Java 1.3
>>  * DEPENDS: Servlet container 2.3
>>    * PROVIDED-BY: Jetty
>>      * DEPENDS: Jasper
>>      * DEPENDS: Servlet API 2.3
>>    * PROVIDED-BY: Tomcat
>>      * DEPENDS: Jasper
>>      * DEPENDS: Servlet API 2.3
>>  * DEPENDS: Commons Logging 1.0
>>    * SUGGESTS: Log4J 1.3
>>  * DEPENDS: XStream 0.4
>>    * RECOMMENDS: DOM
>>      * PROVIDED-BY: Xerces 1.1
>>      * PROVIDED-BY: Crimson 1.0
>>      * PROVIDED-BY: Java 1.4
>>    * SUGGESTS: XPP 3.0
>>
>>A tree like this is a lot more useful to a developer as it allows them
>>to make decisions about what they really need. Contrast this to the tree
>>on ComponentHaus, which suggests that JavaMail and JMS are needed for
>>SocketFactory. Decisions such as "Shall I use Jetty or Tomcat as the
>>Servlet Container?" and "Shall I enhance XStream's performance by using
>>XPP?" can be left to the developer, while an automated system can make
>>the mundane decisions.
>>
>>Combined with an automated package management tool (such as APT, URPMI
>>or YUM in the Linux world) installation of components can be a breeze.
>>
>>For example, to install MyWebApp, the tool can make automate most things
>>and leave the important decisions to the user.
>>
>>- Install MyWebApp
>>- DEPENDS Java 1.3 : Java 1.4 already installed
>>- DEPENDS Servlet Container : Jetty already installed
>>- DEPENDS Commons Logging : Not intalled
>>- SUGGESTS Log4J 1.3 : Log4J 1.2 already installed - upgrade needed
>>- DEPENDS XStream 0.4 : Not installed
>>- RECOMMENDS DOM : Java 1.4 already installed
>>- SUGGESTS XPP3 : Not installed
>>
>>Prompt to user:
>>* Do you want to enhance logging by upgrading Log4J from 1.3 to 1.4?
>>* Do you want to enhance XStream performance by installing XPP3?
>>
>>Having recently become hooked on Debian's package management system, I
>>wouldn't want to work any other way :)
>>
>>Anyhoo, hope that provided some useful input.
>>
>>-joe
>>
>>
>>Mike Hogan wrote:
>>
>>    
>>
>>>Hi Joe,
>>>
>>>Take a look at this:
>>>http://64.4.141.60/componenthaus/componentDetails.action?id=1 .  Click
>>>      
>>>
>on
>  
>
>>>the + icon for the dependencies - it will expand entire dependency
>>>tree for
>>>spice-netserve!
>>>
>>>This is computed when a component is submitted by analyzing maven POMs
>>>      
>>>
>in
>  
>
>>>various maven repos.  Other strategies are possible, but I went with
>>>      
>>>
>this
>  
>
>>>for now just to keep up the momentum.  Next steps, probably, is to
>>>provide
>>>all these dependencies when you download the component, and to show
>>>separation between interface and implementation.
>>>
>>>What ya reckon?
>>>
>>>Cheers,
>>>Mike.
>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>_______________________________________________
>jcontainer-interest mailing list
>jcontainer-interest-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
>http://lists.codehaus.org/mailman/listinfo/jcontainer-interest
>  
>