On 10/22/2010 8:40 AM, Thilo Götz wrote: > 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?
Yes, I think, so, and here's how it works. The trunk has parent pom references to the current "trunk" version of the build tools, so these are at versions like 6-SNAPSHOT, etc. If you've downloaded and built the build tooling, from trunk, these are in your local repo. If you haven't done this, these are obtained from the Apache "snapshot" repository. This last is dependent on having the snapshot repository actually have these artifacts. They currently do, but that's only because someone "deployed" the lastest build of the build tooling at this level, to the snapshot repository. If and when we get around to setting up some kind of continuous integration, this snapshot deploy will happen automatically. That is, most CI systems (like Hudson, for instance), watch for SVN commits to your project, and when those happen, it schedules a "build" plus a deploy to the snapshot repo of the result (if the build is successful, of course). Note that if you already have the 6-SNAPSHOT version in your repository, if someone updates that build tool, you will (by default) soon get it updated in your local repository, via this path: 1) The CI system will notice the SVN change, and rebuild the artifact, and deploy it to the snapshot dir 2) (If there is no CI system, the person who updates the build tool, after checking the update into SVN and verify it's working, do a mvn deploy to update it to the snapshot repository). 3) When you run mvn install, the snapshots in your local .m2 repo are updated (I think once daily) from the snapshot repositories, so in about a day, you would see this update. (You can control this in your maven settings file, and you can request that things be updated when running the mvn command - just use the "-U" option to force an update). -Marshall >> Please let us know if we've overlooked something. Does this explanation >> make sense? >> >> -Marshall >>> BR, >>> >>> Jukka Zitting >>> >>> >
