On 10/22/2010 14:02, Marshall Schor wrote: > > > On 10/21/2010 12:26 PM, Jukka Zitting wrote: >> Hi, >> >> On Mon, Oct 18, 2010 at 4:22 PM, Marshall Schor <[email protected]> wrote: >>> So, I'm thinking 3b) is the way to go. Other opinions? >> I don't quite understand where all this complexity comes from. >> >> The only thing you need for a release is a source archive with >> instructions on how to build it. If the release build depends on >> previously unreleased tools, simply include them in the release >> archive and make sure that the build instructions cover also how to >> build the tools. > Hi Jukka, nice to hear from you :-) > > I'm thinking out-loud how this might work. Consider building using this > source > archive, before the release has happened (while it's being voted on). > - You get the source archive > - You unzip it > - You look at the README and see instructions: > -- cd to this build tools dir, and do "mvn install" > -- cd to this uima dir, and do "mvn install" > > After release, the first "mvn install" would no longer be needed, though > (because the build tooling would have been updated to mvn central). > > Comparing that approach to 3b): > > The build tooling is separately released to the "staging" repository. This > requires at release time, an additional "mvn release:prepare release:perform" > operation. And the source release for UIMA is smaller in that it doesn't > contain the maven release tooling. > > The advantage, I think, of this approach is that the UIMA distribution without > the build tooling is buildable from source using just the one mvn install; > Maven > obtains the build tooling needed from maven central, via Maven's remote > artifact > fetching mechanism, just like it would obtain the common Apache POM. It more > clearly isolates the Maven build tooling from the rest of the project, and > promotes reuse of the build tooling among different releases (we're planning > to > release several things - the base UIMA-SDK, the UIMA-AS add-on, and the > various > "sandbox" projects). Also, by using this common build tooling approach, when > we > find problems and fix them, then they are fixed for all subsequent project > releases. > > So, the additional complexity is really only in releasing the build tooling > that > changes with a *separate* mvn release:prepare/perform. > > I do see one small issue: Our current source README refers to the UIMA website > for instructions on how to build, using maven. But over time, change will > happen :-) - so the source bundle ought to be more self-contained, and have > those instructions (on how to build) directly in the README, instead of via a > reference to the website. They are quite tiny, something like: > > a) download/install Maven 3 > b) unzip the source distribution > c) cd to a directory (depending on what it is you want to build) and do mvn > install
This is after release. What about the current version in trunk? How do I build that? Since the build tooling has not been released, I just need to "mvn install" it and I'm ready to go? > > Please let us know if we've overlooked something. Does this explanation make > sense? > > -Marshall >> BR, >> >> Jukka Zitting >> >>
