Looking for Q

Adding a nature in Eclipse

It's hard for me to replay this error in my well configured computer :P, but I found something useful.

You need to add a "Dynamic Web Module" in Project "Properties" -> "Project Facets".
Then F5 and try to "Run as.. Run on Server".

If I create a Maven Web Project (maven-archetype-webapp in the second configuration window on "New Maven Project", I can read inside my .project file:

<natures>
<nature>org.eclipse.jem.workbench.JavaEMFNature</nature>
<nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
<nature>org.eclipse.jdt.core.javanature</nature>
<nature>org.eclipse.wst.common.project.facet.core.nature</nature>
<nature>org.maven.ide.eclipse.maven2Nature</nature>
<nature>org.eclipse.wst.jsdt.core.jsNature</nature>
</natures>

As said in this web, if I delete the bold line, the option of running on server dissappears, so, it could be a nice clue.

If I try to read active facets in the "Project Facets" property page, I find this:

"This project is not configured to use project facets. Converting this project to faceted form will allow you to easily control the available technologies."

If I accept its proposal, then the bold line reappears! Mmmmm, interesting, isn't it?

That information is coded in ".settings/org.eclipse.wst.common.project.facet.core.xml"

Face and Unface "Dynamic Web Module" and check that file out to find how it works.

Have a nice day :)

Basic Artifactory installation

On Un*x:

http://wiki.jfrog.org/confluence/display/RTF/Installing+on+Un*x

On Windows (I really like this one)

http://www.theserverside.com/news/1364121/Setting-Up-a-Maven-Repository

viernes, 10 de diciembre de 2010

Managing dependencies with Maven

Content:

Managing dependencies with Maven

How does Maven work?

Maven uses repositories for searching any dependency you declare in POM.xml, there are strictly only two types of repositories: local and remote.

The local repository (today's theme) refers to a copy on your own installation that is a cache of the remote downloads, and also contains the temporary build artifacts that you have not yet released. (As said in Maven website).

When working with Eclipse, there are two levels for local repositories. Maven builds one repository over your workspace, therefore, if you have any dependency loaded as project in your workspace, it will be taken previous to any other equally-versioned jar.

The second level for local repositories is your personal space in disk. Maven automatically configures a repository inside your user directory (.m2 for Maven 2), and it is used for synchronizing all your projects, Eclipsoid or not.

In the higher step of this ladder, remote repositories. They could be a server in our own intranet, or one of the mirrors proposed by Maven for downloading its huge library.

Let's do a practice example:

Step one: Creation of secundary project.

Open an instance of SpringSource, configure it for working in the brand-new workspace "workspace_a". It doesn't matter the real path, it only matters that it is new and clean.

Create a "Maven Project",

We have reached the next window using only the "Windows Brain" (next.. next.. next..), until we are prompted for a "Group Id", "Artifact Id" and "Version".

Group Id: Sort of organizational name or hierarchy. It is a good idea that use your domain for all your packets, it could be at the same time your namespace and a good clue for where to locate more of your business.

Artifact Id: Name for this package.

Version: Initial version. SNAPSHOT tells Maven to look for more recent versions in their configured repositories.

If an App.java was created, we wont need anymore for this part of the example.

Try to Run as.. Maven Install.

With this command, you are telling Maven to compile, run tests, and, if succeeded, deploy in local Maven repository to share with other projects.

Now close your SpringSource IDE if you can't afford having two IDEs opened.

Step two: Creation of main project.

Let's do it quickly and painless. As we did in other article, New Project -> Spring Template -> MVC Spring Project (or something similar, I'm not reading it right now :P). I call it "war", why not.

We won't run this new project, because we don't need to. What we only want is being able to compile the code.

Write an import sentence with wildcard like the example, and use one inexistent class like me. God kills kittens for less than this.

Run As -> Maven Install

10/12/10 23:07:14 CET: [ERROR] The import es cannot be resolved

10/12/10 23:07:14 CET: [ERROR] UtilsA cannot be resolved to a type

