On 28/01/2007, at 7:26 PM, David Jencks wrote:
>
> On Jan 27, 2007, at 6:11 PM, Matt Hogstrom wrote:
>
>>
>> On Jan 27, 2007, at 5:38 PM, Jason Dillon wrote:
>>
>>> I think in order to allow multiple instances to work off of the
>>> same installation effectively we need to have a tiered repository
>>> support, so that each instance could include a shared read-only
>>> repository (the system repository), and then a read-write
>>> repository (instance repository), where artifact resolution would
>>> first check the instance repo, then the system repo.
>>>
>>> If we do want to start supporting this, I suggest we also revisit
>>> the basic server's file structure, as we will need to insert a
>>> hierarchy for the instance data.
>>>
>>> --jason
>>
>>
>> IWhat if we started somthing in var like:
>>
>> ./var/servers/server.n
>>
>> The server.n sould be some arbitrary name that users would
>> identify the names of the server instance. We would look in the
>> instance tree first and if something wasn't found we'd look in the
>> main tree. Is that what you meant?
>>
>>
> IIRC we discussed this fairly extensively a long time ago and
> concluded that what made the most sense was to keep the var
> directory structure the same as it is now but allow relocating it,
> so that's what's currently implemented. So, the expected directory
> structure would be
>
> <geronimo_base>/servers/server.n/var
I also remember some discussions on the best approach to share a
Geronimo installation and the above directory structure was preferred
to the other solutions.
>
> I don't see any value in having a hierarchy here: I think that each
> item should be present in exactly one place. For instance if you
> have identical artifacts in 2 repos I'd regard that as an error,
> although since they are identical it wouldn't matter which one you
> picked. Could you provide an example of something your proposed
> search strategy would be useful for?
>
i think that this may be useful in some very specific scenario. For
instance, a developer may want to upgrade some dependencies used by a
module his team is working on in a sandbox. If he simply drops a
newer version in the shared repository, then all the developers will
see the newer version upon server restart. This can be avoided by
updating the artifact_aliases property file of each developer;
however, this is less transparent than a solution based on an
hierarchical dependency resolution mechanism.
I am not sure that the above example is worth to support; at least,
it is less important than a plugin adding a repository into var.
Thanks,
Gianny
> thanks
> david jencks
>
|