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: dev-h..
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 Steph
> 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
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 -Dskip.plugin=org.apache.maven.plugins:maven-surefir
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 h
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
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
(http://maven.apache.o
2011/1/28 John Casey :
>
>
> 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
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. repo
On Thu, Jan 27, 2011 at 5:01 PM, Brian Fox 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 ideas together. Le
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 wrote:
> I want to just put a bit of emphasis on the glo
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
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 co
>
> 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 a
On 1/27/11 11:52 AM, Benson Margulies wrote:
On Thu, Jan 27, 2011 at 11:44 AM, Olivier Lamy 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
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 ar
On Thu, Jan 27, 2011 at 11:44 AM, Olivier Lamy 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 releas
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 stuff.
So it won't be possible to detect possible errors w
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 not
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.
Other
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
wrote:
> The problem is the use of rather than .
> The later only applies to 'perform'. the former also applies to
> prepare.
>
> So, g
The problem is the use of rather than .
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, Ja
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
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 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 upgraded to 4.2.
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 wrote:
> From: Benson Margulies
> Subject: Re: ASF pom release
> To: "Maven Developers List"
> Date: Thu
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 wrote:
> Hello,
>
> The profile apache-release sounds good for adding various release materials.
> Can you explain wh
Yup I wanted this to.
Done.
2011/1/27 Igor Fedorenko :
> 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
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 o
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 :
> I note that -Papache-release is still in there.
>
> I filed a JIRA about the surprising and unpleasant effects of this. I
I note that -Papache-release 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, Olivi
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, Oliv
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.ap
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
33 matches
Mail list logo