> Hi, > > On Fri, Oct 22, 2010 at 5:16 PM, Marshall Schor <[email protected]> wrote: >> So, for instance, there is a docbook parent pom - it adds stuff needed for >> processing docbooks. > The functionality seems to be included in an automatically enabled > profile. That could just as well go to the top-level POM, as it > doesn't affect non-docbook builds.
True, I think. > On the other hand, complex build extensions like that would be better > handled in a proper Maven plugin (like > uima-build-helper-maven-plugin), that docbook components could simply > invoke with a normal <plugin/> entry instead of inheriting the rules > from a parent POM. OK, but would take some work :-) . >> And there is an xxx -ibm-notice - this changes the normal "notice" for source >> files to include additional text the incubator told us we needed to keep for >> copyrights moved from original sources we got from IBM. Only those projects >> that need this specify that parent, for instance. > I'd simply add the extra postNoticeText property to all downstream > POMs where its needed. Good idea >> The "parent-pom-distr" adds the assembly step we use to assemble our source >> and >> binary distributions for UIMA and UIMA-AS. > Why not inherit the source distribution settings directly from the > Apache parent POM? Yes, I've already proposed doing just that, in another thread, & we'll probably move to that at some point (soon). > The binary distribution settings could also be > included in the top level UIMA parent POM by using the same > runOnlyAtExecutionRoot setting used by the Apache parent POM. ?? I think we can embed this by using a profile that's triggered by something in the project. The runOnlyAtExecutionRoot just keeps the assembly from being run in sub-<modules> of a multi-module build, if I understand it correctly... >> We could merge many of these (maybe all) into one parent, and then put in >> some >> logic that activated the right parts of the pom based on what the project >> being >> built, needed. Is that a better way? > Yes, I'd say so, as at least it simplifies the project structure quite > a bit. See above for concrete suggestions. > What do others think? I could go either way. The pros are it simplifies the project structure, the cons are the parent pom becomes bigger and more complex. Isn't this a similar trade off in software design - where you can have large, complex classes or methods, versus doing some kind of decomposition, keeping things which are strongly interconnected and have a particular "concern" separated into smaller things? >> Yes, once a project is released, then to build it just takes that one "mvn >> install" command, done in the right directory, so it should be identical to >> yours. > Then let's add those READMEs! :-) Will do :-) >> There is a difference, though, for building the non-released trunk version - >> some bootstrapping is needed in your maven settings file, I think. (See other >> parts of this thread). If you have a way around that, I'd love to hear about >> that, too :-) > I'm with Thilo here, it would be better if no extra settings were > needed. Or if they really are needed, they need to be documented in > the READMEs, for example by pointing out that you need to checkout and > build project X before building project Y. The way we could do this could be as follows: 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. 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'm guessing that the Tika project just keeps everything together, and that everything is checked out at once, so the right relationships (relative directories) are preserved. Is that right? Maybe there are other approaches too - please post suggestions :-) Thanks again for your feedback! -Marshall > BR, > > Jukka Zitting > >
