I think any global option for skipping a plugin should be done in the
Execution Plan Calculation,
where we try to build the immutable plan of the actual plugins that will
be run.
Kristian
Den 27.01.2011 05:44, skrev Kalyan Akella:
Hi,
I recently came across this situation in my own project
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
Sounds good.
BTW, I added the useAgent flag in there for the GPG plugin. I tested it with
and without an agent here, and can't see any downside - but someone using GPG
on other platforms might like to double check it doesn't mess anything up for
them.
- Brett
On 27/01/2011, at 8:30 PM,
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,
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 bimargul...@gmail.com:
I note that arguments-Papache-release/arguments is still in there.
I filed a JIRA about the
Is there a chance to update resources-plugin version to 2.4.3 for better
m2e compatibility?
--
Regards,
Igor
On 11-01-27 04:30 AM, Olivier Lamy 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
Yup I wanted this to.
Done.
2011/1/27 Igor Fedorenko i...@ifedorenko.com:
Is there a chance to update resources-plugin version to 2.4.3 for better
m2e compatibility?
--
Regards,
Igor
On 11-01-27 04:30 AM, Olivier Lamy wrote:
Hello Folks,
I'd like to release the ASF parent pom [1].
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 ol...@apache.org wrote:
Hello,
The profile apache-release sounds good for adding various release materials.
Can
I hope we can migrate over all the Maven JIRA issues from codehaus to
apache.org as soon as the ASF jira instance got upgraded to 4.2.
LieGrue,
strub
--- On Thu, 1/27/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: ASF pom release
Right, but there are very few MPOM issues. You could ask infra for a
project and deal with it by hand.
On Thu, Jan 27, 2011 at 10:03 AM, Mark Struberg strub...@yahoo.de wrote:
I hope we can migrate over all the Maven JIRA issues from codehaus to
apache.org as soon as the ASF jira instance got
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
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
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
bimargul...@gmail.com wrote:
The problem is the use of arguments rather than releaseProfiles.
The later only applies to 'perform'. the
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
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
I don't follow you here.
AFAIK : mvn release:prepare release:perform wil generate only two
builds (or I have missed something)
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
On Thu, Jan 27, 2011 at 11:44 AM, Olivier Lamy ol...@apache.org 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
On 1/27/11 11:10 AM, Olivier Lamy 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
On 1/27/11 11:52 AM, Benson Margulies wrote:
On Thu, Jan 27, 2011 at 11:44 AM, Olivier Lamyol...@apache.org 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
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
Brian Fox wrote:
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
I want to just put a bit of emphasis on the global impact of this POM.
This POM gets advertised as the appropriate parent for \any/ Apache
project building with Maven. As such, I submit to you, it should
supply all of the necessary settings (e.g. repository locations,
deployment) and no surprising
I don't understand, running the full build on prepare is the default
Maven behavior. This is to make sure that after flipping all the
versions around, that the build works before tagging it.
On Thu, Jan 27, 2011 at 4:22 PM, Benson Margulies bimargul...@gmail.com wrote:
I want to just put a bit
On Thu, Jan 27, 2011 at 5:01 PM, Brian Fox bri...@infinity.nu wrote:
I don't understand, running the full build on prepare is the default
Maven behavior. This is to make sure that after flipping all the
versions around, that the build works before tagging it.
I think I'm mushing a number of
On 1/27/11 4:22 PM, Benson Margulies wrote:
I want to just put a bit of emphasis on the global impact of this POM.
This POM gets advertised as the appropriate parent for \any/ Apache
project building with Maven. As such, I submit to you, it should
supply all of the necessary settings (e.g.
2011/1/28 John Casey jdca...@commonjava.org:
On 1/27/11 4:22 PM, Benson Margulies wrote:
I want to just put a bit of emphasis on the global impact of this POM.
This POM gets advertised as the appropriate parent for \any/ Apache
project building with Maven. As such, I submit to you, it
Hi,
just a question: If i open the maven-failsafe-plugin project page ( for
the link to the issue track it point to
http://jira.codehaus.org/browse/SUREFIRE ? Doesn't this project has it's
own project in JIRA ?
And one other point i found for the maven-failsafe-plugin
Issue Subscription
Filter: Design Best Practices (24 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
thanks a lot.
i tried truzip but there's an error saying that the fileset tag is not
valid.
(2011/01/27 16:31), Stephen Connolly wrote:
be aware that the jar specification has a different filename encoding than
the zip specification (perhaps because at the time sun wasn't thinking)
you may
Hi,
Thank you for the reply.
I just implemented option 1 that modifies the execution plan calculation
algorithm to eliminate plugins executions that should be skipped. Users
should pass this information as...
To skip the surefire plugin,
mvn
just a question: If i open the maven-failsafe-plugin project page ( for the
link to the issue track it point to
http://jira.codehaus.org/browse/SUREFIRE ? Doesn't this project has it's
own project in JIRA ?
No, it shares the same JIRA project as the other surefire-related
components. For a
http://maven.apache.org/plugins/maven-failsafe-plugin/) is that the link
to API (http://maven.apache.org/plugins/maven-failsafe-plugin/api.html)
produces a Page not found ?
Please file a ticket and I'm sure Kristian will update this for the next
release.
Yes, he will ;)
I talked with
Thanks for the patch, which looks good. I added some comments to the
issue, http://jira.codehaus.org/browse/MNG-3321
Kristian
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail:
33 matches
Mail list logo
