I think this could become reality if we have a geronimo/repository in
svn, then have it automatically exported to our zone for access by
builds. I still don't think that accessing the svn tree directly from
maven is a good idea.
--jason
On Dec 2, 2008, at 9:08 PM, Joe Bohn wrote:
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 think there is value in having all of the required elements for a
G release in one svn branch. It keeps everything together when we
release in the tag. How would we manage the artifacts if there were
in a unique svn branch without the release process? I know we don't
exactly release these artifacts as the specified versions - but we
implicitly release them when we create the Geronimo release. Would
they ever move to a tag if they were in a unique svn?
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 the benefit of including all the code in our svn would be
that a user could easily debug the code if necessary. But I'm
nervous that the changes might be difficult to track and migrate to
newer releases without the patch (and an optional patch can be
easily ignored/forgotten). So I think I favor the process as it is
today. I think we really need to work harder to remove these
private builds.
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
