I like the "legacy" advertising (both for cli and system property), which
helps people understand this option should be avoided: with the later warning
during execution, they should report until we understand and document
sufficiently conditions where it is needed and options to fix the build in
On 6 February 2013 10:39, Benson Margulies wrote:
> The issue here is that someone in our community might live in a world
> where an MRM has interposed its body, in the words of Lytton
> Strachey, between themselves and all external repos. Such people had
> better follow olamy's advice about down
The issue here is that someone in our community might live in a world
where an MRM has interposed its body, in the words of Lytton
Strachey, between themselves and all external repos. Such people had
better follow olamy's advice about downloading source and building it
themselves.
On Tue, Feb 5
On 5 February 2013 21:26, James Nord (jnord) wrote:
> Hi all,
>
> I have a question which I am hoping someone can answer.
>
> Rule #1 releases are golden.
> However Apache plugin releases violate that rule[1][2]. If a vote fails the
> next vote seems to be for exactly the same version of the plu
+1
On Tue, Feb 5, 2013 at 1:26 PM, Robert Scholte wrote:
> Hi,
>
> I have my doubts if this should be exposed as a mvn argument. This would
> also mean that we cannot remove it in the future. It would also suggest
> that it is a valid solution, but in fact it makes your build more
> unreliable.
GitHub user agudian opened a pull request:
https://github.com/apache/maven-surefire/pull/22
[SUREFIRE-956] make forkNumber unique among concurrent surefire-executions
in a parallel maven build
This pull request builds upon some changes from
https://github.com/apache/maven-surefire/
Hi,
I have my doubts if this should be exposed as a mvn argument. This would
also mean that we cannot remove it in the future. It would also suggest
that it is a valid solution, but in fact it makes your build more
unreliable.
Users hitting this issue have often enough Maven knowledge to di
Hi,
I'd like to release Wagon 2.4.
We fixed 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335&version=18697
Staging repository:
https://repository.apache.org/content/repositories/maven-199/
Source release:
https://repository.apache.org/content/repositories/maven-199/org/
an other possibility is to download the source release zip and install
it locally.
I believe you want to test pmd.
So here:
https://repository.apache.org/content/repositories/maven-198/org/apache/maven/plugins/maven-pmd-plugin/3.0/maven-pmd-plugin-3.0-source-release.zip
2013/2/5 Benson Margulies
I keep a second Maven install dir that has a settings.xml that does
not point to my corporate MRM, but rather directly to the outside
world.
On Tue, Feb 5, 2013 at 5:56 AM, James Nord (jnord) wrote:
> Hi all,
>
> I have a question which I am hoping someone can answer.
>
> Rule #1 releases are go
Hi all,
I have a question which I am hoping someone can answer.
Rule #1 releases are golden.
However Apache plugin releases violate that rule[1][2]. If a vote fails the
next vote seems to be for exactly the same version of the plugin
I sit behind a corporate MRM - and as such we keep every sin
11 matches
Mail list logo
