I delete my local m2 repo at least once a week (usually when switching
between 2.1.4 and 2.2 builds to ensure truly clean builds.)
Also, the automated 2.0/2.1/trunk builds that run several times a day
always use a clean m2 repo.
Seems that we would be increasing the load on svn.apache.org just to
make it easier for a few people who want to use Nexus....
-Donald
David Jencks wrote:
On Dec 2, 2008, at 5:41 AM, Donald Woods wrote:
David Jencks wrote:
In order to get the build to work with my use of nexus I've added the
trunk svn repo (server/trunk/repository) to the nexus repositories.
This makes me wonder if we should just set up a single repo in svn
and put all our private builds there rather than having
branch-specific repos. Would this result in more or less or the same
load on the svn server?
Seems that moving the artifacts out into a unique svn branch (from
geronimo/server/trunk/repository to geronimo/private/repo) would
increase the load, as now every server build would be hitting the svn
repo for artifacts (instead of just the /samples or /plugins builds.)
I don't understand your reasoning here. Right now anyone working with
any source version of geronimo such as trunk is going to check out the
artifacts they need whether or not they have other copies on their local
system and every time they do svn up they will be hitting the svn repo.
If they are in one svn location then maven will fetch them once per
machine no matter how many branches and copies are checked out. I don't
know which results in more svn server load, but I can imagine that
either choice is less load.
I may not have made it clear that if you use nexus you can't build
geronimo at all unless you tell nexus where to get the artifacts that
are in server/trunk/repository. I first tried listing my local checkout
as a file system repo but couldn't get that to work: using the svn repo
did work.
I also wonder if our policy of patching apache projects and coming up
with our own psuedo releases is really the best idea or if we should
just copy their code over in svn and build it more directly.
I could go either way on this. I would like to see us at least
check-in a tar/zip of the source for the patched artifacts into a
branch, to make it easier to reproduce patched builds if needed (and
so end users can rebuild everything if needed or used the patched
source in a debugger.)
I guess scenarios like this are strong arguments for distributed version
control systems like svk and git.
I also discovered a couple of weeks back that the lack of poms in
this repo was causing significant build delays while maven was
looking everywhere it could think of for them so I added them when I
could easily find them in the artifacts. I think we should add them
for the other artifacts as well.
Agree.
thanks
david jencks
thanks
david jencks
