You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by "Adam R. B. Jack" <aj...@trysybase.com> on 2003/11/21 20:24:53 UTC

Cascading Gumps ( was Re: Distributed Gumps )

Ok, adding SVN (repository with type='svn' as opposed to type='cvs') made me
realize we could add a repository with type='jars'. Such a repository would
be a structured jars repository (e.g. http://gump.dotnot.org/repository)
perhaps produced by an upstream Gump.

The module descript could have a <jars element, just like we have <cvs and
<svn today, and could give the information needed in order to download the
[latest] jars from that repository. Once downloaded a module could be deamed
'packaged' if all it's projects outputs were then found on the disk.

Having this approach seems to fit quite nicely with what exists inside Gump
today, and seems easy to code. Bascially it does restrict each module to
'coming from a known repository' (not any group of repositories upstream)
but that is livable, maybe better. It does meant the workspace/module
metadata needs to be modified (kinda like with packages today) but I think
that a few trailing entries (like next), like we do for packages, are not
too painful:

    <module name='abc' jars='repository1'>

Thoughts?

regards,

Adam


Re: Cascading Gumps ( was Re: Distributed Gumps )

Posted by Nick Chalko <ni...@chalko.com>.
Excelent Idea.  I thnik this could really increase the number of 
indepent gumps.



Adam R. B. Jack wrote:

>Ok, adding SVN (repository with type='svn' as opposed to type='cvs') made me
>realize we could add a repository with type='jars'. Such a repository would
>be a structured jars repository (e.g. http://gump.dotnot.org/repository)
>perhaps produced by an upstream Gump.
>
>The module descript could have a <jars element, just like we have <cvs and
><svn today, and could give the information needed in order to download the
>[latest] jars from that repository. Once downloaded a module could be deamed
>'packaged' if all it's projects outputs were then found on the disk.
>
>Having this approach seems to fit quite nicely with what exists inside Gump
>today, and seems easy to code. Bascially it does restrict each module to
>'coming from a known repository' (not any group of repositories upstream)
>but that is livable, maybe better. It does meant the workspace/module
>metadata needs to be modified (kinda like with packages today) but I think
>that a few trailing entries (like next), like we do for packages, are not
>too painful:
>
>    <module name='abc' jars='repository1'>
>
>Thoughts?
>
>regards,
>
>Adam
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>  
>