Re: [VOTE] Apache Maven Wagon 2.4
+1 Regards, Hervé Le mardi 5 février 2013 15:14:47 Olivier Lamy a écrit : Hi, I'd like to release Wagon 2.4. We fixed 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335version=186 97 Staging repository: https://repository.apache.org/content/repositories/maven-199/ Source release: https://repository.apache.org/content/repositories/maven-199/org/apache/mave n/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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: git commit: fixed typo
legacy local repository rewording done I understand your question about effective usefusess of cli option. I chose to keep it since it permits to have _maven.repositories file name somewhere in our codebase, so it gives a little documentation about the way this feature is implemented and will give a hint to many people to explain what are these _maven.repositories files? Regards, Hervé Le mercredi 6 février 2013 21:26:01 Robert Scholte a écrit : I see your point, although I don't know how often you need to add this option to the commandline to be able to build your project. I would expect almost every time once you're hitting this issue. Still I have my doubts if it should be a new option. From the CLIManager: options.addOption( OptionBuilder.withLongOpt( simple-local-repository-manager ).withDescription( Use a simple Local Repository Manager, ie no use of _maven.repositories. Can be activated using -Dmaven.simpleLocalRepoMan=true ).create( SIMPLE_LOCAL_REPOSITORY_MANAGER ) ); 'mvn phase -Dmaven.simpleLocalRepoMan' would be good enough for me if it only happens now and then. (but this should be changed to -Dmaven.legacyLocalRepo ...) Robert Op Wed, 06 Feb 2013 04:12:03 +0100 schreef Hervé BOUTEMY herve.bout...@free.fr: 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
Re: Fast or exact ?
+1 good result without config is the default people wanting to tweak will learn how to do it, and how to get back to exact when they release, which requires some organization Regards, Hervé Le vendredi 8 février 2013 08:43:25 Anders Hammar a écrit : In general, I think that the default value should be whatever works in most cases. Then we could have params for tweaking this (for better performance e.g. in specific cases), but it would be up to the user to do this. So, in this specific case, I think the default should be to recompress so that it always works even though it might be a bit slower. /Anders On Thu, Feb 7, 2013 at 9:58 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: A lot of you seemed to have realized that the latest version of war and assembly have chosen the fast option over the compact option; and you actually seem to like it ;) https://jira.codehaus.org/browse/MASSEMBLY-639 has been filed and fixed which will revert the behaviour back to slow for both war and assembly, So what do you think ? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Is there any on-going work to implement standard build promotion/staging mechanism?
Hi Hervé, I'm sorry for the late reply introducing new status, with pseudo-pom property and so on seems irrealistic, at least to me: the concept is interesting, but I doubt it can fit into the actual code Do you think it is feasible to add such status info as some plugin config? Perhaps with Maven 3.2 (precise version and feature definition hypothetical), since decoupling dependency resolution in a work in progress because really needed: started in Maven 3.0 with a first extration into Aether, will continue in 3.1 with some experience in evolutions. An evolution like yours could be imagined only after, IMHO When the 3.2 can be expected approx? Within one year? Here I inserted my question into the original discussion. I hope it is still readable... Context: we have several modules which are built on top of each other. The build pipeline: - developer commits his/her changes to the SVN ok, standard SNAPSHOT source - the Jenkins server checks out from SVN, compiles and runs the unit tests; finally, the jar artifacts are created and published with integration status ok, publishing the SNAPSHOT binary to an integration repository - a Jenkins job retrieves this artifact from an Ivy repository and checks out secondary tests from the SVN; runs the secondary tests; if all tests pass, the description of the artifact is re-published with milestone status this one can be done by copying the SNAPSHOT artifact from integration repository to a milestone repository - other jobs grab only the artifact if it has least milestone status other jobs, which refer to the SNAPSHOT with its -SNAPSHOT in the version only use the milestone repository, not the integration one: fine Yep, but: is it possible to use mixed repository references i.e. one dependency references to integration and an other dependency references to milestone? I see here the first issue. - on the end of the pipeline milestone artifacts can be promoted manually to release if the manual tests are successful that's the tricky part: you're changing a SNAPSHOT artifact to a release do you expect build reproducibility of the release? (even if your objective is to promote the pre-built binary, not to deploy a rebuild) I expect reproducible build, but in practice we experienced slight changes in the build environment, which in practice results pseudo reproducible build. E.g.: os/jdk updates, even if they are done in a controlled manner. what about copying the binary into the same repo, ony changing its version coordinates: of course, its content (META-INF/maven/$gid/$aid/pom.xml) won't be consistent - other loosely coupled projects reference only to artifacts with release status ok, they reference release versions in the release repo Promotion is handled completely by the apache-ivy. It allows you not only to reference snapshot as maven do, but you can specify latest.integration or latest.release as version. without any version? and not latest.milestone? Yes, I mean latest.milestone. Ivy is tricky as it can use 4th coordinate namely: branch, then it makes sense to reference latest.release from a specific branch. with Maven and previous repo, you can write an unbounded range: [minimal,) Is [minimal,) means the latest, or any from the specified range? activating integration consists in adding the integration repo Notice: you might require separate integration or milestone repos to distinguish which dependency can include milestone would that make sense? Generally, yes. I have commented the problematic points. Regards, Gabor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Apache Maven Wagon 2.4
Hi, The vote has passed with the following result: +1 (binding): Dan, Hervé, Olivier I will continue the release process. 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
