On Jan 28, 2007, at 3:48 AM, Gianny Damour wrote:
> 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 don't think I understand what you have in mind yet. I would expect
that in a setup with multiple servers the stuff that's specific to a
particular server would be in the server-specific repo we've been
talking about. So if you want to upgrade a dependency to a newer
version you'd put the newer version in your server-specific repo
where your apps would find it but no one else's apps would. The only
scenario I can think of so far where this wouldn't work is if it's a
snapshot dependency so the old and new files have exactly the same
file name. I really think we should NOT support anything that tries
to distinguish between 2 files with the same artifact Id. If people
want to have different versions of a snapshot artifact in the server
they should all be in server-specific repos.
thanks
david jencks
> 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
>>
>
|