Showing posts with label MAVEN. Show all posts
Showing posts with label MAVEN. Show all posts

Saturday, August 24, 2013

Computing path to maven module base directory

Having spent a bunch of time writing functional tests for maven projects with many modules, I tend to end up needing access to the project base path (typically the path with the pom.xml file in it).  This isn't much of a problem when running a single module - new File(".") pretty much does it.  On the other hand when attempting to access modules outside of the jvm base path, things start to get tricky.

There's a couple ways to skin this cat - probably one of the more portable ones is a utility method that accepts a Class and a path and returns a File by checking the supplied Class' classloader:


        public static File getPathInModule(Class<?> classInModule,String ... items){
                String tcPath = classInModule.getProtectionDomain().getCodeSource().getLocation().getFile();
                String[] tcPathParts = StringUtils.split(tcPath,File.separator);
                StringBuffer pomPath = new StringBuffer();
                for(String part:tcPathParts){
                        pomPath.append(File.separator);
                        if("target".equals(part)){
                                break;
                        }
                        pomPath.append(part);
                }
                pomPath.append(StringUtils.join(items,File.separator));
                return new File(pomPath.toString());
        }
This works fairly well as long as there is a target directory present, which is for my purposes - always. It could be modified to look for a pom.xml file instead though.

Wednesday, August 21, 2013

Hadoop 3.0.0 maven repository

Recent maven hadoop artifacts are pretty hard to come by.  The central repository contains stable and 2.0.0-alpha releases, CDH repositories have 2.0.X releases, and the apache repository has 3.X snapshots.  That means if you want 2.3.X or 3.X functionality, you're either stuck pulling in snapshots or building/hosting your own releases.

The apache snapshots are problematic because individual build snapshots don't appear to be retained for very long.  Building/hosting your own artifacts seems like a pain.  Hopefully, this is a temporary issue until hadoop 3.X is released.  Until then, here's a maven repository that has (unofficial) 3.0.0 release artifacts with source jars.

It is pretty easy to put in pretty much any hadoop version into the repository.  Visit the project page or shoot me a email to request one!

Friday, September 9, 2011

First Project in Central Maven Repository - spring-event-router

I've started a few open source java projects built with maven before, but have always ended up using a private repository to host binaries.  One project of note was the CampusEAI portlet-archetype.  Though under a GPLv3 licence, the CampusEAI repository was not publicly accessible until very recently.  I am delighted that CampusEAI appears to have opened up their previously closed maven repository to the world.  The CampusEAI portlet-archetype is an exciting project that deserves a post of its own and is now publicly available at http://svn.campuseai.org/site/portlet-archetype/

Unfortunately, the CampusEAI repository has not been publicly accessible for almost a year after I left the company.  Noticing this, I have committed to publishing any future OSS Java work into the central maven repository.

I've been working a bit with Spring Framework ApplicationEvents at work and thought it would be neat to write a simple dispatch mechanism by which listeners could subscribe to specific types of events without tons of instanceof operations.  I saw a couple of posts on velocityreviews that contained snippets of code tackling similar issues.  There's even a google code proejct over at http://code.google.com/p/spring-custom-annotations/ that attempts to solve a similar problem with their "@EventListener" annotation.  That project appears to no longer be maintained and has some warnings against usage in production code.  In light of this, I decided to hack up some code myself and try out google code's new git source control as well as using Sonatype to publish my first artifacts into the Central Maven repository.

I put together a tiny library called "spring-event-router" hosted over at http://code.google.com/p/spring-event-router/ and followed the Sonatype OSS Maven Repository Usage Guide to try and publish my binaries to the Central Maven Repository.  Setting up a project with Sonatype was a (necessarily) manual process but it only took around 24h to get my first binaries into the repository.  The gist of the ordeal is creating a JIRA issue and having Sonatype review your project to validate some requirements before granting you the ability to stage and publish your artifact.  Once your artifact has been published, a secondary review is performed; upon completion any releases into the Sonatype repository are synced with Central on an hourly basis without further Sonatype oversight.

Though admittedly a very simplistic project, I was very happy with the ease of being able to use "mvn release:prepare; mvn release:perform" to publish artifacts into the central maven repository.  The binaries are available here and should resolve as valid dependencies for any maven project without the need of a custom section!