Hi, On Fri, Oct 22, 2010 at 7:44 PM, Marshall Schor <[email protected]> wrote: > We could copy the build tooling stuff into each project we release (say, the > uimaj SDK, the uima-as add-on, and our Add-ons). Then each would be > independent. But we would have 3 (maybe more) copies of common build tooling > to > keep in sync.
Yeah, that's obviously not a good idea. One way to make this work would be to use svn:externals settings, but that's a bit hacky. > Or, we could keep the build tooling separate and shared, like it is now, but > impose a requirement that it be checked out and put in a particular relative > path with respect to the other projects' checkout, so we could use Maven's > <relativePath> element to help find the parent poms, etc. We had this > approach > before, but it caused problems because of the necessity to have these > checkouts > be in a particular relative path relationship. I wouldn't use relativePath for that, simply instruct people that they need to have a reasonably fresh checkouts and builds of any the upstream projects. Using Tika as an example (even though it's a lot smaller than UIMA), the tika-site component we use for managing the Tika web site has a SNAPSHOT dependency to Tika trunk. Anyone working on the web site is simply instructed to have a recent trunk build whenever changing the site. Note that the Apache parent POM also sets up a snapshot repository reference to repository.apache.org, so any SNAPSHOTs posted there will automatically be available to all projects that inherit from that POM without the need for modifying local Maven settings. > Maybe there are other approaches too - please post suggestions :-) The easy option would be to simply have all of UIMA under the same trunk. That would mean a single release cycle for UIMA. But I guess there are good reasons not to do that. BR, Jukka Zitting
