Launching Solr from Maven for rapid development

If you are developing on top of Apache Solr, you might consider integration Solr with your maven build, by launching it from the maven-jetty-plugin. This brings several advantages, such as the possibility to shorten the time to get started in the project, unify the dev environment of the team with a fixed Solr version, do automated integration tests by launching and stopping Solr in the pre/post integration-test phase of the lifecycle and also creation of a single WAR contained the standard Solr with the custom plugins and configuration.

Here’s a way to do it:

1) Since solr.war is not yet available on public maven repo (SOLR-1218) make sure you deploy the solr.war file in any of your maven repo. In this post I’ll assume that solr.war is found inder org.apache.solr:solr-webapp:1.4.0 of you maven repo.

2) Use the maven webapp archetype to create an empty web project:

mvn archetype:generate

choose the maven-archetype-webapp option.

3) Change the pom.xml to:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.moreover</groupId>
  <artifactId>ubersearch</artifactId>
  <packaging>war</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>ubersearch Maven Webapp</name>
  <url>http://maven.apache.org</url>
  <dependencies>
      <dependency>
        <groupId>org.apache.solr</groupId>
        <artifactId>solr-webapp</artifactId>
        <version>1.4.0</version>
        <type>war</type>
      </dependency>
  </dependencies>
  <build>
    <plugins>
       <plugin>
          <groupId>org.mortbay.jetty</groupId>
          <artifactId>maven-jetty-plugin</artifactId>
          <version>6.1.15.rc4</version>
       </plugin>
    </plugins>
  </build>
</project>

4) Copy the solr config files in the folder src/main/resources of the project. This will allow you to change them especifically for your project

$ ls src/main/resources/
elevate.xml            protwords.txt            solrconfig.xml            stopwords.txt
mapping-ISOLatin1Accent.txt    schema.xml            spellings.txt            synonyms.txt

5) Copy solr’s standard web.xml to the src/main/webapp/WEB-INF/ folder

6) Launch solr by calling the jetty plugin:

mvn jetty:run-exploded

7) Access Solr at http://localhost:8080/<artifactId>/admin/

Scala project quickstart with maven

22px-flag_of_englandsvg To create a simple project:

mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-4:create -DarchetypeGroupId=org.scala-tools.archetypes -DarchetypeArtifactId=scala-archetype-simple -DarchetypeVersion=1.2 -DremoteRepositories=http://scala-tools.org/repo-releases -DgroupId=com.mycompany.scala -DartifactId=scalaTest


To run the sample:


mvn compile exec:java -Dexec.mainClass=com.mycompany.scala.App

Build simples de GWT, com auxílio de Maven

22px-flag_of_brazilsvg Quem começa com o Google Web Toolkit (GWT), logo percebe que a distribuição não funciona em todos os sistemas operacionais. É preciso fazer o download do gwt-linux, gwt-mac ou gwt-windows. Isso porque a distribuição inclui bibliotecas nativas SWT, Mozilla, e scripts para executar a aplicação no modo “hosted”, que diferem entre os vários sistemas operacionais. Além disso, a distribuição não inclui scripts para criar um WAR “deployável” com a aplicação GWT.

Uma opção ao uso da distribuição do GWT, é o uso de um archetype maven que faz todo o trabalho de gestão das diferenças entres os vários sitemas operacionais, além de oferecer a possibilidade de criar um WAR com uma linha de comando. Para  criar o projeto, basta chamar o archetype:


mvn archetype:create -DarchetypeGroupId=com.totsp.gwt \
-DarchetypeArtifactId=maven-googlewebtoolkit2-archetype \
-DarchetypeVersion=1.0.3 \
-DremoteRepositories=http://gwt-maven.googlecode.com/svn/trunk/mavenrepo \
-DgroupId=br.com.dominio \
-DartifactId=app-gwt

Para executar o projeto, use o goal gwt:

mvn gwt:gwt

