Thursday, February 23, 2006

Neat things

Another product from 37 Signals for chatting. Looks neat!
Campfire - Business Chat
A Tag Library for displaying lists

DisplayTag TLD

Friday, February 10, 2006

Universe of Maven 2 Archetypes

Maven 2 has this really neat feature called "archtypes" useful for creating a skeleton directory structure for a project. It allows you to specify an "archetype type" that identifies the project as an api (default), webapp or other types.

For example, you could start a brand new project like this:
mvn archetype:create              -DgroupId=com.mycompany.app              -DartifactId=my-app

Maven then creates a directory structure that Maven can understand:
my-app
|-- pom.xml
`-- src
|-- main
| `-- java
| `-- com
| `-- mycompany
| `-- app
| `-- App.java
`-- test
`-- java
`-- com
`-- mycompany
`-- app
`-- AppTest.java


This directory structure is used when your app is a jar, i.e. an API, or application.

Maven also hints that there are other types of archetypes for other types of applications, but then they don't explain anywhere what these are!

You can create a web-app project by specifying the web-app archetype:
mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp
The only problem is that the Apache Maven group doesn't seem to realize that when users see this neat feature, the first questions are "Great! What types of archtypes are offered?" or "Where can I find in the documentation the list of available archetypes?". The result is that the documentation (well, "mini guides") show some examples of different archtypes used, describe an introduction to archetypes, and even show you how to create your own archetype. (Worse yet, is that "How to create archteypes" is listed before, "Introduction to Archteypes" ... duh!) . But programmers are lazy, and we want to know what archetypes have you created for us!!

To find the answer, I did a little google searching and found two links that pointed me in very unobvious directions:

One link pointed me to the unobvious subdirectories of the build distribution for Maven 2 found here: http://www.ibiblio.org/maven2/org/apache/maven/archetypes/

From here, you can see the possible archetypes are:
maven-archetype-marmalade-mojo
maven-archetype-mojo
maven-archetype-quickstart
maven-archetype-site
maven-archetype-webapp
Another site pointed me to the SVN repository for Maven. Drilling down to the archetypes, it looks like there are a few more available:
maven-archetype-j2ee
maven-archetype-mojo
maven-archetype-portlet
maven-archetype-profiles
maven-archetype-quickstart
maven-archetype-site
maven-archetype-webapp
The directory structure that these archetypes actually create is up to you to try. I've used the default (i.e., don't specify one) API archetype and the web-app and am happy with the directory structure that it creates.

Maybe one day I will report on the directory structures of these archetypes, but really that should be done in the Maven documentation ... (Hint!!!)

Tuesday, February 07, 2006

JCoverage Eclipse Plugin?

