Java

I wanted to find some solution to a problem of automatic generation of build numbers/version identifiers using an ANT. I figured out that I can achieve it in the following way: <target name="numerate.version" description="Generates version number and sets it in Client properties file."> <tstamp> <format property="build.time" pattern="yy-MM-dd_hh:mm" unit="hour" /> </tstamp> <buildnumber file="build.number" /> <property name="version.code" value="${build.version}/${build.time}/${build.number}" /> <echo>Version: ${version.code}</echo> <replaceregexp file="${client.commonsi18n.pl}" match="(version[ \t]*=[ \t]*)+.*$" byline="true" replace="\1${version.code}" /> </target> A short description what is going on: ...

In the Axis2 (which you can download from this site) bin subdirectory, there is a java2wsdl.sh file which can be used to generate a WSDL file from plain Java classes. Below is a very rough example how to use it: /home/palli/axis2-1.5.4/bin/java2wsdl.sh -o /home/palli/ -of Test.wsdl -sn WSAdditionalOperations -cp . -cn com.nullhaus.ediploma.server.WSAdditionalOperations Used arguments: Parameter Description o output directory where the generated WSDL will be saved of output filename of the WSDL cp java classpath sn name of the service cn fully qualified name of the class you want to be used to generate the WSDL file

When you create a *.jar file using jar command-line tool, it is worth to remember that the order of arguments does matter, so: jar cmvf projects/myTags/etc/MANIFEST.MF myTags.war myTags means that you must firstly provide the manifest file (m), than the JAR filename (f). If you use the same order of arguments but change the switches like this: jar cvfm projects/myTags/etc/MANIFEST.MF myTags.war myTags the command will not be executed. According to the switches, your first argument should be the JAR filename (f) and then manifest file (m).

Tonight I’ve fought with making Maven and Hibernate to cooperate… After 1,5h struggle, I’ve decided to write down what I’ve “discovered”. When adding dependencies to your persist module you should avoid adding the hibernate package dependency itself as there should be only hibernate-annotations one. When adding log4j dependency remember that version 1.2.15 is messed up and forces you to download jars from SUN webpages if you want to get rid of those nasty dependency errors that maven throw in your face… Instead of 1.2.15 choose 1.2.14 as it’s dependencies are not optional and Maven will successfully download all of them. When adding slf4j (Simple Logging Factory For Java) remember that when you add slf4j-log4j12 package it comes with depended package slf4j-api but the versions might (and are!) non-compatible… In my case slf4j-log4j12 v. 1.5.6 came with slf4j-api v. 1.4.2. You should exclude slf4j-api dependency from slf4j-log4j12 and add it separately in the same version as slf4j-log4j12 (in this case 1.5.6).