geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <>
Subject Re: Why is GERONIMO_HOME not passed into the server?
Date Sun, 28 Jan 2007 11:48:25 GMT
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
> david jencks

View raw message