On 1/27/11 11:52 AM, Benson Margulies wrote:
On Thu, Jan 27, 2011 at 11:44 AM, Olivier Lamy<[email protected]> wrote:
I don't follow you here.
AFAIK : mvn release:prepare release:perform wil generate only two
builds (or I have missed something)
Olivier,
I spent many happy hours debugging and reading the code to figure this out.
When you do 'mvn release:prepare', mvn starts up and runs the
lifecycle until it gets to release:prepare.
Unless release:prepare is bound to the lifecycle (via a profile or
something equally weird) or otherwise uses an annotation to create a
prerequisite before running, then it should only cause one execution of
the build.
If it uses an annotation to require part of the default lifecycle to run
ahead of it, then it seems like this is redundant when paired with the
external re-execution of the build (via the invoker, when I last saw
it). If this is the case, then I'd be in favor of removing the
annotation-injected lifecycle prerequisite, and reducing the build count
to 2 (external invocations in prepare, then perform).
It then goes to execute
the prepare goal, and for this purpose it forks a new execution, and
starts all over.
The question is, what else is in the lifecycle of the outer run? I had
convinced myself that it included, for example, surefire.
However, it was weeks ago that I did this debugging.
I'm not opposed to an apache convention of running a fairly complete
build in prepare; what drove me to drink on the occasion was that code
signing was turned on. If prepare had profile control (there's another
JIRA for that), we could have an apache_release_prepare and an
apache_release_perform.
FWIW, if the code-signing step fails due to some POM misconfiguration,
and only runs in the perform step, then you've got to rollback the
release and try it again...either that, or muck around with manually
shifting the tag in the SCM, which is probably as ugly.
I'm not as concerned about spending a little extra time to reduce the
chances of things going wrong in the release process, since this seems
to happen often enough already...and causes a HUGE waste of time in some
cases. If we were releasing a 100+ module project structure, then I'd be
willing enough to give on this point and say that accepting a little
extra risk in the 'perform' phase isn't that big of a deal. But, at
least in Maven, the releases aren't that big.
To some extent, I would go away if there was a 'site:site' web site
for the shared pom that just documented it. I would be willing to
provide a patch for this.
And in our case all mojo binds tru the profile apache-release won't be
executed in the prepare if we remove the<arguments> stuff.
So it won't be possible to detect possible errors which can happend
during the perform "phase".
And here is my only point.
2011/1/27 Benson Margulies<[email protected]>:
Remember that there are three runs of maven here.
The outer run.
The forked execution for prepare.
The forked execution for perform.
The first of these is still a full build, and can catch errors.
The last is as full as people choose to make it.
There's an additional problem that there is nothing like
'useReleaseProfiles' for 'prepare'. It seems to me that the designer
expected prepare to be just the 'bagging and tagging', not running
tests and such, since he or she didn't allow any fine control over how
it runs. (<arguments> is a blunt instrument).
My opinion, at least.
On Thu, Jan 27, 2011 at 11:10 AM, Olivier Lamy<[email protected]> wrote:
I see your point.
If we do this the prepare won't be anymore a "repetition" of the real
perform goal (sources, sources bundle, javadoc).
Sure not a big deal but that means folks have some risks to found
issue too late.
So I'm +1.
btw we can add this arguments again in the maven parent pom.
Others WDYT ?
2011/1/27 Benson Margulies<[email protected]>:
On the compat front, can you think of a reason why removing this from
prepare would bust anything for anyone?
On Thu, Jan 27, 2011 at 10:40 AM, Benson Margulies
<[email protected]> wrote:
The problem is the use of<arguments> rather than<releaseProfiles>.
The later only applies to 'perform'. the former also applies to
prepare.
So, gpg is turned on for prepare, which takes a long time and requires
keys to be present. If you just used releaseProfiles and
useReleaseProfiles it would be fine with me.
On Thu, Jan 27, 2011 at 10:35 AM, Olivier Lamy<[email protected]> wrote:
I don't follow you here.
The goal of this profile activation is to generate a set of standard
ASF materials.
As it has been added, removing will means breaking backward comp.
IMHO it's easier to have it here when folks wants to cut a release.
BTW you can override this in your pom if you don't want any arguments
with something like (from mind so not tested :-) ) :
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<arguments combine.self="override"></arguments>
</configuration>
2011/1/27 Benson Margulies<[email protected]>:
MPOM-2. The fact that the Codehaus jira is the home of issues with the
ASF shared POM strikes me as something else that needs fixing.
On Thu, Jan 27, 2011 at 9:31 AM, Olivier Lamy<[email protected]> wrote:
Hello,
The profile apache-release sounds good for adding various release materials.
Can you explain what's wrong or give the jira id ?
Thanks
2011/1/27 Benson Margulies<[email protected]>:
I note that<arguments>-Papache-release</arguments> is still in there.
I filed a JIRA about the surprising and unpleasant effects of this. I
don't own a -1, but it seems to me that it would be reasonable to ask
you to either remove this or close my JIRA explaining why I'm wrong.
On Thu, Jan 27, 2011 at 4:30 AM, Olivier Lamy<[email protected]> wrote:
Hello Folks,
I'd like to release the ASF parent pom [1].
In the maven parent pom [2], we have setup a maven-3 profile for the
site plugin.
No objections I move this profile to the ASF parent ?
Current diff :
$ svn diff http://svn.apache.org/repos/asf/maven/pom/tags/apache-8/pom.xml
http://svn.apache.org/repos/asf/maven/pom/trunk/asf/pom.xml
Index: pom.xml
===================================================================
--- pom.xml (.../tags/apache-8/pom.xml) (revision 1064055)
+++ pom.xml (.../trunk/asf/pom.xml) (revision 1064055)
@@ -31,7 +31,7 @@
-->
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
-<version>8</version>
+<version>9-SNAPSHOT</version>
<packaging>pom</packaging>
<name>The Apache Software Foundation</name>
<description>
@@ -94,9 +94,9 @@
<sourceReleaseAssemblyDescriptor>source-release</sourceReleaseAssemblyDescr
iptor>
</properties>
<scm>
-<connection>scm:svn:http://svn.apache.org/repos/asf/maven/pom/tags/apache-8
</connection>
-<developerConnection>scm:svn:https://svn.apache.org/repos/asf/maven/pom/tag
s/apache-8</developerConnection>
-<url>http://svn.apache.org/viewvc/maven/pom/tags/apache-8</url>
+<connection>scm:svn:http://svn.apache.org/repos/asf/maven/pom/trunk/asf</co
nnection>
+<developerConnection>scm:svn:https://svn.apache.org/repos/asf/maven/pom/tru
nk/asf</developerConnection>
+<url>http://svn.apache.org/viewvc/maven/pom/trunk/asf</url>
</scm>
<build>
@@ -111,7 +111,7 @@
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
-<version>2.2-beta-5</version>
+<version>2.2</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -141,7 +141,7 @@
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
-<version>1.0-beta-1</version>
+<version>1.0</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -186,7 +186,7 @@
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
-<version>2.0-beta-9</version>
+<version>2.1</version>
<configuration>
<useReleaseProfile>false</useReleaseProfile>
<goals>deploy</goals>
@@ -225,9 +225,14 @@
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
-<version>2.4.3</version>
+<version>2.7.2</version>
</plugin>
<plugin>
+<groupId>org.apache.rat</groupId>
+<artifactId>apache-rat-plugin</artifactId>
+<version>0.7</version>
+</plugin>
+<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>clirr-maven-plugin</artifactId>
<version>2.2.2</version>
@@ -240,7 +245,7 @@
<plugin>
<groupId>org.codehaus.modello</groupId>
<artifactId>modello-maven-plugin</artifactId>
-<version>1.2</version>
+<version>1.4.1</version>
</plugin>
</plugins>
</pluginManagement>
@@ -333,9 +338,6 @@
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
-<configuration>
-<encoding>${project.build.sourceEncoding}</encoding>
-</configuration>
<executions>
<execution>
<id>attach-javadocs</id>
@@ -351,6 +353,7 @@
<artifactId>maven-gpg-plugin</artifactId>
<configuration>
<passphrase>${gpg.passphrase}</passphrase>
+<useAgent>true</useAgent>
</configuration>
<executions>
<execution>
Thanks !
--
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy
[1] http://svn.apache.org/repos/asf/maven/pom/trunk/asf/pom.xml
[2] http://svn.apache.org/repos/asf/maven/pom/trunk/maven/pom.xml
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
