Links

  • 1. Sogeti
  • 2. JBoss
  • 3. IBM
  • 4. Oracle
  • 5. SpringSource
  • 6. NL-JUG
  • 7. Java

Archives

Syndication  RSS 2.0

RSS 1.0
RSS 2.0

Bookmark this site

Add 'JCN Blog' site to delicious  Add 'JCN Blog' site to technorati  Add 'JCN Blog' site to digg  Add 'JCN Blog' site to dzone

Posted by wingerma at 9:43 on Friday 3 August    Add 'Maven – missende plug-in-versies' site to delicious  Add 'Maven – missende plug-in-versies' site to technorati  Add 'Maven – missende plug-in-versies' site to digg  Add 'Maven – missende plug-in-versies' site to dzone

Wanneer mijn tooling waarschuwingen geeft, ben ik altijd alert en misschien zijn het zelfs zenuwen. Wat is hier aan de hand? Hoe kunnen we dit oplossen? Bij het inwerken op een nieuw project viel het mij op dat er veel Maven-waarschuwingen waren tijdens het bouwen van de applicatie. Van de waarschuwing ging 85% over missende plug-in-versies.

[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-jar-plugin is missing. @ line 60
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.

In mijn eerste poging om het op te lossen heb ik bij alle plug-ins de ‘latest-and-greatest’-versie ingesteld, maar was dat wel zo’n goed idee? Omdat we ons project voor zowel Glassfish als WebSphere bouwen is er meer wat er mis kon gaan, en dingen die mis kunnen gaan, gaan natuurlijk mis. De build voor Glassfish was perfect, geen vuiltje aan de lucht en hij deployde nog steeds probleemloos.

Drie weken later, ik was alweer bijna vergeten dat ik de plug-in-versies aangepast had, wilden we weer een keer deployen op IBM WebSphere. Het werkte niet meer en namen en beschrijvingen van de EAR die in dialogs werden weergegeven zagen er ook anders uit. Ondertussen had ik toch al gauw 30 keer gecommit en India ook nog enkele. Na een tijdje doelloos zoeken, heb ik met behulp van een binary-search de fout-veroorzakende commit opgezocht. En zoals jullie nu allemaal al verwachten kwam het uiteindelijk uit een zeer onschuldig ogende commit waar ik versienummers aan de plug-ins had toegevoegd. Maar dan is nu natuurlijk de grote vraag waarom ging het mis? En hoe kunnen we de waarschuwing kwijt raken zonder onze applicatie te schaden?

Toevallig zat ik die dag naast Ron Bierman, die wist me te vertellen dat elke versie van Maven zijn eigen standaard plug-in-versies heeft welke gebruikt worden wanneer je zelf geen versies definieert. Dit verklaart ook meteen de waarschuwing en nog belangrijker waarom we in het betreffende project nog steeds met Maven 2.2.1 moesten blijven werken. Ok, nu zijn we ergens, maar we kunnen weer blijven builden met de oude Maven-versie zonder expliciete versienummers maar dat wilde we juist niet. Dus moeten we de impliciete versienummers zien te achterhalen, ook daar kon Ron mij de goede richting wijzen. Met `mvn site` kun je een rapport maken van je project, een van de onderdelen van dit rapport zijn de plug-in-versies die te vinden zijn onder ‘Project Build Plugins’.

Screenshot of project build plugins page of the report

Het bleek inderdaad dat de versienummers die ik gekozen had totaal niet overeenkwamen met de versienummers die Maven 2.2.1 standaard gebruikte en dit nekte ons dus bij het builden van onze EAR voor WebSphere.

Wanneer je dus de waarschuwingen over missende plug-in-versies wil oplossen of wilt overstappen naar een nieuwe versie van Maven en daaraan twijfelt omdat je afhankelijk bent van bepaalde plug-in-versies. Bepaal dan eerst met `mvn site` welke plug-in-versies je gebruikt en definieer deze vervolgens expliciet in je pom.xml.

Posted by Martijn van de Rijdt at 12:41 on Wednesday 20 October    Add 'Maven dependency:tree' site to delicious  Add 'Maven dependency:tree' site to technorati  Add 'Maven dependency:tree' site to digg  Add 'Maven dependency:tree' site to dzone

If you’re interested in getting a quick overview of your Maven project’s dependency structure, the dependency:tree plugin is a very useful tool. Just run the following:

mvn dependency:tree

and you’ll get a nice overview of all of the artifacts your project depends on, directly and indirectly, displayed as a tree structure.

Now say you have a parent project containing a lot of modules (perhaps even nested) and you still want an overview of all of their dependencies. You could just run dependency:tree on the parent project, but that would output a huge list of all of the dependency trees, cluttered up with Maven’s informational log messages. You could also run dependency:tree on each individual leaf project, but that would be a bit of a hassle.

A better solution is to run the following on your parent project:

mvn dependency:tree -DoutputFile=D:\temp\dependencies-${project.artifactId}.txt

This will create some text files in your D:\temp directory, named after your projects’ artifact ids. Each of these text files will contain the corresponding project’s dependency tree.

Of course you can also use other Maven variables (like ${project.groupId} and ${project.version}) in the filenames.

Posted by Willem van de Griendt at 23:55 on Wednesday 13 October    Add 'Maven 3.0 Release Switches to Google’s Guice Framework' site to delicious  Add 'Maven 3.0 Release Switches to Google’s Guice Framework' site to technorati  Add 'Maven 3.0 Release Switches to Google’s Guice Framework' site to digg  Add 'Maven 3.0 Release Switches to Google’s Guice Framework' site to dzone

Version 3.0 of Maven, a free, open-source Java build tool, was released this week and is now available for download. This release, the first major upgrade since Maven 2.0 was released in October 2005, emphasizes performance and architectural enhancements, rather than features. Sponsored and licensed by the Apache Software Foundation (ASF), Maven is an open-source framework and repository for building and managing any Java-based project. Read more on Application Development Trends…

Posted by Martijn van de Rijdt at 18:48 on Saturday 14 August    Add 'Building a JavaFX project with Maven' site to delicious  Add 'Building a JavaFX project with Maven' site to technorati  Add 'Building a JavaFX project with Maven' site to digg  Add 'Building a JavaFX project with Maven' site to dzone

JavaFX is a fairly new language, so I was curious to see if Maven plugins to build JavaFX projects were already available. After considering the FEST JavaFX Plugin and after a failed attempt to get the Plexus Compiler Component for javafxc working, I decided to try out the JFrog JavaFX Compiler Maven Plugin.

Read the rest of this entry »

Posted by Ron Lievens at 13:59 on Wednesday 2 December    Add 'Mijn standaard Jave/Eclipse ontwikkel omgeving' site to delicious  Add 'Mijn standaard Jave/Eclipse ontwikkel omgeving' site to technorati  Add 'Mijn standaard Jave/Eclipse ontwikkel omgeving' site to digg  Add 'Mijn standaard Jave/Eclipse ontwikkel omgeving' site to dzone

Na aanleiding van verschillede discussies over hoe de Java/Eclipse ontwikkel omgeving er uit moet zien, heb ik een voorstel voor een standaard Java/Eclipse ontwikkel omgeving gemaakt.

Mijn voorstel maakt volledig gebruik van open source tooling en is toegespitst op code kwalitie. Mijn voorstel bevat Apache Ant, Apache Maven2, Subversion, CheckStyle en Findbugs intergratie met Eclipse. Verder maakt mijn voorstel gebruik van de EclEmma eclipse plugin voor code dekking en uiteraard maak ik gebruik van de JCN Style Guide in Eclispe.

Read the rest of this entry »

Posted by Barend Garvelink at 23:08 on Thursday 28 August    Add 'maven-tstamp-plugin' site to delicious  Add 'maven-tstamp-plugin' site to technorati  Add 'maven-tstamp-plugin' site to digg  Add 'maven-tstamp-plugin' site to dzone

Since (almost) the dawn of time, ant has had the <tstamp/> task to define build date and time properties in your build for filtering resource files. Maven has no such thing. They do have a workaround which requires a temporary file on the filesystem. A google search on "maven bulid date" takes you to the maven-buildnumber-plugin, which I’m sure works fine but it does more than I need and a few things I don’t need (like access the SCM system). So I wrote a quick maven-tstamp-plugin to match the ant task. The configuration is a bit more verbose, but simple to understand.

Here’s a sample config…

<plugin>
  <groupId>nl.sogeti.jcn.maven.plugins</groupId>
  <artifactId>maven-tstamp-plugin</artifactId>
  <version>1.0</version>
  <configuration>
    <!-- All properties prefixed with 'build.' -->
    <prefix>build.</prefix>
    
    <!-- UNIX timestamp published as 'build.unix-timestamp' -->
    <timestamp>unix-timestamp</timestamp>
    <properties>
      <!-- Publishes build.sortableDate, default locale, default timezone -->
      <sortableDate>yyyy-MM-dd</sortableDate>
      
      <!-- Publishes build.prettyDate, Argentina's locale and timezone -->
      <prettyDate>EEEE d MMMM yyyy, H:mm</prettyDate>
      <prettyDate.locale>es_AR</prettyDate.locale>
      <prettyDate.zone>America/Argentina/Buenos_Aires</prettyDate.zone>
      
      <!-- Publishes build.utc-stamp (calendar-based timestamp) in UTC. -->
      <utc-stamp>yyyyMMddHHmmss</utc-stamp>
      <utc-stamp.zone>UTC</utc-stamp.zone>
    </properties>
  </configuration>
</plugin>

…which I think speaks for itself. Each of the properties defined can be used in ${filtering} expressions. I didn’t require the offset/unit feature in the original <tstamp/> task, nor did I require Joda-Time’s support for nonwestern calendar systems. I’ve reserved suffixed for both, but they currently just cause the property to be ignored.

Source code after the jump.

Read the rest of this entry »

Posted by Barend Garvelink at 19:44 on Thursday 18 January    Add 'Java EE api’s in Maven repo' site to delicious  Add 'Java EE api’s in Maven repo' site to technorati  Add 'Java EE api’s in Maven repo' site to digg  Add 'Java EE api’s in Maven repo' site to dzone

Eén van de problemen met Maven is tot nu toe steeds geweest dat de Java EE API’s niet in de centrale repository stonden. Een probleem met de binary license van Sun, nu opgelost met de GPL. Java EE 1.5 op Maven.

Posted by Hans-J├╝rgen Jacobs at 19:15 on Thursday 8 September    Add 'Building J2EE Projects with Maven' site to delicious  Add 'Building J2EE Projects with Maven' site to technorati  Add 'Building J2EE Projects with Maven' site to digg  Add 'Building J2EE Projects with Maven' site to dzone

Vincent Massol offers some real-life experience building J2EE applications with Maven. Using the example of a Petstore app, Massol shows you how to generate J2EE artifacts (EJB JARs, WARs, EARs) with Maven. He is coauthor of Maven: A Developer’s Notebook. [onjava.com]


© 2020 Java Competence Network. All Rights Reserved.