The Fest Assertions library, a fluent Java API for writing assertions in your test or production code, is quite popular in my development team. Because of it's clean and fluent interface, it was no question to me when trying to use it in an Android project. But due to it's dependency on java.awt classes and due to Android's missing support for them, I currently cannot use it for writing tests in my Android codebase.
There might be several solutions to solve such an incompatibility, like adding classes providing missing packages in Android. Another solution is breaking the fest assertions library into several modules, so that one can use only Android compatible fest assertion modules. The library fest-assert is currently being refactored at GitHub, so nothing hinders us from forking and giving modularization a chance.
The whole approach is quite easy:
- identify all awt dependent classes and corresponding resources in artifact A and move them to another artifact B.
- for all commonly used classes between artifacts A and B, move them to a third artifact C, so that both A and B can be dependent on C.
- in order to ease dependency management for users, create another artifact X, which itself depends on A and B.
Usually, most users should only depend on artifact X, which gives them most of the commonly used assertions. For special needs, you just drop your dependency on artifact X and replace it with one or more of the smaller modules. Using the example above, we have the following modules available:
A: fest-assert-core (https://github.com/gesellix/fest-assert-2.x): contains all core assertions, abstract base classes and the main API, but without dependencies on java.awt classes.
B: fest-assert-awt (https://github.com/gesellix/fest-assert-awt-2.x): contains all awt assertions, which have simply been moved from the old core assertion library.
C: fest-test (https://github.com/gesellix/fest-test): contains commonly used test classes. Some classes have been moved from the fest-assert-core artifact, to make them available for fest-assert-awt, too.
X: fest-assert (https://github.com/gesellix/fest-assert): A minimal artifact without Java classes, providing only dependencies on both fest-assert-core and fest-assert-awt. This artifact should be used in most cases, so that fest developers could continue modularization of fest-assert-core without breaking any client code. fest-assert should be used as facade to all commonly used assertion artifacts.
The only breaking change is a new factory class for the new awt specific artifact, in this case you would use "AwtAssertions" instead of "Assertions". You can find an example using both artifacts in on test class in the fest-examples repository (see the class MixedAssertionFactoriesTest). The whole modularized code can be found at the provided links, a discussion about this approach can be found at the fest easytesting developer group.
After discussion, I hope all changes find their way into the main repository at https://github.com/alexruiz/ and further modularization will take place to make Fest Assertions compatible with GWT and other frameworks. In case you want to support or improve this approach, please provide feedback at the google group or at GitHub!
Working with external interfaces often needs a secured connection, mostly implemented using SSL. I recently ran into some fresh setup of two hosts, sending each other SOAP requests via HTTPS.
Being a Java developer at my office, I got some error messages quite unknown to me, but after some reading of blogs and with other informational sources the problems had been fixed. Understanding the concept behind SSL and how the SSL handshake works are crucial when trying to understand error messages and to know where to fix them.
In case you are trying to use SSL connections with certificates in combination with Java you may have a look at a little how-to I wrote at my employers IT blog. It's written in German, but I guess you can understand most parts. Most of its content is taken from another article, enhanced with additional tips and solutions for special issues.
Liebe Deutsche Bahn AG,
seit Jahren bin ich regelmäßiger Nutzer Ihrer Infrastruktur. Sei es anfangs für regelmäßige Wochenend-Pendelei, später die S-Bahn in Berlin und in letzter Zeit mehr oder weniger regelmäßige Fahrten zwischen Berlin und Westerwald.
Bahnfahrten sind für mich eine entspannte Möglichkeit Entfernungen zu überbrücken, ohne großartige Checkins und Wartezeiten auf Gepäckbänder über mich ergehen zu lassen. Trotz meiner Liebe zum Autofahren sehe ich die Bahn auch als vorteilhaft an, wenn es um Treibstoffkosten, Autoversicherung und KFZ-Steuer geht. Mal ganz abgesehen vom Wertverfall eines Autos. Ja, die Umwelt freut sich bestimmt auch, aber da fehlen mir neutrale Statistiken.
Grundsätzlich gehe ich also mit einem guten Willen zum Bahnhof und steige in den Zug. Die Regel sähe so aus, dass ich von A nach B reise. Abfahrt und Ankunft stehen auf dem Ticket oder meiner Reiseverbindung und das mit dem Umsteigen bekomme ich auch noch hin. Da ich häufig genug fahre, lohnt sich eine BahnCard 50, ganz nebenbei kann ich so auch noch Bonuspunkte sammeln und werde dadurch sogar mit Freikarten oder netten Kleinigkeiten belohnt.
Wenn da nicht die Ausnahmen wären.
Finally a new layout and a bit more motivation to regularly publish content.
First, I will check and update both extensions t make them work with Joomla! 1.7.x and 2.5.x. Afterwards, the documentation will be updated and this is where you could help me: Please send me information about missing or unclear documentation so that I can improve it.
Both extensions are available as source and installable packages as well. Documentation is available via GitHub pages too, so I'll remove the TitleLink documentation here at gesellix.de soon. Other extensions will also be moved to GitHub: you can already find a Mailman subscription module there, which enables your visitors to independently add or remove their email addresses to your mailing list.