DDevelopment & Design

Playing with maven release plugin

Using maven release plugin can save you a lot of time, especially if you still manually mange your project versioning. But sometimes it can be pain in the “back”. Simple scenario that occurred at least few times in some of my maven projects:

  1. Project contains at least two separate modules (A & B)
  2. One of this modules (A) is dependant on the other module (B)
  3. While trying to prepare a release (release:prepare) you get missing artefact error which points at second module (B) “Brute force” solution is launching clean install process just after getting missing artefact error and after that resume release prepare process (release:prepare). But since maven release plugin main purpose was cutting down unnecessary manual work like this – solution should be little bit subtle. For example you can change a little bit plugin configuration: 
org.apache.maven.plugins
    maven-release-plugin
    2.0

        clean install

Lot of other helpful configuration properties exists, be sure to check

http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html

— Previous article

<!--:en-->Glimpse on Tomcat performance tuning.<!--:-->

Next article —

<!--:en-->Complex flows with Apache Camel<!--:-->

You May Also Like
DDevelopment & Design

How we use Kotlin with Exposed at TouK

Why Kotlin? At TouK, we try to early adopt technologies. We don’t have a starter project skeleton that is reused in every new project, we want to try something that fits the project needs, even if it’s not that popular yet. We tried Kotlin first it mid 2016, right after reaching 1.0.2 version
DDevelopment & Design

Grails with Spock unit test + IntelliJ IDEA = No thread-bound request found

During my work with Grails project using Spock test in IntelliJ IDEA I've encountered this error:

java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
 at org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:131)
 at org.codehaus.groovy.grails.plugins.web.api.CommonWebApi.currentRequestAttributes(CommonWebApi.java:205)
 at org.codehaus.groovy.grails.plugins.web.api.CommonWebApi.getParams(CommonWebApi.java:65)
... // and few more lines of stacktrace ;)

It occurred when I tried to debug one of test from IDEA level. What is interesting, this error does not happen when I'm running all test using grails test-app for instance.

So what was the issue? With little of reading and tip from Tomek Kalkosiński (http://refaktor.blogspot.com/) it turned out that our test was missing @TestFor annotation and adding it solved all problems.

This annotation, according to Grails docs (link), indicates Spock what class is being tested and implicitly creates field with given type in test class. It is somehow strange as problematic test had explicitly and "manually" created field with proper controller type. Maybe there is a problem with mocking servlet requests?