In-line. Jarek Gawor wrote:
Maybe I'm missing something, but aren't these artifacts already in svn under ../repository, e.g. http://svn.apache.org/repos/asf/geronimo/server/branches/2.1/repository/(for the given release)?
True, maybe for now, pointing into tags for the required artifacts for samples and GEP will work and we can revisit a geronimo/repo branch later if needed. Only concern, would be updating the release process to look for these svn repo refs, as our samples and GEP builds will eventually have to use the artifacts from trunk and then be updated to point to tags....
Are you proposing one main location for all version of the artifacts for all versions of Geronimo? Will that svn location be added to the repositories list in pom.xml? What I'm concerned about is that if we add that svn location to the repositories list, maven might pick that svn repository as the first repository to check for any artifacts and therefore you will get a lot more hits to that svn repository. I don't know if there is a way to tell maven to check a given repository last or only use it for specific artifacts/versions.
Was thinking we would keep the repositroy/pom.xml in the server build and it would be the only pom that would point to the svn backed files. We would add a similar repository/pom.xml in the other subprojects that need to pull in any of these jars.
Jarek On Thu, Aug 7, 2008 at 9:13 AM, Donald Woods <[EMAIL PROTECTED]> wrote:We have danced around the problem of not being able to build Samples, Plugins or GEP from a clean m2 repo without building the Server's repository subdir for long enough. I believe it is time to create the following location in SVN - geronimo/repo Which would hold our private patched artifacts of other projects (like Tomcat, Pluto, ...), just like the OpenEJB team has done for some of their private depends. I don't see this as a major hit to the svn infrastructure, given the jars (10 for 2.2.) will only be downloaded when starting with a clean m2 repo or when we publish any updated depends. Unless someone comes up with a better solution by Friday morning, I'll create the new repo branch and populate it with the latest 2.1.2 and 2.2 patched artifacts tomorrow. -Donald
smime.p7s
Description: S/MIME Cryptographic Signature
