Monday, June 1, 2009
CommunityOne first impressions
Thursday, March 19, 2009
Maven Meet Up at Sonatype part II
- Hosted - the repo lives on disk
- Proxy - this is a proxy to another repository
- Virtual - this allows you to convert between repository formats, say M1 is hosted, you can create a Virtual proxy that converts M1 to M2
You can schedule tasks like cleaning up snapshots. There are RSS feeds for most of the things Nexus does so you know the state of your repo. It will download remote repo indexes. There is no database required for Nexus. Nexus provides a full set of REST APIs to all its features.
The only time you use a repository URL directly in Nexus is when you want to deploy an artifact. With staging & promotion you don't even need to use a repo URL to deploy your artifacts. Why have a stating & promotion strategy? What if you want to test something before actually release it? Enter Nexus stating & promotion. All release deployments occur against a single REST URL in Nexus. The URL can be set once in the corp-pom for all projects, regardless of repository. With templates you can define how Nexus creates this new stating repo. Currently, you can only stage your binary artifacts but not your site artifacts. If you stage something many times and decide only to keep the last build, you'll need to manually remove all but the last site's you generated (this assumes that you don't overwrite your existing site with each release). Since all of Nexus is controlled by REST URLs, you can build your own work flow to control when a repo is promoted or not.
Next up is procurement, how to control what artifacts are available to your projects. Procurement is effectively a firewall that separates the users from another repository (or repo group) in the system. By default, everything is denied.
Sonatype is planning on multiple versions of Nexus: Nexus (open source version, free), Nexus Pro, Nexus Enterprise (HA, Federation, etc.) and Nexus Compliance (legal, etc.).
Maven Meet Up at Sonatype part I
Maven 3.0 will be fixing what we've learned in Maven 1.0 and 2.0. Layered repository, at the command line there is really only one repo, but in an env like Eclipse there are many repositories, other projects, so Maven 3.0 will have the concept of layered repositories. Jason said they have a lot of integration tests to ensure the backwards compatibility of Maven 3.0 with Maven 2.0. Personally, I hope it goes better than the Maven 2.0.8 to Maven 2.0.9 transition.
Plugin extension points, something borrowed from Eclipse, plugins will have extension points. This way you can extend a plugin without having to hack it. Plugins will also be able to tell Maven, here are my output directories, this way in Eclipse Maven will not need to run all the plugins to get their generated source dirs. This would be a big improvement.
Mercury is the new repository and transport layer for Maven. Why Mercury? Maven 2 has inaccurate conflict resolution, based on custom graph walking algorithm, hard to replace, API is too complex. The resolution mechanism is too coupled to Plexus, cannot use it from other environments. Mercury is a general purpose library for artifact and repository management. ArtifactMetadata - artifact comprehension info, not only do you need GAV (GroupId, ArtifactId, Version) but you also need classifier, type, etc. Mercury repos can be local or remote, readable or read/write, this helps optimize Mercury. It also supports global exclusions.
Mercury has it's own metadata cache to cache metadata for remove repositories. The new transport layer is a Jetty client, supports connection multiplexing (NIO), concurrent connections, SSL support. Webtide added stream verification , proxy support and authentication.
Oleg is now talking about Sonatype Proviso, a tool for updating binaries (e.g. Maven). Mercury Runner is a side project for Oleg, it gives you a way to run an application without defining a classpath. Attribute based resolution, we don't just care about a JAR, or it's version, we actually want to know about it's quality, etc. Like this:
<project> ... <version>1.2</version> ... <attributes> <servletApi>3.0</servletApi> <coverage:pmd>80</coverage:pmd> <quality>alpha</quality> </attributes> ... <project>
<dependency> <servletApi>[2.5,)</servletApi> <coverage:pmd>[80,)</coverage:pmd> </dependency>
Monday, February 16, 2009
SLC Tattoo Convention 2009
On Saturday night, my wife and I went to the SLC Tattoo Convention. It was a great way to spend Valentines day and Nicole said it was a great date. We saw a lot of amazing art and we were both inspired to spend more time on our art. As a result, I'm going to try and spend at least an hour a day for a year, or something close to that, on art.
My Dad was a professional artist and drawing was always a part of my childhood. That said, I haven't done much since. One of my boys loves to draw and he and I sometimes draw together, so I'm hoping he and my wife will join me on my 365 days of art.
So here it is, the first of at least 364 more drawings. I won't post them all here ;-)
Thursday, November 6, 2008
More Maven Best Practices @ ApacheCon by Brett Porter
- Set up your environment in advance
- A repository manager is a must (e.g. Archiva)
- Keep your POM simple, write your build like you write code
- Keep the build portable
- Avoid hard coding
- Make artifacts portable and minimize resource filtering
- Keep db config out of the project
- Make sure the build is reproducible
- Lock down versions, lock down environmental variations (don't rely on getting the latest, use version numbers)
- Use the Enforcer plugin (http://maven.apache.org/plugins/maven-enforcer-plugin/)
- Use this plugin to ensure other modules do not use automatic versions like latest and latestRelease
- Release your project early and often
- Transitive dependencies are a big part of Maven, however sometimes dependencies get messed up, use mvn dependency:tree to analyze your dependencies.
- Use enforcer plugin to ban specific dependencies and then you can use global exclusions to keep that dependency out of the project
- Specify only what you need, specify scope, USE dependencyManagement
- Use dependency:analyze, find out what you're using but not declaring, find out what you're declaring but not using
- Unfortunately, an afterthought in Maven 2.0.x, at least in lifecycle
- Tests in a separate module, tests in same project, you'll most likely need to use profiles
- In Maven, plugin ITs are in the project
- Using a separate project, most common pattern in Maven. If you're testing multiple modules put tests in another module
- create a parallel module, use the regular src/test/java directory, add a dependency on the module being tested, you will typically put this in a profile to control when it's run (e.g. in your CI env)
- If you are testing in the same project (e.g. a plugin or framework example), use another source dir, like src/it or use the src/test/java path and exclude a package from the general test so they can be used during integration testing (this is the easiest approach)
- There are two technologies working here, reporting and rendering, they are not the same thing!
- Site tips, avoid reports and documentation sites, some minimal project reports, like mailing lists, source repository may be relevant
- use site inheritance, just like in your pom, you can break down the site.xml file, they sit along side your pom.xml file
- Use versioning in the URL
- Include release notes in the versioned usage documentation
- Report tips
- Set up what you'll use! Don't create reports with thousands of issues
- It won't be used if, too much information or there is irrelevant information
- Don't settle for the default settings
- Use active checks, not passive reports, fail the build
- Use profiles to control reports, you don't need to run the reports all the time
- Sometimes it is easier to use a script for short, one-off, customizations, e.g. antrun plugin, jruby, groovy plugin, etc.
- If you might use it twice, consider writing a plugin
- Writing a plugin isn't a big deal, you can write it in Java, Ruby, Groovy, etc.
- Write your functionality in components, with the Mojo as a "wrapper"
- Minimize Maven API dependencies and component exposure, e.g. use maven-artifact, not maven-core (be aware of your dependencies, only use what you need)
- Do as we say, not as we do. Maven fails to implement many of these practices in various projects. Maven commiters learned the hard way!
Friday, August 8, 2008
Seam and Maven
- basic-settings, this is a parent pom project to define the JBoss repository, set your compiler to Java SE 5 (Maven defaults to Java SE 1.3), and sets some defaults for the Maven eclipse plugin.
- seam-dependencies this project defines all your Seam dependencies. You will use this as a dependency in your Seam project. This defines the Hibernate and Seam JARs you need to get your Seam application working.
- seam-example this is a sample application that uses both basic-settings and seam-dependencies, to illustrate how to put it all together. This application is a simplified version of the JPA-booking example that comes with Seam.
- basic-settings
- seam-dependencies
cd seam-example
mvn jetty:run
You can access the app from port 9090, using this URL: http://localhost:9090/seam-example
I also did a Seam presentation at the July 2008 UJUG meeting. You can see the presentation here.
Wednesday, April 2, 2008
Accepted into the iPhone Developer Program
Thursday, March 6, 2008
iPhone SDK now available
Sunday, March 2, 2008
JavaPosse Roundup 2008
- Episode 9, interview with Josh Bloch
- Episode 14, interview with Jonathan Schwartz
- Episode 25, first episode with Joe Nuxoll
- Episode 32, interview with Gavin King
- Episode 70, interview with Brett Porter of Maven
- Episode 99.5, interview with Charles Nutter and Thomas Enebo (JRuby)
- Episode 100, the number says it all
- Episode 107, special from JavaPosse Roundup 2007
- Episode 155, interview with Martin Odersky (Scala)