Re: [Informal Vote] please express your opinion on using Nexus and Hudson: see https://issues.apache.org/jira/browse/UIMA-1717
On 3/28/2010 12:36 PM, Jörn Kottmann wrote: Marshall Schor wrote: I'm +1 for doing this, and offer to do some/most of the legwork to get this to happen. Other opinions? From a development point of view Hudson can help us to make sure that our build is never broken, and if so notice us, but usually our build always works. Not sure if it is worth the effort to get one build broken notification per year. The only other advantage I see is that it can automatically publish snapshot builds, but when this is the motivation to get CI on Hudson we maybe should start to release more frequently. I'm in favor of streamlining our build process to release more frequently :-). -Marshall Jörn
release / build simplification
Toward this goal, I think I have found a way to make each maven artifact independently buildable (and even releasable). The key is to remove the cross project dependencies on having other checked-out things. To do this I would make these 3 changes: 1) separate pom functions: into parent poms (whose function is to factor out common things) and aggregate poms (whose function is to aggregate other modules - so they can be built and released as one thing). 2) replace our docbook tooling with the maven docbkx plugin - I've tried this on a small piece of documentation, and it seems like with a bit of work, it could be configured to fit our docbook usage. 3) replace our dependency on copying license/notice boilerplate from the uimaj-distr project checkout, with the approach used in the apache.org pom - using the maven remote-resources plugin to get it. When this is done, it will no longer be important exactly how svn checkouts occur, since we won't be depending on relative directory coordinates to do builds (with the exception of aggregate poms). For aggregate poms, these would always be checked out with the sub-modules they are aggregating, since that's their purpose. But with this, if someone wanted to checkout and build a sandbox annotator, they could just do that one project. With this approach, we could transition to a scheme whereby we would not update submodules that don't change from release to release, if we so desired (I think that would be a good idea). I'll push forward with seeing if I can get our big docbooks to build properly using the docbkx plugin. What do others think about this direction? -Marshall
Bug in XmiCasSerializer?
UIMA developers--
XmiCasSerializer.XmiCasDocSerializer has this method:
private void addAttribute(AttributesImpl attrs, String attrName, String
attrValue) {
attrs.addAttribute(null, null, attrName, cdataType, attrValue);
}
When I plug in a different ContentHandler (such as the ones from AgileDelta or
Siemens
for generating binary XML, aka EXI), then I get NullPointerExceptions.
Apparently, they
aren't expecting null for an attribute's URI and/or localName.
I changed the above line to use instead of null, and these ContentHandlers
no longer throw
an NPE.
The developer at AgileDelta claims that the SAX spec says these should not be
null (only if the
index is out of range).
So what is your opinion? Is null incorrect? Would there be any consequences
(performance,
perhaps?) to changing the arguments to ?
If you think it's a bug, I'll create an issue in Jira.
Thanks,
Greg Holmberg
