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