Antes de gerar o WAR, é preciso descomentar a linha “<!– <webXml>target/web.xml</webXml>–>” no plugin war e a linha ” <!–mergewebxml–>” do plugin maven-googlewebtoolkit2-plugin, tudo isso no pom.xml gerado. Isso porque o GWT no modo “hosted” utiliza um xml (chamado Application.gwt.xml) para declara configurações client-side E server-side. Caso você esteja utilizando RPC, o plugin maven fará um merge do Application.gwt.xml para um web.xml, migrando todas as declarações de servlet.

E finalmente para gerar o WAR, basta:

mvn package

Java on the Desktop: still a no go

22px-flag_of_englandsvg After the launch of Java 6 update 10 final, and recently JavaFX 1.0, I decided to take a look on how desktop java was going.

I hoped that after the disastrous failures of applets and java web start, Sun would finally get it right, coming up with something that could be a real option to Flash and Ajax, something that could allow us, developers, to write and distribute reliable and fast desktop applications using Java on the Internet.

But it seems that I’ll have to wait some more time :)

I went to javafx.com to see the new demos, and received a very cryptic error whenever I clicked in one of them:

fx

To solve this, it’s necessary to go to java console and do some changes in the temporary storage of files (!),  as described here.

I don’t remember having any problems  installing Flash on any operational system, and that includes Linux, Windows, PalmOS, Pocket PC and Symbian, using several browsers such as Internet Explorer, Opera, Firefox, Chrome and Safari.  Flash just works! You go to a page and Flash runs.  If you  don’t  have Flash, it get installed in a matter of seconds.  It works flawlessly and equally everywhere.

That’s  why things like YouTube uses Flash.  Because if a user has to figure out how to solve errors like that, he’ll simply go away.

Extending Confluence using Wicket

Recently I started to work at two projects in my new job, in one of them doing some plugins to Atlassian Confluence (which is a yet-another-java-based-wiki) and participating on another that uses wicket.

In order to add new (visual) functionality to confluence, it’s common to use XWork to create new actions or replacing the existent actions to add new behavior. I particularly don’t like Xwork and in one of the moments to avoid boredom in these two projects I decided to somehow try to do wicket development inside confluence. The advantage would be avoiding completely XWork, possibility to use wicket advanced features and possibility to run the feature outside confluence (more testable).

So I started giving a look at the Confluence PDK (Plug in development kit), and see that it was already possible to define a servlet as part of a plugin

I then started declaring the wicket servet in atlassian-plugin.xml:

And creating the WicketApplication that simply loads my page:

That will use the Confluence API in order to do a paginated ajax table with the names of the plugins available on confluence.

After that, confluence will load the servlet and will make it available on the /plugins/servlet/sampleplugin/  URL.

ISSUES

1. The first problem is that the output will be strictly the page output, without confluence headers and menus. There’s an issue describing that bug, but while it is not fixed commenting the line 16 in the WEB-INF/decorators.xml in your confluence installation will suffice:

<url-pattern>/plugins/*</url-pattern>

That line when uncommented tells that for the URLs starting with “/plugins”, no decorator will be used. So, It’s enough to comment it.

2. The second problem is that confluence does not destroys the servlet when the plugin is uninstalled using maven PDK tool. There is another issue describing that problem. Basically, wicket creates its session object using one classloader. When the plugin is removed and reinstalled, it’ll gain another classloader. So nasty ClassCastExcetions occurs on trying to obtain the wicket session. The workaround for now is to restart the server on reinstall of the plugin.

Here we can see the final result: The standard confluence header and footer, and the wicket page in the center.

Download here the zip file containing the maven project for this example plugin.

Reliable Windows Vista partition writing from Linux

The first thing to do in order to mount a windows vista partition (in a reliable read-write mode) from a Linux, is to add support for FUSE, which means to add support for filesystem in userspace

Support for FUSE was added to linux kernel from the 2.6.14 version. To enable it:
File systems  --->
<*> Filesystem in Userspace support

After recompiling and booting the kernel, it’s necessary to install NTFS-3G. In gentoo linux this means issuing a “emerge sys-fs/ntfs3g”

To mount the driver:

ntfs-3g /dev/sda2 /mnt/win