Docbook story: Most of the afternoon was spent tracking down a bug, which turned out to be formerly hidden by Maven 2.2.1, but which Maven 3.0 exposed (I'm trying Maven 3.0 beta 1 - it seems to run faster/better :-) ). The symptom was a report that the "catalog file" could not be found.
The bug is that if you ask in a plugin to load a resource at the top level, using the string "/xxx.xml" for instance, it fails. This is because that leading "/" makes the Java classloader.getResource(aString) fail. To fix, just drop the leading "/". I've reported this along with the fix to the docbkx project - they use this to load the "catalog.xml" file that comes with docbook 4.x and 5.0 distributions. So, now, after all that, I'm starting to get docbook building again, this time with fully factored parent plugins. The olink stuff I'm going to try to do by using maven "attachments", and going for a strategy of only 1 docbook per project (I've split the uima-docbooks project, which held 4 docbooks, into 4 projects, each holding one docbook). This aligns the approach with the way Sandbox projects are doing documentation - they have the project produce the 1 main artifact (a jar), and now it will also produce (when I'm fininshed :-) ) an additional "attached" artifact - the olink data for the pdf and html versions. This will allow other docbooks which want to hyperlink to a reference in the first docbook to be able to do so. (OLinking is like normal hyperlinking, except that information about the target is known, so for PDFs, the link includes the "book" + page number in the book, and it includes locating the other book via a relative directory path.). It looks like I'll be able to put all the gorp (that's a technical term :-) ) for docbook formatting, like boiler plate, title pages, things to enable xInclude, fonts, css stuff, customization xsl layers, etc. into a shared "resource bundle" that projects will be able to fetch (from their local .m2 repository, or from the big repo in the sky). -Marshall On 4/22/2010 4:03 PM, Marshall Schor wrote: > progress - > > the uimaj/branches/mavenAlign branch should now build all of the Java > components. There are 2 new aggregate (only) POMs for this, to build in > batch, called aggregate-pom-uimaj and aggregate-pom-uimaj-eclipse-plugins. > > More checking to do to verify the build is ok. > > Next to tackle: docbooks, then the assemblies. > > -Marshall > > On 4/19/2010 5:16 PM, Marshall Schor wrote: > >> Progress - created a common eclipse-plugin parent pom, and got the >> ep-configurator eclipse project to build. >> >> I noticed as a side effect of checking things that our 2.3.0 build for >> these artifacts are missing the License, Notice, etc. in the Jar >> manifest. The new structure of parent poms corrects this in a uniform >> way :-) >> >> -Marshall >> >> On 4/19/2010 10:42 AM, Marshall Schor wrote: >> >> >>> Progress - >>> >>> To handle the many Jars that need the extra bit in their Notice file(s), >>> I made a version of the remote-resource "bundle" that includes a >>> placeholder for additional text following the standard NOTICE boiler plate. >>> >>> Then I made a version of the parent pom for uimaj (uimaj-ibm-notice) >>> which uses this extra remote resource, and sets the additional text to >>> the required boilerplate for those jars which were originally coming >>> from IBM. >>> >>> Now, JVinci has the right notice file... >>> >>> next problems I'm working on for JVinci: The implementation url is >>> incorrect (it's for the parent-pom), and the project title META-INF >>> which we used to have, is missing. >>> >>> -Marshall >>> >>> On 4/15/2010 5:17 PM, Marshall Schor wrote: >>> >>> >>> >>>> Progress - >>>> >>>> I made a new top-level node in the uima tree called "build" - for >>>> artifacts that we won't normally be including in assemblies, but which >>>> are instead build things. >>>> >>>> In there, I put a folder called "parent-poms" - the intent is to keep >>>> these organized in one place. >>>> >>>> I made a top level pom for the whole project, which inherits from the >>>> common Apache pom version 7. The common Apache pom connects the deploy >>>> / release process with the Nexus repository. >>>> >>>> I also made a top level pom for just the main UIMA Java SDK - >>>> corresponding sort of to the former uimaj pom, except it doesn't have >>>> any aggregation stuff. >>>> >>>> BTW, in fiddling with the poms, I'm following the recommended ordering >>>> for elements in the POM, listed here: >>>> http://maven.apache.org/developers/conventions/code.html (scroll 3/4 of >>>> the way toward the bottom) >>>> >>>> After fiddling with my .m2/settings.xml files per the instructions on >>>> migrating to Nexus, both install and deploy worked (deploy was for a >>>> SNAPSHOT - no real releases :-) ). >>>> >>>> You can see the deployed artifacts on repository.apache.org in the >>>> Snapshots area. >>>> >>>> I'm now trying to see how to set up projects whose poms inherit from >>>> uimaj. First trying jVinci. I'm comparing what gets built to what was >>>> built for 2.3.0-incubating. >>>> One difference - a bunch of our components have slightly different >>>> Notices needed, so I'll fix that. >>>> >>>> Another thing to fix: thinking about when to run RAT. Some projects put >>>> it into a profile - so you can run it when you want to. It could also >>>> be in the apache-release profile - so it's always run when doing a >>>> release candidate. Unless there's a better idea, I'll add this. >>>> >>>> -Marshall >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> > >