10/12/10 23:07:14 CET: Build errors for war; org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.2:compile (default) on project a: Compiler errors : 

error at import es.anavarro.util.*;

       ^

/home/anavarro/Documents/workspace a/war/src/main/java/a/a/a/HomeController.java:10:0::0 The import es cannot be resolved

error at UtilsA a;

^^^^

/home/anavarro/Documents/workspace a/war/src/main/java/a/a/a/HomeController.java:20:0::0 UtilsA cannot be resolved to a type

Now type this in your pom.xml (inside <dependencies> tag, create it if it doesn't exist yet).

<dependency>

    <groupId>es.anavarro</groupId>

    <artifactId>util</artifactId>

    <version>0.0.1-SNAPSHOT</version>

</dependency>

Of course, adapt it to your step-one project. Rebuild the project, if everything went ok, Maven found the dependency and resolved the "import" error.

10/12/10 23:10:30 CET: Refreshing [/war/pom.xml]

10/12/10 23:10:30 CET: [INFO] snapshot es.anavarro:util:0.0.1-SNAPSHOT: checking for updates from org.springframework.maven.snapshot

10/12/10 23:10:44 CET: Maven Builder: AUTO_BUILD 

The other error is damn logical, that class doesn't exist in util project. Let's create it, one blank "UtilsA" class, in its workspace and project, then Run as -> Maven Install. A new version will be deployed in our local repository, with the same name and version, but (invisible to the user) with a newer timestamp.

Once your "util" project is done, return to the main project, rebuild it, Maven should download your last version, find your "UtilsA" and be able to compile it all. If it doesn't compile by Eclipse build, try Maven Install, it's the important one, and forces checking and download of dependences.

That is the base of Maven approach, easy to version projects and libraries, easy to collaborate, easy to use.

See you on @anavarro_prof

martes, 7 de diciembre de 2010

Maven Essentials: standard folders.

Content:

Maven standard folders

Directly from Maven documentation entry, short and concise.

Introduction to the Standard Directory Layout

Having a common directory layout would allow for users familiar with one Maven project to immediately feel at home in another Maven project. The advantages are analogous to adopting a site-wide look-and-feel.

The next section documents the directory layout expected by Maven and the directory layout created by Maven. Please try to conform to this structure as much as possible; however, if you can't these settings can be overridden via the project descriptor.

src/main/java Application/Library sources

src/main/resources Application/Library resources

src/main/filters Resource filter files

src/main/assembly Assembly descriptors

src/main/config Configuration files

src/main/webapp Web application sources

src/test/java Test sources

src/test/resources Test resources

src/test/filters Test resource filter files

src/site Site

LICENSE.txt Project's license

NOTICE.txt Notices and attributions required by libraries that the project depends on

README.txt Project's readme

At the top level files descriptive of the project: a pom.xml file (and any properties, maven.xml or build.xml if using Ant). In addition, there are textual documents meant for the user to be able to read immediately on receiving the source: README.txt, LICENSE.txt, etc.

There are just two subdirectories of this structure: src and target. The only other directories that would be expected here are metadata like CVS or .svn, and any subprojects in a multiproject build (each of which would be laid out as above).

The target directory is used to house all output of the build.

The src directory contains all of the source material for building the project, its site and so on. It contains a subdirectory for each type: main for the main build artifact, test for the unit test code and resources, site and so on.

Within artifact producing source directories (ie. main and test), there is one directory for the language java (under which the normal package hierarchy exists), and one for resources (the structure which is copied to the target classpath given the default resource definition).

If there are other contributing sources to the artifact build, they would be under other subdirectories: for example src/main/antlr would contain Antlr grammar definition files.

lunes, 6 de diciembre de 2010

Tunning your Maven project

Content:

Tunning your Maven proyect

Now let's suppose you want to build a new Maven project in SpringSource,

New Project -> Other -> Maven project.

You already know about the benefits of a Maven project and you want to roll your own like a library, without Spring dependencies.

As soon as you have created your project, you notice that your project doesn't have any resource folder as source folder. They doesn't exist in the folder hierarchy either. But you need those folder for Unit Testing (that is something that will be explained afterwards).

Round one, fight!

As a Eclipse user, the first you think is you may create those folders manually- Create a "resources" folder inside "main", and another "resources" inside "test", then register them as "source folders" in Properties -> Java Build Path -> Source -> Add Folder. By selecting the new folders you may access resource files throw classpath.

It's important to sort the order of folders in Order and Export tab, put your main/resources above your test/resources entry.

Now create three files, "a.xml" in "main/resources", a different copy of "a.xml" in "test/resources" and finally one "b.xml" in "test/resources".

Try it please. Then Run As -> Maven Install and you will get a jar file in your target project directory. Unzip your jar, you should find an "a.xml" with the content of "main/resources" and "b.xml".

What did it happened?

Maven will export every file in "source folders", compiled or not, that's the reason of the undesired existence of "b.xml". We shouldn't export our testing data!
If Maven finds two or more files with the same name, it is chosen by classpath priority, so it is important to tune it well in "Order and Export" tab.

Nevertheless, we don't find the result appropriate, because we don't want to export our testing data.

Take a look to your "Order and Export" tab, you can't uncheck your "Source folders" for exporting (the box at the right of the entry), so, this isn't a good solution.

Round two, fight!

Please delete both entries from "Source folders" in Properties -> Java Build Path.

Now go to "Libraries" tab in the same dialog. "Add class folder" and check your main and test "resource" folders.

Is it the same than before? no. Because now you can drift to your "Order and Export" tab and check your "main/resources" folder for exporting, and not the same for "test/resources" one.

Run As -> Maven Install. Unzip your Jar and see how magically you haven't exported your testing resources. :) Terrific.

DELETE your project, without deleting sources or resources. Only the project from your workspace. Reimport it like a "Existing Maven Project" and... Ops, you have lost all your classpath configuration. Yes, you can reimport like a Simple Project as well, but have now experienced what will happen when any of your workmates download your project from any cvs/svn/other repository.

Take a look to your ".classpath" file, there you have all your configuration. But this file won't be uploaded to the repository, and therefore, no mate will be able to export this library correctly.

You have draft this round too ;)

