Must the next parent SNAP exist for a downstream artifact release:perform to work ?
A little difficult to explain, but here goes:
We branch from trunk and then release our parent and core together
from SNAPs on our branches. For example,
com.blifnok
main-parent
3.23.0-SNAPSHOT
com.blifnok
core
jar
3.23.0-SNAPSHOT
I cut the 3.23.0 release of main-parent, but the subsequent perform on
core fails with
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot
find parent: com.blifnok:main-parent for project:
com.blifnok:core:jar:3.23.1-SNAPSHOT for project
com.blifnok:core:jar:3.23.1-SNAPSHOT
The perform appears to be looking for the next development version,
instead of just building the 3.23.0 version of the artifact. Here are
the release.properties created by the prepare:
#release configuration
#Fri Apr 20 14:10:11 PDT 2012
dependency.com.blifnok\:main-parent.release=3.23.0
scm.tagNameFormat=@{project.artifactId}-@{project.version}
scm.tag=3.23.0
dependency.com.blifnok\:main-parent.development=3.23.1-SNAPSHOT
pushChanges=true
scm.url=scm\:svn\:file\:///opt/svnroot/main/core/branches/3.23.x
preparationGoals=clean verify
project.dev.com.blifnok\:core=3.23.1-SNAPSHOT
remoteTagging=true
scm.commentPrefix=[maven-release-plugin]
project.scm.com.blifnok\:core.tag=HEAD
project.rel.com.blifnok\:core=3.23.0
exec.additionalArguments=-DskipTests\=true -P nexus
exec.snapshotReleasePluginAllowed=false
project.scm.com.blifnok\:core.developerConnection=scm\:svn\:file\:///opt/svnroot/main/core/branches/3.23.x
completedPhase=end-release
Obviously, I can just build this SNAPSHOT, but why is the perform
trying to resolve the next parent development version? Is the phase
using "dependency.com.blifnok\:main-parent.development=3.23.1-SNAPSHOT"
instead of "dependency.com.blifnok\:main-parent.release=3.23.0" ? Or,
is it reading this from the pom that was changed by the prepare?
Perhaps, there is a convention or best practice I am unaware of OR
maybe a bug ?
Thanks
--
James Levinson
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: checkModificationExclude NOT ignoring modified files
Continuing my own thread here regarding maven-release-plugin release:branch,
I discovered that the comparison
in org.apache.maven.shared.release.phase.ScmCheckModificationsPhase.execute()
strips the path and compares file names only. So, I changed my pom to ignore
application.properties instead of ${thewholepath}/applications properties.
Lo and behold, success.
However, what I thought would happen did not happen and it makes me question
my understanding of the intent of checkModificationExcludes. I thought I
could modify files, call branch and have them be committed to the branch in
their modified state. This does not happen. A branch gets created and the
pom gets checked in but the files I want on the branch do not. So, what was
the intention of checkModificationExcludes? Was it just for any versioned
file in the project root?
Further, regarding my use-case, can anyone recommend a better way to modify
files at branch time. Currently, we have a script we run after we branch,
but I was looking for something a bit more elegant, that could be part of
the pom.
Thanks, James
On Sun, Oct 23, 2011 at 10:56 AM, James Levinson
wrote:
> I am trying to do a simple replace in 2 files when I release:branch. I
> thought checkModificationExcludes looked like it would make it possible to
> modify the files and have them be on my branch, but it's not working for me.
>
> I added the following profile to my pom:
>
>
> branch
>
>
> branch
>
>
>
>
>
> org.codehaus.mojo
> build-helper-maven-plugin
> 1.7
>
>
> verify
> parse-version
>
> parse-version
>
>
>
>
>
>
> com.google.code.maven-replacer-plugin
> maven-replacer-plugin
> 1.3.9
>
>
> verify
>
> replace
>
>
>
>
>
>
>
> src/test/resources/config/dev/hudson/application.properties
>
> src/test/resources/config/dev/jenkins/application.properties
>
>
>
> poseur_test
>
> poseur_test_${parsedVersion.majorVersion}_${parsedVersion.minorVersion}_branch
>
>
>
>
>
> org.apache.maven.plugins
> maven-release-plugin
> 2.1
>
>
>
> src/test/resources/config/dev/hudson/application.properties
>
> src/test/resources/config/dev/jenkins/application.properties
>
> pom.xml
>
>
>
>
>
>
>
> I run the following on my command line, the replace occurs:
>
> mvn build-helper:parse-version replacer:replace release:branch -Pbranch
> -DdryRun=true -DbranchName=3.15.x -X -e
>
> I get the following output:
>
> [INFO] [release:branch {execution: default-cli}]
> [DEBUG] release.properties not found - using empty properties
> [INFO] Verifying that there are no local modifications...
> [INFO] ignoring changes on: pom.xml.next, release.properties,
> pom.xml.releaseBackup,
> src/test/resources/config/dev/jenkins/application.properties,
> pom.xml.backup, pom.xml, pom.xml.branch,
> src/test/resources/config/dev/hudson/application.properties, pom.xml.tag
> [INFO] Executing: /bin/sh -c cd
> /Users/jameslevinson/workspace/main/rate/trunk && svn --non-interactive
> status
> [INFO] Working directory: /Users/jameslevinson/workspace/main/rate/trunk
> [DEBUG] ? pom.xml.releaseBackup
> [DEBUG] M src/test/resources/config/dev/hudson/application.properties
> [DEBUG] M
> src/test/resources/config/dev/jenkins/application.properties
> [DEBUG] M pom.xml
> [INFO]
>
checkModificationExclude NOT ignoring modified files
cation.properties:modified]
[INFO]
[DEBUG] Trace
org.apache.maven.BuildFailureException: Cannot prepare the release because
you have local modifications :
[src/test/resources/config/dev/hudson/application.properties:modified]
[src/test/resources/config/dev/jenkins/application.properties:modified]
As you can see the exclusions are in the checkModificationExcludes array,
but they are not being "ignored" when the svn status runs. Oddly, when I add
pom.xml to the ignores, it gets ignored, but I have not been able to get the
files to be ignored. How are the arrays being compared? I have tried every
which way to run it, using the cmd line to pass
in checkModificationExcludeList, pre-pending ${basedir}, re-ordering the
plugins. I tried version 2.1 and 2.2.1. Same result. I have found
http://jira.codehaus.org/browse/MRELEASE-554, which indicates the
functionality is there, but again, I can't get it to work.
Anybody ever try this with success ?
--
**
*James Levinson*
Senior Release Engineer
*
Opower
* <http://www.opower.com/>
*
**
We’re hiring! See jobs here <http://www.opower.com/careers>
*
Re: second zip artifact from the same pom?
I wanted to thank you for responding and giving me a good head start on the
maven-assembly-plugin. The documentation is Excellent and they are powerful
indeed. I also wanted to share the very simple solution to building the zip
file:
--in my profile sections for different env's I have the assembly plugin
activation "attached" to the package phase
maven-assembly-plugin
src/assembly/assembly.xml
make-assembly
package
attached
--and for the descriptor itself, all I needed was a fileSet
static-assembly
zip
false
false
style/**
js/**
images/**
target/${hard-coded-final-name}
/
Thanks again, James
using release plugin with a profile and distributionManagement section
I have been able to use profiles with the standard "mvn deploy", but when I try to run mvn release:perform (after prepare) I get the error below. My distributionManagement is inside my profile in my pom, but the plugin can't seem to find it. Perhaps, I am not understanding the plugin properly. Does anybody have this working ? Thanks. ==ERROR== [ERROR] BUILD ERROR [INFO] [INFO] Failed to configure plugin parameters for: org.apache.maven.plugins:maven-deploy-plugin:2.3 check that the following section of the pom.xml is present and correct: repo Repository Name scp://host/path/to/repo repo Repository Name scp://host/path/to/repo Cause: Class 'org.apache.maven.artifact.repository.ArtifactRepository' cannot be instantiated ==PROFILE== prod org.apache.maven.plugins maven-surefire-plugin true prod prod-releases Managed Releases Repository file:///mnt/code/repository/releases ==CMDLINE== 1) mvn deploy -P prod --this works 2) mvn release:perform -P prod --fails [INFO] Executing: mvn deploy --no-plugin-updates -P prod -DperformRelease=true looks right but still fails with same error 3) mvn release:perform -Dprod --fails [INFO] Executing: mvn deploy --no-plugin-updates -P maestro -DperformRelease=true this one defaults out to my settings active profile (this may have something to do with my issue, not sure?) 4) thinking my activation section was wrong I perused http://maven.apache.org/guides/introduction/introduction-to-profiles.htmland decided to change the section to: env prod and call it like thus: mvn release:perform -Denv=prod. Same failure with "[INFO] Executing: mvn deploy --no-plugin-updates -P prod -DperformRelease=true" printed. ==STACK== [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Maven execution failed, exit code: '1' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals( DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal( DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal( DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures (DefaultLifecycleExecutor.jav a:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute( DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java :315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java :430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Maven execution failed, exit code: '1' at org.apache.maven.plugins.release.PerformReleaseMojo.execute( PerformReleaseMojo.java:106) at org.apache.maven.plugin.DefaultPluginManager.executeMojo( DefaultPluginManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals( DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Maven execution failed, exit code: '1' at org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute( AbstractRunGoalsPhase.java:66) at org.apache.maven.shared.release.phase.RunPerformGoalsPhase.execute( RunPerformGoalsPhase.java:57) at org.apache.maven.shared.release.DefaultReleaseManager.perform( DefaultReleaseManager.java:319) at org.apache.maven.shared.releas
Release Plugin: resolving snapshot dependencies & cutting releases
I am valiantly trying to replace my old "ant w/ many sandboxes and ssh" build/release process in favor of a new&improved "mvn2-svn-wagonssh" process. I have my super-pom and my other poms working nicely; I can create my artifacts just fine. But, the last piece in the puzzle is a bit of a hurdle: release. Here is what my simple webapp looks like: super-pom | |_resource1 pom (jar) | |_resource2 pom (jar) | |_webapp1 pom (war) The 2 jars are dependencies of the webapp. So, I cut (prepare/perform) release 9.1.1 of the 2 jars. No prob - they are in my repos. Now, for the webapp, my pom has the 2 dependencies as snapshots. The plugin asks if I want to resolve them and I get a bit lost there. Do I need to modify the pom of the webapp to specify versions 9.1.1 of the jars ? If I do that, I have to commit it and then my trunk pom is then incorrect. Would I reedit and recommit it after release? Am I releasing my webapp correctly? Perhaps, I don't need to release the jar dependencies first ? Not sure. Thanks, James (no-longer-lurking)
