Re: Sorry and problem description
2008/6/23 Martin Höller [EMAIL PROTECTED]: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration !-- force to use JDK 1.6 -- encodingUTF-8/encoding source1.6/source target1.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 pluginsplugin or not. What works for me is having the following in my parent pom: project build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.5/source target1.5/target encodingISO-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry and problem description
Hi Andre! On Tuesday 24 June 2008 André Kelpe wrote: 2008/6/23 Martin Höller [EMAIL PROTECTED]: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration !-- force to use JDK 1.6 -- encodingUTF-8/encoding source1.6/source target1.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 groupIdyourGroupId/groupId artifactIdtheParentId/artifactId versionsomeVersion/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 pluginsplugin or not. What works for me is having the following in my parent pom: project build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.5/source target1.5/target encodingISO-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 signature.asc Description: This is a digitally signed message part.
Re: Sorry and problem description
Hi Martin! 2008/6/24 Martin Höller [EMAIL PROTECTED]: [...] 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 groupIdyourGroupId/groupId artifactIdtheParentId/artifactId versionsomeVersion/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 artifactIdmaven-release-plugin/artifactId version2.0-beta-7/version configuration tagBasesvn://foo/bar/baz/tagBase generateReleasePomstrue/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry and problem description
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId executions execution idattach-javadocs/id goals goaljar/goal /goals /execution /executions /plugin [...] and this is what will end up in the release-pom plugin artifactIdmaven-javadoc-plugin/artifactId versionRELEASE/version -- this is the problem configuration links linkhttp://java.sun.com/javase/6/docs/api//link /links aggregatetrue/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry and problem description
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 groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId executions execution idattach-javadocs/id goals goaljar/goal /goals /execution /executions /plugin [...] and this is what will end up in the release-pom plugin artifactIdmaven-javadoc-plugin/artifactId versionRELEASE/version -- this is the problem configuration links linkhttp://java.sun.com/javase/6/docs/api//link /links aggregatetrue/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 signature.asc Description: This is a digitally signed message part.
Re: Sorry and problem description
Hi Martin! 2008/6/23 Martin Höller [EMAIL PROTECTED]: 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 groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration !-- force to use JDK 1.6 -- encodingUTF-8/encoding source1.6/source target1.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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry and problem description
On Monday 23 June 2008 André Kelpe wrote: Hi Martin! 2008/6/23 Martin Höller [EMAIL PROTECTED]: 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 groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration !-- force to use JDK 1.6 -- encodingUTF-8/encoding source1.6/source target1.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 pluginsplugin or not. What works for me is having the following in my parent pom: project build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.5/source target1.5/target encodingISO-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 signature.asc Description: This is a digitally signed message part.
