Monthly Archives: December 2012

find file in svn

after out switch from cvs to svn all old (not more improved) project where copied to a chaotic seperate lagacy svn… and hurray… i need to find some code in there… so how to search?

svn list -R https://subversion/repository | grep filename

but it takes for ever… so i used:

svn list -R file:///subversion/repository | tee svnlegacy.log

so i see, that it is still working… takes for ever… and if there is a typo in the file, i am looking for, i can search it much fuster in the logfile…

and yeah… still running 🙁

wsdl sharing by pack/unpack artifact

The problem is simple… we have a service-contract maven project, which contains all the wsdls… this will be deployed on a seperate server… why not simply use the maven repo?

so there are actually two solutions… put wsdl artifact on maven or unpack the arifact. This blog entry handles only the unpacking…

The solution is to put all wsdls as jar to the maven repo. Get the artifact, unpack it and generate the server or client from the unpacked wsdls. This solution matches my problem at work and no really effort was needed… but the solution kinda sucks… later more… first the solution 😉

Create a jar and pack the wsdls with build-helper-maven-plugin:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-resource</id>
<phase>generate-resources</phase>
<goals>
<goal>add-resource</goal>
</goals>
<configuration>
<resources>
<resource>
<directory>src/main</directory>
<targetPath></targetPath>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>

And then unpack it in the actual service with maven-dependency-plugin:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>unpack</id>
<phase>initialize</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>ch.michio.test</groupId>
<artifactId>service-contracts</artifactId>
<version>1.0.0</version>
<type>jar</type>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/service-contracts</outputDirectory>
<includes>**/*.xsd,**/*.wsdl</includes>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>

Important it needs to be unpacked, before the generate-sources. Now it is in the target folder…

And finally generate it with cxf-codegen-plugin.

webservices contract-first and contract sharing

The webservices contract-first is, i think, a good concept. But how it actually should be executed is really complicated…

in my opinion it is writing the wsdl by hand and then generate the server and clients form it. So the contract is clear. On the otherhand it is also possible to write the server stubs (in eg. java) first, and then generate the wsdl out of it and define this as contract first. The big benefit of the second method is, that noone needs to be able to write the dm wsdl xmls… but is this really contract first?

The big other issue on webservice is the sharing of the wsdl itself… if you have a handwritten wsdl it is easy to share it… but where? But remember the generated server and its generated new wsdl does not need to be exactly the same…

at work we have a seperate service-contract maven project, which puts the wsdl on a seperate server on install. the idea then is then to get the wsdl with cxf and generate the server and clients. Good idea, nobody uses it 🙁

So a different solution should be found…