Hi Andre!

On Tuesday 24 June 2008 André Kelpe wrote:
> 2008/6/23 Martin Höller <[EMAIL PROTECTED]>:
> >>       <plugin>
> >>         <groupId>org.apache.maven.plugins</groupId>
> >>         <artifactId>maven-compiler-plugin</artifactId>
> >>         <version>2.0.2</version>
> >>         <configuration>
> >>           <!-- force to use JDK 1.6 -->
> >>           <encoding>UTF-8</encoding>
> >>           <source>1.6</source>
> >>           <target>1.6</target>
> >>         </configuration>
> >>       </plugin>
> >>
> >> Why is this not present in the release-pom?
> >
> > First, the configuration needs not to be in the release-pom, as it's
> > (probably) inherited from the parent which is specified in the
> > release-pom and therefore available via a repository.
>
> I do not really understand what you mean by that.

Ok, let me explain it in more detail.

What you have is a parent project P and a child project C. The child 
specifies its parent via

  <parent>
    <groupId>yourGroupId</groupId>
    <artifactId>theParentId</artifactId>
    <version>someVersion</version>
    <relativePath>../wherever/parent/lives</relativePath>
  </parent>

in the pom.xml file. Is this correct?

The parent project P configures the compiler plugin via <pluginManagement> 
as described in my previous mail. Also correct?

If the above is true, C should inherit the configuration from P when 
building. AFIAK maven does not insert the configuration from P into C's 
pom.xml, as the configuration can always be retreived from P's pom.xml. 
That's the reason why maven inserts a version tag for your parent when 
releasing the child.

> The parent pom is in 
> a different directory and included via a relative path, which works
> w/o any problem for the dependencies so far.

Ok, I wouldn't expect any problem here.

> Do I have to change that to a released pom in our company maven repo?

You don't have to change that.

What you have to do is, to also release your parent's project to your repo. 
Otherwise the build of the child couldn't complete because of missing 
depedencies.

Unfortunately I'm not 100% sure if all details are completely correct, but 
the basics are.

> > Second, where exactly do you specify this section? Within a
> > <pluginManagement> section? I'm not sure wheter it is inherited if it
> > is in <plugins><plugin> or not. What works for me is having the
> > following in my parent pom:
> >
> > <project
> >  <build>
> >    <pluginManagement>
> >      <plugins>
> >        <plugin>
> >          <groupId>org.apache.maven.plugins</groupId>
> >          <artifactId>maven-compiler-plugin</artifactId>
> >          <version>2.0.2</version>
> >          <configuration>
> >            <source>1.5</source>
> >            <target>1.5</target>
> >            <encoding>ISO-8859-1</encoding>
> >          </configuration>
> >        </plugin>
> >      </plugins>
> >    </pluginManagement>
> >  </build>
> > </project>
>
> I tried exactly this, and it's not inherited into the release-pom.

What do you mean by "inherited"? Copyied into C's pom.xml? That's not the 
intention. It should be inserted into the reactor at runtime from the 
parent.

> > I mixed things up a little bit in my first mail: <dependencyManagement>
> > is for defining version of dependencies and <pluginManagement> is for
> > defining
> >
> > versions of plugins. What I wanted to write was:
> > | Just define the version of all plugins you are using (best in a
> > | <pluginyManagement> section),...
>
> Hmm, why are the docs/FAQ's not always mention that? Are these tags
> kind of implicit or why do so many examples simply omit them?

Probably because most examples want to stay simple and small. Using a 
<pluginManagement> in a parent is like specifying a default plugin version 
to use, if not explicitly specivied via the <version> tag in a subproject.

See the books "Better Builds with Maven" and "Maven - The Definitve Guide" 
for more explanations.

hth,
- martin

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to