Kevan Miller wrote:
On Dec 1, 2008, at 8:12 PM, 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?
I'm not sure that load is going to be a big issue. There's one aspect to
hosting the repository in the same svn branch (e.g.
server/trunk/repository) -- these private builds are part of our release
voting process. To consider moving to a geronimo/repository structure,
I'd like to understand how we maintain appropriate control on these
artifacts (not saying it can't be done...).
This is the same concern that I raised in my response. I don't know how
we would control these artifacts in their current form if they are not
part of a Geronimo server release process.
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.
Not sure that it's *necessary*, but it's a good idea. Although patches
give a better idea of the intent of these private builds -- they're
patches, not forks...
Right ... and I think putting just the delta in a patch rather the
including the entire source helps to keep them patches and not forks. I
think managing the code changes could get complicated if we start to
include all of the source - even if we include the patch as well - since
it will be the source build that is validated with each release and not
the application of the patch and build. The patch would really be just
a "bolt-on" that could easily get out of sync.
At one point we discussed renaming these artifacts as geronimo artifacts
(e.g.
org/apache/geronimo/patched/jasper/6.0.18-G678601/jasper-6.0.18-G678601.jar
). Would this be a better technique for solving the issue?
I'm concerned this pushes us toward forking the code as well. Would
that require that we maintain source poms with the appropriate package
names and versions and a source svn from which to build the artifacts?
At the moment we bypass all of this by simply renaming the jars as we
check them into our repo. Maybe that is already an issue, but it seems
that releasing these as independent entities makes them more public and
subject to more scrutiny (and possible mis-use by other projects).
