On 10/22/2010 15:07, Marshall Schor wrote:
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.
Marshall, your background information is appreciated, but
what I need most of all is precise instructions on what
to do.
I got the "build" projects from svn. There are no build
instructions in there, so I cd'ed to each subdir and did
a mvn install. Some of those dirs contain various poms,
and I'm obviously not supposed to mvn install them, as
maven informs me. Anyway. Success otherwise.
On to uimaj-core/aggregate-uimaj. Doing a mvn install there
gives me:
~/code/uima-svn/core/aggregate-uimaj$ mvn install
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project org.apache.uima:aggregate-uimaj:2.3.1-SNAPSHOT
(/home/tgoetz/code/uima-svn/core/aggregate-uimaj/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact
org.apache.uima:parent-pom-top:pom:7-SNAPSHOT and 'parent.relativePath' points
at wrong local POM @ line 25, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
What am I doing wrong?
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
