You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by André Kelpe <ef...@googlemail.com> on 2008/06/23 10:52:56 UTC

Sorry and problem description

Hello again,

big apologies for the premature email. Seems like I did not have enough caffeine
today :-)

I hope someone can help me, so here is now my problem:

In the company I work for we have a somewhat big maven2 setup which is working
quite good so far. We now wanted to organize our release process in a more
structured way (esp. release-poms) to avoid problems with version ranges and I
found the maven release plugin, which looks like it can solve all our problems.
Currently I am trying to set it correctly up, but I always encounter a problem,
which is that the release pom is not correctly created. For all plugins that we
use the version number in the release-pom is set to "RELEASE" instead of the
actual version number. Here is an example:

This is in the master pom:
[...]
<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-javadoc-plugin</artifactId>
 <executions>
   <execution>
     <id>attach-javadocs</id>
     <goals>
       <goal>jar</goal>
     </goals>
   </execution>
 </executions>
</plugin>
[...]

and this is what will end up in the release-pom

<plugin>
 <artifactId>maven-javadoc-plugin</artifactId>
 <version>RELEASE</version>  <-- this is the problem
 <configuration>
   <links>
     <link>http://java.sun.com/javase/6/docs/api/</link>
   </links>
   <aggregate>true</aggregate>
 </configuration>
</plugin>

Because of these broken version numbers the verify phase will fail and
I cannot use the release plugin at all. What am I doing wrong?

Thanks a lot for your help and apologies for my first email.

André

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Sorry and problem description

Posted by André Kelpe <ef...@googlemail.com>.
Hi again:

Replying to myself: After googling and searching JIRA I found this
http://jira.codehaus.org/browse/MRELEASE-294 and since it's still
open. The way I intended to use the plugin does not work right now. Is
there any way I can help out to get that problem fixed and a new
release out?

Andre

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Sorry and problem description

Posted by André Kelpe <ef...@googlemail.com>.
Hi Martin!

2008/6/24 Martin Höller <ma...@xss.co.at>:
[...]
> 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?

Yes.

> 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.

Okay, maybe I wasn't explicit enough I am not talking about the normal
use case I am talking about the usage of the release plugin, where you
specify in the config to generate a release pom, like so:
<build>
      <plugin>
        <artifactId>maven-release-plugin</artifactId>
        <version>2.0-beta-7</version>
        <configuration>
          <tagBase>svn://foo/bar/baz</tagBase>
          <generateReleasePoms>true</generateReleasePoms>
        </configuration>
      </plugin>
<build>

This is what I have in the child projects pom and this also ends up in
the release-pom.xml which the release plugin generates. But what I
found out is that all other plugins defined in the <build> tag of the
_parents_ pom are completely ignored and do not end up in the
release-pom.xml, which is, what I would expect as that works for all
other stuff coming from the parent pom like reporting, dependencies or
repositories. To make it more clear: I try to create a pom that is
completely frozen (no version ranges etc.) to be checked in to be able
to rebuild any release in the future w/ the ability to use version
ranges during development. That is what the release plugin promises
and does except for the configuration for plugins in the build section
of the parent pom, from what I can see so far.

>> 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.

As I said, the generated release-pom.xml does not contain any of the
settings defined in the build tag of the parent pom. Bug? Feature?
Wrong understanding?


> 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.

Will digg into those once again, but I have tried to find answers
there, maybe I just overlook something obvious.

Thanks again!

Andre

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Sorry and problem description

Posted by Martin Höller <ma...@xss.co.at>.
Hi Andre!

On Tuesday 24 June 2008 André Kelpe wrote:
> 2008/6/23 Martin Höller <ma...@xss.co.at>:
> >>       <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

Re: Sorry and problem description

Posted by André Kelpe <ef...@googlemail.com>.
2008/6/23 Martin Höller <ma...@xss.co.at>:
>>
>>       <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. 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. Do I have to change that
to a released pom in our company maven repo?

