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

Mike, Ryan,

Got an idea on related to this topic:

Maven's POM presently represents dependencies however these dependencies
are a flattened list of a dependency tree.  Basically something is a 
dependency or it is not.  There are no provisions at this point for 
qualifying runtime dependencies resulting from the dependencies of 
dependencies and so on.

If it is possible to extend the POM or use different versions of the POM
with maven in a pluggable fashion we could qualify the nature of a 
dependency using attributes like 'runtime', 'buildtime' and perhaps 
'optional'.  I see nothing in the way of adding the set of dependency 
qualifiers discussed below by Ryan.  Essentially what I'm getting at is
dependency information can be directly access from the POM.

(Oh yeah yet another means to extend the POM may be to introduce 
application specific referrals to other XML documents etc. But the 
maven folks would know this better than I.)

The only limitation however is that efficient dynamic queries for 
dep info may require a database of sorts rather than just using
XML for the sake of performance.  It is conceivable that for a tool
just to document or generate the proper dependency tree the XML of
the POMs in question can be read and searched.  The efficiency of the
operation would impose the need for query or search capabilities found
in databases.

I have no particular intention for mentioning this other than its
an interesting thought and I would like to hear your opinions on the 
idea and whether or not you see value in it.  I always come off 
looking as the LDAP dude but I see this as a directory for components
which need not be LDAP based by the way.  Please don't think I'm trying
to push yet another LDAP solution here.  But the key is to have 
dependency qualifier attributes and the ability to dynamically query
them.

I think I may have discussed this at one point or another with Jason
but my long term memory is bad :-).  It would be good to have his 
thoughts about it as well.

Alex

> 
> From: Ryan Hoegg <[email protected]>
> Date: 2004/01/21 Wed PM 01:00:57 EST
> To: jcontainer-interest-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
> Subject: 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
> >  
> >
> 
> _______________________________________________
> jcontainer-interest mailing list
> jcontainer-interest-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
> http://lists.codehaus.org/mailman/listinfo/jcontainer-interest
>