Re: [Geotools-devel] UTF-8 or Bust!

[Mark P. <mc....@gm...>]

2012/5/30 Jody Garnett <jod...@gm...>:
> On Tuesday, 29 May 2012 at 8:27 PM, Mark Prins wrote:
>
> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
>
> Thanks that did the trick; adding to the root pom.
>
> The next set of warnings we have is more tricky:
>
>
> [WARNING] Some problems were encountered while building the effective model
> for org.geotools.maven:jar-collector:maven-plugin:8-SNAPSHOT
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-resources-plugin is missing. @
> org.geotools:geotools:8-SNAPSHOT,
> /Volumes/Fiore/jody/java/geotools/trunk/pom.xml, line 1159, column 15
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-compiler-plugin is missing. @
> org.geotools:geotools:8-SNAPSHOT,
> /Volumes/Fiore/jody/java/geotools/trunk/pom.xml, line 1136, column 15
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-surefire-plugin is missing. @
> org.geotools:geotools:8-SNAPSHOT,
> /Volumes/Fiore/jody/java/geotools/trunk/pom.xml, line 1190, column 15
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-source-plugin is missing. @
> org.geotools:geotools:8-SNAPSHOT,
> /Volumes/Fiore/jody/java/geotools/trunk/pom.xml, line 1246, column 15
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-jar-plugin is missing. @
> org.geotools:geotools:8-SNAPSHOT,
> /Volumes/Fiore/jody/java/geotools/trunk/pom.xml, line 1224, column 15
> [WARNING] 'reporting.plugins.plugin.version' for
> org.apache.maven.plugins:maven-project-info-reports-plugin is missing. @
> org.geotools:geotools:8-SNAPSHOT,
> /Volumes/Fiore/jody/java/geotools/trunk/pom.xml, line 1324, column 15
> [WARNING] 'reporting.plugins.plugin.version' for
> org.apache.maven.plugins:maven-jxr-plugin is missing. @
> org.geotools:geotools:8-SNAPSHOT,
> /Volumes/Fiore/jody/java/geotools/trunk/pom.xml, line 1349, column 15
> [WARNING]
>
> It amounts to a request that we nail the version numbers to the wall[1]
> using; although it looks like we can do that once in our root pom.
> The downside of this would be the project committing to the use of Maven 3.
>

the maven way to handle this is to define a <pluginManagement> section
 in the parent pom (actually there are already two plugins defined
there)

The good thing about defining a plugin version is that the build does
not automatically use the latest locally available version (which may
be different for everyone) making all the builds consistent (who ever
uses the -up/ -cpu or -U options?), the drawback is that with
supporting both mvn 2 and 3 build from the same set of poms, there
will be incompatibilities in the plugins (eg. multi-threaded builds
and reporting most common). There is a way around this using profiles
(eg. mvn2 and mvn3) that define the version numbers as properties for
the incompatible plugins, but things may get quite complex..

eg.
...
<profile>
      <id>mvn3</id>
        <file>
          <!--  This employs that the basedir expression is only
recognized by Maven 3.x (see MNG-2363) -->
          <exists>${basedir}</exists>
        </file>
      <properties>
        <some.plugin.version>1.2.3
...

<build>
<plugins>
<plugin>
    <groupId>some
    <artifactId>some.plugin
    <version>$some.plugin.version
...

> Currently I am working with Maven 3.0.3. Anyone still using Maven 2?

I can only recommend upgrading to 3.0.4 (at least from 3.0.3), there
were many improvements in de dependency handler/resolver and related
downloader libs.

Mark

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of
sending. The message may contain information that is not intended for
you or that you don't understand.