Round 3, fight!

By losing your second round, you must have noticed that you can't win this battle by using local classpath files. Indeed, you won't never export it to the repository, so the solution must be as exportable as functional.

Take a look to your "Java Build Path" again,

Let's take a look to your pom.xml file. It's quite clean, isn't it? Let's take a look to the "Super POM.xml" from Maven.

See the build entry:

<build>
    <directory>target</directory>
    <outputDirectory>target/classes</outputDirectory>
    <finalName>${artifactId}-${version}</finalName>
    <testOutputDirectory>target/test-classes</testOutputDirectory>
    <sourceDirectory>src/main/java</sourceDirectory>
    <scriptSourceDirectory>src/main/scripts</scriptSourceDirectory>
    <testSourceDirectory>src/test/java</testSourceDirectory>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
      </resource>
    </resources>
    <testResources>
      <testResource>
        <directory>src/test/resources</directory>
      </testResource>
    </testResources>
  </build>

Quite appealing, I will take it as is and drop it in my "pom.xml". Delete and reimport as Maven project.

That is what you will find:
.classpath independent, the information is in your "pom.xml" file.
Files under "testResource" member of "pom.xml" file won't be exported
Appropiate for sharing throw control version repositories, every mate will build the project correctly.

Epilogue

Now clean every fingerprint from this project, create a new one, create the same folders, the same files inside:

src/main/resources
a.xml

src/test/resources
a.xml (different)
b.xml

Delete the project, reimport it like a Maven one again... yes, Maven did it for you.

Those are the standard folders for a Maven project, and, by being standard, as far as you name your folder so, you won't have to configure they as testResource folders, and their content won't be ever exported.

You are 20% smarter than your mates, you woooon! :)

I will check my horrible English tomorrow. Enjoy this article as much as I enjoyed writing it.

domingo, 5 de diciembre de 2010

Maven

Content:

Maven abstract.