A new instance requires var, etc, and repository else it won't start up.
The documented method is a straight copy of these directories to the instance directory.

A problem with this method is if the directories being copied have already been modified from a separate run-time execution. deploy:new-instance would only copy the directories instead of generating new "default" directories. So after a person make this call, then they have to go and make modifications to these directories on the local disk to set up the instance.

If we are going to have a gogo/karaf command to do this for us, what we really need is to have the var, etc, and repository directories generated new each time deploy:new-instance is called. And still then, we need a way to configure the new instance from gogo/karaf commands as well.

Otherwise, we might as well abandon this procedure and use a different procedure that allows us to deploy an archive that contains an admin-user-modified var/etc/repository bundle.

Or I guess, deploy:new-instance could allow (optionally) a new-instance-archive to be passed in as an argument.

Russell E Glaue
added a comment - 29/Jun/11 14:26 GERONIMO-5988 duplicates this issue.
A new instance requires var, etc, and repository else it won't start up.
The documented method is a straight copy of these directories to the instance directory.
A problem with this method is if the directories being copied have already been modified from a separate run-time execution. deploy:new-instance would only copy the directories instead of generating new "default" directories. So after a person make this call, then they have to go and make modifications to these directories on the local disk to set up the instance.
If we are going to have a gogo/karaf command to do this for us, what we really need is to have the var, etc, and repository directories generated new each time deploy:new-instance is called. And still then, we need a way to configure the new instance from gogo/karaf commands as well.
Otherwise, we might as well abandon this procedure and use a different procedure that allows us to deploy an archive that contains an admin-user-modified var/etc/repository bundle.
Or I guess, deploy:new-instance could allow (optionally) a new-instance-archive to be passed in as an argument.

+ //the repository folder is needed for local deployments, defined in etc/org.ops4j.pax.url.mvn.cfg
+ //we want to deploy artifacts specific to the instance to this local repository, not the shared bootstrap repository

Russell E Glaue
added a comment - 28/Mar/12 15:46 Regarding patch GERONIMO-5164 /new-instance+30.patch
I would remove the comment in the patch that reads:
+ //?? repository folder needed by karaf, but don't know why ?
If a comment is desired, I recommend this:
+ //the repository folder is needed for local deployments, defined in etc/org.ops4j.pax.url.mvn.cfg
+ //we want to deploy artifacts specific to the instance to this local repository, not the shared bootstrap repository
See also: GERONIMO-6287#comment-13240477