You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2006/12/29 22:25:39 UTC
Re: svn commit: r490209 - /maven/plugins/trunk/pom.xml
I don't understand why this is needed - this seems to only augment
the one in the parent POM (except for the specification of explicit
versions for source/javadoc which could be changed using plugin
management). Why was overriding necessary?
- Brett
On 26/12/2006, at 2:08 PM, jvanzyl@apache.org wrote:
> Author: jvanzyl
> Date: Mon Dec 25 19:08:55 2006
> New Revision: 490209
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=490209
> Log:
> o adding a profile for a direct release which overrides the one
> buried in the POM
>
>
> Modified:
> maven/plugins/trunk/pom.xml
>
> Modified: maven/plugins/trunk/pom.xml
> URL: http://svn.apache.org/viewvc/maven/plugins/trunk/pom.xml?
> view=diff&rev=490209&r1=490208&r2=490209
> ======================================================================
> ========
> --- maven/plugins/trunk/pom.xml (original)
> +++ maven/plugins/trunk/pom.xml Mon Dec 25 19:08:55 2006
> @@ -10,7 +10,7 @@
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-plugins</artifactId>
> <packaging>pom</packaging>
> - <version>6</version>
> + <version>7</version>
> <name>Maven Plugins</name>
> <description>Maven Plugins</description>
> <url>http://maven.apache.org/plugins/</url>
> @@ -268,5 +268,94 @@
> </plugins>
> </build>
> </profile>
> + <profile>
> + <!--
> + | When doing a direct release to a production repository
> use the following command to prepare the release:
> + |
> + | mvn -PdirectRelease release:prepare
> + |
> + | When doing a direct release to a production repository
> use the following command to perform the release:
> + |
> + | mvn release:perform -DuseReleaseProfile=false
> + |
> + | You see here that we want to disable the profile that is
> buried in the Super POM
> + -->
> + <id>directRelease</id>
> + <build>
> + <plugins>
> + <!-- We want the sources JAR published with the release -->
> + <plugin>
> + <inherited>true</inherited>
> + <artifactId>maven-source-plugin</artifactId>
> + <version>2.0.2</version>
> + <executions>
> + <execution>
> + <id>attach-sources</id>
> + <goals>
> + <goal>jar</goal>
> + </goals>
> + </execution>
> + </executions>
> + </plugin>
> + <!-- We want the JavaDoc JAR published with the release -->
> + <plugin>
> + <inherited>true</inherited>
> + <artifactId>maven-javadoc-plugin</artifactId>
> + <version>2.2</version>
> + <executions>
> + <execution>
> + <id>attach-javadocs</id>
> + <goals>
> + <goal>jar</goal>
> + </goals>
> + </execution>
> + </executions>
> + </plugin>
> + <!-- We want to sign the artifact, the POM, and all
> attached artifacts -->
> + <plugin>
> + <artifactId>maven-gpg-plugin</artifactId>
> + <version>1.0-alpha-1</version>
> + <configuration>
> + <passphrase>${gpg.passphrase}</passphrase>
> + </configuration>
> + <executions>
> + <execution>
> + <goals>
> + <goal>sign</goal>
> + </goals>
> + </execution>
> + </executions>
> + </plugin>
> + <!-- We want to package up license resources in the JARs
> produced -->
> + <plugin>
> + <artifactId>maven-remote-resources-plugin</artifactId>
> + <version>1.0-alpha-1</version>
> + <executions>
> + <execution>
> + <goals>
> + <goal>process</goal>
> + </goals>
> + <configuration>
> + <resourceBundles>
> + <resourceBundle>org.apache:apache-jar-resource-
> bundle:1.0</resourceBundle>
> + </resourceBundles>
> + </configuration>
> + </execution>
> + </executions>
> + </plugin>
> + <!-- Since we are ignoring the release profile we need
> to use the deploy plugin with the update release info option -->
> + <plugin>
> + <inherited>true</inherited>
> + <groupId>org.apache.maven.plugins</groupId>
> + <artifactId>maven-deploy-plugin</artifactId>
> + <!-- We don't need any staging for this -->
> + <version>2.2.1</version>
> + <configuration>
> + <updateReleaseInfo>true</updateReleaseInfo>
> + </configuration>
> + </plugin>
> + </plugins>
> + </build>
> + </profile>
> </profiles>
> </project>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r490209 - /maven/plugins/trunk/pom.xml
Posted by Brett Porter <br...@apache.org>.
I said in my original mail that they wouldn't be locked down. But
either way, there's a number of other plugins that aren't locked down
(compiler, resources, jar, etc) - this is a known problem. For any
that we think it's important to lock down the versions for, we should
do so in plugin management (not in individual profiles).
Direct release wasn't needed as the "default" was back to being a
direct release (see below). We can reverse this when we want staging
to be the default.
- Brett
On 06/01/2007, at 1:10 AM, Jason van Zyl wrote:
> On 29 Dec 06, at 10:21 PM 29 Dec 06, Brett Porter wrote:
>
>> Easier to do than explain. I've just removed half of the plugin
>> parent POM, and compared the output of help:effective-pom for that
>> and for version 7. They are identical.
>>
>
> Where did the directRelease go that locked down the versions? Now
> we're back to getting a willy nilly version for the deploy,
> javadoc, and source plugin. If someone has locked down to versions
> of these plugins somewhere else on their system and they have
> automatic updates turned off they will get versions not intended.
> It wasn't just for staging it was for consistent releases while
> directly deploying.
>
> How did you get the same thing when there are no versions specified
> in the Super POM for any of the plugins while I had versions
> specified?
>
> What command did you use to with "mvn help:effective-pom" ?
>
> Jason.
>
>> To stage before release:
>> mvn -Pstaging,release-profile deploy site-deploy
>>
>> To prepare:
>> mvn release:prepare
>>
>> To perform release to staging (could be wrapped up as a standard
>> release:stage):
>> mvn release:perform -Darguments="-Pstaging"
>>
>> To perform release to production (until we have a way to move from
>> staging to production):
>> mvn release:perform
>>
>> I can roll this back if I've missed something - but it looks like
>> this is the same as now, just simpler, and you can still move
>> forward with the other changes.
>>
>> - Brett
>>
>> On 30/12/2006, at 1:58 PM, Jason van Zyl wrote:
>>
>>>
>>> On 29 Dec 06, at 9:43 PM 29 Dec 06, Brett Porter wrote:
>>>
>>>>
>>>> On 30/12/2006, at 1:24 PM, Jason van Zyl wrote:
>>>>
>>>>> 2) The profile for releases, or any profile, should be put in
>>>>> the parent POM. It's just completely invisible and people will
>>>>> do releases differently
>>>>
>>>> agreed
>>>>
>>>>> 3) Any mojo specified in the lifecycle gets run twice if it's
>>>>> listed in more then one profile.
>>>>
>>>> I'm still confused - since the source and javadoc definitions
>>>> are identical, why do they need to be listed in more than one
>>>> profile?
>>>
>>> Because I didn't use the profile in the Super POM at all.
>>>
>>>> Putting it in the ASF POM with the same activation and id as the
>>>> main one should put them all together fine - it worked for the
>>>> plugin tools.
>>>>
>>>
>>> For the staging where I had two definitions of deploy it didn't
>>> work. The source and javadoc mojos are in any lifecycle so no
>>> affect there. I just didn't want to try and mesh them and just
>>> created a clean on outside the super pom.
>>>
>>>> Perhaps it is something related to the staging that I am
>>>> missing, but I was curious why it was added for 'directRelease'.
>>>>
>>>
>>> I just simply by passed the super pom is all.
>>>
>>>> Anyway, if you can come up with an alternate solution that's
>>>> even better.
>>>>
>>>
>>> Will do.
>>>
>>> Jason.
>>>
>>>> - Brett
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r490209 - /maven/plugins/trunk/pom.xml
Posted by Jason van Zyl <ja...@maven.org>.
On 29 Dec 06, at 10:21 PM 29 Dec 06, Brett Porter wrote:
> Easier to do than explain. I've just removed half of the plugin
> parent POM, and compared the output of help:effective-pom for that
> and for version 7. They are identical.
>
Where did the directRelease go that locked down the versions? Now
we're back to getting a willy nilly version for the deploy, javadoc,
and source plugin. If someone has locked down to versions of these
plugins somewhere else on their system and they have automatic
updates turned off they will get versions not intended. It wasn't
just for staging it was for consistent releases while directly
deploying.
How did you get the same thing when there are no versions specified
in the Super POM for any of the plugins while I had versions specified?
What command did you use to with "mvn help:effective-pom" ?
Jason.
> To stage before release:
> mvn -Pstaging,release-profile deploy site-deploy
>
> To prepare:
> mvn release:prepare
>
> To perform release to staging (could be wrapped up as a standard
> release:stage):
> mvn release:perform -Darguments="-Pstaging"
>
> To perform release to production (until we have a way to move from
> staging to production):
> mvn release:perform
>
> I can roll this back if I've missed something - but it looks like
> this is the same as now, just simpler, and you can still move
> forward with the other changes.
>
> - Brett
>
> On 30/12/2006, at 1:58 PM, Jason van Zyl wrote:
>
>>
>> On 29 Dec 06, at 9:43 PM 29 Dec 06, Brett Porter wrote:
>>
>>>
>>> On 30/12/2006, at 1:24 PM, Jason van Zyl wrote:
>>>
>>>> 2) The profile for releases, or any profile, should be put in
>>>> the parent POM. It's just completely invisible and people will
>>>> do releases differently
>>>
>>> agreed
>>>
>>>> 3) Any mojo specified in the lifecycle gets run twice if it's
>>>> listed in more then one profile.
>>>
>>> I'm still confused - since the source and javadoc definitions are
>>> identical, why do they need to be listed in more than one profile?
>>
>> Because I didn't use the profile in the Super POM at all.
>>
>>> Putting it in the ASF POM with the same activation and id as the
>>> main one should put them all together fine - it worked for the
>>> plugin tools.
>>>
>>
>> For the staging where I had two definitions of deploy it didn't
>> work. The source and javadoc mojos are in any lifecycle so no
>> affect there. I just didn't want to try and mesh them and just
>> created a clean on outside the super pom.
>>
>>> Perhaps it is something related to the staging that I am missing,
>>> but I was curious why it was added for 'directRelease'.
>>>
>>
>> I just simply by passed the super pom is all.
>>
>>> Anyway, if you can come up with an alternate solution that's even
>>> better.
>>>
>>
>> Will do.
>>
>> Jason.
>>
>>> - Brett
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r490209 - /maven/plugins/trunk/pom.xml
Posted by Jason van Zyl <ja...@maven.org>.
On 29 Dec 06, at 10:21 PM 29 Dec 06, Brett Porter wrote:
> Easier to do than explain. I've just removed half of the plugin
> parent POM, and compared the output of help:effective-pom for that
> and for version 7. They are identical.
>
> To stage before release:
> mvn -Pstaging,release-profile deploy site-deploy
>
> To prepare:
> mvn release:prepare
>
> To perform release to staging (could be wrapped up as a standard
> release:stage):
> mvn release:perform -Darguments="-Pstaging"
This is what I was missing. I was looking at the code that was
supposed to pass on the active profiles in the configuration to the
perform.
>
> To perform release to production (until we have a way to move from
> staging to production):
> mvn release:perform
>
> I can roll this back if I've missed something - but it looks like
> this is the same as now, just simpler, and you can still move
> forward with the other changes.
>
Provided all the versions are locked down and I can still do direct
releases until the staging is fully worked out.
Jason.
> - Brett
>
> On 30/12/2006, at 1:58 PM, Jason van Zyl wrote:
>
>>
>> On 29 Dec 06, at 9:43 PM 29 Dec 06, Brett Porter wrote:
>>
>>>
>>> On 30/12/2006, at 1:24 PM, Jason van Zyl wrote:
>>>
>>>> 2) The profile for releases, or any profile, should be put in
>>>> the parent POM. It's just completely invisible and people will
>>>> do releases differently
>>>
>>> agreed
>>>
>>>> 3) Any mojo specified in the lifecycle gets run twice if it's
>>>> listed in more then one profile.
>>>
>>> I'm still confused - since the source and javadoc definitions are
>>> identical, why do they need to be listed in more than one profile?
>>
>> Because I didn't use the profile in the Super POM at all.
>>
>>> Putting it in the ASF POM with the same activation and id as the
>>> main one should put them all together fine - it worked for the
>>> plugin tools.
>>>
>>
>> For the staging where I had two definitions of deploy it didn't
>> work. The source and javadoc mojos are in any lifecycle so no
>> affect there. I just didn't want to try and mesh them and just
>> created a clean on outside the super pom.
>>
>>> Perhaps it is something related to the staging that I am missing,
>>> but I was curious why it was added for 'directRelease'.
>>>
>>
>> I just simply by passed the super pom is all.
>>
>>> Anyway, if you can come up with an alternate solution that's even
>>> better.
>>>
>>
>> Will do.
>>
>> Jason.
>>
>>> - Brett
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r490209 - /maven/plugins/trunk/pom.xml
Posted by Brett Porter <br...@apache.org>.
Easier to do than explain. I've just removed half of the plugin
parent POM, and compared the output of help:effective-pom for that
and for version 7. They are identical.
To stage before release:
mvn -Pstaging,release-profile deploy site-deploy
To prepare:
mvn release:prepare
To perform release to staging (could be wrapped up as a standard
release:stage):
mvn release:perform -Darguments="-Pstaging"
To perform release to production (until we have a way to move from
staging to production):
mvn release:perform
I can roll this back if I've missed something - but it looks like
this is the same as now, just simpler, and you can still move forward
with the other changes.
- Brett
On 30/12/2006, at 1:58 PM, Jason van Zyl wrote:
>
> On 29 Dec 06, at 9:43 PM 29 Dec 06, Brett Porter wrote:
>
>>
>> On 30/12/2006, at 1:24 PM, Jason van Zyl wrote:
>>
>>> 2) The profile for releases, or any profile, should be put in the
>>> parent POM. It's just completely invisible and people will do
>>> releases differently
>>
>> agreed
>>
>>> 3) Any mojo specified in the lifecycle gets run twice if it's
>>> listed in more then one profile.
>>
>> I'm still confused - since the source and javadoc definitions are
>> identical, why do they need to be listed in more than one profile?
>
> Because I didn't use the profile in the Super POM at all.
>
>> Putting it in the ASF POM with the same activation and id as the
>> main one should put them all together fine - it worked for the
>> plugin tools.
>>
>
> For the staging where I had two definitions of deploy it didn't
> work. The source and javadoc mojos are in any lifecycle so no
> affect there. I just didn't want to try and mesh them and just
> created a clean on outside the super pom.
>
>> Perhaps it is something related to the staging that I am missing,
>> but I was curious why it was added for 'directRelease'.
>>
>
> I just simply by passed the super pom is all.
>
>> Anyway, if you can come up with an alternate solution that's even
>> better.
>>
>
> Will do.
>
> Jason.
>
>> - Brett
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r490209 - /maven/plugins/trunk/pom.xml
Posted by Jason van Zyl <ja...@maven.org>.
On 29 Dec 06, at 9:43 PM 29 Dec 06, Brett Porter wrote:
>
> On 30/12/2006, at 1:24 PM, Jason van Zyl wrote:
>
>> 2) The profile for releases, or any profile, should be put in the
>> parent POM. It's just completely invisible and people will do
>> releases differently
>
> agreed
>
>> 3) Any mojo specified in the lifecycle gets run twice if it's
>> listed in more then one profile.
>
> I'm still confused - since the source and javadoc definitions are
> identical, why do they need to be listed in more than one profile?
Because I didn't use the profile in the Super POM at all.
> Putting it in the ASF POM with the same activation and id as the
> main one should put them all together fine - it worked for the
> plugin tools.
>
For the staging where I had two definitions of deploy it didn't work.
The source and javadoc mojos are in any lifecycle so no affect there.
I just didn't want to try and mesh them and just created a clean on
outside the super pom.
> Perhaps it is something related to the staging that I am missing,
> but I was curious why it was added for 'directRelease'.
>
I just simply by passed the super pom is all.
> Anyway, if you can come up with an alternate solution that's even
> better.
>
Will do.
Jason.
> - Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r490209 - /maven/plugins/trunk/pom.xml
Posted by Brett Porter <br...@apache.org>.
On 30/12/2006, at 1:24 PM, Jason van Zyl wrote:
> 2) The profile for releases, or any profile, should be put in the
> parent POM. It's just completely invisible and people will do
> releases differently
agreed
> 3) Any mojo specified in the lifecycle gets run twice if it's
> listed in more then one profile.
I'm still confused - since the source and javadoc definitions are
identical, why do they need to be listed in more than one profile?
Putting it in the ASF POM with the same activation and id as the main
one should put them all together fine - it worked for the plugin tools.
Perhaps it is something related to the staging that I am missing, but
I was curious why it was added for 'directRelease'.
Anyway, if you can come up with an alternate solution that's even
better.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r490209 - /maven/plugins/trunk/pom.xml
Posted by Jason van Zyl <ja...@maven.org>.
On 29 Dec 06, at 4:25 PM 29 Dec 06, Brett Porter wrote:
> I don't understand why this is needed - this seems to only augment
> the one in the parent POM (except for the specification of explicit
> versions for source/javadoc which could be changed using plugin
> management). Why was overriding necessary?
>
1) I put everything in one profile that will be used in the future
and did that because profiles are not preserver through the release,
what's used in prepare is not passed on. I put that in JIRA.
2) The profile for releases, or any profile, should be put in the
parent POM. It's just completely invisible and people will do
releases differently
3) Any mojo specified in the lifecycle gets run twice if it's listed
in more then one profile. This was happening with the deploy for
staging so I just overrode everything and did it as if there was
nothing in the Super POM. When I work on the release plugin I'll put
it in a place that can easily be shared a la the remote resources
which is a model which scales nicely and doesn't require copying
profiles around or putting things that should be visible and
configurable in the Super POM.
Jason.
> - Brett
>
> On 26/12/2006, at 2:08 PM, jvanzyl@apache.org wrote:
>
>> Author: jvanzyl
>> Date: Mon Dec 25 19:08:55 2006
>> New Revision: 490209
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=490209
>> Log:
>> o adding a profile for a direct release which overrides the one
>> buried in the POM
>>
>>
>> Modified:
>> maven/plugins/trunk/pom.xml
>>
>> Modified: maven/plugins/trunk/pom.xml
>> URL: http://svn.apache.org/viewvc/maven/plugins/trunk/pom.xml?
>> view=diff&rev=490209&r1=490208&r2=490209
>> =====================================================================
>> =========
>> --- maven/plugins/trunk/pom.xml (original)
>> +++ maven/plugins/trunk/pom.xml Mon Dec 25 19:08:55 2006
>> @@ -10,7 +10,7 @@
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-plugins</artifactId>
>> <packaging>pom</packaging>
>> - <version>6</version>
>> + <version>7</version>
>> <name>Maven Plugins</name>
>> <description>Maven Plugins</description>
>> <url>http://maven.apache.org/plugins/</url>
>> @@ -268,5 +268,94 @@
>> </plugins>
>> </build>
>> </profile>
>> + <profile>
>> + <!--
>> + | When doing a direct release to a production repository
>> use the following command to prepare the release:
>> + |
>> + | mvn -PdirectRelease release:prepare
>> + |
>> + | When doing a direct release to a production repository
>> use the following command to perform the release:
>> + |
>> + | mvn release:perform -DuseReleaseProfile=false
>> + |
>> + | You see here that we want to disable the profile that is
>> buried in the Super POM
>> + -->
>> + <id>directRelease</id>
>> + <build>
>> + <plugins>
>> + <!-- We want the sources JAR published with the release
>> -->
>> + <plugin>
>> + <inherited>true</inherited>
>> + <artifactId>maven-source-plugin</artifactId>
>> + <version>2.0.2</version>
>> + <executions>
>> + <execution>
>> + <id>attach-sources</id>
>> + <goals>
>> + <goal>jar</goal>
>> + </goals>
>> + </execution>
>> + </executions>
>> + </plugin>
>> + <!-- We want the JavaDoc JAR published with the release
>> -->
>> + <plugin>
>> + <inherited>true</inherited>
>> + <artifactId>maven-javadoc-plugin</artifactId>
>> + <version>2.2</version>
>> + <executions>
>> + <execution>
>> + <id>attach-javadocs</id>
>> + <goals>
>> + <goal>jar</goal>
>> + </goals>
>> + </execution>
>> + </executions>
>> + </plugin>
>> + <!-- We want to sign the artifact, the POM, and all
>> attached artifacts -->
>> + <plugin>
>> + <artifactId>maven-gpg-plugin</artifactId>
>> + <version>1.0-alpha-1</version>
>> + <configuration>
>> + <passphrase>${gpg.passphrase}</passphrase>
>> + </configuration>
>> + <executions>
>> + <execution>
>> + <goals>
>> + <goal>sign</goal>
>> + </goals>
>> + </execution>
>> + </executions>
>> + </plugin>
>> + <!-- We want to package up license resources in the
>> JARs produced -->
>> + <plugin>
>> + <artifactId>maven-remote-resources-plugin</artifactId>
>> + <version>1.0-alpha-1</version>
>> + <executions>
>> + <execution>
>> + <goals>
>> + <goal>process</goal>
>> + </goals>
>> + <configuration>
>> + <resourceBundles>
>> + <resourceBundle>org.apache:apache-jar-
>> resource-bundle:1.0</resourceBundle>
>> + </resourceBundles>
>> + </configuration>
>> + </execution>
>> + </executions>
>> + </plugin>
>> + <!-- Since we are ignoring the release profile we need
>> to use the deploy plugin with the update release info option -->
>> + <plugin>
>> + <inherited>true</inherited>
>> + <groupId>org.apache.maven.plugins</groupId>
>> + <artifactId>maven-deploy-plugin</artifactId>
>> + <!-- We don't need any staging for this -->
>> + <version>2.2.1</version>
>> + <configuration>
>> + <updateReleaseInfo>true</updateReleaseInfo>
>> + </configuration>
>> + </plugin>
>> + </plugins>
>> + </build>
>> + </profile>
>> </profiles>
>> </project>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org