Ivan Lagunov's Blog

Here you'll find a short overview of the actions required for publishing your artifacts to Maven Central Repository . The best way to publish your artifacts is using Open Source Software Repository Hosting (OSSRH) which runs Sonatype Nexus Platform . We'll follow the official guide with some remarks. Get permission for deployment. Deployment of artifacts. Release procedure. Get permission for deployment In the beginning you need to get permission for deployment under a certain Maven groupId. This should be done by signing up and creating a ticket in Sonatype JIRA . If the groupId already exists, either the initial requester should apply for a new user account or you should demonstrate an approval from the project owners. As a result, you'll get an account in OSSRH . For example, this is how I requested permission for com.github.dita-ot groupId. Deployment of artifacts The deployment is the first phase of artifacts publication. Here you need to create and s...

I've recently got a fresh new licensed IntelliJ IDEA 12 and have been so glad about it until I've suddenly stumbled upon a strange issue. The Java project that was being developed successfully in previous versions of IDEA crashed during building this time. Shortly, the solution was hidden under IDEA Settings Compiler.Excludes where the JAXB generated sources directory was excluded due to some unknown reason. Below are the details and the screenshots. Symptoms of issue Here are the symptoms of the issue. Whenever the sources directory is excluded from compiling, it's marked with cross signs. See generated directory below: This issue results in numerous "cannot find symbol" errors during compilation: Settings Compiler.Excludes Here is the screenshot with the solution for this issue. You just need to delete the item with excluded sources and they will again magically appear in the classpath. Update - the root cause found After a while I real...

This article explains how to set up maven jetty plugin 6 for rapid development of Cocoon applications (this part is based on the official tutorial about cocoon maven plugin ). The article also describes an interesting pitfall reported here by Robby Pelssers. Modify project pom file In order to enable Jetty support you need to add the following plugins into your project pom file: <!-- Prepares block resources and classes for Jetty plugin --> <plugin> <groupId>org.apache.cocoon</groupId> <artifactId>cocoon-maven-plugin</artifactId> <version>1.0.0</version> <executions> <execution> <phase>compile</phase> <goals> <goal>prepare</goal> </goals> <configuration> <useConsoleAppender>true</useConsoleAppender> </configuration> </execution> </executions> </plugin> <!-- Runs current coc...

This article is about an efficient technique of caching static resources on the client side (user's browser). There are quite many ways to implement caching including HTTP headers. A common disadvantage of them is that as soon as some resource is cached by the browser, it won't be updated until it's expired. Thus, the server loses control over the browser caching mechanism for some period of time. As a result we have to adjust the expiration time period or updating frequency somehow. The better alternative is the case when it's only the server that is in charge of the browser caching mechanism. Actually the idea has been borrowed here . If we append a GET parameter with some changing value (like a timestamp or a version) for a static resource URL, it'll force the browser to get the fresh version of the resource from the server. If we keep the parameter value steady, the resource will be taken from the browser cache. Finally this article is about implementation....