I strongly advise to not use the system repo as a local repository. It
is very difficult to make sure it will be read only.
Maven (aether) assumes that it can write to the local repository.
Eventually you can combine it with the offline setting of maven so it
knows it does not have to access other repos and write to the local
repository.
See:
http://stackoverflow.com/questions/5238769/is-there-a-way-to-disable-the-local-maven-repository
Having said that using the system repo as local repo might be a
workaround for now if you make sure aether does not write anything in
the system repo.
I think a real solution would be to either define a the system dir as
local in the sense of "does not need to be cached" or to define the
local repository as read only.
Another solution would be to tell maven to not use a local repository.
Till now I did not find such options in maven but I will dig some more.
If aether provides the option
we need then I am pretty sure we can make it configurable in karaf too.
Btw. Why do you need to avoid writing to the local repository? Is it
because of the additional space consumption on the hard disk or do you
have a different constraint?
I agree that it is a bit ugly that karaf copies the system repo to the
local repo but it is something that can just be ignored in most settings.
Christian
Am 29.07.2014 02:01, schrieb thully:
To elaborate a bit, our application has two distinct builds - one for core
developers, and one for users. In general, we want developers to easily be
able to test updates to our core bundles (which are built using Maven). On
the other hand, we want the end-user build to always use the core bundles in
the installation directory, though we want to allow users to test add-on
bundles stored in the Maven repository. In both cases, we don't want Karaf
(or any of its components) creating additional copies of bundles or
modifying the .m2 or system repos, and the user build of our application
should run with a read-only Karaf installation directory.
Based on what I've found, it seems that the best approach for the end-user
distribution of our application is to put all our bundles in the system
repository, use that as the local repository and enable .m2/repository as an
external repository. In the developer environment, we will keep .m2 as the
local repository and deploy our bundles there.
I only see a few small issues at this point - we will be writing
resolver-status.properties files to the system repo, and we will have copies
of Karaf core bundles in both .m2 and system in the developer build. Also,
on systems with read-only Karaf installation directories, we do get warnings
about not being able to write resolver-status.properties. However, those
seem tolerable - is there anything else we should be concerned about?
--
View this message in context:
http://karaf.922171.n3.nabble.com/Disabling-local-repository-creation-on-Karaf-3-tp4034426p4034479.html
Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
