The Basement Coders Developer Podcast

Brian gave us some excellent insider knowledge on Maven 3 (and Maven in general), what it means for all of us who will be upgrading from Maven 2.x and a detailed overview of the killer features packed into Maven 3 including Parallel Builds and the new Repository API. We thank Brian very much for his excellent answers!

• No bookmarks avaliable.

Listen here:

Download

Enjoy!

An exclusion is a dependency you do not want used when building your project. For instance, if you have a parent project which declares a dependency in it's dependencyManagement section, and that dependency has a transitive dependency that you don't want to be used (i.e. an old version of JAXB) you can exclude the transitive dependency like so:

<dependencyManagement>
<dependencies>
  <dependency>
    <groupId>some.group</groupId>
    <artifactId>some.artifact</artifactId>
    <exclusions>
       <exclusion>
          <groupId>javax.xml</groupId>
          <artifactId>jaxb-xjc</artifactId>
       </exclusion>
    </exclusion>
  </dependency>
</dependencies>
</dependencyManagement>

However, if you have a child project which references the parent containing the exclusion, and the child project itself places another exclusion on the same dependency:

<dependencyManagement>
<dependencies>
  <dependency>
    <groupId>some.group</groupId>
    <artifactId>some.artifact</artifactId>
    <exclusions>
       <exclusion>
          <groupId>javax.xml.parsers</groupId>
          <artifactId>jaxp-api</artifactId>
       </exclusion>
    </exclusion>
  </dependency>
</dependencies>
</dependencyManagement>

It's not like both jaxb-xjc and jaxp-api will be excluded from your build. In fact, when the child specifies its exclusion, that exclusion "wins". It overrides any exclusions specified in the parent's dependencyManagement section.

mvn -X [your goals here] helps a lot when trying to debug which dependencies are actually being used in a build of your code. So for instance: mvn -X clean install will dump out diagnostic info about what JVM you are running, as well as an "mvn dependency:tree" type output of the dependencies being used in your build.

Hope this helps someone else banging their heads against the wall trying to figure out why their exclusions aren't working!

Integration--the process of porting ones build artifacts from a development to end production environment--in my mind is the biggest unknown for a software project. Production environments are usually locked down, log files are hard to get to and requests for provisions or server resets -- long to wait for. What's even worse? When your integration process involves not only the end goal of "hosting" your application, but also incorporates build and deploy processes and policies that directly affect your code base.

For instance, a client I worked for needed a site. They provided a nice set of requirements and wireframes, in fact they provided all visual aspects for the site mocked as ASP pages (including the AJAX elements). What more could I ask for? It seemed like the perfect storm, a developer I hired would swoop in and add the dynamic elements to the site and we would be done in no time.

We weren't limited in the frameworks we chose in fact early on it was assumed the client only cared that the end result ran fine under IBM WAS. No problem (I thought), WAS is a servlet container and that's the beauty of Java web development, there is actually a spec describing the functionality of application servers. This means that the application being produced should operate in a bubble of sorts, it should know nothing (well that's not always possible) of where it's living, it's just a war and it needs a place to live.

Then reality kicked in. About a few weeks into the project the client presented a "Build and Deployment process for the <insert internal acronym> environment" document. As far as the build document was concerned Ant was the only real requirement. Their continuous integration (CI) tool however did support Maven which was great because Maven is what I used. So, with too much trust in the reasonability of clients we continued on our development path.

Read more...