The current Gump assumes that all of these projects are defined in the
workspace. You are just moving that responsibility to the <depend/> tag
itself, which would not seem to be much of a problem, besides the coding
part ;-)
Jeff suggestion of an uber-workspace would seem to be easier to
implement. This may indeed be better because then Gump could have a
workspace that defines all projects in the repository, and then someone
defines only the projects that they want built, and not have to worry
about the dependencies, which Sam has already taken care of ;-)
Of course, declaring just xml-cocoon2 builds about everything on the
planet anyways ;-)
Scott
Morrison, John wrote:
> <grin/> I don't think you've not been paying attention, but can't a relative
> location mapping be assumed? ATM the workspace supplies 'trees' but I think
> these should be elsewhere for defaults and only modified if you're not using
> the default, anon, access...?
>
>
>> -----Original Message-----
>> From: Jeff Martin [mailto:[EMAIL PROTECTED]]
>> Sent: 11 April 2001 3:41 pm
>> To: '[EMAIL PROTECTED]'
>> Subject: RE: [GUMP] Changes ahead...
>>
>>
>> Yup, but the workspace def define where to find the project defs for
>> jakarta-ant, xml-xerces, xml-xalan2 etc.
>>
>> Or have I not been paying attention again ;o)
>>
>>
>>> -----Original Message-----
>>> From: Morrison, John [mailto:[EMAIL PROTECTED]]
>>> Sent: 11 April 2001 15:44
>>> To: '[EMAIL PROTECTED]'
>>> Subject: RE: [GUMP] Changes ahead...
>>>
>>>
>>> Doesn't the xml-cocoon2.xml file define it's dependencies...
>>>
>>> <project name="xml-cocoon2">
>>> <depend project="jakarta-ant"/>
>>
> <snip/>
>
>>> <depend project="bsf"/>
>>> </project>
>>>
>>> ?
>>>
>>>
>>>> -----Original Message-----
>>>> From: Jeff Martin [mailto:[EMAIL PROTECTED]]
>>>> Sent: 11 April 2001 3:32 pm
>>>> To: '[EMAIL PROTECTED]'
>>>> Subject: RE: [GUMP] Changes ahead...
>>>>
>>>>
>>>> Seems like a nice idea but the implementation may prove a
>>>> little problematic
>>>> as you would have to still have a definition of the dependencies.
>>>>
>>>> At the moment the workspace is used to link the dependency
>>>> definitions to
>>>> the actually projects definitions. This would still have to
>>>
>>> take place
>>>
>>>> somewhere. So either we move the location of the project
>>>> definitions which a
>>>> project is dependant on into the project definition, which
>>>> kinda defeats the
>>>> object of separating the workspace from the projects, or
>>>
>> we have two
>>
>>>> workspace definitions, one which describes the world (i.e.
>>>> the links between
>>>> project names and project definitions) and then a second
>>>> workspace def which
>>>> defines only what is needed for this run.
>>>>
>>>> Does that make sense?
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: John Morrison [mailto:[EMAIL PROTECTED]]
>>>>> Sent: 10 April 2001 13:25
>>>>> To: [EMAIL PROTECTED]
>>>>> Subject: RE: [GUMP] Changes ahead...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Sam Ruby [mailto:[EMAIL PROTECTED]]
>>>>>>
>>>>>> Would something like the following suit your needs?
>>>>>>
>>>>>> build -r xml-cocoon2
>>>>>
>>>>> This would be OK (and possibly easier than what's below) but
>>>>> Scott figured
>>>>> out what I intended. Excellent example of telepathy in
>>>>
>>>> action! *GRIN*
>>>>
>>>>>> -----Original Message-----
>>>>>> From: Scott Sanders [mailto:[EMAIL PROTECTED]]
>>>>>
>>>>>> I think what John is trying to say is that his workspace
>>>>>> looks like this:
>>>>>>
>>>>>> <workspace basedir="foo" cvsdir="bar">
>>>>>> <project name="xml-cocoon2"/>
>>>>>> </workspace>
>>>>>>
>>>>>> and then when Gump runs, it sees all the <depend/>s and
>>>>>> can still resolve them.
>>>>>
>>>>> Yes! Just right! I realise that this is prob quite some time
>>>>> (and effort)
>>>>> away, but most people will just want to reference the
>>>>> projects they are
>>>>> interested in and expect the dependencies to take care of
>>>>> themselves. What
>>>>> do you think guys? is it possible/reasonable/desirable?
>>>>>
>>>>> John.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
