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
