geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Why is GERONIMO_HOME not passed into the server?
Date Sun, 28 Jan 2007 16:56:41 GMT

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
>>
>


Mime
View raw message