Stefan Bodewig's Weblog http://stefan.samaflost.de/blog
Mixed ContentenMaven Coverall Plugin Doesn't Like Buildnumber Pluginhttp://stefan.samaflost.de/blog/en/oss/XMLUnit/maven_coverall_and_buildnumber_plugins_conflict.html
<p>I wanted to track test coverage for <a
href="https://github.com/xmlunit/xmlunit">XMLUnit for Java</a> using
<a href="https://coveralls.io/r/xmlunit/xmlunit">Coveralls</a> (could
be better and I should do the same for <a
href="https://github.com/xmlunit/xmlunit.net">XMLUnit.NET</a>, but
these are different stories).</p>
<p>In theory this is pretty easy, given that there already is a Travis
CI build. I added the Jacoco and Coveralls plugins in a Maven profile
and made Travis run the profile as an <code>after_success</code>
script. But instead of publishing data, I was greeted by
<pre class="code">
[ERROR] Failed to execute goal org.eluder.coveralls:coveralls-maven-plugin:3.0.1:report (default-cli) on project xmlunit-parent:
Unable to parse configuration of mojo org.eluder.coveralls:coveralls-maven-plugin:3.0.1:report for parameter timestamp:
Cannot convert '1425416381951' to Date -> [Help 1]
</pre>
<p>Well, I never configured the timestamp for coveralls and I was
pretty sure I wasn't setting a <code>timestamp</code> property,
either. Searching around didn't lead to anything, there was no
environment variable configured, strange. Finally it dawned on me
that the buildnumber plugin I used in order to get the git hash into
the jar manifests also sets a property named <code>timestamp</code> as
a side-effect. So far I wasn't using it but rather
<code>maven.build.timestamp</code> for the manifest so I had ignored
said property. With that</p>
<pre class="code">
&lt;plugin>
&lt;groupId>org.codehaus.mojo&lt;/groupId>
&lt;artifactId>buildnumber-maven-plugin&lt;/artifactId>
&lt;version>1.3&lt;/version>
&lt;configuration>
...
&lt;timestampFormat>{0,date,yyyy-MM-dd HH:mm:ssa}&lt;/timestampFormat>
...
&lt;/configuration>
&lt;/plugin>
</pre>
<p>finally did the trick.</p>XMLUnit 2.x Development Moved to GitHubhttp://stefan.samaflost.de/blog/en/oss/XMLUnit/2_x_moved_to_github.html
<pre>
We are actively working on a re-designed XMLUnit which will be
available for both Java and .NET with a similar API. Development of
this version has moved to a GitHub organization [1] with two git
repositories for Java and .NET respectively.
All discussion about XMLUnit independent of any version will happen on
the XMLUnit general mailing list [2].
XMLUnit for Java 1.x will still be maintained using the Sourceforge
infrastructure that has served as well for many years.
We don't intend to maintain XMLUnit for .NET 0.x any longer.
[1] <a href="https://github.com/xmlunit">https://github.com/xmlunit</a>
[2] <a href="https://sourceforge.net/p/xmlunit/mailman/xmlunit-general/">https://sourceforge.net/p/xmlunit/mailman/xmlunit-general/</a>
</pre>Bloglines is Gone, Againhttp://stefan.samaflost.de/blog/en/personal/blogging/bloglines_gone_again.html
<p>Since about a week, all HTTP requests to
<code>dashboard.bloglines.com</code> return an empty
<code>text/plain</code> response, no feed. This is not the first time
it has failed, not the first time without any public notice.</p>
<p>When I tried to find others experiencing the same problem I came
along <a href="http://www.isitdownrightnow.com/bloglines.com.html">is
it down right now</a> which not only confirmed what I saw but also
contained a workaround to resurrect your feed list as OPML. It was
one of the latest comments further down that page and I've forgotten
who had written it - strangely it is no longer there.</p>
<ul>
<li>Go to <code>www.netvibes.com</code> and login using your
bloglines credentials.</li>
<li>In the upper right corner under "Dashboards" go to "manage
dashboards"</li>
<li>On the left hand side click "backup data" and select "Bloglines"
from the pulldown. Now you've got an OPML feed.</li>
<li>It seems you can then go to "my dashboard" and import the OPML
feed to your netvibes dashboard using "Add" (upper left corner) /
"Feeds" / "Import OPML" to start reading your feeds in the netvibes
reader which looks a lot like the bloglines you are used to. I
haven't read the terms of service, yet, you better do so yourself.
In either case most every RSS reader out there should be able to
import the OPML file you've just created.</li>
</ul>XMLUnit for Java 1.6 Released!http://stefan.samaflost.de/blog/en/oss/XMLUnit/1.6_released.html
<p>XMLUnit for Java 1.6 is mostly a bugfix release adressing four
issues:</p>
<ul>
<li>If the sought for attribute in <code>ATTR_NAME_NOT_FOUND</code>
or node in <code>CHILD_NODE_NOT_FOUND</code> differences is inside
an XML namespace, the difference's value is now Java5-QName like
<code>{NS-URI}LOCAL-NAME</code> rather than just the local
name.<br/> <a
href="https://sourceforge.net/p/xmlunit/bugs/65/">Issue 65</a></li>
<li>for <code>ATTR_NAME_NOT_FOUND</code> differences the XPath on
the side where the attribute exists now points to the attribute
itself rather than the parent element.<br/> <a
href="https://sourceforge.net/p/xmlunit/feature-requests/33/">Feature
33</a></li>
<li>a new <code>assertXpathEvaluatesTo</code> assertion in
<code>XMLAssert</code> combined with a new
<code>QualifiedName</code> class allows stringified XPath values to
be interpreted as qualified names.<br/> <a
href="https://sourceforge.net/p/xmlunit/feature-requests/25/">Feature
25</a></li>
<li>The JAXP 1.3 based validator ignored now uses the
<code>xsi:namespaceLocation</code> and
<code>xsi:noNamespaceLocation</code> attributes if you specify no
schema sources at all.<br/> <a
href="https://sourceforge.net/p/xmlunit/bugs/65/">Issue 65</a></li>
</ul>
<p>Note the first two changes may be breaking backwards compatibility
in rare cases.</p>
<p>Source and binary distributions are available from <a
href="https://sourceforge.net/projects/xmlunit/files/xmlunit%20for%20Java/XMLUnit%20for%20Java%201.6/">SourceForge's
File Service</a>, the checksums and PGP signatures can be found <a
href="http://xmlunit.sourceforge.net/checksums/">here</a></p>.XMLUnit 2.x Plans for Infrastructure Changeshttp://stefan.samaflost.de/blog/en/oss/XMLUnit/2_x_infrastructure_plans.html
<p>Reposting what I just sent to the xmlunit-general list for wider
feedback, don't hesitate dropping me a mail if you want to stop
me.</p>
<pre>
Hi all
if you are following the commits, you may have seen I've started to work
on XMLUnit 2.x again, nothing big, but I'm trying to get it done this
time.
Apart from re-thinking the abstractions used in the difference engine
the biggest piece missing for a release - even a beta - is
documentation. Here I realized more and more that I really do not feel
like writing a big docbook document again, I need someting more
ligthweight with more immediate feedback. A wiki would be fine, but
we've also always had a PDF version and I'd like to keep it that way.
Also I realized I prefer git over subversion by now, so I'd like to move
2.x to git. I know I could do so on Sourceforge, but right now I feel
it would be best to move active development over to github. A quick
search showed several forks over there, so we may be able to reconnect
and make this a community effort rather than mostly a one-man-show.
Here is what I intend to do, please let me know if anything looks
completely wrong:
* create an xmlunit organization at github
* create three repositories (for now)
* XMLUnit Java 2.x - including the matchers and xmlunit-legacy
* XMLUnit .NET 2.x - including constraints
* a pure Wiki repository for the user guide. github markdown works
well enough for me and pandoc can create PDF or even epub from it
(thanks to Stefan Tilkov for pointing me at it)
* start using github's issue tracker
* create a github.io site for XMLUnit 2.x
* keep using Sourceforge for XMLUnit 1.x
* move XMLUnit 1.x back to svn trunk and keep it at sourceforge
* keep using sourceforge's issue tracker for 1.x
* keep the xmlunit.sf.net site for 1.x
* keep using the xmlunit-general@lists.sourceforge as primary
communication medium for all versions
* keep the sourceforge forums even though I never liked them (or any web
forum)
</pre>