> On 10/22/2010 18:06, Marshall Schor wrote: >>> On 10/22/2010 17:02, Marshall Schor wrote: >>>> Hi - >>>> >>>> Let's do some debugging... >>>> >>>> >>>> >>>> On 10/22/2010 9:44 AM, Thilo Götz wrote: >>>>> 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. >>>> This step (above) should be unnecessary, but it's ok to do. >>>> >>>>> On to uimaj-core/aggregate-uimaj. Doing a mvn install there >>>>> gives me: >>>> ... >>>>> [ERROR] Non-resolvable parent POM: Could not find artifact >>>>> org.apache.uima:parent-pom-top:pom:7 >>>> ... >>>>> What am I doing wrong? >>>> Nothing that I can see at the moment. >>>> Here's some guesses: >>>> >>>> 1) Maybe you didn't build the parent-pom-top project in build? >>> Apparently I didn't. Do I have to maven install every >>> single on of those poms? >> No, you don't need to "mvn install" every project. All you have to do is >> one: >> mvn install - in the parent-pom-top project. It will build/install >> everything >> else that's needed. >> I'll add a README somewhere, that says this. >> >> The build tools are set up so a mvn install builds the particular parent-pom >> and >> all children of that pom. > Ah, that's good then. Just need to know which one's the > magic pom then. > >>> Do you know on how many different machines >>> I build at varying times (about 4-5 atm)? >> Wow... >>> On the bright side, this is the first time in about half a year >>> that I've been able to build without having to manipulate some >>> xml first. Even the sandbox built without a hitch. >> :-) >>> So what are we going to do about installing those poms? Nothing >>> an Ant or even shell script couldn't handle, but can maven do this >>> more elegantly? If not, I volunteer to write a script, if you >>> will make sure it stays up to date with your maven adventures. >>> >> There's 2 cases: (1) Building from trunk, and (2) building from a "released" >> source-release. >> >> In case 2, you don't have to do any "fiddling" with the build tooling >> (because >> released source depends on released versions of our build tooling, which is >> in >> maven central). >> >> In case 1, there is a bootstrapping issue: you have to either download/build >> the >> build tooling, (one mvn install) or have a maven settings entry that points >> to >> the Apache maven snapshot repository - which will enable the UIMA projects to >> find their parent poms. > I'd much rather build the build tools, I have no issue > with that whatsoever. It just needs to be described > somewhere how to do that.
OK, will do. >>>> 2) Maybe your Maven .m2/settings.xml file isn't set up to refer to the >>>> Apache >>>> maven snapshot repository? >>> It most certainly isn't. I absolutely draw the line at fiddling >>> with maven settings files before I build. Particularly given >>> that I like to nuke my maven repo every now and then. >>> >> Note that you can nuke your maven repo without nuking your maven settings >> file. >> >> Note also that you don't need to fiddle before building - this is more like a >> one-time setup that tells your maven installation that it can reference the >> Apache Maven Snapshot repository for artifacts - and that is where unreleased >> things are. > It really makes no difference. I expect to be able > to extract the source code from svn onto a clean > machine and build it without any extra setup. Every > other open source project that I know works that > way, and I see no good reason why we should be > different. We could do this, but it would impose the requirement that the build tooling be in a particular, fixed relative location relative to the other projects. I was trying to decouple these. > But we don't need to argue about that as long as > I can just build the build tools myself. > >> You'll also need the maven settings file if you plan to do "deploying" or >> "releasing" - it contains info on where the target servers are for uploading, >> together with info on how password access to those is being managed. > I have no plans to go there :-) > >> >>> I don't do any of the other maven setup described on our website >>> either, btw, I've never found it necessary. >> When I try and build the docbooks or uimaj-core without the -Xmx800m setting >> it >> fails. Our maven setup on our web site says to get around this by adding the >> MAVEN_OPTS environment variable. I guess you do this some other way? > No, I just don't do it, and it still works. May depend on what > JVM you use. > True. Maybe the JVM has a higher default memory size limit. >> That (plus the settings.xml) is really the only setup mentioned on our >> website, >> other than downloading Maven 3, unless I missed something. > There's the -XX:MaxPermSize=256m, whatever that is. Why the heck > do we need that? > I don't recall, it another memory limit parameter, I think in Sun JVMs it a place where interned strings, for instance, go, etc. Again, this may depend on the particular JVM / platform you're building on. >> Note: I've just updated the website for this section to add the info about >> maven >> settings.xml file, under the category of it's optional, but needed if you're >> building from trunk, not from released-sources. > I'd rather you documented how to build from scratch on a naked > machine without modifying the settings.xml. OK, I'll add that. -Marshall >> -Marshall >>> --Thilo >>> >>> >>> >
