Homo Sapiens Abstractus

Search for maven artifacts

http://maven.ozacc.com/
http://www.mvnrepository.com/

Create a new project (standard application)

mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app

Create a new project (web application)

mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-webapp -DgroupId=com.mycompany.app -DartifactId=my-webapp

Resolve all dependencies

mvn dependency:resolve

Resolve all dependencies & their source attachments

mvn dependency:sources

Analyze dependencies

mvn dependency:analyze

Generate Ant build files

mvn ant:ant

Remove target directory & all build data

mvn clean

Compile

mvn compile

Build the package (JAR is the default)

mvn package

Only compile the unit tests

mvn test-compile

Compile & execute unit tests

mvn test

Compile & execute a single test

mvn -Dtest=MySingleTest test

Copy all the dependencies to target/dependency

mvn dependency:copy-dependencies

Assemble a package with all dependencies included

mvn assembly:assembly -DdescriptorId=jar-with-dependencies

Assemble a package with the sources

mvn assembly:assembly -DdescriptorId=src
mvn source:jar
mvn source:test-jar

Skip the tests when packaging

mvn -Dmaven.test.skip=true ...

Install an external jar into our local repo

mvn install:install-file -DgroupId=javax.transaction -DartifactId=jta -Dversion=1.0.1B -Dpackaging=jar -Dfile=/path/to/file

VCS Checkin

mvn -Dusername=username -Dpassword=password -Dmessage="Some message" scm:checkin

Prepare a release

mvn release:prepare

Translate 1.5+ project with retrotranslator

mvn package retrotranslator:translate-project

It seems that lately I have been crashing javac…

An exception has occurred in the compiler (1.6.0_10-rc). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report.  Thank you.

java.lang.NullPointerException
  at com.sun.tools.javac.comp.Check.checkCompatibleConcretes(Check.java:1215)
  at com.sun.tools.javac.comp.Check.checkCompatibleSupertypes(Check.java:1567)
  at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:2674)
  at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2628)
  at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2564)
  at com.sun.tools.javac.comp.Attr.visitClassDef(Attr.java:525)
  at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:575)
  at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
  at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:397)
  at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:2697)
  at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2628)
  at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2564)
  at com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1036)
  at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:765)
  at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:730)
  at com.sun.tools.javac.main.Main.compile(Main.java:353)
  at com.sun.tools.javac.main.Main.compile(Main.java:279)
  at com.sun.tools.javac.main.Main.compile(Main.java:270)
  at com.sun.tools.javac.Main.compile(Main.java:69)
  at com.sun.tools.javac.Main.main(Main.java:54)

The thing mostly annoying about the situation is that it is messing up with my project plan!

[This is a comment on the recent post The Mysterious TreeMap Signature by D. Spinellis, also posted in his blog.]

Recently I had to delve into Java Generics quite deep, since I (as my search concluded) needed to use

public class Foo<t extends Foo<T>>

recursive constructs for a personal project (which by the way are fixed-point equations of the form x=f(x) !). The point is I had to read a lot (including Anglelika’s marvelous contribution) in order to understand what is going on beyond the overhyped and embarassingly simplistic for-each construct.

Unfortunately, it seems the JDK is full of compromises of the kind described in the post. I do not argue that compatibility is a bad issue. I am just concerned with what else will follow in the road to Java evolution, since I do not want to see this wonderful and very pragmatic language become lame.

About five years [correction: after thinking better about it, I believe it is more than six or seven years] ago, I envisioned a merging of the Functional and Object-oriented paradigms. This need had come out my experience in designing and programming. I had next-to-none experience with FOP, but it was too obviously appealing to my brain to ignore it… Today, I would like to experiment with scala a bit, time permitting…

I have been writing some Hibernate code and in order to check what is going on with the mappings and the data they actually retrieve, all my domain objects implement org.ckkloverdos.string.IToStringAware of ckkl-core.

The actual domain model does not matter for this post, but let’s say that two of my classes are Person and Address and the association is such that a Person has one or more Addresses (under the hoods there are 3 tables, 2 for the entities and one join table). Also, an Address object has a reference to the Person it belongs to.

Here is a printout an Addresses list:

ArrayList[
  0=Address(
    name="Some address 1"
    person=null
    addressId=4)
  1=Address(
    name="Some address 2"
    person=null
    addressId=3)
  2=<REF:1>Address(
    name="The Master Address"
    person=Person$$EnhancerByCGLIB$$e8f89ce1(
      addresses=PersistentSet[0=<@REF:1>]
      name="The Master Person"
      personId=1)
    addressId=1)

...
]

So, actually, I can verify that I have one Person (”The Master Person”) to which one Address (”The Master Address”) belongs to. Notice how this Address lists its Person, which in turn has a circular reference to the particular Address.

Do not get confused by the domain object model. It actually does not matter. The idea here is that ToString can correctly report a circular reference in my object graph. It can also index those circular references in order of appearance, so that you will see <REF:1>, <REF:2> and so on, and of course the respective back-references <@REF:1>, <@REF:2> and so on.

<REF:n> marks a reference and <@REF:n> designates a circular (back) reference to the point where <REF:n> appeared. So, at the example above, we mark the particular Address having index 2 in the ArrayList because its object is also used in one of its properties, the Person.

One little bonus, as a side-effect of using the ToString mini-framework, is that I can see what Hibernate does under the hood, by noticing the name of the class

Person$$EnhancerByCGLIB$$e8f89ce1

Well, that’s nice!

One of the reasons I created org.ckkloverdos.collection.L, is to be able to adopt a more declarative style of programming, since this collection/array wrapper class makes it easy to do some functional-oriented programming.

The other day, I was playing around with the API of Package. At one point, I just wanted to see the loaded packages from my own ckkl-core library. The implementation, using L, is both simple and I believe elegant:

new L(Package.getPackages())
  .selectProperty("name")
  .filterStartsWith("org.ckkloverdos")
  .print();

What would be the alternative in plain-old-Java?

Package[] packages = Package.getPackages();
for(int i = 0; i < packages.length; i++)
{
  String name = packages[i].getName();
  if(name.startsWith("org.ckkloverdos"))
  {
    System.out.println(name);
  }
}

Spring brings the power of POJOs to BEA’s server

Spring 2.0.1 and BEA WebLogic Server 9.2 Integration by Andy Piper and Eric Hsiao, Rod Johnson, Chris Wall — WebLogic Server 9.2 provides a platform for enhanced management, ease-of-use and scalability of Java applications. The Spring Framework enables a simpler, POJO based, approach to Java EE development without sacrificing the power of the platform. This article describes the synergy of these two systems, and introduces the Spring on WebLogic kit.