Testing [Vote] plugins?
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 single release we download forever (as we need to make sure all builds are reproducible). Changing this policy to test plugins up for a vote could end up with an un-reproducible build (if a staged plugin is used). Grabbing the plugin and installing to my local maven repo is likely doomed to failure due to MNG-5181. So given that releases are not always golden my question is what do people do in order to test this with their software in a corporate environment? (or to put it another way why are versions re-used if a vote fails, violating the #1 maven rule)? Regards, /James [1] http://dev.markmail.org/message/mto7fl4ngxht63ue?q=list:org%2Eapache%2Emaven%2Edev+canceled+vote [2] http://dev.markmail.org/message/j4i325udpvoxm67d?q=list:org%2Eapache%2Emaven%2Edev+ANN+Maven+Filtering+version+1%2E0
Re: Testing [Vote] plugins?
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) jn...@cisco.com 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 plugin I sit behind a corporate MRM - and as such we keep every single release we download forever (as we need to make sure all builds are reproducible). Changing this policy to test plugins up for a vote could end up with an un-reproducible build (if a staged plugin is used). Grabbing the plugin and installing to my local maven repo is likely doomed to failure due to MNG-5181. So given that releases are not always golden my question is what do people do in order to test this with their software in a corporate environment? (or to put it another way why are versions re-used if a vote fails, violating the #1 maven rule)? Regards, /James [1] http://dev.markmail.org/message/mto7fl4ngxht63ue?q=list:org%2Eapache%2Emaven%2Edev+canceled+vote [2] http://dev.markmail.org/message/j4i325udpvoxm67d?q=list:org%2Eapache%2Emaven%2Edev+ANN+Maven+Filtering+version+1%2E0 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Testing [Vote] plugins?
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 bimargul...@gmail.com: 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) jn...@cisco.com 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 plugin I sit behind a corporate MRM - and as such we keep every single release we download forever (as we need to make sure all builds are reproducible). Changing this policy to test plugins up for a vote could end up with an un-reproducible build (if a staged plugin is used). Grabbing the plugin and installing to my local maven repo is likely doomed to failure due to MNG-5181. So given that releases are not always golden my question is what do people do in order to test this with their software in a corporate environment? (or to put it another way why are versions re-used if a vote fails, violating the #1 maven rule)? Regards, /James [1] http://dev.markmail.org/message/mto7fl4ngxht63ue?q=list:org%2Eapache%2Emaven%2Edev+canceled+vote [2] http://dev.markmail.org/message/j4i325udpvoxm67d?q=list:org%2Eapache%2Emaven%2Edev+ANN+Maven+Filtering+version+1%2E0 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Apache Maven Wagon 2.4
Hi, I'd like to release Wagon 2.4. We fixed 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335version=18697 Staging repository: https://repository.apache.org/content/repositories/maven-199/ Source release: https://repository.apache.org/content/repositories/maven-199/org/apache/maven/wagon/wagon/2.4/wagon-2.4-source-release.zip Vote open for 72H [+1] [0] [-1] Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: git commit: fixed typo
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 discover
this option, so I don't see the need for this mvn commandline argument.
Instead I would only use the MAVEN_OPTS option, and rename it to
LegacyLocalRepository instead of SimpleLocalRepository to encourage not to
use it.
WDYT?
Robert
Op Tue, 05 Feb 2013 00:02:47 +0100 schreef Hervé BOUTEMY
herve.bout...@free.fr:
good idea
any objection?
Regards,
Hervé
Le lundi 4 février 2013 11:11:32 Brian Fox a écrit :
i'm on the fence about if this is good or not, but I think the option if
provided should be simple-local-repository without the manager part.
People
already get confused about what's a local repo vs what's a repository
manager and the mixing of these concepts here will make that worse.
On Sat, Feb 2, 2013 at 10:59 AM, hbout...@apache.org wrote:
Updated Branches:
refs/heads/master 71dd7f3d2 - 5d06bc6a2
fixed typo
Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/5d06bc6a
Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/5d06bc6a
Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/5d06bc6a
Branch: refs/heads/master
Commit: 5d06bc6a25d40da49b9f477e3c2b408505dbae61
Parents: 71dd7f3
Author: Hervé Boutemy hbout...@apache.org
Authored: Sat Feb 2 16:59:20 2013 +0100
Committer: Hervé Boutemy hbout...@apache.org
Committed: Sat Feb 2 16:59:20 2013 +0100
--
.../main/java/org/apache/maven/DefaultMaven.java |2 +-
.../execution/DefaultMavenExecutionRequest.java| 10 +-
.../maven/execution/MavenExecutionRequest.java |4 ++--
.../main/java/org/apache/maven/cli/CLIManager.java |4 ++--
.../main/java/org/apache/maven/cli/MavenCli.java |2 +-
5 files changed, 11 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/maven/blob/5d06bc6a/maven-core/src/
main/java/org/apache/maven/DefaultMaven.java
--
diff --git
a/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
b/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
index d85f1ac..ac92afc 100644
--- a/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
+++ b/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
@@ -358,7 +358,7 @@ public class DefaultMaven
LocalRepository localRepo = new LocalRepository(
request.getLocalRepository().getBasedir() );
-if ( request.isUseSimpleLocalRepostoryManager() )
+if ( request.isUseSimpleLocalRepositoryManager() )
{
try
{
http://git-wip-us.apache.org/repos/asf/maven/blob/5d06bc6a/maven-core/src/
main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java
--
diff --git
a/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutio
nRequest.java
b/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecuti
onRequest.java index 3139846..09ead1a 100644
---
a/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutio
nRequest.java +++
b/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutio
nRequest.java @@ -143,7 +143,7 @@ public class
DefaultMavenExecutionRequest
*/
private boolean noSnapshotUpdates;
-private boolean useSimpleLocalRepostoryManager = false;
+private boolean useSimpleLocalRepositoryManager = false;
public DefaultMavenExecutionRequest()
{
@@ -1078,14 +1078,14 @@ public class DefaultMavenExecutionRequest
return this;
}
-public boolean isUseSimpleLocalRepostoryManager()
+public boolean isUseSimpleLocalRepositoryManager()
{
-return this.useSimpleLocalRepostoryManager;
+return this.useSimpleLocalRepositoryManager;
}
-public MavenExecutionRequest setUseSimpleLocalRepostoryManager(
boolean useSimpleLocalRepostoryManager )
+public MavenExecutionRequest setUseSimpleLocalRepositoryManager(
boolean useSimpleLocalRepositoryManager )
{
-this.useSimpleLocalRepostoryManager =
useSimpleLocalRepostoryManager;
+this.useSimpleLocalRepositoryManager =
useSimpleLocalRepositoryManager;
return this;
}
}
http://git-wip-us.apache.org/repos/asf/maven/blob/5d06bc6a/maven-core/src/
main/java/org/apache/maven/execution/MavenExecutionRequest.java
--
diff
maven-surefire pull request: [SUREFIRE-956] make forkNumber unique among co...
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/pull/21 - that one would need to be
applied first, leaving this one with only commits starting with [SUREFIRE-956]
(currently one).
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/agudian/maven-surefire SUREFIRE-956-forkNumber
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/maven-surefire/pull/22.patch
commit e9f758471aa9ac967025209df004d426e49e1844
Author: agudian andreas.gud...@gmail.com
Date: 2013-01-05T20:13:12Z
[SUREFIRE-946] prevent hanging main process if forked process was killed
(softly)
commit b32af3edadce6fd7b50a401b7362b039120ba33b
Author: agudian andreas.gud...@gmail.com
Date: 2013-01-05T21:08:53Z
Fix typo, format source
commit 16e544cf44c669981b1394a1e3e94734d74c6aac
Author: agudian andreas.gud...@gmail.com
Date: 2013-01-09T21:56:15Z
[SUREFIRE-946] fix crash-detection for reuseForks=true, now including hard
crashes.
* use a callback to close the TestProvidingInputStream after the forked
process ended but before waiting on InputFeeder to finish
* removed the shutdown hook in the forked VM again, removed
BOOTERCODE_CRASH (also fixes the other ITs that broke before)
* extend CrashDetectionIT for testing hard VM crashes
* add IT for killed main process with reusable fork
commit 652aab9f0315bd7d065c2ec57f6e6299d46c23be
Author: agudian andreas.gud...@gmail.com
Date: 2013-01-11T22:11:55Z
[SUREFIRE-946] reset verifier version to 1.4, update ForkStarter to latest
m-s-u snapshot.
commit 3c342a606a11ff72c21577132906dbf5ecd133d6
Author: agudian andreas.gud...@gmail.com
Date: 2013-01-11T22:20:22Z
[SUREFIRE-946] Fix the IT - now it actually tests the reported problem.
commit e27b083ba7b01e4ac6e6b94a10382287f51ae12d
Author: agudian andreas.gud...@gmail.com
Date: 2013-01-13T16:16:56Z
Use ShutdownHookUtils
commit 914123ff4776eb6289ec471b23cad7b51f643933
Author: Andreas Gudian andreas.gud...@gmail.com
Date: 2013-01-18T20:15:09Z
[SUREFIRE-949] add forkCount parameter, making the inconsitent forkMode
parameter deprecated.
- All defaulting works as in the previous versions, with the exception of
reuseForks (introduced in the last release). It's now true by default.
- forkCount supports C notation as in -T of maven-core
commit 2baed8122db7ad9e4e62c35d6e447865b890cc96
Author: Andreas Gudian andreas.gud...@gmail.com
Date: 2013-01-21T19:55:11Z
fix test (parenthesis were missing in the computation)
commit b70c2f29a069fc202a0a491b9d92bc57aa63b805
Author: Andreas Gudian andreas.gud...@gmail.com
Date: 2013-01-24T20:06:35Z
clean up variable naming: threadNumber becomes forkNumber
commit c1c76d5fabe83897786a71ca372569ba5bb0dbe6
Author: Andreas Gudian andreas.gud...@gmail.com
Date: 2013-01-24T20:12:08Z
[SUREFIRE-949] update documentation with new forkCount / reuseForks options
- also make ${surefire.threadNumber} replacement undocumented, as its
naming is totally misleading and might give users wrong impressions
commit aa4a7fe78e339dc8d89c6bb5d0c54f8c44639f3e
Author: Andreas Gudian andreas.gud...@gmail.com
Date: 2013-01-24T20:24:10Z
make test more robust by removing some assertions that depend on current
system load
commit 12bacc5e4ad0fccfcc6acba2b1aae7df7f79607d
Author: Andreas Gudian andreas.gud...@gmail.com
Date: 2013-01-24T20:35:02Z
[SUREFIRE-949] update documentation with new forkCount / reuseForks options
commit f6a0eaf3c8953769d3a0458d4798da48181d12ff
Author: Andreas Gudian andreas.gud...@gmail.com
Date: 2013-02-05T21:01:03Z
[SUREFIRE-956] make forkNumber unique among concurrent surefire-executions
in a parallel maven build
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: git commit: fixed typo
+1
On Tue, Feb 5, 2013 at 1:26 PM, Robert Scholte rfscho...@apache.org 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.
Users hitting this issue have often enough Maven knowledge to discover
this option, so I don't see the need for this mvn commandline argument.
Instead I would only use the MAVEN_OPTS option, and rename it to
LegacyLocalRepository instead of SimpleLocalRepository to encourage not to
use it.
WDYT?
Robert
Op Tue, 05 Feb 2013 00:02:47 +0100 schreef Hervé BOUTEMY
herve.bout...@free.fr:
good idea
any objection?
Regards,
Hervé
Le lundi 4 février 2013 11:11:32 Brian Fox a écrit :
i'm on the fence about if this is good or not, but I think the option if
provided should be simple-local-repository without the manager part.
People
already get confused about what's a local repo vs what's a repository
manager and the mixing of these concepts here will make that worse.
On Sat, Feb 2, 2013 at 10:59 AM, hbout...@apache.org wrote:
Updated Branches:
refs/heads/master 71dd7f3d2 - 5d06bc6a2
fixed typo
Project:
http://git-wip-us.apache.org/**repos/asf/maven/repohttp://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/**repos/asf/maven/commit/**
5d06bc6a http://git-wip-us.apache.org/repos/asf/maven/commit/5d06bc6a
Tree:
http://git-wip-us.apache.org/**repos/asf/maven/tree/5d06bc6ahttp://git-wip-us.apache.org/repos/asf/maven/tree/5d06bc6a
Diff:
http://git-wip-us.apache.org/**repos/asf/maven/diff/5d06bc6ahttp://git-wip-us.apache.org/repos/asf/maven/diff/5d06bc6a
Branch: refs/heads/master
Commit: 5d06bc6a25d40da49b9f477e3c2b40**8505dbae61
Parents: 71dd7f3
Author: Hervé Boutemy hbout...@apache.org
Authored: Sat Feb 2 16:59:20 2013 +0100
Committer: Hervé Boutemy hbout...@apache.org
Committed: Sat Feb 2 16:59:20 2013 +0100
--**--**
--
.../main/java/org/apache/**maven/DefaultMaven.java |2 +-
.../execution/**DefaultMavenExecutionRequest.**java| 10
+-
.../maven/execution/**MavenExecutionRequest.java |4 ++--
.../main/java/org/apache/**maven/cli/CLIManager.java |4 ++--
.../main/java/org/apache/**maven/cli/MavenCli.java |2 +-
5 files changed, 11 insertions(+), 11 deletions(-)
--**--**
--
http://git-wip-us.apache.org/**repos/asf/maven/blob/5d06bc6a/**
maven-core/src/http://git-wip-us.apache.org/repos/asf/maven/blob/5d06bc6a/maven-core/src/
main/java/org/apache/maven/**DefaultMaven.java
--**--**
--
diff --git a/maven-core/src/main/java/**org/apache/maven/DefaultMaven.
**java
b/maven-core/src/main/java/**org/apache/maven/DefaultMaven.**java
index d85f1ac..ac92afc 100644
--- a/maven-core/src/main/java/**org/apache/maven/DefaultMaven.**java
+++ b/maven-core/src/main/java/**org/apache/maven/DefaultMaven.**java
@@ -358,7 +358,7 @@ public class DefaultMaven
LocalRepository localRepo = new LocalRepository(
request.getLocalRepository().**getBasedir() );
-if ( request.**isUseSimpleLocalRepostoryManag**er() )
+if ( request.**isUseSimpleLocalRepositoryMana**ger() )
{
try
{
http://git-wip-us.apache.org/**repos/asf/maven/blob/5d06bc6a/**
maven-core/src/http://git-wip-us.apache.org/repos/asf/maven/blob/5d06bc6a/maven-core/src/
main/java/org/apache/maven/**execution/**DefaultMavenExecutionRequest.
**java
--**--**
--
diff --git
a/maven-core/src/main/java/**org/apache/maven/execution/**
DefaultMavenExecutio
nRequest.java
b/maven-core/src/main/java/**org/apache/maven/execution/**
DefaultMavenExecuti
onRequest.java index 3139846..09ead1a 100644
---
a/maven-core/src/main/java/**org/apache/maven/execution/**
DefaultMavenExecutio
nRequest.java +++
b/maven-core/src/main/java/**org/apache/maven/execution/**
DefaultMavenExecutio
nRequest.java @@ -143,7 +143,7 @@ public class
DefaultMavenExecutionRequest
*/
private boolean noSnapshotUpdates;
-private boolean useSimpleLocalRepostoryManager = false;
+private boolean useSimpleLocalRepositoryManage**r = false;
public DefaultMavenExecutionRequest()
{
@@ -1078,14 +1078,14 @@ public class DefaultMavenExecutionRequest
return this;
}
-public boolean isUseSimpleLocalRepostoryManag**er()
+public boolean isUseSimpleLocalRepositoryMana**ger()
{
-return this.**useSimpleLocalRepostoryManager**;
+return
Re: Testing [Vote] plugins?
On 5 February 2013 21:26, James Nord (jnord) jn...@cisco.com 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 plugin I sit behind a corporate MRM - and as such we keep every single release we download forever (as we need to make sure all builds are reproducible). Changing this policy to test plugins up for a vote could end up with an un-reproducible build (if a staged plugin is used). Grabbing the plugin and installing to my local maven repo is likely doomed to failure due to MNG-5181. So given that releases are not always golden my question is what do people do in order to test this with their software in a corporate environment? (or to put it another way why are versions re-used if a vote fails, violating the #1 maven rule)? Regards, /James [1] http://dev.markmail.org/message/mto7fl4ngxht63ue?q=list:org%2Eapache%2Emaven%2Edev+canceled+vote [2] http://dev.markmail.org/message/j4i325udpvoxm67d?q=list:org%2Eapache%2Emaven%2Edev+ANN+Maven+Filtering+version+1%2E0 If these are being released into Central - then they *will* never change. They are Golden. Prior to getting their, e.g. during the voting process, these jars are released into a staging area. You are invited to try those jars from the staging area to ensure they dont have regression issues etc. If you do this then you generally delete your local m2 cache (~/.m2/repository) or you use a new settings.xml file that points to a different location. You would not normally use an MRM in this scenario as the staging jars are not yet Golden. If the release fail, then the staging areas are deleted and the process starts again. Nothing has happened to Central yet. If the release passes, then staging is promoted into Central, its all Golden and then never changes. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Testing [Vote] plugins?
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, 2013 at 7:04 PM, Barrie Treloar baerr...@gmail.com wrote: On 5 February 2013 21:26, James Nord (jnord) jn...@cisco.com 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 plugin I sit behind a corporate MRM - and as such we keep every single release we download forever (as we need to make sure all builds are reproducible). Changing this policy to test plugins up for a vote could end up with an un-reproducible build (if a staged plugin is used). Grabbing the plugin and installing to my local maven repo is likely doomed to failure due to MNG-5181. So given that releases are not always golden my question is what do people do in order to test this with their software in a corporate environment? (or to put it another way why are versions re-used if a vote fails, violating the #1 maven rule)? Regards, /James [1] http://dev.markmail.org/message/mto7fl4ngxht63ue?q=list:org%2Eapache%2Emaven%2Edev+canceled+vote [2] http://dev.markmail.org/message/j4i325udpvoxm67d?q=list:org%2Eapache%2Emaven%2Edev+ANN+Maven+Filtering+version+1%2E0 If these are being released into Central - then they *will* never change. They are Golden. Prior to getting their, e.g. during the voting process, these jars are released into a staging area. You are invited to try those jars from the staging area to ensure they dont have regression issues etc. If you do this then you generally delete your local m2 cache (~/.m2/repository) or you use a new settings.xml file that points to a different location. You would not normally use an MRM in this scenario as the staging jars are not yet Golden. If the release fail, then the staging areas are deleted and the process starts again. Nothing has happened to Central yet. If the release passes, then staging is promoted into Central, its all Golden and then never changes. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Testing [Vote] plugins?
On 6 February 2013 10:39, Benson Margulies bimargul...@gmail.com 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 downloading source and building it themselves. They can still do this, they just need to configure their MRM correctly. The staging releases should be quarantined on a separate URL. No developer should be using this particular URL, only the person delegated to test the staged release. They should then follow normal practice and delete the quarantined MRM repository when done. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: git commit: fixed typo
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 a
more
reliable way
I'm less inclined to removing mvn argument: only supporting MVN_OPTS will
force users to set the system property, then have the option enabled for every
builds
I think this would have the counter effect of using the option more than
necessary
Regards,
Hervé
Le mardi 5 février 2013 19:26:51 Robert Scholte a écrit :
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 discover
this option, so I don't see the need for this mvn commandline argument.
Instead I would only use the MAVEN_OPTS option, and rename it to
LegacyLocalRepository instead of SimpleLocalRepository to encourage not to
use it.
WDYT?
Robert
Op Tue, 05 Feb 2013 00:02:47 +0100 schreef Hervé BOUTEMY
herve.bout...@free.fr:
good idea
any objection?
Regards,
Hervé
Le lundi 4 février 2013 11:11:32 Brian Fox a écrit :
i'm on the fence about if this is good or not, but I think the option if
provided should be simple-local-repository without the manager part.
People
already get confused about what's a local repo vs what's a repository
manager and the mixing of these concepts here will make that worse.
On Sat, Feb 2, 2013 at 10:59 AM, hbout...@apache.org wrote:
Updated Branches:
refs/heads/master 71dd7f3d2 - 5d06bc6a2
fixed typo
Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/5d06bc6a
Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/5d06bc6a
Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/5d06bc6a
Branch: refs/heads/master
Commit: 5d06bc6a25d40da49b9f477e3c2b408505dbae61
Parents: 71dd7f3
Author: Hervé Boutemy hbout...@apache.org
Authored: Sat Feb 2 16:59:20 2013 +0100
Committer: Hervé Boutemy hbout...@apache.org
Committed: Sat Feb 2 16:59:20 2013 +0100
--
.../main/java/org/apache/maven/DefaultMaven.java |2 +-
.../execution/DefaultMavenExecutionRequest.java| 10 +-
.../maven/execution/MavenExecutionRequest.java |4 ++--
.../main/java/org/apache/maven/cli/CLIManager.java |4 ++--
.../main/java/org/apache/maven/cli/MavenCli.java |2 +-
5 files changed, 11 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/maven/blob/5d06bc6a/maven-core/src
/
main/java/org/apache/maven/DefaultMaven.java
--
diff --git
a/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
b/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
index d85f1ac..ac92afc 100644
--- a/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
+++ b/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
@@ -358,7 +358,7 @@ public class DefaultMaven
LocalRepository localRepo = new LocalRepository(
request.getLocalRepository().getBasedir() );
-if ( request.isUseSimpleLocalRepostoryManager() )
+if ( request.isUseSimpleLocalRepositoryManager() )
{
try
{
http://git-wip-us.apache.org/repos/asf/maven/blob/5d06bc6a/maven-core/src
/
main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java
--
diff --git
a/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecuti
o
nRequest.java
b/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecuti
onRequest.java index 3139846..09ead1a 100644
---
a/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecuti
o
nRequest.java +++
b/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecuti
o
nRequest.java @@ -143,7 +143,7 @@ public class
DefaultMavenExecutionRequest
*/
private boolean noSnapshotUpdates;
-private boolean useSimpleLocalRepostoryManager = false;
+private boolean useSimpleLocalRepositoryManager = false;
public DefaultMavenExecutionRequest()
{
@@ -1078,14 +1078,14 @@ public class DefaultMavenExecutionRequest
return this;
}
-
