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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
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]
---------------------------------------------------------------------
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]