> 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.


> 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? In any
case, adding them did not really solve my problem.

Thanks again!

Andre

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Sorry and problem description

Posted by Martin Höller <ma...@xss.co.at>.
On Monday 23 June 2008 André Kelpe wrote:
> Hi Martin!
>
> 2008/6/23 Martin Höller <ma...@xss.co.at>:
> > You probably didn't define a version for the maven-javadoc-plugin in
> > this projects pom or a parent pom, so maven (prior to 2.0.9) defaults
> > to RELEASE.
>
> You were right, I didn't do that. I updated the parent pom and now I
> can enter the validation phase but there I encounter the next problem:
>
> The forked validate tries to compile all sources with compliance level
> 1.3 which will fail b/c we use generics etc. The strange thing is that
> the parent pom sets the compiler plugin to compliance level 1.6, which
> was never a problem, but somehow this setting is not carried over into
> the release-pom.xml. Here is how the compiler plugin is configured in
> the parent pom:
>
>       <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.

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>

> > Just define the version of all plugins you are using (best in a
> > <dependencyManagement> section), which is a best practice anyway. This
> > should solve your problem.
>
> Never heard of the dependencyManagement before, will take a look.

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),...

hth,
- martin

Re: Sorry and problem description

Posted by André Kelpe <ef...@googlemail.com>.
Hi Martin!

2008/6/23 Martin Höller <ma...@xss.co.at>:

> You probably didn't define a version for the maven-javadoc-plugin in this
> projects pom or a parent pom, so maven (prior to 2.0.9) defaults to
> RELEASE.

You were right, I didn't do that. I updated the parent pom and now I
can enter the validation phase but there I encounter the next problem:

The forked validate tries to compile all sources with compliance level
1.3 which will fail b/c we use generics etc. The strange thing is that
the parent pom sets the compiler plugin to compliance level 1.6, which
was never a problem, but somehow this setting is not carried over into
the release-pom.xml. Here is how the compiler plugin is configured in
the parent pom:

      <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?

> Just define the version of all plugins you are using (best in a
> <dependencyManagement> section), which is a best practice anyway. This
> should solve your problem.

Never heard of the dependencyManagement before, will take a look.

Thanks!

Andre

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Sorry and problem description

Posted by Martin Höller <ma...@xss.co.at>.
On Monday 23 June 2008 André Kelpe wrote:
> In the company I work for we have a somewhat big maven2 setup which is
> working quite good so far. We now wanted to organize our release process
> in a more structured way (esp. release-poms) to avoid problems with
> version ranges and I found the maven release plugin, which looks like it
> can solve all our problems. Currently I am trying to set it correctly up,
> but I always encounter a problem, which is that the release pom is not
> correctly created. For all plugins that we use the version number in the
> release-pom is set to "RELEASE" instead of the actual version number.
> Here is an example:
>
> This is in the master pom:
> [...]
> <plugin>
>  <groupId>org.apache.maven.plugins</groupId>
>  <artifactId>maven-javadoc-plugin</artifactId>
>  <executions>
>    <execution>
>      <id>attach-javadocs</id>
>      <goals>
>        <goal>jar</goal>
>      </goals>
>    </execution>
>  </executions>
> </plugin>
> [...]
>
> and this is what will end up in the release-pom
>
> <plugin>
>  <artifactId>maven-javadoc-plugin</artifactId>
>  <version>RELEASE</version>  <-- this is the problem
>  <configuration>
>    <links>
>      <link>http://java.sun.com/javase/6/docs/api/</link>
>    </links>
>    <aggregate>true</aggregate>
>  </configuration>
> </plugin>

You probably didn't define a version for the maven-javadoc-plugin in this 
projects pom or a parent pom, so maven (prior to 2.0.9) defaults to 
RELEASE.

Just define the version of all plugins you are using (best in a 
<dependencyManagement> section), which is a best practice anyway. This 
should solve your problem.

hth,
- martin