Has anyone every tried installing the jcoverage plugin for eclipse? I tried but it doesn't seem to work. I followed this step to "Add jcoverage nature" and Eclipse does nothing. Doesn't move, no change, nada. Then it says to complete the license information screen. Umm. What license information screen? I can't do anything after this. The view opens, but that's it. No pretty jcoverage charts =( Anyone ever have any luck?

Upgrading Eclipse?

Ever upgrade eclipse? Seems to not be a smart move. When trying to use the jcoverage plugin for maven, I saw that jcoverage comes as an eclipse plugin! After going through the install guide, it didn't seem to work properly. I looked at teh compatible versions and I just had plain old 3.1, not 3.1 M2. Ok, let's upgrade.

Bad idea.

Why does eclipse make it so easy to upgrade its own plugins, but doesn't allow for an upgrade of the product itself. Now I have to do a fresh install and go install all the plugins all over again.

Pain in my ass!!

Working with Maven 2

I had not used Maven 1.X. I remember giving it a test drive, but a lot of it made me shiver. It seemed like a lot of learning and a lot of quirky behavior for something that was supposed to help me.

Looking at Maven 2, it seemed like a good place to start. I heard "total rewrite" and was a little scared, but I figured that the Apache folks had their shit together. The quick start guide was helpful and it did what I needed it to do right off the bat.

My whole point was that I wanted to put no effort into the build process. I am doing almost everything myself and I didn't want shit like the package process to hold me up. Here is what I needed m2 to do:

- run my junit tests
- package the APIs as JARs
- package the web-apps as WARs

I even sacrificed setting up the deployment of my WARs to my app server web-apps directory. Simply, I knew Windows would poke it's ugly head and I'd be pullying my hair over backslashed backslashes, or spaces in file paths or something terrible like that. I figured a drag and drop of a WAR was the least of my hold-ups.

Also, one nice feature of m2 is setting up dependencies, and since the app1-core was packaged as a JAR, that meant in the app1-webapp pom.xml, I could set up that JAR as a dependency meaning I just add to package app1-core and not deploy it anywhere.

Getting tests tested quickly, JARs built quickly and WARs built quickly was easily achieved. Here are some things that really screwed me up.

Downloading of dependencies and plugins. When you first run mvn, it needs to download all the plugins and dependencies. Well jaysus, I just fuckin downloaded the program, why didn't the plugins come with it? You watch line after line after line of new plugin being downloaded which is sort of a drag.

Then I started adding dependencies like junit, spring, struts and hibernate. This was pretty easy, although when m2 sets up its repository, it also downloads all the dependencies that *those* jars have. Again, you watch your screen flicker with new downloads and wonder if it is all working properly. You also have the problem of Sun Jars not being stored on the Maven JAR repository.

Can't find a jar? don't know it's heirarchy or version? Easy browsing here.

One problem with m2 is that it seems to have little patience if it doesn't find a jar that you have double-checked is in the repository. I got hung up on the struts jar for 3-4 tries running mvn, and it finally was able to download it. A better message than "download it manually yourself" would have been better.

This was all I needed to get started though. I don't really need m2 to build me a project site or documentation yet. But knowing that it can do that is fabulous. Now, I get away with these few basic commands

Test:
mvn test

package the API into a jar:
mvn package

package the web-apps into WARs
mvn package

(yes, the same, in the POM you just declare what the package type is)

I may be skipping over some other headaches I had with m2, but I think they mostly had to do with poor documentation. The topics for the documentation don't really follow and rhyme or reason, and they really vary from complete to scant to the obscure. They go from "getting started" right to "mini-guides". Not good, not good. Documentation should be more procedural, especially something as big as maven.

Overally, i give m2 a 8.5 out of 10 for "suiting my needs with minimal headaches".

Setting up code with Maven 2 and SVN

Ok, it has been a long time since my first post, but let's act like it never happened.

I decided to use Maven 2 for my code management and building. Ant was easy, but from what I had experienced, there were 841 ways to write a build script, and that always made me uneasy. Plus, I liked the bonus of what maven appeared to give: documentation perks, site creation, and library management.

Did I have any experience with Maven 1.X? No. I wasn't sure if that was a pro or a con. The docs on maven.apache.org seemed pretty good, and I did the getting started guide with relative ease.

The notion of "archtypes" really got me charged up. I was stuck at a place to start, and when you use the different create types to organize your code, I loved how it did that work for me. But how was this going to fit in with the best practices tags/, trunk/ branches/ directory structure of subversion? Time to put two directory layout conventions together like chocolate and peanut butter.

For my project, I was developing two APIs and two webapps - the APIs would be packaged as jars and the webapps would be packaged as WARs. Therefore, I decided to do create four specific code projects.

Couple this with SVN!! Oy, now how do I integrate one into the other. I decided to combine both and do this:

app1-core
/trunk
/tags
/branches

app2-webapp
/trunk
/tags
/branches

app2-core
/trunk
/tags
/branches

app2-webapp
/trunk
/tags
/branches

Now, within trunk is where the maven part starts. So within each trunk/ directory, there is another named directory after the trunk, so each project goes like this:

app1-core/trunk/app1-core
app1-core/trunk/app1-webapp
app2-core/trunk/app2-core
app2-webapp/trunk/app2-webapp

each of these directories contains the main src/ and pom.xml pieces for Maven. Was it overkill? I don't think so. Was it a lot of switching around of directories? At first, yes, but that is why we have bash profile and windows properties for setup aliases. 99% of the time I was bouncing around to each project home so doing "cd $app1core" was a lot easier than doing "cd ~/app1-core/trunk/app1-core".

So when I was done I was happy. I felt like my project setup was like the 2-person horse costume. The high level directories were the horse's rear for subversion - project names followed by the trunk/, tags/ branches/ convention. And the horse's front part (wink, where the brains are) are the project directories for maven.

More catching up to do. The next entry will be on the fine balance of the pros and cons of maven 2.