Picture the following scenario: You have an Enterprise Application Archive (EAR) which contains an EJB module and a WAR file. The web application uses a Spring application context and the same application context must be – for some reason – shared with your EJB. Using the beanRefContext.xml which points to the applicationContext.xml means that you will instantiate a new application context and have no access to the Spring environment of the web instance.
I used the following method:
Our new project makes use of Maven as build management tool. Eclipse (STS edition) is used for the development process. A part of the project consists of a transformation process which converts XML files to Java POJOs. Because of the given XML structure we used JAXB in combination with EclipseLink MOXy for this.
After a few weeks of initial development, mainly architectural decisions I prepared our TeamCity instance. The first TeamCity build failed because some of the unit tests throw unexpected errors. I must admit that until this time I had only executed the unit tests through Eclipse and every test case had passed without any problem. My local command line Maven builds were triggered with -DskipTests=true and succeeded too.
The failed build in TeamCity occured through the following JAXB error:
com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExceptions org.springframework.integration.Message is an interface, and JAXB can't handle interfaces. this problem is related to the following location: at org.springframework.integration.Message at public org.springframework.integration.Message ...
I repeated the test suite on my local machine (mvn test) and the first time it ran it succeeded. Eclipse passed the unit tests, too. At first I suspected different Java/JDK versions on my local machine and the build server, but the versions were the same. So I started with a fresh mvn clean test on my machine and the build failed, too. WTF? Now running the compiled unit test and the source code in Eclipse although resulted in the error above. Re-compiling the code with Eclipse fixed the errors. Eclipse uses Eclipse Compiler for Java (ECJ) during compilation and not javac of the JDK. Could it be a compiler bug? The byte code of both .class files (Maven compiled vs. Eclipse compiled) were more or less the same so this was not the answer.
During debugging the Maven compiled artifacts I noticed that the MOXy compiler was not hit, instead the default implementation was used. Could it be that the jaxb.properties file was not copied to the class path? jaxb.properties is read by JAXB for initializing/overwriting the default XML context factory. And indeed, the jaxb.properties was missing. ECJ copied the .properties file to the target directory but Maven ignored the file.
What did I learned from that?
I received the message “Segmentation fault” while running an apt-get install. My syslog contained the following lines:
Aug 11 11:34:19 srv kernel: [65729.407484] check-new-relea: segfault at 7f2dfd94746c ip 00007f2dfc0becd8 sp 00007fffd0671d20 error 4 in libapt-pkg.so.4.12.0[7f2dfc069000+11c000] Aug 11 11:35:52 srv kernel: [65822.603384] apt-get: segfault at 7f7d256e346c ip 00007f7d24252cd8 sp 00007fffdbb89140 error 4 in libapt-pkg.so.4.12.0[7f7d241fd000+11c000]
I fixed it with
Here are the instructions for letting your home server send e-mails with help of your Uberspace account. This small guide is based on Ubuntu 13.04. I assume your Uberspace username is $USUSER and your Uberspace host is $USHOST.
ssh $USUSER@$USHOST.uberspace.de vadduser local-server # enter a non-trivial password # the address "local-server" is now available via $USUSER-local-server@USHOST.uberspace.de
apt-get install postfix libsasl2-modules bsd-mailx # choose "Satellite System" for Postfix server type
myhostname = mail.my-local.domain mydestination = mail.my-local.domain, localhost relayhost = $USHOST.uberspace.de:submission smtp_sasl_auth_enable = true smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
Add your newly created mail account
touch /etc/postfix/sasl_password chmod 600 /etc/postfix/sasl_password vim /etc/postfix/sasl_password # add the following line # $USHOST.uberspace.de:submission $USUSER-local-server@USHOST.uberspace.de:$PASSWORD # :wq service postfix restart
mail -s "Test" firstname.lastname@example.org -- -f email@example.com
tail -f /var/log/syslog should now contain something like
Aug 10 19:52:26 srv postfix/qmgr: 63EDB13C0F83: from=<firstname.lastname@example.org>, size=309, nrcpt=1 (queue active) Aug 10 19:52:26 srv postfix/smtp: connect to $USHOST.uberspace.de[2001:1a50:11:0:xx:yy:zz:x]:587: Network is unreachable Aug 10 19:52:26 srv postfix/smtp: 63EDB13C0F83: to=<email@example.com>, relay=$USHOST.uberspace.de[95.143.xx.yy]:587, delay=0.64, delays=0.26/0.12/0.19/0.07, dsn=2.0.0, status=sent (250 ok 1376157144 qp 15391) Aug 10 19:52:26 srv postfix/qmgr: 63EDB13C0F83: removed
The Network is unreachable is not important, because I don’t have IPv6 enabled.
You know it: an old project gets reactivated because your customer needs a new feature or has found bug. Meanwhile, the responsible developers have been reassigned to new projects and have no time to finish the task. You are currently not at a 100 percent workload so you get the task assigned. Because of the missing documentation you are busy with the setup of your development environment in the first few hours. After that you spend the next hours (days) with trying to understand the architecture of the application.
This is an experience every developer or system administrator has made for sure: There is no documentation available or the existing documentation is insufficient or outdated. Thereby an appropriate documentation would result in having more time which could be spent for development and testing.
Besides the inline documentation of the source code and the end user manual other types of documentation exist. Unit and integration tests for example are a good basis for new developers to understand the internal API. Acceptance tests show how the application will be used by the customer and which typical workflows exist.
It does not matter if frameworks like FitNesse or Cucumber are used or everything is tested with “plain” JUnit/TestNG. The essential fact is that the tests document how the application or architecture can be used.
Furthermore, a developer documentation should exist so that new developers can easily incorporate into new projects. A developer documentation describes the basic topics which must be considered during the development process, for example:
As the developer documentation has only the developers as target audience and is only used for internal purposes, the architecture documentation could be although read from external persons. For example one of our customer claims a documentation about security-relevant processes and a documentation about the system and application architecture. The documentation about security relevant processes is required during a security certification, the system documentation is a requirement for the deployment in the datacenter.
In the best case the architecture documentation contains all desired information and can be simply forwarded to the customer.
The Ops needs a operational documentation which can be derived from the architecture documentation. The operational documentation contains topics like “Where can the logging be customized?” or “Where can I customize the database connection string?”.
Organisational and project relevant topics with non-technical background are discussed in the project handbook. The project handbook contains topics like repsonsibilities, contact cards, the processes for bugtracking and meeting notes and so on. Target audience for this documentation is the project management.
The writing of documentation should be firmly established as central position in your company culture. New employees should seee on their first day at work that the corporate wiki contains all required information. The involvement in discussions and the improvement of existing documents is explicitly requested. This concept can only succeed if every coworker has already realized how important a good documentation is and leads by example.
In my opinion it is the duty of every good developer or administrator to document his work and his decisions. A good documentation makes the difference between a project and a professional project.
Therefore in our company the following dictum exists: “If it is not documented in the wiki or bugtracker it has not been done.”
One of the biggest faults is the usage of the wrong tools. Making a good documentation means not using Word and Excel in first line. Instead push every information into your corporate wiki so that every project-related person has instantly access to it. I really like Confluence and can only suggest you give it a try.
Templates like arc42 are a really good start for the documentation. Try to make your own templates which are adjusted to your needs.
The development and architecture documentation should be written from the responsible architect during the the development of the concept. He knows the big picture and makes the technical decisions. Always document, what leads to your decisions!
The operating documentation can be written by the developers who implemented the application. The architecture documentation can be used as a basis. The internal system administrators should although read the documentation. They know at best which information is expected in such a document.
Writing the end user manual can be a chance for transfering the domain knowledge of the project to new employees who are not directly connected to it. This can only work if every team member is a aware of the fact that the documentation is an important component of a successful project. It is not a job which can be done by anyone. The requirements for writing a good end user documentation are high:
A professional end user manual will demonstrate the customer that the application is elaborated and developed by professionals. A good end user manual is making a major contribution in the successful acceptance of your application.
Every document should be read early and regularly by other persons to reveal problems in the comprehension of the documentation.
Footnote: If you liked the blog post, you would probably like Jens’ blog post about software documentation.
Yesterday I read the article written by Christoph and thought about updating my current installed CyanogenMod 9 with the current version. Here are the instructions (assuming, you have already CM installed):
How to update the firmware for video codecs is described here. Two remarks: the newest build does work too and use Total Commander for moving the firmware.
You can find the complete example in my Github repository: https://github.com/schakko/asp.net-msbuild-casperjs-teamcity.
Momentan befindet sich die NeosIT GmbH in der Situation, dass wir zum 1.8.2013 zwei neue Azubis suchen. Nachdem wir vor einigen Wochen die Ausschreibung beim Arbeitsamt aufgegeben hatten, kamen viele Bewerbungen herein. Als Ausbilder bin ich der direkte Ansprechpartner für potenzielle Auszubildende und dementsprechend stark in den Auswahlprozess involviert.
Einige Sachen sind mir während der letzten Wochen aufgefallen:
Momentan sind wir noch auf der Suche nach Auszubildenden. Die Ausschreibung sagt schon ziemlich viel. Hier noch ein paar private Statements.
Nachdem ich zwischen Ende November und Ende Januar die ganze Zeit an der Bachelorarbeit gewerkelt habe, habe ich nun endlich mein Bachelor-Studium Web- und Medieninformatik am Freitag (1.3.2013) erfolgreich abgeschlossen. Das Kolloquium lief richtig gut und es hat Spaß gemacht, über das Thema Integration von Xtext in einen bestehenden Softwareentwicklungsprozess zu referieren – was sich auch in der Note niedergeschlagen hat
Freitag Abend wurde der Abschluss mit den Kommilitonen erfolgreich begossen, so dass ich bei der Abschlussfeier am Samstag Mittag noch einen leichten Kater hatte. Sehr symbolisch war, dass am Samstag zum ersten Mal in diesem Jahr die Sonne heraus kam. Im Anschluss an die Entlassung fuhr ich noch ins Kletterwerk zum Bouldern.
Die komplette Bachelorarbeit zum Thema (PDF + LaTeX) steht jetzt unter https://github.com/schakko/bsc-thesis-documentation zum freien Klonen zur Verfügung. Den Quellcode der Arbeit kann ich allerdings aus gegebenen Gründen nicht veröffentlichen
Mein zweites Ziel für dieses Jahr (neben der Bachelorarbeit) habe ich übrigens auch gepackt: Mit den Kollegen bin ich heute Abend bei der JUG Ostfalen in der Autouni gewesen, wo wir uns von Oliver Gierke und Stefan Tilkov zum Thema REST anhörten.
A few days ago I finished my bachelor thesis with the title Integrating Xtext in an existing Software development process. I developed a domain specific language with Xtext and some extensions for easily adding new generators as new Eclipse plug-ins.
After finishing the thesis I added a Maven Tycho based build configuration. The build configuration can be easily deployed to TeamCity, Hudson or any other build server of your choice. I assume that you have already developed an Xtext based DSL and you know a little bit about OSGi and Maven.
The complete project source code can be found at https://github.com/schakko/xtext-plugin-with-maven-tycho
First of all you should think about a sensible directory structure. I use the following organization
Every pom.xml inside the subdirectories inherits from the master pom.xml. The configuration defines all modules of your project, sets the needed plug-in repositories and plug-ins. The most interesting part of the lifecycle configuration is, that the xtend-maven-plugin is not executed in generate-sources but generate-resources. This is needed as the MWE2 workflow of your DSL project has to be executed first. If you have both plug-ins inside the generate-sources phase the xtend-maven-plugin will be called first, resulting in a ClassNotFoundException as the DSL infrastructure is not generated yet. So the compilation of Xtend is moved to generate-resources which is executed after generate-sources phase. Another solution would be moving the xtend-maven-plugin to every child pom but this means duplicate configuration code.
The pom.xml contains the plug-in for executing the MWE2 workflow. Notice that your <workflowDescriptor> must begin with src/ or you will receive the message Cannot create a resource for…. All the other stuff is straight forward. The packaging type eclipse-plugin is introduced by the tycho-maven-plugin.
The file build.properties contains the source and binary folders. This is important, as tycho-maven-plugin uses this file as reference for compiling and packaging the sources. The xtend-gen directory must be added.
It is important, that your Bundle-Version must end with the suffix .qualifier, e.g. 1.0.0.qualifier. The string is automatically replaced with the build date.
At first the two automatic generated files from src-gen (*InjectorProvider.java and *UiInjectorProvider.java) must be copied to the src folder if you want use the xtend-maven-plugin. The Xtend Maven plug-in does not allow (at least in version 2.2.1) any additional source pathes so that none class in src-gen can be found by xtend-maven-plugin. Remove the src-gen directory from your Eclipse classpath too.
The pom.xml for the test project uses a different Xtend version because I ran into heavy problems with the xtend-maven-plugin using the ValidatorHelper. Referencing the ValidatorHelper class results in a GenericSignatureFormatError. Sven Efftinge mentioned yesterday that the bug should be fixed in the latest snapshot.
The packaging type must be eclipse-test-plugin.
Include the xtend-gen directory and make sure that the src-gen directory is not included because of the xtend-maven-plugin problem.
The MANIFEST.MF uses the Import-Package statement for importing Mockito. See the next section how to set up this dependency.
I used Mockito as mocking framework inside my tests. Adding this dependency is a little bit tricky:
A much better solution is including the required JAR files inside an own OSGi package. I took the idea from the atlassian-connector project.
Create a new Eclipse plug-in project, create a folder lib and copy the mockito-all-1.9.5.jar inside.
Nothing new, just use eclipse-plugin as packaging type.
Your build.properties must include the lib directory.
Here comes the interesting part. We use Bundle-ClassPath to define the additional path to the mockito JAR file. Every package inside this JAR file is re-exported via Export-Package.
The pom.xml must use the packaging type eclipse-plugin.
I added the schema and icons directory and plugin.xml. This depends on your needs.
Features are bundles which consist of different plug-ins. Lars Vogel made a good tutorial which you can use for more information
We need to create two features:
Create a pom.xml and use the packaging type eclipse-feature.
The update site contains every feature the user can install. Lars wrote a tutorial about this but my needs were different. I wanted to deploy the content on a local webserver with a simple copy command.
To do so, generate a new update site project inside your releng directory and add a category definition (in Eclipse: Plug-in Development > Category Definition).
The category.xml contains the features which are available through he update site. First of all, add a new category named “Xtext” and assign both of your previously created features to this category.
The packaging must be eclipse-repository. I use the copy-maven-plugin for copying the update site to the local webserver.
With all these settings the project can be build inside Eclipse without m2e plug-in and on the command line. Go to the command line and execute mvn install:
Create a new configuration in your TeamCity instance and add a Maven buildstep. I pass the -DupdateSite.target parameter for specifying the destination directory of the update site.
Enter the path to your update site and you will see your installable Xtext DSL