Re: 3.1.0 Release
I will wait until after this release. I will start running the ITs and validate and start preparing cutting the release. On May 19, 2013, at 11:20 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: IIUC, you wanted to make some changes before the release: if you can commit these changes before cuttung the release, to let us time to review the commit before voting on a release, this could be useful Regards, Hervé Le dimanche 19 mai 2013 08:05:30 Jason van Zyl a écrit : Hervé, You happy with all your updates? Have everything in your want in before I cut the release? Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Re: DepMgt is useless because not transitive
Checking them out. It's not that I didn't agree with you the first time :-) It really is a matter of how to introduce and not introduce any discrepancies in behaviour. The general solution is to look at the dependencies of your final runtime and constrain them in the depMgmt section that you control. The way the nearest rule and depMgmt behaviour currently work bing altered would cause problems unless we tied a particular convention to a particular version of a POM. Having one version of Maven resolve a project one way and another version of Maven resolve it differently would probably be very confusing. A) Would cause a resolution behaviour issue. B) Don't you think what currently exists is simpler where you understand the composition of your application and control it from the depMgmt section in your project? C) I have no doubt improvements can be made in general, and in a standard, but completely pluggable resolution i think is unworkable generally. I'll load up your POMs and take a look. On May 19, 2013, at 1:57 PM, Geoffrey De Smet ge0ffrey.s...@gmail.com wrote: On 19-05-13 17:18, Jason van Zyl wrote: I can show you visually whats happening and it's not so much a bug (which I think I explained to you when you showed me the slides initially) but the current design. I'd like to propose to review the current design. Here are some idea's for an improved design: A) Make dependencyManagement transitive: Apply the inherited dependencyManagement on yourproject before processing it in myproject. Or simply put: the dependency graph that yourproject compiles and build with, is the same dependency subgraph that myproject incorporates due to depending on yourproject. B) Transitive dependencies overrides should be declared within the element of the dependency, just like excludes. For example: dependency... artifactIda/artifactId transitiveDependencieOverrides dependency artifactIdjbpm-flow/artifactId version5.3.0.Final/version /dependency /transitiveDependencieOverrides /dependency If a is upgraded and a no longer depends on jbpm, this gives an error. If a is upgraded and the new version of a requires a higher jbpm-flow, then the guy upgrading a would notice that we explicitly overwrote the jbpm-flow in the past, so there's at least a chance he upgrades jbpm-flow too (and doesn't run into NoSuchMethodError (*)). Declaring a normal dependency just to override transitive dependency (regardless if it's in dependencyManagement or not) is in practice a maintenance nightmare, but it's the only option that's available now. B) would fix that. C) Pluggable conflict resolution Out-of-the-box, we should have: 1) the nearest (which is part of the reason that the version of direct dependencies win). 2) the highest version (according to lexicographic version number comparison). Any sane project will want to use 2): When the nearest rule decides to use the lowest version of 2 versions, it's asking for a NoSuchMethodError (*). (*) If you're lucky, in your test coverage. If you're unlucky, in production. Compilation doesn't see it because dependencies are not recompiled. HTH :) On May 19, 2013, at 11:05 AM, Jason van Zyl ja...@tesla.io wrote: You have the POMs handy you made the slides from? On May 17, 2013, at 11:42 AM, Geoffrey De Smet ge0ffrey.s...@gmail.com wrote: I've always believed this is a bug, not a feature. I am still hoping to convince Jason etc of that. I talked about this last year already at Devoxx 2012 in my session Maven dependency puzzlers. I had several reactions that this must be a bug. Just look at 3 slides, and tell me maven 3.0.4 does the sane thing: The setup (click right to go the next slide) http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#34.0 How maven 3.0.4 resolved it: http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#35.0 And what this means for users: http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#36.0 Look at that last slide and tell me this is not a bug. wkr, Geoffrey On 09-04-13 13:38, Arnaud Héritier wrote: Yes when I analyzed the behavior, seeing it was here for long long time I understood that it was probably done by design. I had a look at our doc ( http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management) and we should probably detail more this behavior which is local to the currently built project (At least to be sure to be able to say RTFM). I'm not the only one to have supposed the wrong behavior which in users mind is more a bug than a feature On Tue, Apr 9, 2013 at 12:59 PM, Jason van Zyl ja...@tesla.io wrote
Re: next plugin releases toward Maven 3.1-A1
I'm planning to cut a release on Monday. I have a a refactoring of the CLI that I will finish over the weekend, primary to help exposing JSR330 bindings from startup so that the core can start down the path of switching the Plexus components to proper JSR330 components. If no one gets around to updating the plugins I will do that as well. Hervé if you're not going to be happy with your plugin updates by Monday just let me know over the weekend. I'm not in any rush. On May 6, 2013, at 3:50 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: To have Maven 3.1-A1 compatible plugins, we now need to release: - maven-site-plugin 3.3 - maven dependency-plugin 2.8 - maven-shade-plugin 2.1 - maven-project-info-reports-plugin 2.7 Other projects may have plugins to release too, like Tycho. I still have some work to do on maven-site-plugin before I can release. If anybody has something to do on other plugins, please report. If anybody wants to take care of a release, please do: I'm not against some help. Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
Re: [VOTE] Apache 3.1.0-alpha-1
The vote for 3.1.0-alpha-1 is cancelled. There is a snapshot repository in the parent POM and the vote has gone on for far longer than acceptable. Hervé go ahead and update any versions of the POMs you like, I have some small changes I'm going to make and when you're happy with the updated plugins I'll cut the release again. On May 4, 2013, at 11:40 AM, Jason van Zyl ja...@tesla.io wrote: Sure, update all the plugins. We might as well do all that maintenance work now before the next release. I can look at making an enforcer rule. It's been something I've been meaning at looking at is breaking out all the checks in the release plugin to enforcer rules so they can be used anywhere. Inside and outside the release plugin. On May 4, 2013, at 11:26 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: uh, I didn't see this one :( if the check can be automated through an enforcer rule, this would be a Good Thing (TM) I finally found my way with maven-dependency-tree (vote in progress) + dependency:tree (re-added verbose mode, which was a big users expectation). And since I have some time this week (holidays), I should be able to release everything during these holidays. It would be nice to update default plugins in Maven core before the next release candidate. Regards, Hervé Le samedi 4 mai 2013 10:12:25 Jason van Zyl a écrit : I will cancel the vote and respin it. No one has looked that hard: there's a snapshot repository in the top-level POM. I haven't made any noise as Hervé is trying to release all the prerequisites so that some of the standard plugins don't fail. On May 2, 2013, at 5:16 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Currently it's +1 (binding): Hervé me Some other +1's and -1's I'd expect the release manager for ths release to have made some noise by now (as any release manager should) On Thursday, 2 May 2013, Stephen Connolly wrote: I think we are just waiting for one more binding vote from a PMC member... But somebody should double check the count On Thursday, 2 May 2013, ceki wrote: Hello all, Out of curiosity, are there any other non-resolved issues holding up this release? Best regards, On 23.04.2013 12:24, Stephen Connolly wrote: +1 (binding) for 3.1.0-alpha-1 The following issue needs to be resolved before I will vote +1 on a non-alpha release: http://jira.codehaus.org/**browse/MNG-5470http://jira.codehaus.org/brows e/MNG-5470 RAT is reporting the 391 files are either missing license headers or have not been flagged as files that cannot support a license header. Most of these are test data files and I would be happy to argue that the test may require a specific exact content for reproducibility, but the following I do not feel I can make a case for. I will require these 39 files to be addressed in some way before the final 3.1.0 release or I cannot provide a binding vote for the release. (the MANIFEST.MF may be one where a header does not make sense, but it is a non-generated file) I cannot speak for the rest of the PMC, but my understanding is that as a PMC member it is one of our duties to ensure that the source (which is what the vote is on) has met with the ASF requirements for license headers. * Unapproved licenses: apache-maven/src/bin/m2.conf apache-maven/src/conf/logging/**simplelogger.properties maven-aether-provider/src/**main/java/org/apache/maven/** repository/internal/package.**html maven-aether-provider/src/**site/apt/index.apt maven-artifact/src/site/apt/**index.apt maven-compat/compatibility.cfl maven-compat/src/main/**resources/META-INF/maven/**plugin.xml maven-core/lifecycle-executor.**txt maven-core/plugin-manager.txt maven-core/project-builder.txt maven-core/src/main/resources/**org/apache/maven/messages/** build.properties maven-core/src/site/apt/**artifact-handlers.apt maven-core/src/site/apt/**configuration-management.apt maven-core/src/site/apt/**default-bindings.apt.vm maven-core/src/site/apt/**getting-to-container-**configured-mojos.apt maven-core/src/site/apt/index.**apt maven-core/src/site/apt/**inheritance.apt maven-core/src/site/apt/**lifecycles.apt.vm maven-core/src/site/apt/**offline-mode.apt maven-core/src/site/apt/**plugin-execution-isolation.apt maven-core/src/site/apt/**scripting-support/marmalade-**support.apt maven-core/src/site/resources/**design/2.1-lifecycle-refactor.**graffle maven-embedder/src/examples/**simple-project/src/main/java/** org/apache/maven/embedder/App.**java maven-embedder/src/examples/**simple-project/src/test/java/** org/apache/maven/embedder/**AppTest.java maven-embedder/src/main/**resources/META-INF/MANIFEST.MF maven-embedder/src/main/**resources/META-INF/maven/** slf4j-configuration.properties maven-embedder/src/site/apt/**cli.apt.vm maven-embedder/src/site/apt/**index.apt.vm maven-embedder/src/site/apt
Re: [VOTE] Apache 3.1.0-alpha-1
I will cancel the vote and respin it. No one has looked that hard: there's a snapshot repository in the top-level POM. I haven't made any noise as Hervé is trying to release all the prerequisites so that some of the standard plugins don't fail. On May 2, 2013, at 5:16 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Currently it's +1 (binding): Hervé me Some other +1's and -1's I'd expect the release manager for ths release to have made some noise by now (as any release manager should) On Thursday, 2 May 2013, Stephen Connolly wrote: I think we are just waiting for one more binding vote from a PMC member... But somebody should double check the count On Thursday, 2 May 2013, ceki wrote: Hello all, Out of curiosity, are there any other non-resolved issues holding up this release? Best regards, On 23.04.2013 12:24, Stephen Connolly wrote: +1 (binding) for 3.1.0-alpha-1 The following issue needs to be resolved before I will vote +1 on a non-alpha release: http://jira.codehaus.org/**browse/MNG-5470http://jira.codehaus.org/browse/MNG-5470 RAT is reporting the 391 files are either missing license headers or have not been flagged as files that cannot support a license header. Most of these are test data files and I would be happy to argue that the test may require a specific exact content for reproducibility, but the following I do not feel I can make a case for. I will require these 39 files to be addressed in some way before the final 3.1.0 release or I cannot provide a binding vote for the release. (the MANIFEST.MF may be one where a header does not make sense, but it is a non-generated file) I cannot speak for the rest of the PMC, but my understanding is that as a PMC member it is one of our duties to ensure that the source (which is what the vote is on) has met with the ASF requirements for license headers. * Unapproved licenses: apache-maven/src/bin/m2.conf apache-maven/src/conf/logging/**simplelogger.properties maven-aether-provider/src/**main/java/org/apache/maven/** repository/internal/package.**html maven-aether-provider/src/**site/apt/index.apt maven-artifact/src/site/apt/**index.apt maven-compat/compatibility.cfl maven-compat/src/main/**resources/META-INF/maven/**plugin.xml maven-core/lifecycle-executor.**txt maven-core/plugin-manager.txt maven-core/project-builder.txt maven-core/src/main/resources/**org/apache/maven/messages/** build.properties maven-core/src/site/apt/**artifact-handlers.apt maven-core/src/site/apt/**configuration-management.apt maven-core/src/site/apt/**default-bindings.apt.vm maven-core/src/site/apt/**getting-to-container-**configured-mojos.apt maven-core/src/site/apt/index.**apt maven-core/src/site/apt/**inheritance.apt maven-core/src/site/apt/**lifecycles.apt.vm maven-core/src/site/apt/**offline-mode.apt maven-core/src/site/apt/**plugin-execution-isolation.apt maven-core/src/site/apt/**scripting-support/marmalade-**support.apt maven-core/src/site/resources/**design/2.1-lifecycle-refactor.**graffle maven-embedder/src/examples/**simple-project/src/main/java/** org/apache/maven/embedder/App.**java maven-embedder/src/examples/**simple-project/src/test/java/** org/apache/maven/embedder/**AppTest.java maven-embedder/src/main/**resources/META-INF/MANIFEST.MF maven-embedder/src/main/**resources/META-INF/maven/** slf4j-configuration.properties maven-embedder/src/site/apt/**cli.apt.vm maven-embedder/src/site/apt/**index.apt.vm maven-embedder/src/site/apt/**logging.apt maven-model/src/main/java/org/**apache/maven/model/io/xpp3/** package.html maven-model/src/main/java/org/**apache/maven/model/merge/**package.html maven-model/src/main/java/org/**apache/maven/model/package.**html maven-model/src/site/apt/**index.apt maven-model-builder/src/site/**apt/index.apt maven-model-builder/src/site/**apt/super-pom.apt.vm maven-plugin-api/src/site/apt/**index.apt maven-plugin-api/src/test/**resources/plugin.xml maven-repository-metadata/src/**site/apt/index.apt maven-settings/src/site/apt/**index.apt Attached is the full report (if it makes it through the mailing list filters) -Stephen On 1 April 2013 13:12, Jason van Zyl ja...@tesla.io mailto:ja...@tesla.io wrote: Here are the release bits for 3.1.0-alpha-1: Release notes: https://jira.codehaus.org/**secure/ReleaseNote.jspa?** projectId=10500version=18967https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 S -- Sent from my phone -- Sent from my phone Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Script timed out
Re: [VOTE] Apache 3.1.0-alpha-1
Sure, update all the plugins. We might as well do all that maintenance work now before the next release. I can look at making an enforcer rule. It's been something I've been meaning at looking at is breaking out all the checks in the release plugin to enforcer rules so they can be used anywhere. Inside and outside the release plugin. On May 4, 2013, at 11:26 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: uh, I didn't see this one :( if the check can be automated through an enforcer rule, this would be a Good Thing (TM) I finally found my way with maven-dependency-tree (vote in progress) + dependency:tree (re-added verbose mode, which was a big users expectation). And since I have some time this week (holidays), I should be able to release everything during these holidays. It would be nice to update default plugins in Maven core before the next release candidate. Regards, Hervé Le samedi 4 mai 2013 10:12:25 Jason van Zyl a écrit : I will cancel the vote and respin it. No one has looked that hard: there's a snapshot repository in the top-level POM. I haven't made any noise as Hervé is trying to release all the prerequisites so that some of the standard plugins don't fail. On May 2, 2013, at 5:16 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Currently it's +1 (binding): Hervé me Some other +1's and -1's I'd expect the release manager for ths release to have made some noise by now (as any release manager should) On Thursday, 2 May 2013, Stephen Connolly wrote: I think we are just waiting for one more binding vote from a PMC member... But somebody should double check the count On Thursday, 2 May 2013, ceki wrote: Hello all, Out of curiosity, are there any other non-resolved issues holding up this release? Best regards, On 23.04.2013 12:24, Stephen Connolly wrote: +1 (binding) for 3.1.0-alpha-1 The following issue needs to be resolved before I will vote +1 on a non-alpha release: http://jira.codehaus.org/**browse/MNG-5470http://jira.codehaus.org/brows e/MNG-5470 RAT is reporting the 391 files are either missing license headers or have not been flagged as files that cannot support a license header. Most of these are test data files and I would be happy to argue that the test may require a specific exact content for reproducibility, but the following I do not feel I can make a case for. I will require these 39 files to be addressed in some way before the final 3.1.0 release or I cannot provide a binding vote for the release. (the MANIFEST.MF may be one where a header does not make sense, but it is a non-generated file) I cannot speak for the rest of the PMC, but my understanding is that as a PMC member it is one of our duties to ensure that the source (which is what the vote is on) has met with the ASF requirements for license headers. * Unapproved licenses: apache-maven/src/bin/m2.conf apache-maven/src/conf/logging/**simplelogger.properties maven-aether-provider/src/**main/java/org/apache/maven/** repository/internal/package.**html maven-aether-provider/src/**site/apt/index.apt maven-artifact/src/site/apt/**index.apt maven-compat/compatibility.cfl maven-compat/src/main/**resources/META-INF/maven/**plugin.xml maven-core/lifecycle-executor.**txt maven-core/plugin-manager.txt maven-core/project-builder.txt maven-core/src/main/resources/**org/apache/maven/messages/** build.properties maven-core/src/site/apt/**artifact-handlers.apt maven-core/src/site/apt/**configuration-management.apt maven-core/src/site/apt/**default-bindings.apt.vm maven-core/src/site/apt/**getting-to-container-**configured-mojos.apt maven-core/src/site/apt/index.**apt maven-core/src/site/apt/**inheritance.apt maven-core/src/site/apt/**lifecycles.apt.vm maven-core/src/site/apt/**offline-mode.apt maven-core/src/site/apt/**plugin-execution-isolation.apt maven-core/src/site/apt/**scripting-support/marmalade-**support.apt maven-core/src/site/resources/**design/2.1-lifecycle-refactor.**graffle maven-embedder/src/examples/**simple-project/src/main/java/** org/apache/maven/embedder/App.**java maven-embedder/src/examples/**simple-project/src/test/java/** org/apache/maven/embedder/**AppTest.java maven-embedder/src/main/**resources/META-INF/MANIFEST.MF maven-embedder/src/main/**resources/META-INF/maven/** slf4j-configuration.properties maven-embedder/src/site/apt/**cli.apt.vm maven-embedder/src/site/apt/**index.apt.vm maven-embedder/src/site/apt/**logging.apt maven-model/src/main/java/org/**apache/maven/model/io/xpp3/** package.html maven-model/src/main/java/org/**apache/maven/model/merge/**package.html maven-model/src/main/java/org/**apache/maven/model/package.**html maven-model/src/site/apt/**index.apt maven-model-builder/src/site/**apt/index.apt maven-model-builder/src/site/**apt/super-pom.apt.vm maven-plugin
Re: DepMgt is useless because not transitive
This is how is was designed to work. Aether can do anything but the original implementation is simply a map of GAs with a version preference. If the GA is encountered then its version is overridden. This effectively gives you a target platform like mechanism but is intended to be controlled from the final application. Maven does not consider depMan at every level in the tree. It's a global map controlled from your project and its functionality is very limited in scope. You would need to do some relatively sophisticated conflict resolution to have every sub graph and its managed dependencies be reconciled with every other. Not that it can not be done but this certainly not how dependency management is implemented currently. This is not a bug, this is how the feature is implemented. On 2013-04-08, at 8:28 AM, Arnaud Héritier aherit...@gmail.com wrote: Hi all (and especially Herve, Jason and those who are working on Aether), We are several to hit what we consider to be a bug but myself I don't understand how we did to not see it before. To be short the problem resides in depMgt usage. It is useful only in the project you are building to enforce/lock some versions. If this is in a transitive path of a dep it is unused. For example here is a sample : http://parleys.com/#play/515ef261e4b0cb5a00d98074/chapter34/about The code to test : https://github.com/ndeloof/maven-puzzler/tree/master/3 As far as we don't define the version in the depMgt of the project itself Maven will use the one from dependencies and won't take care of any other depMgt in the transitive path Vincent Massol also reproduced it at code level here : http://jira.codehaus.org/browse/MNG-5462 If someone could have a look at this issue please. -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache 3.1.0-alpha-1
On Apr 7, 2013, at 7:32 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: while working on site publication, I found that all my work on maven-aether- provider unit tests had simply been pruned when merging Aether. I will need to re-do the work, step by step :( I don't think you need to redo anything. If you can find the commits I can work them back in. I'd like to figure out how they got pruned. From my perspective, maven-reporting-exec is ready to release: I'll do it tomorrow if nobody objects. I'd like some review on DOXIA-484 before releasing Doxia 1.4 And I still didn't have a look at dependency:tree... Regards, Hervé Le lundi 1 avril 2013 08:12:09 Jason van Zyl a écrit : Here are the release bits for 3.1.0-alpha-1: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18 967 Staging repository: https://repository.apache.org/content/repositories/maven-042/ Staged distribution: https://repository.apache.org/content/repositories/maven-042/org/apache/mave n/apache-maven/3.1.0-alpha-1/ Anyone trying this in advance should know that the Site, Dependency, and Shade plugin are not going to work. We are aware of this and those responsible for those plugins are looking into it. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
Re: [VOTE] Apache 3.1.0-alpha-1
Are you talking about properties on dependencies like we used to have in Maven 1.x? On Apr 4, 2013, at 1:28 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: Wayne and ALL: Thank you very much for considering this request, I got my answer. Does it make sense to file a jira at this point? Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Wayne Fay wayne...@gmail.com To: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 12:10:07 PM CDT to be able to annotate dependency with user properties - the kind of constrains I would like maven to remove in 3.1.0. Doubtful to be removed in 3.1.0. So: can I please respectfully request a formal PMC vote on my change request or should I just go away and leave you all alone? :-) No need to go away but please appreciate this is an issue that we are aware of and will continue to discuss for enhancement/change in some future release of Maven. Calling for a formal vote of the PMC at this time is unlikely to provide the result you desire. Wayne - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: [VOTE] Apache 3.1.0-alpha-1
Thanks. On Apr 2, 2013, at 1:00 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Staged documentation: http://maven.apache.org/ref/3.1.0-alpha-1/ Regards, Hervé Le lundi 1 avril 2013 08:12:09 Jason van Zyl a écrit : Here are the release bits for 3.1.0-alpha-1: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18 967 Staging repository: https://repository.apache.org/content/repositories/maven-042/ Staged distribution: https://repository.apache.org/content/repositories/maven-042/org/apache/mave n/apache-maven/3.1.0-alpha-1/ Anyone trying this in advance should know that the Site, Dependency, and Shade plugin are not going to work. We are aware of this and those responsible for those plugins are looking into it. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham
Re: WTF is Tesla?
I have been focusing on getting this next Maven release out which has taken a lot longer than I had wished. This release of Maven will serve as the first building block of Tesla. I require the JSR330, SLF4J, and Eclipse Aether changes in order for the features I plan to be a pure superset of Maven. I do not want a forked core if it can be avoided, and I think it can. So, first things first, once this release is out I can take the Maven binary distribution and layer in parts of Tesla. I won't use the Maven lists to promote it so keep watching the tesla.io site (it's back up) if you're interested. Ultimately to get where I would like to there are some proposals I still need to make for Maven. The core still needs some refactoring to do some of the more advanced things I'd like to do. On Mar 31, 2013, at 9:32 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: *Hello*. I am curious if there is any progress with this http://tesla.io/tesla/index.html Thank you, Andrei Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown
[VOTE] Apache 3.1.0-alpha-1
Here are the release bits for 3.1.0-alpha-1: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repository: https://repository.apache.org/content/repositories/maven-042/ Staged distribution: https://repository.apache.org/content/repositories/maven-042/org/apache/maven/apache-maven/3.1.0-alpha-1/ Anyone trying this in advance should know that the Site, Dependency, and Shade plugin are not going to work. We are aware of this and those responsible for those plugins are looking into it. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare
Re: [VOTE] Apache 3.1.0-alpha-1
Sure, log an issue. I don't consider it a show stopper. On Apr 1, 2013, at 9:36 AM, Baptiste MATHUS bmat...@batmat.net wrote: Just tried it, seems like there's a missing newline when using -V. With m3.0.4: *$ mvn -V clean verify* *Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)* *Maven home: /home/tiste/tools/Mavens/maven* *Java version: 1.6.0_37, vendor: Sun Microsystems Inc.* *Java home: /home/tiste/tools/JDKs/jdk1.6.0_37/jre* *Default locale: fr_FR, platform encoding: UTF-8* *OS name: linux, version: 3.5.0-26-generic, arch: amd64, family: unix* *[INFO] Scanning for projects...* *[INFO] * With m3.1.0-alpha-1: *$ mvn -V clean verify* *Apache Maven 3.1.0-alpha-1 (262b9bb1ef91d1414e5162d9dd0f5522e7186202; 2013-03-30 22:38:49+0100)* *Maven home: /home/tiste/tools/Mavens/maven* *Java version: 1.6.0_37, vendor: Sun Microsystems Inc.* *Java home: /home/tiste/tools/JDKs/jdk1.6.0_37/jre* *Default locale: fr_FR, platform encoding: UTF-8* *OS name: linux, version: 3.5.0-26-generic, arch: amd64, family: unix[INFO] Scanning for projects...* *[INFO]* Is this confirmed by someone else? Should I file an issue about this one? Thanks 2013/4/1 Igor Fedorenko i...@ifedorenko.com Tycho is not compatible with 3.1.0-alpha-1 either. -- Regards, Igor On 2013-04-01 8:12 AM, Jason van Zyl wrote: Here are the release bits for 3.1.0-alpha-1: Release notes: https://jira.codehaus.org/**secure/ReleaseNote.jspa?** projectId=10500version=18967https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repository: https://repository.apache.org/**content/repositories/maven-**042/https://repository.apache.org/content/repositories/maven-042/ Staged distribution: https://repository.apache.org/**content/repositories/maven-** 042/org/apache/maven/apache-**maven/3.1.0-alpha-1/https://repository.apache.org/content/repositories/maven-042/org/apache/maven/apache-maven/3.1.0-alpha-1/ Anyone trying this in advance should know that the Site, Dependency, and Shade plugin are not going to work. We are aware of this and those responsible for those plugins are looking into it. Thanks, Jason --** Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --**--- We know what we are, but know not what we may be. -- Shakespeare --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Three people can keep a secret provided two of them are dead. -- Benjamin Franklin
Re: [VOTE] Apache 3.1.0-alpha-1
Are you on Windows? On Apr 1, 2013, at 10:14 AM, Baptiste MATHUS bmat...@batmat.net wrote: Sure, neither do I, even less for an alpha release. http://jira.codehaus.org/browse/MNG-5458 Cheers 2013/4/1 Jason van Zyl ja...@tesla.io Sure, log an issue. I don't consider it a show stopper. On Apr 1, 2013, at 9:36 AM, Baptiste MATHUS bmat...@batmat.net wrote: Just tried it, seems like there's a missing newline when using -V. With m3.0.4: *$ mvn -V clean verify* *Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)* *Maven home: /home/tiste/tools/Mavens/maven* *Java version: 1.6.0_37, vendor: Sun Microsystems Inc.* *Java home: /home/tiste/tools/JDKs/jdk1.6.0_37/jre* *Default locale: fr_FR, platform encoding: UTF-8* *OS name: linux, version: 3.5.0-26-generic, arch: amd64, family: unix* *[INFO] Scanning for projects...* *[INFO] * With m3.1.0-alpha-1: *$ mvn -V clean verify* *Apache Maven 3.1.0-alpha-1 (262b9bb1ef91d1414e5162d9dd0f5522e7186202; 2013-03-30 22:38:49+0100)* *Maven home: /home/tiste/tools/Mavens/maven* *Java version: 1.6.0_37, vendor: Sun Microsystems Inc.* *Java home: /home/tiste/tools/JDKs/jdk1.6.0_37/jre* *Default locale: fr_FR, platform encoding: UTF-8* *OS name: linux, version: 3.5.0-26-generic, arch: amd64, family: unix[INFO] Scanning for projects...* *[INFO]* Is this confirmed by someone else? Should I file an issue about this one? Thanks 2013/4/1 Igor Fedorenko i...@ifedorenko.com Tycho is not compatible with 3.1.0-alpha-1 either. -- Regards, Igor On 2013-04-01 8:12 AM, Jason van Zyl wrote: Here are the release bits for 3.1.0-alpha-1: Release notes: https://jira.codehaus.org/**secure/ReleaseNote.jspa?** projectId=10500version=18967 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repository: https://repository.apache.org/**content/repositories/maven-**042/ https://repository.apache.org/content/repositories/maven-042/ Staged distribution: https://repository.apache.org/**content/repositories/maven-** 042/org/apache/maven/apache-**maven/3.1.0-alpha-1/ https://repository.apache.org/content/repositories/maven-042/org/apache/maven/apache-maven/3.1.0-alpha-1/ Anyone trying this in advance should know that the Site, Dependency, and Shade plugin are not going to work. We are aware of this and those responsible for those plugins are looking into it. Thanks, Jason --** Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --**--- We know what we are, but know not what we may be. -- Shakespeare --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Three people can keep a secret provided two of them are dead. -- Benjamin Franklin -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Maven 3.1.0-alpha-1
I'll make a more formal announcement after I play around a bit more, but if anyone wants to play around until then the staged distro is here: https://repository.apache.org/content/repositories/maven-042/org/apache/maven/apache-maven/3.1.0-alpha-1/ Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - A language that doesn’t affect the way you think about programming is not worth knowing. -- Alan Perlis
Re: Maven Core IT failures with Eclipse Aether
Hervé, I don't see any adjustment in the ITs for the site/dependency plugin. I'm going to cut the release today if I can so are you fine with the release? If you're fine I'm fine because I haven't tried the site or dependency plugin. On Mar 27, 2013, at 3:10 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: I just fixed http://jira.codehaus.org/browse/MSITE-683 / http://jira.codehaus.org/browse/MSHARED-280 Any tests from others are welcome Regards, Hervé Le mardi 19 mars 2013 01:49:08 Hervé BOUTEMY a écrit : I just had a look at the failures: they are caused by DefaultMavenReportExecutor using Sonatype Aether ExclusionsDependencyFilter [1] for MavenPluginManager.setupPluginRealm(...) API call [2] which is affected by switching to Eclipse Aether We will need some tweaks in maven-reporting-exec to detect Eclipse Aether, then a new maven-site-plugin version I will create Jira entries tomorrow to track the issue and work on a fix. IMHO, this doesn't require Maven 4.0: 3.1 is really fine for end users Regards, Hervé [1] http://maven.apache.org/shared/maven-reporting- exec/xref/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html#12 8 [2] http://maven.apache.org/shared/maven-reporting- exec/xref/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html#26 7 Le lundi 18 mars 2013 13:29:12 Jason van Zyl a écrit : In the ITs I have changed the ranges to accommodate these ITs not running with Eclipse Aether: MavenITmng3743ForkWithPluginManagementTest: Site plugin MavenITmng3703ExecutionProjectWithRelativePathsTest: Site plugin MavenITmng3684BuildPluginParameterTest: Site plugin MavenITmng3372DirectInvocationOfPluginsTest: dependency:tree used directly MavenITmng5019StringBasedCompLookupFromChildPluginRealmTest: Site plugin So I would consider this fairly major which is why I'm arguing for 4.0.0. These may not be trivial things to fix and we probably can't predict when things like the Site, Dependency, and Shade plugin will be updated. The ITs run with these changes and I will proceed to merge the Eclipse Aether branch into master. On Mar 16, 2013, at 7:27 AM, Jason van Zyl ja...@tesla.io wrote: Hervé, Olivier, There are two failures due to the SLF4J Simple changes made which only affect the embedded mode but it's really nice having those clean because they are so much faster. Hervé, maybe these worked for you locally and you still have some more work to do? This I can take a looked into and I'll ask Ceki for a little help here. The rest of the errors are related to the use of the actual Site and Dependency plugins in the ITs which I don't think is quite right. I have no familiarity with these plugins and I believe you two work on these for the most part. There are direct linkage problems and it's hard for me to tell what it is you're trying to test in the case of the ITs with failures. If you are testing behavior that is general can you please make ITs that don't depend on actual plugins? Or if they are truly to test the site or dependency plugins can you move them to their respective plugins? If you build from the eclipse-aether branch and run the ITs you'll see the errors. I consistently get the following: Tests run: 716, Failures: 2, Errors: 5, Skipped: 0, Time elapsed: 269.409 sec FAILURE! https://gist.github.com/jvanzyl/5176584 Once those are sorted out then we can move on to the Plugin ITs and see what kind of errors/failures we have there but we need to get past the core ITs first. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare - 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 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting
Re: Maven Core IT failures with Eclipse Aether
On Mar 30, 2013, at 10:00 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: yes, the ITs will be modified after the m-site-p release, ie just use m-site-p 3.3 Cool. Just wanted to make sure. I didn't have time for the moment to try m-dependency-p:tree and work on a fix, but that will be the same: the IT will just need to use the next version, which will be improved to use the new Maven core API no problem to release now Regards, Hervé Le samedi 30 mars 2013 09:38:47 Jason van Zyl a écrit : Hervé, I don't see any adjustment in the ITs for the site/dependency plugin. I'm going to cut the release today if I can so are you fine with the release? If you're fine I'm fine because I haven't tried the site or dependency plugin. On Mar 27, 2013, at 3:10 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: I just fixed http://jira.codehaus.org/browse/MSITE-683 / http://jira.codehaus.org/browse/MSHARED-280 Any tests from others are welcome Regards, Hervé Le mardi 19 mars 2013 01:49:08 Hervé BOUTEMY a écrit : I just had a look at the failures: they are caused by DefaultMavenReportExecutor using Sonatype Aether ExclusionsDependencyFilter [1] for MavenPluginManager.setupPluginRealm(...) API call [2] which is affected by switching to Eclipse Aether We will need some tweaks in maven-reporting-exec to detect Eclipse Aether, then a new maven-site-plugin version I will create Jira entries tomorrow to track the issue and work on a fix. IMHO, this doesn't require Maven 4.0: 3.1 is really fine for end users Regards, Hervé [1] http://maven.apache.org/shared/maven-reporting- exec/xref/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html #12 8 [2] http://maven.apache.org/shared/maven-reporting- exec/xref/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html #26 7 Le lundi 18 mars 2013 13:29:12 Jason van Zyl a écrit : In the ITs I have changed the ranges to accommodate these ITs not running with Eclipse Aether: MavenITmng3743ForkWithPluginManagementTest: Site plugin MavenITmng3703ExecutionProjectWithRelativePathsTest: Site plugin MavenITmng3684BuildPluginParameterTest: Site plugin MavenITmng3372DirectInvocationOfPluginsTest: dependency:tree used directly MavenITmng5019StringBasedCompLookupFromChildPluginRealmTest: Site plugin So I would consider this fairly major which is why I'm arguing for 4.0.0. These may not be trivial things to fix and we probably can't predict when things like the Site, Dependency, and Shade plugin will be updated. The ITs run with these changes and I will proceed to merge the Eclipse Aether branch into master. On Mar 16, 2013, at 7:27 AM, Jason van Zyl ja...@tesla.io wrote: Hervé, Olivier, There are two failures due to the SLF4J Simple changes made which only affect the embedded mode but it's really nice having those clean because they are so much faster. Hervé, maybe these worked for you locally and you still have some more work to do? This I can take a looked into and I'll ask Ceki for a little help here. The rest of the errors are related to the use of the actual Site and Dependency plugins in the ITs which I don't think is quite right. I have no familiarity with these plugins and I believe you two work on these for the most part. There are direct linkage problems and it's hard for me to tell what it is you're trying to test in the case of the ITs with failures. If you are testing behavior that is general can you please make ITs that don't depend on actual plugins? Or if they are truly to test the site or dependency plugins can you move them to their respective plugins? If you build from the eclipse-aether branch and run the ITs you'll see the errors. I consistently get the following: Tests run: 716, Failures: 2, Errors: 5, Skipped: 0, Time elapsed: 269.409 sec FAILURE! https://gist.github.com/jvanzyl/5176584 Once those are sorted out then we can move on to the Plugin ITs and see what kind of errors/failures we have there but we need to get past the core ITs first. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h
Re: Maven Core IT failures with Eclipse Aether
Cool. On Mar 27, 2013, at 3:10 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: I just fixed http://jira.codehaus.org/browse/MSITE-683 / http://jira.codehaus.org/browse/MSHARED-280 Any tests from others are welcome Regards, Hervé Le mardi 19 mars 2013 01:49:08 Hervé BOUTEMY a écrit : I just had a look at the failures: they are caused by DefaultMavenReportExecutor using Sonatype Aether ExclusionsDependencyFilter [1] for MavenPluginManager.setupPluginRealm(...) API call [2] which is affected by switching to Eclipse Aether We will need some tweaks in maven-reporting-exec to detect Eclipse Aether, then a new maven-site-plugin version I will create Jira entries tomorrow to track the issue and work on a fix. IMHO, this doesn't require Maven 4.0: 3.1 is really fine for end users Regards, Hervé [1] http://maven.apache.org/shared/maven-reporting- exec/xref/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html#12 8 [2] http://maven.apache.org/shared/maven-reporting- exec/xref/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html#26 7 Le lundi 18 mars 2013 13:29:12 Jason van Zyl a écrit : In the ITs I have changed the ranges to accommodate these ITs not running with Eclipse Aether: MavenITmng3743ForkWithPluginManagementTest: Site plugin MavenITmng3703ExecutionProjectWithRelativePathsTest: Site plugin MavenITmng3684BuildPluginParameterTest: Site plugin MavenITmng3372DirectInvocationOfPluginsTest: dependency:tree used directly MavenITmng5019StringBasedCompLookupFromChildPluginRealmTest: Site plugin So I would consider this fairly major which is why I'm arguing for 4.0.0. These may not be trivial things to fix and we probably can't predict when things like the Site, Dependency, and Shade plugin will be updated. The ITs run with these changes and I will proceed to merge the Eclipse Aether branch into master. On Mar 16, 2013, at 7:27 AM, Jason van Zyl ja...@tesla.io wrote: Hervé, Olivier, There are two failures due to the SLF4J Simple changes made which only affect the embedded mode but it's really nice having those clean because they are so much faster. Hervé, maybe these worked for you locally and you still have some more work to do? This I can take a looked into and I'll ask Ceki for a little help here. The rest of the errors are related to the use of the actual Site and Dependency plugins in the ITs which I don't think is quite right. I have no familiarity with these plugins and I believe you two work on these for the most part. There are direct linkage problems and it's hard for me to tell what it is you're trying to test in the case of the ITs with failures. If you are testing behavior that is general can you please make ITs that don't depend on actual plugins? Or if they are truly to test the site or dependency plugins can you move them to their respective plugins? If you build from the eclipse-aether branch and run the ITs you'll see the errors. I consistently get the following: Tests run: 716, Failures: 2, Errors: 5, Skipped: 0, Time elapsed: 269.409 sec FAILURE! https://gist.github.com/jvanzyl/5176584 Once those are sorted out then we can move on to the Plugin ITs and see what kind of errors/failures we have there but we need to get past the core ITs first. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare - 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 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown
Re: Releasing 3.1.0-alpha-1
Nope, I just got off a plane. I'll cut it in the morning. But you can build from master, it will be the same :-) On Mar 24, 2013, at 5:44 PM, Mark Derricutt m...@talios.com wrote: Did this get rolled at all? If so, where can we download it? Mark Hervé BOUTEMY wrote: +1 I didn't have time to fix MSITE-683 but will work on it this WE too: we should have a working m-site-p 3.3-SNAPSHOT at the time Maven 3.1.0-alpha-1 is out Regards, Hervé Le jeudi 21 mars 2013 19:30:20 Jason van Zyl a écrit : If no one objects I'm going to roll a release of 3.1.0-alpha-1 over the weekend. There are plugins that don't work but I think those can be sorted out over a few alphas. Being alpha will make it clear it's not for the faint of heart. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
Releasing 3.1.0-alpha-1
If no one objects I'm going to roll a release of 3.1.0-alpha-1 over the weekend. There are plugins that don't work but I think those can be sorted out over a few alphas. Being alpha will make it clear it's not for the faint of heart. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Re: Contribute the code
We have not actually decided whether we want this behaviour or not. I'll take a look, but we have code to turn on/off that behaviour it's really more a decision about what the proper behaviour is. On Mar 18, 2013, at 1:03 AM, kunal somani kunal.somani2...@gmail.com wrote: Hi, I was trying to implement the below feature in my project. http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges After implementing range feature with Maven 3.0..5 in my project, come to know that there is bug where Maven pick the the latest Snapshot artifact as well even if we don't define the SNAPSHOT in range. Version ranges with non-snapshot bounds can contain snapshot versions bug http://jira.codehaus.org/browse/MNG-3092 I had to implement this feature in my project and for that looked into the Maven code and found after adding few lines of code, we can resolve this bug. I would like to contribute the code in Maven and for that need guidance. Thanks Regards, Kunal Somani (408-767-8685) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl -
Re: maven pull request: Fix call to SimpleLoggerFactory.reset method
No problem, Stuart fixed it up. All good. On Mar 18, 2013, at 12:18 PM, ceki c...@qos.ch wrote: sorry about the unused INSTANCE field in SimpleLoggerFactory which is unnecessarily confusing. Just got rid of it: https://github.com/qos-ch/slf4j/commit/192f47034eda752 On 18.03.2013 19:59, mcculls wrote: GitHub user mcculls opened a pull request: https://github.com/apache/maven/pull/4 Fix call to SimpleLoggerFactory.reset method Use LoggerFactory to make sure we get the right instance to reset, as SimpleLoggerFactory.INSTANCE is not actually used by slf4j-simple's StaticLoggerBinder (instead it has its own SINGLETON field to hold the logger factory). Can now remove temporary reflection workaround. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcculls/maven slf4j-simple-reset Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/4.patch commit bae4b5a5613737c99ae99eca7d5ea7bbed99419a Author: Stuart McCulloch mccu...@gmail.com Date: 2013-03-18T18:57:04Z Fix call to SimpleLoggerFactory.reset method (use LoggerFactory to make sure we get the right instance to reset, as SimpleLoggerFactory.INSTANCE is not actually used by slf4j-simple's StaticLoggerBinder) and remove temporary reflection workaround -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: Maven Core IT failures with Eclipse Aether
In the ITs I have changed the ranges to accommodate these ITs not running with Eclipse Aether: MavenITmng3743ForkWithPluginManagementTest: Site plugin MavenITmng3703ExecutionProjectWithRelativePathsTest: Site plugin MavenITmng3684BuildPluginParameterTest: Site plugin MavenITmng3372DirectInvocationOfPluginsTest: dependency:tree used directly MavenITmng5019StringBasedCompLookupFromChildPluginRealmTest: Site plugin So I would consider this fairly major which is why I'm arguing for 4.0.0. These may not be trivial things to fix and we probably can't predict when things like the Site, Dependency, and Shade plugin will be updated. The ITs run with these changes and I will proceed to merge the Eclipse Aether branch into master. On Mar 16, 2013, at 7:27 AM, Jason van Zyl ja...@tesla.io wrote: Hervé, Olivier, There are two failures due to the SLF4J Simple changes made which only affect the embedded mode but it's really nice having those clean because they are so much faster. Hervé, maybe these worked for you locally and you still have some more work to do? This I can take a looked into and I'll ask Ceki for a little help here. The rest of the errors are related to the use of the actual Site and Dependency plugins in the ITs which I don't think is quite right. I have no familiarity with these plugins and I believe you two work on these for the most part. There are direct linkage problems and it's hard for me to tell what it is you're trying to test in the case of the ITs with failures. If you are testing behavior that is general can you please make ITs that don't depend on actual plugins? Or if they are truly to test the site or dependency plugins can you move them to their respective plugins? If you build from the eclipse-aether branch and run the ITs you'll see the errors. I consistently get the following: Tests run: 716, Failures: 2, Errors: 5, Skipped: 0, Time elapsed: 269.409 sec FAILURE! https://gist.github.com/jvanzyl/5176584 Once those are sorted out then we can move on to the Plugin ITs and see what kind of errors/failures we have there but we need to get past the core ITs first. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare
Re: Maven Core IT failures with Eclipse Aether
On Mar 18, 2013, at 5:49 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: I just had a look at the failures: they are caused by DefaultMavenReportExecutor using Sonatype Aether ExclusionsDependencyFilter [1] for MavenPluginManager.setupPluginRealm(...) API call [2] which is affected by switching to Eclipse Aether We will need some tweaks in maven-reporting-exec to detect Eclipse Aether, then a new maven-site-plugin version I will create Jira entries tomorrow to track the issue and work on a fix. Cool, thanks! IMHO, this doesn't require Maven 4.0: 3.1 is really fine for end users If the plugins we know of are fixed before we release it's probably fine. Regards, Hervé [1] http://maven.apache.org/shared/maven-reporting- exec/xref/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html#128 [2] http://maven.apache.org/shared/maven-reporting- exec/xref/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html#267 Le lundi 18 mars 2013 13:29:12 Jason van Zyl a écrit : In the ITs I have changed the ranges to accommodate these ITs not running with Eclipse Aether: MavenITmng3743ForkWithPluginManagementTest: Site plugin MavenITmng3703ExecutionProjectWithRelativePathsTest: Site plugin MavenITmng3684BuildPluginParameterTest: Site plugin MavenITmng3372DirectInvocationOfPluginsTest: dependency:tree used directly MavenITmng5019StringBasedCompLookupFromChildPluginRealmTest: Site plugin So I would consider this fairly major which is why I'm arguing for 4.0.0. These may not be trivial things to fix and we probably can't predict when things like the Site, Dependency, and Shade plugin will be updated. The ITs run with these changes and I will proceed to merge the Eclipse Aether branch into master. On Mar 16, 2013, at 7:27 AM, Jason van Zyl ja...@tesla.io wrote: Hervé, Olivier, There are two failures due to the SLF4J Simple changes made which only affect the embedded mode but it's really nice having those clean because they are so much faster. Hervé, maybe these worked for you locally and you still have some more work to do? This I can take a looked into and I'll ask Ceki for a little help here. The rest of the errors are related to the use of the actual Site and Dependency plugins in the ITs which I don't think is quite right. I have no familiarity with these plugins and I believe you two work on these for the most part. There are direct linkage problems and it's hard for me to tell what it is you're trying to test in the case of the ITs with failures. If you are testing behavior that is general can you please make ITs that don't depend on actual plugins? Or if they are truly to test the site or dependency plugins can you move them to their respective plugins? If you build from the eclipse-aether branch and run the ITs you'll see the errors. I consistently get the following: Tests run: 716, Failures: 2, Errors: 5, Skipped: 0, Time elapsed: 269.409 sec FAILURE! https://gist.github.com/jvanzyl/5176584 Once those are sorted out then we can move on to the Plugin ITs and see what kind of errors/failures we have there but we need to get past the core ITs first. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon
Re: Logger and Embedded Maven Core ITs
Thanks! We can try it with the helper we currently have.
jvz
On 2013-03-17, at 1:10 PM, ceki c...@qos.ch wrote:
On 17.03.2013 00:47, Jason van Zyl wrote:
If that's the case Ceki might be able to add the clearing of the logger map
to the reset method.
Ceki, would this be hard to change?
I just added a reset method to SimpleLoggerFactory. See
https://github.com/qos-ch/slf4j/commit/6dd3a60ee77a5cd17e for the commit.
Here is sample code for invoking this method in Maven tests:
import org.slf4j.ILoggerFactory;
import org.slf4j.LoggerFactory;
ILoggerFactory iLoggerFactory = LoggerFactory.getILoggerFactory();
if(iLoggerFactory instanceof SimpleLoggerFactory) {
((SimpleLoggerFactory) iLoggerFactory).reset();
}
As the reset() method is package protected, it needs to be invoked from code
in the org.slf4j.impl package. A friend class could expose the reset method
to classes in other packages.
Anyway, let me know how if this works for you.
On Mar 16, 2013, at 4:38 PM, Stuart McCulloch mccu...@gmail.com wrote:
On 16 Mar 2013, at 13:58, Jason van Zyl wrote:
Hervé,
Can you take a look at the logging changes you made to try and use the
SLF4J package private method for resetting the logger? The streams are
being reset correctly but the logging level doesn't appear to be reset
which causes the embedded ITs to fail.
Did some investigating and the issue seems to be that SLF4J Simple uses a
static singleton logger factory which contains a map of cached loggers.
Because embedded test mode uses the same classloader for all the tests (it
only forks once at the start) each test therefore sees the same logger
factory and any previously cached loggers.
This means that although the MavenCLI successfully resets SLF4J to refresh
the log level, the new setting doesn't affect previously cached loggers
(they only pick up the level in their constructor).
This can be shown with the following hack to clear the logger map (not sane
code, just proof-of-concept) which solves the embedded logging IT failures:
diff --git
a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
index 6a7f385..f1af143 100644
---
a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
+++
b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
@@ -58,5 +58,20 @@ public void activate()
// property for root logger level or System.out redirection need to
be taken into account
MavenSlf4jFriend.reset();
MavenSlf4jSimpleFriend.init();
+
+try
+{
+ org.slf4j.ILoggerFactory loggerFactory =
org.slf4j.LoggerFactory.getILoggerFactory();
+ synchronized ( loggerFactory )
+ {
+ java.lang.reflect.Field loggerMap =
loggerFactory.getClass().getDeclaredField( loggerMap );
+ loggerMap.setAccessible( true );
+ ( (java.util.Map) loggerMap.get( loggerFactory )
).clear();
+ }
+}
+catch ( Exception e )
+{
+// ignore for now...
+}
}
}
Thanks,
Jason
--
Jason van Zyl
Founder CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
-
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.
-- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
--
Ceki
-
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: Logger and Embedded Maven Core ITs
Thanks Ceki, the change you made works.
On Mar 17, 2013, at 1:10 PM, ceki c...@qos.ch wrote:
On 17.03.2013 00:47, Jason van Zyl wrote:
If that's the case Ceki might be able to add the clearing of the logger map
to the reset method.
Ceki, would this be hard to change?
I just added a reset method to SimpleLoggerFactory. See
https://github.com/qos-ch/slf4j/commit/6dd3a60ee77a5cd17e for the commit.
Here is sample code for invoking this method in Maven tests:
import org.slf4j.ILoggerFactory;
import org.slf4j.LoggerFactory;
ILoggerFactory iLoggerFactory = LoggerFactory.getILoggerFactory();
if(iLoggerFactory instanceof SimpleLoggerFactory) {
((SimpleLoggerFactory) iLoggerFactory).reset();
}
As the reset() method is package protected, it needs to be invoked from code
in the org.slf4j.impl package. A friend class could expose the reset method
to classes in other packages.
Anyway, let me know how if this works for you.
On Mar 16, 2013, at 4:38 PM, Stuart McCulloch mccu...@gmail.com wrote:
On 16 Mar 2013, at 13:58, Jason van Zyl wrote:
Hervé,
Can you take a look at the logging changes you made to try and use the
SLF4J package private method for resetting the logger? The streams are
being reset correctly but the logging level doesn't appear to be reset
which causes the embedded ITs to fail.
Did some investigating and the issue seems to be that SLF4J Simple uses a
static singleton logger factory which contains a map of cached loggers.
Because embedded test mode uses the same classloader for all the tests (it
only forks once at the start) each test therefore sees the same logger
factory and any previously cached loggers.
This means that although the MavenCLI successfully resets SLF4J to refresh
the log level, the new setting doesn't affect previously cached loggers
(they only pick up the level in their constructor).
This can be shown with the following hack to clear the logger map (not sane
code, just proof-of-concept) which solves the embedded logging IT failures:
diff --git
a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
index 6a7f385..f1af143 100644
---
a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
+++
b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
@@ -58,5 +58,20 @@ public void activate()
// property for root logger level or System.out redirection need to
be taken into account
MavenSlf4jFriend.reset();
MavenSlf4jSimpleFriend.init();
+
+try
+{
+ org.slf4j.ILoggerFactory loggerFactory =
org.slf4j.LoggerFactory.getILoggerFactory();
+ synchronized ( loggerFactory )
+ {
+ java.lang.reflect.Field loggerMap =
loggerFactory.getClass().getDeclaredField( loggerMap );
+ loggerMap.setAccessible( true );
+ ( (java.util.Map) loggerMap.get( loggerFactory )
).clear();
+ }
+}
+catch ( Exception e )
+{
+// ignore for now...
+}
}
}
Thanks,
Jason
--
Jason van Zyl
Founder CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
-
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.
-- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
--
Ceki
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
-
the course of true love never did run smooth ...
-- Shakespeare
Logger and Embedded Maven Core ITs
Hervé, Can you take a look at the logging changes you made to try and use the SLF4J package private method for resetting the logger? The streams are being reset correctly but the logging level doesn't appear to be reset which causes the embedded ITs to fail. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks
Maven Core IT failures with Eclipse Aether
Hervé, Olivier, There are two failures due to the SLF4J Simple changes made which only affect the embedded mode but it's really nice having those clean because they are so much faster. Hervé, maybe these worked for you locally and you still have some more work to do? This I can take a looked into and I'll ask Ceki for a little help here. The rest of the errors are related to the use of the actual Site and Dependency plugins in the ITs which I don't think is quite right. I have no familiarity with these plugins and I believe you two work on these for the most part. There are direct linkage problems and it's hard for me to tell what it is you're trying to test in the case of the ITs with failures. If you are testing behavior that is general can you please make ITs that don't depend on actual plugins? Or if they are truly to test the site or dependency plugins can you move them to their respective plugins? If you build from the eclipse-aether branch and run the ITs you'll see the errors. I consistently get the following: Tests run: 716, Failures: 2, Errors: 5, Skipped: 0, Time elapsed: 269.409 sec FAILURE! https://gist.github.com/jvanzyl/5176584 Once those are sorted out then we can move on to the Plugin ITs and see what kind of errors/failures we have there but we need to get past the core ITs first. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
Re: Logger and Embedded Maven Core ITs
If that's the case Ceki might be able to add the clearing of the logger map to
the reset method.
Ceki, would this be hard to change?
On Mar 16, 2013, at 4:38 PM, Stuart McCulloch mccu...@gmail.com wrote:
On 16 Mar 2013, at 13:58, Jason van Zyl wrote:
Hervé,
Can you take a look at the logging changes you made to try and use the SLF4J
package private method for resetting the logger? The streams are being reset
correctly but the logging level doesn't appear to be reset which causes the
embedded ITs to fail.
Did some investigating and the issue seems to be that SLF4J Simple uses a
static singleton logger factory which contains a map of cached loggers.
Because embedded test mode uses the same classloader for all the tests (it
only forks once at the start) each test therefore sees the same logger
factory and any previously cached loggers.
This means that although the MavenCLI successfully resets SLF4J to refresh
the log level, the new setting doesn't affect previously cached loggers (they
only pick up the level in their constructor).
This can be shown with the following hack to clear the logger map (not sane
code, just proof-of-concept) which solves the embedded logging IT failures:
diff --git
a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
index 6a7f385..f1af143 100644
---
a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
+++
b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
@@ -58,5 +58,20 @@ public void activate()
// property for root logger level or System.out redirection need to
be taken into account
MavenSlf4jFriend.reset();
MavenSlf4jSimpleFriend.init();
+
+try
+{
+ org.slf4j.ILoggerFactory loggerFactory =
org.slf4j.LoggerFactory.getILoggerFactory();
+ synchronized ( loggerFactory )
+ {
+ java.lang.reflect.Field loggerMap =
loggerFactory.getClass().getDeclaredField( loggerMap );
+ loggerMap.setAccessible( true );
+ ( (java.util.Map) loggerMap.get( loggerFactory ) ).clear();
+ }
+}
+catch ( Exception e )
+{
+// ignore for now...
+}
}
}
Thanks,
Jason
--
Jason van Zyl
Founder CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
-
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.
-- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
-
A language that doesn’t affect the way you think about programming is not worth
knowing.
-- Alan Perlis
Re: git commit: Use Eclipse/Sisu 0.0.0.M2 milestone
Why is it an issue? Unless you have a non painful way to setup jobs to test it against the IT matrix how else are we going to vet the changes? On Mar 13, 2013, at 5:32 PM, Olivier Lamy ol...@apache.org wrote: master branch really ? 2013/3/13 jvan...@apache.org: Updated Branches: refs/heads/master 41a292d9a - 2c2bf6e6e Use Eclipse/Sisu 0.0.0.M2 milestone Signed-off-by: Jason van Zyl ja...@tesla.io Project: http://git-wip-us.apache.org/repos/asf/maven/repo Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/2c2bf6e6 Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/2c2bf6e6 Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/2c2bf6e6 Branch: refs/heads/master Commit: 2c2bf6e6e5b06c35a935ca69c5dcb54b381baf46 Parents: 41a292d Author: Stuart McCulloch mccu...@gmail.com Authored: Wed Mar 13 01:11:34 2013 + Committer: Jason van Zyl ja...@tesla.io Committed: Wed Mar 13 08:49:00 2013 -0400 -- apache-maven/pom.xml |4 +- maven-aether-provider/pom.xml |4 +- maven-compat/pom.xml |4 +- maven-core/pom.xml |4 +- .../apache/maven/DefaultArtifactFilterManager.java |1 + .../maven/classrealm/DefaultClassRealmManager.java |5 +- maven-embedder/pom.xml |4 +- maven-model-builder/pom.xml|4 +- maven-plugin-api/pom.xml |4 +- pom.xml| 34 +++ 10 files changed, 42 insertions(+), 26 deletions(-) -- http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/apache-maven/pom.xml -- diff --git a/apache-maven/pom.xml b/apache-maven/pom.xml index ce547e7..9794928 100644 --- a/apache-maven/pom.xml +++ b/apache-maven/pom.xml @@ -48,8 +48,8 @@ artifactIdmaven-compat/artifactId /dependency dependency - groupIdorg.sonatype.sisu/groupId - artifactIdsisu-inject-plexus/artifactId + groupIdorg.eclipse.sisu/groupId + artifactIdorg.eclipse.sisu.plexus/artifactId /dependency !-- CLI -- dependency http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/maven-aether-provider/pom.xml -- diff --git a/maven-aether-provider/pom.xml b/maven-aether-provider/pom.xml index 6c61177..f6985d9 100644 --- a/maven-aether-provider/pom.xml +++ b/maven-aether-provider/pom.xml @@ -76,8 +76,8 @@ under the License. scopetest/scope /dependency dependency - groupIdorg.sonatype.sisu/groupId - artifactIdsisu-inject-plexus/artifactId + groupIdorg.eclipse.sisu/groupId + artifactIdorg.eclipse.sisu.plexus/artifactId /dependency dependency groupIdorg.codehaus.plexus/groupId http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/maven-compat/pom.xml -- diff --git a/maven-compat/pom.xml b/maven-compat/pom.xml index 3bdb1aa..e098fad 100644 --- a/maven-compat/pom.xml +++ b/maven-compat/pom.xml @@ -54,8 +54,8 @@ artifactIdplexus-interpolation/artifactId /dependency dependency - groupIdorg.sonatype.sisu/groupId - artifactIdsisu-inject-plexus/artifactId + groupIdorg.eclipse.sisu/groupId + artifactIdorg.eclipse.sisu.plexus/artifactId /dependency dependency groupIdorg.codehaus.plexus/groupId http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/maven-core/pom.xml -- diff --git a/maven-core/pom.xml b/maven-core/pom.xml index dcc2699..7dbde4a 100644 --- a/maven-core/pom.xml +++ b/maven-core/pom.xml @@ -72,8 +72,8 @@ /dependency !-- Plexus -- dependency - groupIdorg.sonatype.sisu/groupId - artifactIdsisu-inject-plexus/artifactId + groupIdorg.eclipse.sisu/groupId + artifactIdorg.eclipse.sisu.plexus/artifactId /dependency dependency groupIdorg.codehaus.plexus/groupId http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java -- diff --git a/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java b/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java index 9d772f7..7676834 100644 --- a/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java +++ b/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java @@ -58,6 +58,7 @@ public class
Re: git commit: Use Eclipse/Sisu 0.0.0.M2 milestone
Agreed, I don't see any harm on this being on master. Do those two issues below correspond to the two failed ITs here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403286 If so, if you can publish a snapshot I'll update master and then we can let it bake more. On Mar 14, 2013, at 4:15 PM, Stuart McCulloch mccu...@gmail.com wrote: On 14 Mar 2013, at 14:23, Jason van Zyl wrote: Why is it an issue? Unless you have a non painful way to setup jobs to test it against the IT matrix how else are we going to vet the changes? From my perspective it's better in master so people can kick the tyres rather than have it squirrelled away on a branch. FWIW, I've been trying to run it with as many plugin builds / ITs I can find and only found two regressions so far: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403286 https://bugs.eclipse.org/bugs/show_bug.cgi?id=403287 These are already fixed and will be in the next milestone, but I'll wait to see if anyone else spots anything else before staging M3. -- Cheers, Stuart On Mar 13, 2013, at 5:32 PM, Olivier Lamy ol...@apache.org wrote: master branch really ? 2013/3/13 jvan...@apache.org: Updated Branches: refs/heads/master 41a292d9a - 2c2bf6e6e Use Eclipse/Sisu 0.0.0.M2 milestone Signed-off-by: Jason van Zyl ja...@tesla.io Project: http://git-wip-us.apache.org/repos/asf/maven/repo Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/2c2bf6e6 Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/2c2bf6e6 Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/2c2bf6e6 Branch: refs/heads/master Commit: 2c2bf6e6e5b06c35a935ca69c5dcb54b381baf46 Parents: 41a292d Author: Stuart McCulloch mccu...@gmail.com Authored: Wed Mar 13 01:11:34 2013 + Committer: Jason van Zyl ja...@tesla.io Committed: Wed Mar 13 08:49:00 2013 -0400 -- apache-maven/pom.xml |4 +- maven-aether-provider/pom.xml |4 +- maven-compat/pom.xml |4 +- maven-core/pom.xml |4 +- .../apache/maven/DefaultArtifactFilterManager.java |1 + .../maven/classrealm/DefaultClassRealmManager.java |5 +- maven-embedder/pom.xml |4 +- maven-model-builder/pom.xml|4 +- maven-plugin-api/pom.xml |4 +- pom.xml| 34 +++ 10 files changed, 42 insertions(+), 26 deletions(-) -- http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/apache-maven/pom.xml -- diff --git a/apache-maven/pom.xml b/apache-maven/pom.xml index ce547e7..9794928 100644 --- a/apache-maven/pom.xml +++ b/apache-maven/pom.xml @@ -48,8 +48,8 @@ artifactIdmaven-compat/artifactId /dependency dependency - groupIdorg.sonatype.sisu/groupId - artifactIdsisu-inject-plexus/artifactId + groupIdorg.eclipse.sisu/groupId + artifactIdorg.eclipse.sisu.plexus/artifactId /dependency !-- CLI -- dependency http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/maven-aether-provider/pom.xml -- diff --git a/maven-aether-provider/pom.xml b/maven-aether-provider/pom.xml index 6c61177..f6985d9 100644 --- a/maven-aether-provider/pom.xml +++ b/maven-aether-provider/pom.xml @@ -76,8 +76,8 @@ under the License. scopetest/scope /dependency dependency - groupIdorg.sonatype.sisu/groupId - artifactIdsisu-inject-plexus/artifactId + groupIdorg.eclipse.sisu/groupId + artifactIdorg.eclipse.sisu.plexus/artifactId /dependency dependency groupIdorg.codehaus.plexus/groupId http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/maven-compat/pom.xml -- diff --git a/maven-compat/pom.xml b/maven-compat/pom.xml index 3bdb1aa..e098fad 100644 --- a/maven-compat/pom.xml +++ b/maven-compat/pom.xml @@ -54,8 +54,8 @@ artifactIdplexus-interpolation/artifactId /dependency dependency - groupIdorg.sonatype.sisu/groupId - artifactIdsisu-inject-plexus/artifactId + groupIdorg.eclipse.sisu/groupId + artifactIdorg.eclipse.sisu.plexus/artifactId /dependency dependency groupIdorg.codehaus.plexus/groupId http://git-wip-us.apache.org/repos/asf/maven/blob/2c2bf6e6/maven-core/pom.xml -- diff --git a/maven-core/pom.xml b/maven-core/pom.xml index dcc2699..7dbde4a 100644 --- a/maven-core/pom.xml +++ b/maven-core/pom.xml @@ -72,8 +72,8 @@ /dependency !-- Plexus
Re: The next major release of Maven: 4.0.0
I will push the Eclipse Aether work to a branch as there are several ITs that fail that are related to using real plugins in the ITs which are affected by the changes. The dependency plugins and site plugin are the ones that are visible right now. The shade plugin also doesn't work. The ITs should probably not be using real plugins, but we can decide what to do once the branch is in. Hervé, just a note that I quickly tried the dependency tree with the dependency plugin with Eclipse Aether wired in and it still seems to be breaking. I have a build if you want to try it to see the error messages. I assume what's on master is intended to work with both versions of Aether? On Mar 12, 2013, at 11:29 AM, Jason van Zyl ja...@tesla.io wrote: I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only
Re: The next major release of Maven: 4.0.0
On Mar 13, 2013, at 3:30 AM, herve.bout...@free.fr wrote: I'm on vacation, with weak mobile connexion... I'll try m-dependency-tree when back home Id You updates m-dependency-p to latest -tree, the hope was it would work without more efforts It may be something small, but it appears to be an issue at the moment. Envoyé depuis mon mobile - Reply message - De : Jason van Zyl ja...@tesla.io Pour : Maven Developers List dev@maven.apache.org Objet : The next major release of Maven: 4.0.0 Date : mer., mars 13, 2013 08:00 I will push the Eclipse Aether work to a branch as there are several ITs that fail that are related to using real plugins in the ITs which are affected by the changes. The dependency plugins and site plugin are the ones that are visible right now. The shade plugin also doesn't work. The ITs should probably not be using real plugins, but we can decide what to do once the branch is in. Hervé, just a note that I quickly tried the dependency tree with the dependency plugin with Eclipse Aether wired in and it still seems to be breaking. I have a build if you want to try it to see the error messages. I assume what's on master is intended to work with both versions of Aether? On Mar 12, 2013, at 11:29 AM, Jason van Zyl ja...@tesla.io wrote: I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since
Re: The next major release of Maven: 4.0.0
Ansgar, Sadly it was forced upon us it seems. And I don't believe it's a rant to comment on a tool that is hard to use and detracts from productivity especially given how much other work there is to do. It's hard to use tools like this home grown CMS, given the prevalence of great tools like Github pages where you don't even have to think about it. It's amazing that to this day at Apache projects are given little choice over the tools they use. The model at Eclipse is more reasonable where there is infrastructure provided and if you want to leverage that you are free to do so. But you have webspace and want to use something different then you can because ultimately it is the project that is responsible for their website. I think it's great that base services are offered but I don't think it's great to force people to use a tool that no one else in the world uses. I believe it adds zero value to the project, it's only made creating documentation more painful, we've really had tons of problems with syncing and 4/5th of the commit logs are now related to the website. It's unfortunate, much like the situation where we had to wait years to use Git. The infrastructure here is dictated in many cases which is not an optimal model IMO. It would be like me forcing everyone at Apache to build with Maven because that's what I understand. Isn't building your software just as, or more, important than publishing your website? Yet we don't force everyone to build with Maven, we let each project decide based on their preferences and needs. It should be the same for any tool a project decides to use. On Mar 13, 2013, at 8:50 AM, Benson Margulies bimargul...@gmail.com wrote: On Wed, Mar 13, 2013 at 8:47 AM, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Am 13.03.2013 08:38 schrieb herve.bout...@free.fr herve.bout...@free.fr : If you write documentation in Maven core (the components), not in Maven site (the global project), you'll be happy with git like you do with sources I can then take care of svnpubsub publication, or anybody else since I already prepared it (notice ranting against svnpubsub is just a waste of time and karma) What is the value of svnpubsub? Why is it so valuable compared to alternatives? Which alternatives are could you (all) imagine? We don't have an alternative at Apache, so it's not worth chewing over, and this is not the list to re-produce infra@'s reasons I'm clueless. Best Ansgar Envoyé depuis mon mobile - Reply message - De : Jason van Zyl ja...@tesla.io Pour : Maven Developers List dev@maven.apache.org Objet : The next major release of Maven: 4.0.0 Date : mar., mars 12, 2013 16:29 I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote
Re: The next major release of Maven: 4.0.0
So what do you normally use for documentation? Or what would you prefer? Of anything I've seen here the Confluence -- static website looked the most promising. As soon as you saved a page it attempted to make the update to the static website. I don't know if that's still in use but was being used by some projects at some point. On Mar 13, 2013, at 9:37 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: As long as one definitely and 100% stays away from the EU mirror it would seem to work. Running through the mirror is route to disaster and *lots* of wasted time. It would appear that the equivalent git-based solution for site publication is not ready yet. So for this moment someone will have to do the pom changes to make core use svnsubpub. There is little to like about svnsubpub. There was little to like about the previous solutions used for maven sites either. Nor do I like github pages. It all makes me feel a little depressed. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon
Re: The next major release of Maven: 4.0.0
On Mar 13, 2013, at 12:09 PM, Daniel Kulp dk...@apache.org wrote: On Mar 13, 2013, at 9:18 AM, Jason van Zyl ja...@tesla.io wrote: Sadly it was forced upon us it seems. And I don't believe it's a rant to comment on a tool that is hard to use and detracts from productivity especially given how much other work there is to do. It's hard to use tools like this home grown CMS, given the prevalence of great tools like Github pages where you don't even have to think about it. It's amazing that to this day at Apache projects are given little choice over the tools they use. The model at Eclipse is more reasonable where there is infrastructure provided and if you want to leverage that you are free to do so. But you have webspace and want to use something different then you can because ultimately it is the project that is responsible for their website. I think it's great that base services are offered but I don't think it's great to force people to use a tool that no one else in the world uses. I believe it adds zero value to the project, it's only made creating documentation more painful, we've really had tons of problems with syncing and 4/5th of the commit logs are now related to the website. It's unfortunate, much like the situation where we had to wait years to use Git. The infrastructure here is dictated in many cases which is not an optimal model IMO. Umm…. No one in Apache is forcing the CMS on anyone. Just quoting Benson about the choice issue. I don't ever remember any discussion it just seemed to start happening and I remember mention of a CMS. The only requirement is that your website must be stored in subversion someplace. It can be in your projects main svn tree someplace or infra has setup a separate repo that can be used. This really is no different than a directory someplace other than it's backed by an SCM.How the project populates that SVN space is completely up to the project.The CMS is just one way of accomplishing that.Confluence + the exporter tool + buildbot is one.Directly editing .html files with emacs is another. A maven build from buildbot is another.That's completely up to the project to decide. Do you like the Confluence setup? That seems the easiest of solutions where you edit a page and the site is updated eventually. Dan Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: The next major release of Maven: 4.0.0
I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right
Re: The next major release of Maven: 4.0.0
Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right now. Until I actually merged in Eclipse Aether, worked with Benjamin to get all the ITs working, and testing it in the field with 10 or so people I didn't know how much work was involved, or what plugins were affected until I started getting feedback. I am not interested in weaving stuff back and forth between the branches given that all the ITs work with Eclipse Aether merged in and there are a few plugin compatibility issues. I myself cannot imagine trying to keep the two of those branches in sync and I don't see the point because the Eclipse Aether stuff is ready. I have the energy to maintain what I proposed. Even if someone wanted to stand up and maintain the 3.1.x branch I believe it would
Re: The next major release of Maven: 4.0.0
On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right now. Until I actually merged in Eclipse Aether, worked with Benjamin to get all the ITs working, and testing it in the field with 10 or so people I didn't know how much work was involved, or what plugins were affected until I started getting feedback. I am not interested in weaving stuff back and forth between the branches given that all the ITs work with Eclipse Aether merged in and there are a few plugin compatibility issues. I myself cannot imagine trying to keep the two of those branches in sync and I don't see the point because the Eclipse Aether stuff is ready. I have the energy to maintain what I proposed. Even if someone wanted to stand up and maintain the 3.1.x branch I believe it would be a waste of time given what little time the core receives. On Mar 3, 2013, at 5:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 3 March 2013 14:16, Jason van Zyl ja...@tesla.io wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear
Re: The next major release of Maven: 4.0.0
On Mar 3, 2013, at 2:43 PM, Stuart McCulloch mccu...@gmail.com wrote: On 3 Mar 2013, at 14:16, Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. Apart from the org.sonatype.aether - org.eclipse.aether package rename, is there an overview of the client-facing changes? (or perhaps a jdiff report?) There are various other Aether users who'll also need to know how to upgrade, so if this information isn't captured somewhere then it's worth putting it on the Eclipse wiki. Even if it's not possible to bridge between the old and new APIs then this information will help people migrate their existing code. Here you go: http://wiki.eclipse.org/Aether/New_and_Noteworthy Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith
The next major release of Maven: 4.0.0
Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for a couple months. I am not willing to do that again and I honestly doubt anyone but myself or Benjamin can do it in a reasonable amount of time and neither of us want to do it. I don't think it's the end of the world that some plugins that touch Aether will not work without some upgrading. But this is a major API breakage and would deserve a major version change to 4.0.0. I think it needs to be clear that people know what they may potentially be getting themselves into. As such I believe doing a 3.0.5 release, and then a 3.0.6 release (to fix the problem with 3.0.5), a 3.1.0 release for SLF4J and then a 4.0.0 for the Eclipse Aether changes is just going to confuse users greatly. I would prefer to roll in the Eclipse Aether changes and skip the 3.1.0 release and just call it a 4.0.0. I would just like to move on and start developing some features. Trying to create adapter layers and shims is just going to kill us. I think we should just cut bait because there is no desire amongst the people who can make a shim that have time (myself, Benjamin, Igor) and I doubt Hervé or Kristian really have the time to make a complete shim between the versions of Aether. The few points that people are calling into Aether essentially expose the whole API so the shim needed will be enormous given the package name changes and the API changes in Aether. It will be very much like bridge Aether and Maven Artifact APIs and that simply isn't something that would ever have been done without full-time work and I just don't deem that a worthy investment this time. So I propose rolling in the Eclipse Aether changes along with the JSR330 and SLF4J changes and call it 4.0.0. Also I feel that any hiding of the Aether at this point has been a failure. Everyone is jumping around the Maven Artifact APIs because they need to get at more powerful constructs. This hiding of Aether in practice has been futile and no one is every going to make another artifact API in Maven, it's just not going to happen let's face it. Once Eclipse Aether 1.0.0 is released given the Eclipse standards the API will have to remain compatible. I believe all the changes in Aether made in the last 18 months have been worthwhile and there's no point to unwind anything to try and make it work with Sonatype Aether. If we agree on this then I will roll in all the changes, figure out what's wrong with JDK8 and then we release it. The ITs pass and we'll just have to help people adapt their plugins. I talked to Manfred Moser who works on the Android Maven plugin and he doesn't see an issue with updating. We'll just have to update the rest of the plugins or we'll be spending months trying to make a shim or a magic classloader and I'm not sure it's really worth it. I think it's time to move on with our better core and just move on in general. I think people need to digest this and think about it, but I do believe it is the most practical way forward. SLF4J I consider standard, JSR330 is standard and Eclipse Aether post 1.0.0 will adhere to the Eclipse API guidelines and won't be changing so it's best just to build on these technologies of any new versions of Maven and get on with it. Thanks, Jason [1]: http://ci.tesla.io:8080/job/tesla-its/ws/ -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl
Re: The next major release of Maven: 4.0.0
On Mar 3, 2013, at 2:43 PM, Stuart McCulloch mccu...@gmail.com wrote: On 3 Mar 2013, at 14:16, Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. Apart from the org.sonatype.aether - org.eclipse.aether package rename, is there an overview of the client-facing changes? (or perhaps a jdiff report?) There are various other Aether users who'll also need to know how to upgrade, so if this information isn't captured somewhere then it's worth putting it on the Eclipse wiki. Even if it's not possible to bridge between the old and new APIs then this information will help people migrate their existing code. I'll collect them with Benjamin, as I'm not sure how good any standard API diffing tool is going to work with all the package changes. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for a couple months. I am not willing to do that again and I honestly doubt anyone but myself or Benjamin can do it in a reasonable amount of time and neither of us want to do it. I don't think it's the end of the world that some plugins that touch Aether will not work without some upgrading. But this is a major API breakage and would deserve a major version change to 4.0.0. I think it needs to be clear that people know what they may potentially be getting themselves into. As such I believe doing a 3.0.5 release, and then a 3.0.6 release (to fix the problem with 3.0.5), a 3.1.0 release for SLF4J and then a 4.0.0 for the Eclipse Aether changes is just going to confuse users greatly. I would prefer to roll in the Eclipse Aether changes and skip the 3.1.0 release and just call it a 4.0.0. Speaking personally, one concern I have is that there will no doubt be other major features people want to get into 4.0.0 (because of the major version shift) and this could all take a while to plan, stabilize, and release - I don't really want to add anything beyond JSR330, SLF4J and Eclipse Aether. The frequency of change in the core for new features basically ground to a halt. I really don't think this behaviour is going to change radically so I don't see much point in waiting for anything beyond agreement to get a 4.0.0 out the door. meanwhile there could be minor fixes and features stuck in limbo that would benefit people. So while I think it's a good idea to plan for 4.0.0 I'm not sure that should prevent anyone planning a 3.0.x or 3.1.x release. If someone wants to do a 3.1.x that's fine with me but I think having two major branches will just get out of sync. I'm personally in favour of getting a 4.0.0 as fast as possible because the ITs still pass and the few plugins that seem to have issue can be fixed pretty quickly. I just don't think the bandwidth exists to maintain two major branches. Sonatype Aether isn't going to get any love and syncing the branches across package changes probably won't be much fun. We would probably also have to deal with multiple branches across the plugins that will be affected. I proposed what I'm willing to maintain and I think that's ultimately going to be the easiest for us to maintain. PS. I see that Maven trunk currently exports org.sonatype.inject from the core realm - this package is not required for the JSR330 support, only if you want to use some of the additional Sisu behaviour such as eager singletons. If you happen to know which classes or annotations you want to use (or are using) from this package then I can make sure
Re: The next major release of Maven: 4.0.0
On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Re: The next major release of Maven: 4.0.0
Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right now. Until I actually merged in Eclipse Aether, worked with Benjamin to get all the ITs working, and testing it in the field with 10 or so people I didn't know how much work was involved, or what plugins were affected until I started getting feedback. I am not interested in weaving stuff back and forth between the branches given that all the ITs work with Eclipse Aether merged in and there are a few plugin compatibility issues. I myself cannot imagine trying to keep the two of those branches in sync and I don't see the point because the Eclipse Aether stuff is ready. I have the energy to maintain what I proposed. Even if someone wanted to stand up and maintain the 3.1.x branch I believe it would be a waste of time given what little time the core receives. On Mar 3, 2013, at 5:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 3 March 2013 14:16, Jason van Zyl ja...@tesla.io wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for a couple months. I am not willing to do that again and I honestly doubt anyone but myself or Benjamin can do it in a reasonable amount of time and neither of us want to do it. I don't think it's the end of the world that some plugins that touch Aether will not work without some upgrading. But this is a major API breakage and would deserve a major version change to 4.0.0. I think it needs to be clear that people know what they may potentially be getting themselves into. I have not formed an opinion yet, but here are some things that are filtering around in my head w.r.t. this proposal. * When the switch to Aether was originally put forward, the promise was that with Aether at Eclipse there would be a community of people to work on the directed dependency graph problem set... http://lh5.ggpht.com/-MY5CB_MVKCo/UQErH7pws-I/AK8/WT_zSXWy2eQ/graph.png?imgmax=800 I am seriously worried when I see that *I* am the #3 most active committer to Aether at Eclipse, not that I don't believe I could be a contributor to Aether, more that I have on two occasions said OK, Stephen, time to try and get involved with Aether, started trying to get my feet wet with some small tweaks, and then had my spare time stolen again. I.O.W. I have not engaged with Aether to the level I feel
Re: The next major release of Maven: 4.0.0
On Mar 3, 2013, at 5:41 PM, Benson Margulies bimargul...@gmail.com wrote: As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. Any JSR330 discrepancies, SLF4J being used for logging and the Aether changes. 4.0.0 says we did our best to make everything work, but you may have issues. I would rather see us use the version number to communicate with the vast number of people who use Maven. How do you see this as not communicating with everyone. JSR330, SLF4J, and Eclipse Aether are not insignificant. So, I'd switch to Eclipse Aether, including the need to fork a few plugins, as 3.2, and use the number 4.0.0 for a version that has real user-visible impact and value. I see JSR330, SLF4J and Eclipse Aether as valuable. If you presented a long list of wonderful user-visible improvements that would result from the adoption of the new Aether, I'd be happier with your proposal. I have no long use of user-visible improvements because I'm the only one working on the core. There's only so much I'm willing to do and I won't develop any features until I know they will be used. On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: The next major release of Maven: 4.0.0
To me I would like to roll in all of it, I think the bump in major version is appropriate but if we call that 3.1.0 that's fine. It really does work almost the same, there are some plugins that will get need some rework but that's not the end of the world. To me a plugin that works in 3.0.x but not in another later versions is a major breakage. We can define it however we like and call the version whatever we like. I think the major rub is adopting Aether as the Artifact API we're going to expose. My opinion is that it already is. It's out there because people ducked around to get at Aether but we also allowed the RepositorySystem and RepositorySystemSession to be pushed into plugins. Some people moaned but no one stopped it and that is public plugin API as far as I'm concerned. With those two classes exposed you have access to all of Aether and that's been sitting there for 2 years. So the cat is out of the bag and another Artifact API is such a futile value-less effort given Aether's existence. If someone had jumped up and made the bridge a year ago and kept in sync with Eclipse Aether that would be different. But as I noted it's hard, time consuming work. Unless someone commits to do full-time work on this I don't see a bridge, or shim, or new API being made before I'm elderly. If we roll the combo of JSR330, SLF4J and Eclipse Aether things will work for most and we can probably update the rest of the plugins before anyone switches. The code will also be smaller, the dependency plugins using Aether, for example, would probably shed 2/3 of the code. On Mar 3, 2013, at 7:58 PM, Benson Margulies bimargul...@gmail.com wrote: On Sun, Mar 3, 2013 at 4:29 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 5:41 PM, Benson Margulies bimargul...@gmail.com wrote: As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. Any JSR330 discrepancies, SLF4J being used for logging and the Aether changes. 4.0.0 says we did our best to make everything work, but you may have issues. I would rather see us use the version number to communicate with the vast number of people who use Maven. How do you see this as not communicating with everyone. JSR330, SLF4J, and Eclipse Aether are not insignificant. Let's consider three audiences: 1. end users 2. most plugin developers 3. core devs and the devs of the small inventory of very dependency-sensitve plugins I think that all of these things you are citing are good things. But I think that they are mostly in categories 2 and 3, and in the case of Aether, entirely in 3. Thus my view about version numbers. if I'm missing something and picking up a new Aether has benefits for category 1, great. I also want to write now that I'm not on a campaign here. I'd rather see all this happen as '4.0.0' than not happen at all, even if my preference is as expressed. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith
Re: Nexus Staging Maven Plug-in
You probably want to post on the Nexus list as this plugin already exists. On Feb 27, 2013, at 11:57 AM, alex.price alexander.pr...@tnt.com wrote: Hi, I am currently implementing the Nexus Staging Maven Plug-in for many of our releases, which aims to place artifacts in the Nexus Staging area in an automated closed state. I am currently reading the Sonatype article on the plug-in: http://www.sonatype.com/books/nexus-book/reference/staging-sect-deployment.html I have noticed a paragraph in this article which concerns me slighly, and wanted clarification on what the statement means: /The implicit matching relies on the setup of repository targets as well as the correct order of staging profiles and is therefore an error prone approach when many staging profiles are in use. The preferred way to work in this sceneario is to change the profile selection strategy on all staging profiles to explicit only and pass the staging profile id to the Nexus Staging Maven Plugin using the stagingProfileId configuration parameter as documented above./ What number of Staging profiles would this be talking about? Would this definitely be solved if a stagingProfileId parameter was used? What other factors could effect this error prone approach? Thanks, Alex. -- View this message in context: http://maven.40175.n5.nabble.com/Nexus-Staging-Maven-Plug-in-tp5748574.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Releasing 3.1.0
As I posted previously I would like to do the 3.1.0 release but I don't want to do the work of isolating SLF4J until it's shown that it will be a problem. I don't the believe the adoption of 3.1.0 is going to be so quick that we can't create a fix if necessary. I would rather do the release in a lean style and not do work for theoretical problems. In full disclosure I have a release of Tesla I want to make and I already have JSR330, SLF4J/Logback, and Eclipse Aether integrated so I would like to try and help get the JSR330, SLF4J out the door and then get Eclipse Aether integrated. If anyone feels strongly about trying to create the SLF4J isolation and is going to start the work to do it shortly there's no harm in waiting. But I would prefer to start getting the 3.1.0 release out the door, get some feedback and adjust if necessary. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Releasing 3.1.0
Yup, sounds reasonable. On Feb 26, 2013, at 9:14 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I would propose that we give until this time next week for somebody to stand up and state that they feel the isolation is necessary and that they are prepared to do the work to implement the isolation. If there is at least one person committing themselves, then we should discuss the timetable they see for the implementation of isolation, and make a judgement call on the basis of that discussion. If there is nobody feeling strongly about isolation, then at that point I think it is safe to proceed with cutting 3.1.0 (assuming it is ready at that point, or if not ready by then, finish the remaining tasks) Until/unless somebody steps up, I would think it is safe to proceed on the basis that the release will be cut as soon as it is ready and the week has expired. Thoughts? -Stephen On 26 February 2013 14:05, Jason van Zyl ja...@tesla.io wrote: As I posted previously I would like to do the 3.1.0 release but I don't want to do the work of isolating SLF4J until it's shown that it will be a problem. I don't the believe the adoption of 3.1.0 is going to be so quick that we can't create a fix if necessary. I would rather do the release in a lean style and not do work for theoretical problems. In full disclosure I have a release of Tesla I want to make and I already have JSR330, SLF4J/Logback, and Eclipse Aether integrated so I would like to try and help get the JSR330, SLF4J out the door and then get Eclipse Aether integrated. If anyone feels strongly about trying to create the SLF4J isolation and is going to start the work to do it shortly there's no harm in waiting. But I would prefer to start getting the 3.1.0 release out the door, get some feedback and adjust if necessary. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Simplex sigillum veri. (Simplicity is the seal of truth.) Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: [SECURITY] CVE-2013-0253 Apache Maven 3.0.4
When will the CVE entry be updated? http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0253 On Feb 23, 2013, at 9:59 AM, Olivier Lamy ol...@apache.org wrote: VE-2013-0253 Apache Maven Severity: Medium Vendor: The Apache Software Foundation Versions Affected: - Apache Maven 3.0.4 - Apache Maven Wagon 2.1, 2.2, 2.3 Description: Apache Maven 3.0.4 (with Apache Maven Wagon 2.1) has introduced a non-secure SSL mode by default. This mode disables all SSL certificate checking, including: host name verification , date validity, and certificate chain. Not validating the certificate introduces the possibility of a man-in-the-middle attack. All users are recommended to upgrade to Apache Maven 3.0.5 and Apache Maven Wagon 2.4. Credit This issue was identified by Graham Leggett -- The Apache Maven Team Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
Re: Pain with MNG-5181 (_maven.repositories)
On Feb 4, 2013, at 5:55 AM, Nicolas Delsaux nicolas.dels...@gmail.com wrote: Sorry to jump in that conversation like the user I'm, but having seen some messages of both Arnaud and Olivier, I feel I should add my own noise to that discussion. First, a little context info. My company build a complex system, involving flexmojos artifacts and other ones coming from various repositories (maven central, obviously, but also jboss one and now defunct Tinkerpop one). Due to budget restrictions, we couldn't yet install an enterprise proxy. As a consequence, our build directly check artifacts from these remote locations. Unfortunatly, Tinkerpop recently decided their artifacts could now be hosted on maven central. What do you think happened to our build ? Yup. Failure all the way long. And what do you think happen when the repository hosting the various flexmojos artifacts goes down ? Yes, failure also. Failure because of this artifact identification mechanism. If you have no proxy and you are all just pointing at Maven Central then this particular feature will not affect you. Maven, with no mirrorOf configuration in a settings.xml, will follow the repositories listed in the POMs. If you several settings.xml files and switch between them you may potentially have issues. I'd be interested in looking at your configuration as this safeguard only results in failure when an artifacts are not available remotely. Though this is not strictly a repository manager problem. It is a problem when the configuration changes result in pointing Maven at a different set of remote repositories. Where artifacts available via one configuration are not available to another. You can think of Maven behaving as if it were always building from an empty local repository. If this condition cannot be met Maven will fail: Maven does not care what you have locally, it cares that in the context of the current configuration you can resolve a particular artifact. I perfectly understand Jason for a better artifact identification mechanism than the GAV one. BUT, I also consider the current solution to be more a pain than a feature as it is uninformative (I'm sorry if this message may feel aggressive, because it is not my goal). To my mind, Jason solution of also storing an artifact MD5 or any identification mechanism would be a far better solution than hard-storing the repository from which an artifact was received. I have an implementation that does stronger identification checking. But this kicks in after Maven has determined there is something by that GAV available remotely and is not something you'll be affected by because it's not a publicly available feature. Again, the description for this particular feature: --- The feature verifies that the remote repositories configured for the current build can be used to successfully resolve the artifact in question. If you retrieved an artifact in the past from Central and now changed your build to only know about Nexus and it doesn't have any knowledge of that artifact then the build is going to fail. Put differently, if you purged your local repo, your build won't work either. Neglecting offline mode, the goal is to ensure that the resolution works if it could be performed using a clean local repo with the current configuration. Giving confidence that co-workers can reproduce the build and not depend on some artifact magically being pulled down into your local repository in the past which is nowhere to be found in the configured remote repository. --- Make sense? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
Re: Pain with MNG-5181 (_maven.repositories)
Anyone who's interested in MNG-5181, pop into #maven-dev on irc.codehaus.org as I want to clarify what the behavior actually is and answer any questions. It's obvious the motive for the feature isn't understood very clearly which is a documentation/communication problem on the Maven developer's side. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language
Re: Pain with MNG-5181 (_maven.repositories)
On Feb 4, 2013, at 11:43 AM, Nicolas Delsaux nicolas.dels...@gmail.com wrote: On Mon, Feb 4, 2013 at 5:14 PM, Jason van Zyl ja...@tesla.io wrote: If you have no proxy and you are all just pointing at Maven Central then this particular feature will not affect you. Maven, with no mirrorOf configuration in a settings.xml, will follow the repositories listed in the POMs. If you several settings.xml files and switch between them you may potentially have issues. Well ... it appear that, most of the time, I've got issue not by switching my settings.xml, but rather with a remote repository (not maven central) being down. I'd be interested in looking at your configuration as this safeguard only results in failure when an artifacts are not available remotely. I'm using as remote repositories (the ones with troubles) * http://repository.sonatype.org/content/groups/flexgroup/ (use as example artifact com.adobe.flex.framework:flex-framework:3.4.0.14408) * http://tinkerpop.com/maven2 (use as example artifact com.tinkerpop.blueprints:blueprints-core:1.1) Both these repositories may sometimes be down, in which case my build fail, ignoring my locally downloaded artifacts. What I find personnally annoying is the fact that maven successfully downloaded these artifacts before, so why not use locally cached ones ? The underlying assumption is that if they just randomly go away, that it may be permanent and that it won't work for anyone else and considered a failure. The aggregate downtime for RSO (repository.sonatype.org) is very little so that one surprises me. I don't know anything about the older Tinkerpop artifacts but they would probably put the older stuff in Central if we asked. So this is not normal that remote repositories are failing so often that this appears frequently in your builds. But the result internally would be that if it were a developer that were starting from scratch it would fail for them. While repository managers like Nexus OSS are free, I realize it takes time and energy to install one it is a valuable investment. Anyone being onboarded in an environment where connections to repositories are unstable are going to encounter failures even if you disabled this feature. But agreed, in unstable network conditions without a repository manager you're going to have issues. How frequently does this happen? I have an implementation that does stronger identification checking. But this kicks in after Maven has determined there is something by that GAV available remotely and is not something you'll be affected by because it's not a publicly available feature. Again, the description for this particular feature: --- The feature verifies that the remote repositories configured for the current build can be used to successfully resolve the artifact in question. If you retrieved an artifact in the past from Central and now changed your build to only know about Nexus and it doesn't have any knowledge of that artifact then the build is going to fail. Put differently, if you purged your local repo, your build won't work either. Neglecting offline mode, the goal is to ensure that the resolution works if it could be performed using a clean local repo with the current configuration. Giving confidence that co-workers can reproduce the build and not depend on some artifact magically being pulled down into your local repository in the past which is nowhere to be found in the configured remote repository. --- Make sense? In a sense. But if so, why keeping a local repository ? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa -- Nicolas Delsaux - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown
Re: Pain with MNG-5181 (_maven.repositories)
On Feb 3, 2013, at 4:12 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le samedi 2 février 2013 22:39:55 Jason van Zyl a écrit : On Feb 1, 2013, at 3:47 AM, Arnaud Héritier aherit...@gmail.com wrote: My position was to propose the low cost possible solution to have a quick fix and not to wait for months. You realize that disabling this feature allows the potential for a developer to go home, download something in a build with a GAV and go to work where that GAV doesn't correspond to the same thing for whatever reason -- and he will never know or be warned with it disabled. Maybe the JAR is patched and not renamed but does something important for the organization like fix a security problem. This might cause a disparity in how the build behaves in a mild case where he sees something different than the other developers. Worst case is that artifact finds its way into something it's not supposed to and cause a real problem. is it really a part of the feature? I didn't understand that this feature calculated something like a checksum of an artifact and could store the artifact multiple times I thought it was only to avoid for example downloading a dependency from a plugin then use it in component dependency (ie the use case I was expecting): that's what I understanding when reading aether-impl's EnhancedLocalRepositoryManager javadoc and source (in source, since this class is package private, then not published in javadoc) Am I wrong? Do I miss something? h1. Enhanced Remote Repository Support The feature verifies that the remote repositories configured for the current build can be used to successfully resolve the artifact in question. If you retrieved an artifact in the past from Central and now changed your build to only know about Nexus and it doesn't have any knowledge of that artifact then the build is going to fail. Put differently, if you purged your local repo, your build won't work either. Neglecting offline mode, the goal is to ensure that the resolution works if it could be performed using a clean local repo with the current configuration. Giving confidence that co-workers can reproduce the build and not depend on some artifact magically being pulled down into your local repository in the past which is nowhere to be found in the configured remote repository. --- So the upshot is that with this feature off you will happily build all day, but when you commit your CI will fail and anyone you're working with will also get failures because the artifact is not available in your shared setup. I have identity management in my code but the base feature as it exists in Maven asserts the availability of the artifact with the given repository setup. I do not see what value there is in even allowing this feature to be turned off ever. It can only cause inconsistencies. Maven currently does not consider the same GAV from two different sources to be the same and for good reason. If we added the logic which asserted they were, in fact, the same JAR like checking the SHA1 I think that would be perfectly reasonable. Turning it off is just not wise. Turning it off is just a workaround to get the same behaviour than Maven 2, which is not perfect but that everybody understand, to help people while we're working to understand the feature ourselves (yes, ourselves...) and document it sufficiently for end-users What Maven 2.x does is wrong because it can lead to works for me while not working for anyone else. If you move around between work and home a lot use a repository manager locally. I've done that forever and I don't have any issues aside from having to add the odd proxy repository when there is a repository listed in a POM. I don't consider it a problem and it prevents the problem of mismatched identity. This logic should be improved not neutered. +1 but if we can't improve it before the next release, disabling it can be a temporary solution since this feature is really hard for users Why is it a good thing to let people believe they have something that works when it doesn't work for anyone else? This is what you'll get turning this off. I'm looking at the JIRA and Arnaud's explanation with the staging feature and I think it just needs to be configured correctly. I have never had that problem with Nexus as a staging repository is automatically added to the group according to the staging profile and therefore the same URL for the group works consistently. I'm not sure why you would use a profile to get at staging repositories as you should let the repository manager deal with that as Robert points out in the second comment. Arnaud, I'm not sure this feature actually solves your real problem. The failure occurs when the artifact is not available remotely, why would you let someone carry on? Anyone using the same configuration with a clean local repository will have a build that fails. This feature protects
Re: Pain with MNG-5181 (_maven.repositories)
On Feb 3, 2013, at 1:14 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le dimanche 3 février 2013 11:14:03 Jason van Zyl a écrit : I do not see what value there is in even allowing this feature to be turned off ever. It can only cause inconsistencies. please read back the initial user complaining turning this feature off is just getting Maven 2 behaviour, even if it's not the best solution Maven 2 to 3 was the time to change behaviour to a more sane approach. Just because a user wants something that's broken doesn't mean we should put it back. This behaviour disabled overall is a net negative. There is no normal workflow in a users day where disabling this is beneficial. What Maven 2.x does is wrong because it can lead to works for me while not working for anyone else. we're in perfect sync if the error meessage was clear about a solution, and gave a link to a good documentation about the possible causes and real fixes, we could avoid this flag Why is it a good thing to let people believe they have something that works when it doesn't work for anyone else? This is what you'll get turning this off. it is good because Maven 3 behaves like Maven 2 (even if default Maven 3 behaviour is better) I disagree. The benefit of consistent behaviour across versions is dwarfed by the greater confusion caused by a build working in one place and not another. The artifact they require is not remotely accessible, I don't see under any condition this should not fail. I agree a full description of the feature can pop up to tell the user why. I honestly still don't understand the issue Arnaud is having. I'm looking at the JIRA and Arnaud's explanation with the staging feature and I think it just needs to be configured correctly. I have never had that problem with Nexus as a staging repository is automatically added to the group according to the staging profile and therefore the same URL for the group works consistently. I'm not sure why you would use a profile to get at staging repositories as you should let the repository manager deal with that as Robert points out in the second comment. Arnaud, I'm not sure this feature actually solves your real problem. we all know this feature does not solve the real problem: yes, it's only a workaround I honestly don't think it's a problem. It stops someone from being able build when the artifact is not available remotely. For someone who only ever uses Central and no mirrors this is never going to be a problem. For people who are moving in and out of organizations where they are doing work, the build should fail if no one else in the organization can get to the artifact. I just do not see how, in any way, it makes sense to make it possible for an individual to have a different behaviour then everyone else in an organization. We do so much to ensure this and this change in behaviour is a step forward. For the case where someone is trying to build an offline portable repository, well this is just not what Maven does and optimizing for that use case is not important IMO. I can think of a number of ways to create a portable repository of artifacts without requiring the disablement of consistency. And I'm frankly tired of slapdash changes like this being made in the core without any discussion or review. which change are you talking about? enhanced local repository without really understanding or documentation, or the addition of -slrm option as a reasonable fix for MNG-5181, ie add an option to disable the enhanced local repository manager? Benjamin's changes are never slapdash, I'm referring to Olivier's changes. ask users if this feature is slapdash, and IMHO they will more likely say finally. Of course, if we had a better alternative, it would be even better I doubt it. These will be users who don't know what they are doing. Just because a user asks for something doesn't mean you should give it to them. Especially if you don't understand what the feature is intended to do. That there is no documentation is no excuse. Read the code or ask someone. I think Arnaud's case probably can be solved with a bit of re-configuration in Nexus. Most of the users complaining either don't care about organizational consistency and are just building for themselves, or are trying to build offline repositories which is not Maven's primary concern. and the fact is that current error message doesn't help them understand what they are doing wrong, then help them fix it So I would agree that putting the feature explanation there would have been wiser than disabling the feature. Ignoring the explanation of the features benefit and potentially causing a number of more harmful situations isn't the right way to do it. I don't see why you would ever disable this. It covers up other problems you have and just creates more issues. no, it does not create more issues than Maven 2 So why is that good? I agree
Re: Pain with MNG-5181 (_maven.repositories)
On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS m...@batmat.net wrote: +1. Though the feature seems interesting, it should have had its own advertisement while being introduced. Even after re-reading https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository I'm still unsure about where/when it would bite me. Does this make sense to you? --- h1. Enhanced Remote Repository Support The feature verifies that the remote repositories configured for the current build can be used to successfully resolve the artifact in question. If you retrieved an artifact in the past from Central and now changed your build to only know about Nexus and it doesn't have any knowledge of that artifact then the build is going to fail. Put differently, if you purged your local repo, your build won't work either. Neglecting offline mode, the goal is to ensure that the resolution works if it could be performed using a clean local repo with the current configuration. Giving confidence that co-workers can reproduce the build and not depend on some artifact magically being pulled down into your local repository in the past which is nowhere to be found in the configured remote repository. --- And would you want that off by default? As I know and like Maven quite well, if I was bitten by that, I might do some reseach and find jiras etc. Others might just struggle to make it work and grow the maven bashing group as Jeff said. 2013/2/1 Jeff MAURY jeffma...@jeffmaury.com +1 on Arnaud's comments. The main problem with this feature is that it is not documented thus I can't explain the real reason why Maven download several times released artifacts and this causes members of the Maven bashing group to grow Jeff On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier aherit...@gmail.com wrote: My position was to propose the low cost possible solution to have a quick fix and not to wait for months. If it could be fixed/configurable in aether it may be the solution to follow but I'm not sure about the status of this 3rd party project (eclipse migration ...) on which we don't have the hand. Seriously I helped and lost MANY hours with this problem because it is hard to diagnose. I'm sure that many people abandoned to try to understand and just dropped their local repo or decided to downgraded to m2 (or to switch to another tool). I think we can have a lot of similar feedbacks. The worst thing is to have another thing that users don't understand (lake of documentation ? communication ?) The side effect is that changing a repository id (or mirror id) makes maven to re-download all the earth (while we are claiming from the beginning that Maven won't never download twice a release). And when the remote artifact just disappeared it is just a nightmare due to the lake of correct logs and this case is easy to have. For example in my company I have a profile to let people DL artifacts from staging repositories (thus these are releases). It happened that they activated it once to test a build and then they rebuild the project without the profile (thinking the artifact is in the local repo) and it fails ... Sincerely I think I had my worst headaches with maven due to this bug On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl ja...@tesla.io wrote: On Jan 31, 2013, at 7:13 PM, Arnaud Héritier aherit...@gmail.com wrote: Hi Olivier, Thx a lot for the fix. It will help a lot the community. But from my point of view it's perhaps not yet enough. We should : 1/ change the default behavior to deactivate this control which is difficult to understand I disagree. We may want to change it slightly but it's only a problem for people who flip between Maven a repository manager and without but it's to ensure the identity of a component. I haven't seen a huge number of complaints. I do not want to turn this off. Improve it, sure, but turning it off by default I believe is not the right thing to do. 2/ change the error message when this control is activated to clearly explain that the problem comes from the unavailability of the artifact on its original remote repo. For me 1/ is mandatory and 2/ a nice to have WDYT ? On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy ol...@apache.org wrote: I have pushed a fix for that. Now you can desactivate the enhanced local repository using: * new cli option: -slrm,--simple-local-repository-manager * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true will be available for testing here https://builds.apache.org/job/maven-3.x/ with build #368 2013/1/31 Jörg Hohwiller jo...@j-hohwiller.de: Hi Arnaud, +1 to consider the current behavior as a bug. We should be able to deactivate it easily (and perhaps to have it off by default to activate it only on CI servers) :) and we should take care to have a real error message explaining
Re: Pain with MNG-5181 (_maven.repositories)
If this is on one machine where you are not changing configurations or locations then something else is wrong as this does not happen for a machine that stays in the same place using the same settings.xml. Do you use a mirrorOf in your settings.xml that points to a group repository? Can you share your configuration? When you encounter this problem next, move your whole local repository out of the way (or use -Dmaven.repo.local=/tmp/repo) and you find that the build will fail. When this error occurs it means that the artifacts you're asking for are not available in any configured repository. You erase _maven.repositories file, and Maven does not verify that artifact's existence in the remote repository and let's you use the artifact you acquired locally by some other means. This generally happens as a result of switching between configurations which changes the id/url of the repository you are using. You do a build against id=repo1(URL1) and get some artifacts and those are recorded in the _maven.repositories files, and then you switch configurations and use id=repo2(URL2) and that repository doesn't have the artifacts you acquired from id=repo1(URL1). The problem encountered for people flipping between using Central directly and using a mirrorOf setting with a repository manager is as follows: If you have no mirrorOf setting and you have POMs that contain repository entries Maven will follow the repositories in the POMs and acquire any dependencies from those repositories listed in the POMs. Now when you flip to using a mirrorOf setting with a repository manager all those requests will be routed through that single URL. If you have not setup the proxies in your repository manager that correspond to the repositories in the POMs the build will fail because those artifacts are not accessible to the repository manager. On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi guys, Not sure it is linked or not (i read the thread lately) but at work we use a proxy and not at home and i often have to remove _maven.repo files (both ways) to make my build work again...that's an everyday pain. Le 3 févr. 2013 21:41, Jason van Zyl ja...@tesla.io a écrit : On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS m...@batmat.net wrote: +1. Though the feature seems interesting, it should have had its own advertisement while being introduced. Even after re-reading https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository I'm still unsure about where/when it would bite me. Does this make sense to you? --- h1. Enhanced Remote Repository Support The feature verifies that the remote repositories configured for the current build can be used to successfully resolve the artifact in question. If you retrieved an artifact in the past from Central and now changed your build to only know about Nexus and it doesn't have any knowledge of that artifact then the build is going to fail. Put differently, if you purged your local repo, your build won't work either. Neglecting offline mode, the goal is to ensure that the resolution works if it could be performed using a clean local repo with the current configuration. Giving confidence that co-workers can reproduce the build and not depend on some artifact magically being pulled down into your local repository in the past which is nowhere to be found in the configured remote repository. --- And would you want that off by default? As I know and like Maven quite well, if I was bitten by that, I might do some reseach and find jiras etc. Others might just struggle to make it work and grow the maven bashing group as Jeff said. 2013/2/1 Jeff MAURY jeffma...@jeffmaury.com +1 on Arnaud's comments. The main problem with this feature is that it is not documented thus I can't explain the real reason why Maven download several times released artifacts and this causes members of the Maven bashing group to grow Jeff On Fri, Feb 1, 2013 at 9:47 AM, Arnaud Héritier aherit...@gmail.com wrote: My position was to propose the low cost possible solution to have a quick fix and not to wait for months. If it could be fixed/configurable in aether it may be the solution to follow but I'm not sure about the status of this 3rd party project (eclipse migration ...) on which we don't have the hand. Seriously I helped and lost MANY hours with this problem because it is hard to diagnose. I'm sure that many people abandoned to try to understand and just dropped their local repo or decided to downgraded to m2 (or to switch to another tool). I think we can have a lot of similar feedbacks. The worst thing is to have another thing that users don't understand (lake of documentation ? communication ?) The side effect is that changing a repository id (or mirror id) makes maven to re-download all the earth (while we
Re: Pain with MNG-5181 (_maven.repositories)
Can you send me the configurations? If the artifacts are accessible and it fails then that's a bug. But I am willing to bet one configuration yields a different set of URLs to which particular artifacts are not accessible. If I can reproduce it then this will help contribute to an error message that's more useful. On Feb 3, 2013, at 4:35 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: I switch my settings and the only differences are: 1) some server config (i guess that's not important) 2) (more important) proxies (host/port) i don't use mirrorOf. PS: the issue can happen with tomee trunk so repos are always available since the internet is available. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/2/3 Jason van Zyl ja...@tesla.io If this is on one machine where you are not changing configurations or locations then something else is wrong as this does not happen for a machine that stays in the same place using the same settings.xml. Do you use a mirrorOf in your settings.xml that points to a group repository? Can you share your configuration? When you encounter this problem next, move your whole local repository out of the way (or use -Dmaven.repo.local=/tmp/repo) and you find that the build will fail. When this error occurs it means that the artifacts you're asking for are not available in any configured repository. You erase _maven.repositories file, and Maven does not verify that artifact's existence in the remote repository and let's you use the artifact you acquired locally by some other means. This generally happens as a result of switching between configurations which changes the id/url of the repository you are using. You do a build against id=repo1(URL1) and get some artifacts and those are recorded in the _maven.repositories files, and then you switch configurations and use id=repo2(URL2) and that repository doesn't have the artifacts you acquired from id=repo1(URL1). The problem encountered for people flipping between using Central directly and using a mirrorOf setting with a repository manager is as follows: If you have no mirrorOf setting and you have POMs that contain repository entries Maven will follow the repositories in the POMs and acquire any dependencies from those repositories listed in the POMs. Now when you flip to using a mirrorOf setting with a repository manager all those requests will be routed through that single URL. If you have not setup the proxies in your repository manager that correspond to the repositories in the POMs the build will fail because those artifacts are not accessible to the repository manager. On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi guys, Not sure it is linked or not (i read the thread lately) but at work we use a proxy and not at home and i often have to remove _maven.repo files (both ways) to make my build work again...that's an everyday pain. Le 3 févr. 2013 21:41, Jason van Zyl ja...@tesla.io a écrit : On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS m...@batmat.net wrote: +1. Though the feature seems interesting, it should have had its own advertisement while being introduced. Even after re-reading https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository I'm still unsure about where/when it would bite me. Does this make sense to you? --- h1. Enhanced Remote Repository Support The feature verifies that the remote repositories configured for the current build can be used to successfully resolve the artifact in question. If you retrieved an artifact in the past from Central and now changed your build to only know about Nexus and it doesn't have any knowledge of that artifact then the build is going to fail. Put differently, if you purged your local repo, your build won't work either. Neglecting offline mode, the goal is to ensure that the resolution works if it could be performed using a clean local repo with the current configuration. Giving confidence that co-workers can reproduce the build and not depend on some artifact magically being pulled down into your local repository in the past which is nowhere to be found in the configured remote repository. --- And would you want that off by default? As I know and like Maven quite well, if I was bitten by that, I might do some reseach and find jiras etc. Others might just struggle to make it work and grow the maven bashing group as Jeff said. 2013/2/1 Jeff MAURY jeffma...@jeffmaury.com +1 on Arnaud's comments. The main problem with this feature is that it is not documented thus I can't explain the real reason why Maven download several times released
Re: Pain with MNG-5181 (_maven.repositories)
Would still be useful if you removed your passwords and sent me both configurations, if this is happening to you with this configuration it's probably happening to others. If I can give it a quick look I can probably tell you why the error is happening or determine if it is, in fact, a bug. On Feb 3, 2013, at 5:04 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: well nothing special in it (host/port/protocol proxies + username/password servers). however i build company projects using enterprise project having as dependencies tomee, could it generate it? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/2/3 Jason van Zyl ja...@tesla.io Can you send me the configurations? If the artifacts are accessible and it fails then that's a bug. But I am willing to bet one configuration yields a different set of URLs to which particular artifacts are not accessible. If I can reproduce it then this will help contribute to an error message that's more useful. On Feb 3, 2013, at 4:35 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: I switch my settings and the only differences are: 1) some server config (i guess that's not important) 2) (more important) proxies (host/port) i don't use mirrorOf. PS: the issue can happen with tomee trunk so repos are always available since the internet is available. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/2/3 Jason van Zyl ja...@tesla.io If this is on one machine where you are not changing configurations or locations then something else is wrong as this does not happen for a machine that stays in the same place using the same settings.xml. Do you use a mirrorOf in your settings.xml that points to a group repository? Can you share your configuration? When you encounter this problem next, move your whole local repository out of the way (or use -Dmaven.repo.local=/tmp/repo) and you find that the build will fail. When this error occurs it means that the artifacts you're asking for are not available in any configured repository. You erase _maven.repositories file, and Maven does not verify that artifact's existence in the remote repository and let's you use the artifact you acquired locally by some other means. This generally happens as a result of switching between configurations which changes the id/url of the repository you are using. You do a build against id=repo1(URL1) and get some artifacts and those are recorded in the _maven.repositories files, and then you switch configurations and use id=repo2(URL2) and that repository doesn't have the artifacts you acquired from id=repo1(URL1). The problem encountered for people flipping between using Central directly and using a mirrorOf setting with a repository manager is as follows: If you have no mirrorOf setting and you have POMs that contain repository entries Maven will follow the repositories in the POMs and acquire any dependencies from those repositories listed in the POMs. Now when you flip to using a mirrorOf setting with a repository manager all those requests will be routed through that single URL. If you have not setup the proxies in your repository manager that correspond to the repositories in the POMs the build will fail because those artifacts are not accessible to the repository manager. On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi guys, Not sure it is linked or not (i read the thread lately) but at work we use a proxy and not at home and i often have to remove _maven.repo files (both ways) to make my build work again...that's an everyday pain. Le 3 févr. 2013 21:41, Jason van Zyl ja...@tesla.io a écrit : On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS m...@batmat.net wrote: +1. Though the feature seems interesting, it should have had its own advertisement while being introduced. Even after re-reading https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository I'm still unsure about where/when it would bite me. Does this make sense to you? --- h1. Enhanced Remote Repository Support The feature verifies that the remote repositories configured for the current build can be used to successfully resolve the artifact in question. If you retrieved an artifact in the past from Central and now changed your build to only know about Nexus and it doesn't have any knowledge of that artifact then the build is going to fail. Put differently, if you purged your local repo
Re: Pain with MNG-5181 (_maven.repositories)
Cool, much appreciated. I'll take a look. On Feb 3, 2013, at 5:15 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: here it is https://gist.github.com/c07256a99d3b2af322eb @home i remove the settings.xml in general *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/2/3 Jason van Zyl ja...@tesla.io Would still be useful if you removed your passwords and sent me both configurations, if this is happening to you with this configuration it's probably happening to others. If I can give it a quick look I can probably tell you why the error is happening or determine if it is, in fact, a bug. On Feb 3, 2013, at 5:04 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: well nothing special in it (host/port/protocol proxies + username/password servers). however i build company projects using enterprise project having as dependencies tomee, could it generate it? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/2/3 Jason van Zyl ja...@tesla.io Can you send me the configurations? If the artifacts are accessible and it fails then that's a bug. But I am willing to bet one configuration yields a different set of URLs to which particular artifacts are not accessible. If I can reproduce it then this will help contribute to an error message that's more useful. On Feb 3, 2013, at 4:35 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: I switch my settings and the only differences are: 1) some server config (i guess that's not important) 2) (more important) proxies (host/port) i don't use mirrorOf. PS: the issue can happen with tomee trunk so repos are always available since the internet is available. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/2/3 Jason van Zyl ja...@tesla.io If this is on one machine where you are not changing configurations or locations then something else is wrong as this does not happen for a machine that stays in the same place using the same settings.xml. Do you use a mirrorOf in your settings.xml that points to a group repository? Can you share your configuration? When you encounter this problem next, move your whole local repository out of the way (or use -Dmaven.repo.local=/tmp/repo) and you find that the build will fail. When this error occurs it means that the artifacts you're asking for are not available in any configured repository. You erase _maven.repositories file, and Maven does not verify that artifact's existence in the remote repository and let's you use the artifact you acquired locally by some other means. This generally happens as a result of switching between configurations which changes the id/url of the repository you are using. You do a build against id=repo1(URL1) and get some artifacts and those are recorded in the _maven.repositories files, and then you switch configurations and use id=repo2(URL2) and that repository doesn't have the artifacts you acquired from id=repo1(URL1). The problem encountered for people flipping between using Central directly and using a mirrorOf setting with a repository manager is as follows: If you have no mirrorOf setting and you have POMs that contain repository entries Maven will follow the repositories in the POMs and acquire any dependencies from those repositories listed in the POMs. Now when you flip to using a mirrorOf setting with a repository manager all those requests will be routed through that single URL. If you have not setup the proxies in your repository manager that correspond to the repositories in the POMs the build will fail because those artifacts are not accessible to the repository manager. On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi guys, Not sure it is linked or not (i read the thread lately) but at work we use a proxy and not at home and i often have to remove _maven.repo files (both ways) to make my build work again...that's an everyday pain. Le 3 févr. 2013 21:41, Jason van Zyl ja...@tesla.io a écrit : On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS m...@batmat.net wrote: +1. Though the feature seems interesting, it should have had its own advertisement while being introduced. Even after re-reading https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes
Re: Pain with MNG-5181 (_maven.repositories)
Just so I'm clear do you switch between this settings.xml and no settings.xml, or you just use this settings.xml all the time? On Feb 3, 2013, at 5:15 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: here it is https://gist.github.com/c07256a99d3b2af322eb @home i remove the settings.xml in general *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/2/3 Jason van Zyl ja...@tesla.io Would still be useful if you removed your passwords and sent me both configurations, if this is happening to you with this configuration it's probably happening to others. If I can give it a quick look I can probably tell you why the error is happening or determine if it is, in fact, a bug. On Feb 3, 2013, at 5:04 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: well nothing special in it (host/port/protocol proxies + username/password servers). however i build company projects using enterprise project having as dependencies tomee, could it generate it? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/2/3 Jason van Zyl ja...@tesla.io Can you send me the configurations? If the artifacts are accessible and it fails then that's a bug. But I am willing to bet one configuration yields a different set of URLs to which particular artifacts are not accessible. If I can reproduce it then this will help contribute to an error message that's more useful. On Feb 3, 2013, at 4:35 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: I switch my settings and the only differences are: 1) some server config (i guess that's not important) 2) (more important) proxies (host/port) i don't use mirrorOf. PS: the issue can happen with tomee trunk so repos are always available since the internet is available. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/2/3 Jason van Zyl ja...@tesla.io If this is on one machine where you are not changing configurations or locations then something else is wrong as this does not happen for a machine that stays in the same place using the same settings.xml. Do you use a mirrorOf in your settings.xml that points to a group repository? Can you share your configuration? When you encounter this problem next, move your whole local repository out of the way (or use -Dmaven.repo.local=/tmp/repo) and you find that the build will fail. When this error occurs it means that the artifacts you're asking for are not available in any configured repository. You erase _maven.repositories file, and Maven does not verify that artifact's existence in the remote repository and let's you use the artifact you acquired locally by some other means. This generally happens as a result of switching between configurations which changes the id/url of the repository you are using. You do a build against id=repo1(URL1) and get some artifacts and those are recorded in the _maven.repositories files, and then you switch configurations and use id=repo2(URL2) and that repository doesn't have the artifacts you acquired from id=repo1(URL1). The problem encountered for people flipping between using Central directly and using a mirrorOf setting with a repository manager is as follows: If you have no mirrorOf setting and you have POMs that contain repository entries Maven will follow the repositories in the POMs and acquire any dependencies from those repositories listed in the POMs. Now when you flip to using a mirrorOf setting with a repository manager all those requests will be routed through that single URL. If you have not setup the proxies in your repository manager that correspond to the repositories in the POMs the build will fail because those artifacts are not accessible to the repository manager. On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi guys, Not sure it is linked or not (i read the thread lately) but at work we use a proxy and not at home and i often have to remove _maven.repo files (both ways) to make my build work again...that's an everyday pain. Le 3 févr. 2013 21:41, Jason van Zyl ja...@tesla.io a écrit : On Feb 3, 2013, at 3:26 PM, Baptiste MATHUS m...@batmat.net wrote: +1. Though the feature seems interesting, it should have had its own advertisement while being introduced. Even after re-reading https
Re: Pain with MNG-5181 (_maven.repositories)
You mind if I ping you off line? I have a couple things I'd like to test. On Feb 3, 2013, at 6:21 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Usually i comment all in this one Le 4 févr. 2013 00:20, Jason van Zyl ja...@tesla.io a écrit : Just so I'm clear do you switch between this settings.xml and no settings.xml, or you just use this settings.xml all the time? On Feb 3, 2013, at 5:15 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: here it is https://gist.github.com/c07256a99d3b2af322eb @home i remove the settings.xml in general *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/2/3 Jason van Zyl ja...@tesla.io Would still be useful if you removed your passwords and sent me both configurations, if this is happening to you with this configuration it's probably happening to others. If I can give it a quick look I can probably tell you why the error is happening or determine if it is, in fact, a bug. On Feb 3, 2013, at 5:04 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: well nothing special in it (host/port/protocol proxies + username/password servers). however i build company projects using enterprise project having as dependencies tomee, could it generate it? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/2/3 Jason van Zyl ja...@tesla.io Can you send me the configurations? If the artifacts are accessible and it fails then that's a bug. But I am willing to bet one configuration yields a different set of URLs to which particular artifacts are not accessible. If I can reproduce it then this will help contribute to an error message that's more useful. On Feb 3, 2013, at 4:35 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: I switch my settings and the only differences are: 1) some server config (i guess that's not important) 2) (more important) proxies (host/port) i don't use mirrorOf. PS: the issue can happen with tomee trunk so repos are always available since the internet is available. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/2/3 Jason van Zyl ja...@tesla.io If this is on one machine where you are not changing configurations or locations then something else is wrong as this does not happen for a machine that stays in the same place using the same settings.xml. Do you use a mirrorOf in your settings.xml that points to a group repository? Can you share your configuration? When you encounter this problem next, move your whole local repository out of the way (or use -Dmaven.repo.local=/tmp/repo) and you find that the build will fail. When this error occurs it means that the artifacts you're asking for are not available in any configured repository. You erase _maven.repositories file, and Maven does not verify that artifact's existence in the remote repository and let's you use the artifact you acquired locally by some other means. This generally happens as a result of switching between configurations which changes the id/url of the repository you are using. You do a build against id=repo1(URL1) and get some artifacts and those are recorded in the _maven.repositories files, and then you switch configurations and use id=repo2(URL2) and that repository doesn't have the artifacts you acquired from id=repo1(URL1). The problem encountered for people flipping between using Central directly and using a mirrorOf setting with a repository manager is as follows: If you have no mirrorOf setting and you have POMs that contain repository entries Maven will follow the repositories in the POMs and acquire any dependencies from those repositories listed in the POMs. Now when you flip to using a mirrorOf setting with a repository manager all those requests will be routed through that single URL. If you have not setup the proxies in your repository manager that correspond to the repositories in the POMs the build will fail because those artifacts are not accessible to the repository manager. On Feb 3, 2013, at 3:46 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi guys, Not sure it is linked or not (i read the thread lately) but at work we use a proxy and not at home and i often have to remove _maven.repo files (both ways) to make my build work again...that's an everyday pain. Le 3 févr. 2013 21
Re: Pain with MNG-5181 (_maven.repositories)
Cool, fair enough. On Feb 3, 2013, at 7:31 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: a question of compromise: I just added a warning message to let users know they should avoid the option Regards, Hervé Le dimanche 3 février 2013 13:37:13 Jason van Zyl a écrit : On Feb 3, 2013, at 1:14 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le dimanche 3 février 2013 11:14:03 Jason van Zyl a écrit : I do not see what value there is in even allowing this feature to be turned off ever. It can only cause inconsistencies. please read back the initial user complaining turning this feature off is just getting Maven 2 behaviour, even if it's not the best solution Maven 2 to 3 was the time to change behaviour to a more sane approach. Just because a user wants something that's broken doesn't mean we should put it back. This behaviour disabled overall is a net negative. There is no normal workflow in a users day where disabling this is beneficial. What Maven 2.x does is wrong because it can lead to works for me while not working for anyone else. we're in perfect sync if the error meessage was clear about a solution, and gave a link to a good documentation about the possible causes and real fixes, we could avoid this flag Why is it a good thing to let people believe they have something that works when it doesn't work for anyone else? This is what you'll get turning this off. it is good because Maven 3 behaves like Maven 2 (even if default Maven 3 behaviour is better) I disagree. The benefit of consistent behaviour across versions is dwarfed by the greater confusion caused by a build working in one place and not another. The artifact they require is not remotely accessible, I don't see under any condition this should not fail. I agree a full description of the feature can pop up to tell the user why. I honestly still don't understand the issue Arnaud is having. I'm looking at the JIRA and Arnaud's explanation with the staging feature and I think it just needs to be configured correctly. I have never had that problem with Nexus as a staging repository is automatically added to the group according to the staging profile and therefore the same URL for the group works consistently. I'm not sure why you would use a profile to get at staging repositories as you should let the repository manager deal with that as Robert points out in the second comment. Arnaud, I'm not sure this feature actually solves your real problem. we all know this feature does not solve the real problem: yes, it's only a workaround I honestly don't think it's a problem. It stops someone from being able build when the artifact is not available remotely. For someone who only ever uses Central and no mirrors this is never going to be a problem. For people who are moving in and out of organizations where they are doing work, the build should fail if no one else in the organization can get to the artifact. I just do not see how, in any way, it makes sense to make it possible for an individual to have a different behaviour then everyone else in an organization. We do so much to ensure this and this change in behaviour is a step forward. For the case where someone is trying to build an offline portable repository, well this is just not what Maven does and optimizing for that use case is not important IMO. I can think of a number of ways to create a portable repository of artifacts without requiring the disablement of consistency. And I'm frankly tired of slapdash changes like this being made in the core without any discussion or review. which change are you talking about? enhanced local repository without really understanding or documentation, or the addition of -slrm option as a reasonable fix for MNG-5181, ie add an option to disable the enhanced local repository manager? Benjamin's changes are never slapdash, I'm referring to Olivier's changes. ask users if this feature is slapdash, and IMHO they will more likely say finally. Of course, if we had a better alternative, it would be even better I doubt it. These will be users who don't know what they are doing. Just because a user asks for something doesn't mean you should give it to them. Especially if you don't understand what the feature is intended to do. That there is no documentation is no excuse. Read the code or ask someone. I think Arnaud's case probably can be solved with a bit of re-configuration in Nexus. Most of the users complaining either don't care about organizational consistency and are just building for themselves, or are trying to build offline repositories which is not Maven's primary concern. and the fact is that current error message doesn't help them understand what they are doing wrong, then help them fix it So I would agree that putting the feature explanation there would have been wiser than disabling the feature. Ignoring the explanation
Re: Pain with MNG-5181 (_maven.repositories)
On Feb 1, 2013, at 3:47 AM, Arnaud Héritier aherit...@gmail.com wrote: My position was to propose the low cost possible solution to have a quick fix and not to wait for months. You realize that disabling this feature allows the potential for a developer to go home, download something in a build with a GAV and go to work where that GAV doesn't correspond to the same thing for whatever reason -- and he will never know or be warned with it disabled. Maybe the JAR is patched and not renamed but does something important for the organization like fix a security problem. This might cause a disparity in how the build behaves in a mild case where he sees something different than the other developers. Worst case is that artifact finds its way into something it's not supposed to and cause a real problem. Maven currently does not consider the same GAV from two different sources to be the same and for good reason. If we added the logic which asserted they were, in fact, the same JAR like checking the SHA1 I think that would be perfectly reasonable. Turning it off is just not wise. If you move around between work and home a lot use a repository manager locally. I've done that forever and I don't have any issues aside from having to add the odd proxy repository when there is a repository listed in a POM. I don't consider it a problem and it prevents the problem of mismatched identity. This logic should be improved not neutered. And I'm frankly tired of slapdash changes like this being made in the core without any discussion or review. The last two major changes I've made I've asked other to review my work which I think now with some other incidents of late that would be wise for all changes to the core. I'm -1 on disabling this feature by default. Fix it properly, using a property to turn it off is half measure which potentially causes users even more severe problems. If it could be fixed/configurable in aether it may be the solution to follow but I'm not sure about the status of this 3rd party project (eclipse migration ...) on which we don't have the hand. Seriously I helped and lost MANY hours with this problem because it is hard to diagnose. I'm sure that many people abandoned to try to understand and just dropped their local repo or decided to downgraded to m2 (or to switch to another tool). I think we can have a lot of similar feedbacks. The worst thing is to have another thing that users don't understand (lake of documentation ? communication ?) The side effect is that changing a repository id (or mirror id) makes maven to re-download all the earth (while we are claiming from the beginning that Maven won't never download twice a release). And when the remote artifact just disappeared it is just a nightmare due to the lake of correct logs and this case is easy to have. For example in my company I have a profile to let people DL artifacts from staging repositories (thus these are releases). It happened that they activated it once to test a build and then they rebuild the project without the profile (thinking the artifact is in the local repo) and it fails ... Sincerely I think I had my worst headaches with maven due to this bug On Fri, Feb 1, 2013 at 4:47 AM, Jason van Zyl ja...@tesla.io wrote: On Jan 31, 2013, at 7:13 PM, Arnaud Héritier aherit...@gmail.com wrote: Hi Olivier, Thx a lot for the fix. It will help a lot the community. But from my point of view it's perhaps not yet enough. We should : 1/ change the default behavior to deactivate this control which is difficult to understand I disagree. We may want to change it slightly but it's only a problem for people who flip between Maven a repository manager and without but it's to ensure the identity of a component. I haven't seen a huge number of complaints. I do not want to turn this off. Improve it, sure, but turning it off by default I believe is not the right thing to do. 2/ change the error message when this control is activated to clearly explain that the problem comes from the unavailability of the artifact on its original remote repo. For me 1/ is mandatory and 2/ a nice to have WDYT ? On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy ol...@apache.org wrote: I have pushed a fix for that. Now you can desactivate the enhanced local repository using: * new cli option: -slrm,--simple-local-repository-manager * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true will be available for testing here https://builds.apache.org/job/maven-3.x/ with build #368 2013/1/31 Jörg Hohwiller jo...@j-hohwiller.de: Hi Arnaud, +1 to consider the current behavior as a bug. We should be able to deactivate it easily (and perhaps to have it off by default to activate it only on CI servers) :) and we should take care to have a real error message explaining the issue and not a classical dependency not found while the artifact is in the local repo
Cutting a release
I have not had a lot of time to work on the class loader isolation but in light of these two problems: WAGON-372 WAGON-383 I would say a Wagon release should be cut, and we live without the logging classloader isolation and get the release out. I am going to do a full graph analysis on Central to see what Maven plugins actually depend on SLF4J or an implementation and if it's less than 5% I say we just live with it for now and revisit if there is a problem. So in summary go with SLF4J simple, live without classloader isolation and get these critical SSL problems out in a released version. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
Re: Pain with MNG-5181 (_maven.repositories)
On Jan 31, 2013, at 7:13 PM, Arnaud Héritier aherit...@gmail.com wrote: Hi Olivier, Thx a lot for the fix. It will help a lot the community. But from my point of view it's perhaps not yet enough. We should : 1/ change the default behavior to deactivate this control which is difficult to understand I disagree. We may want to change it slightly but it's only a problem for people who flip between Maven a repository manager and without but it's to ensure the identity of a component. I haven't seen a huge number of complaints. I do not want to turn this off. Improve it, sure, but turning it off by default I believe is not the right thing to do. 2/ change the error message when this control is activated to clearly explain that the problem comes from the unavailability of the artifact on its original remote repo. For me 1/ is mandatory and 2/ a nice to have WDYT ? On Fri, Feb 1, 2013 at 12:53 AM, Olivier Lamy ol...@apache.org wrote: I have pushed a fix for that. Now you can desactivate the enhanced local repository using: * new cli option: -slrm,--simple-local-repository-manager * or in MAVEN_OPTS: -Dmaven.simpleLocalRepoMan=true will be available for testing here https://builds.apache.org/job/maven-3.x/ with build #368 2013/1/31 Jörg Hohwiller jo...@j-hohwiller.de: Hi Arnaud, +1 to consider the current behavior as a bug. We should be able to deactivate it easily (and perhaps to have it off by default to activate it only on CI servers) :) and we should take care to have a real error message explaining the issue and not a classical dependency not found while the artifact is in the local repo. This is exactly filed here: http://jira.codehaus.org/browse/MNG-5185 Arnaud Cheers Jörg -- If know-how becomes know-where, then knowledge gets nowhere. [Jörg Hohwiller] -- 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 -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: settings or pom - where should repositories be defined?
Brian has a good blog entry on this: http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ On Jan 23, 2013, at 4:08 AM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello, in a lot of threads on the dev and user list, I have read that thou shalt not define repositories in your pom is the way to go. However http://maven.apache.org/settings.html#Servers reads: The repositories for download and deployment are defined by the repositories and distributionManagement elements of the POM. Is this a bug or is there no consensus on this :-)? Regards Mirko - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith
Re: Logging
That's all reasonable. I will take silence from the rest as tacit agreement. On Jan 7, 2013, at 1:33 PM, Dennis Lundberg denn...@apache.org wrote: Hi Jason From what I have gathered from these discussions, we have a majority of people that want to stick with SLF4J Simple for the 3.1.0 release, if all the quirks are ironed out. Judging by Hervé's recent commits this is almost done, except for the class loading isolation in MNG-5406. I think having the 3.1.0 release sit with SLF4J Simple for 6 months is a good idea. That will give it more time in the field, and we can fix any edge cases that might turn up. At the same time it will give us a necessary breather from discussing logging. Having a discussion before selecting some other logging implementation is a must as I see it. As for the licensing issue, I don't see that as a problem at all. It is just an extra hoop that we have to jump through, if we choose an EPL licensed logging implementation. If we in 6 months time have a majority in favor of an EPL licensed logging, then the vote to add that dependency will pass. Thanks for working on this, and for taking things slow so that everyone that wants to get involved is given the opportunity to do so. On 2013-01-06 17:31, Jason van Zyl wrote: I believe this is sufficient provided that we agree when any one attempts to select the logging framework that there is a discussion. As I see it I have been blocked as the person doing the work from selecting the implementation I would like because of a rule against EPL dependencies which was created for something not related to this. That said I understand why it was originally done. What I don't want to see if a month from now try someone trying inject something that isn't Logback without a discussion because I have a lot to say on the matter. So provided there is agreement that if we're choosing SLF4J Simple we just leave it there for at least 6 months because the discussion will be between Logback and Log4J2 and 1) That's at least how long it's going to take for Log4J2 to get to any level of maturity and we can see how it's being adopted and 2) I don't really want to talk about logging for a while. If we pick SLF4J Simple we stick with it for a while. I will express my opinion again that I think Logback is the right choice right now, but I'm fine with the agreed upon selection by the group to use SLF4J Simple provided this isn't going to be contended for the next 6 months. If anyone has any intention of changing the implementation before then we should just stop and have the discussion now. I also think the PMC should remove the requirement to vote in the use of EPL licensed dependencies, there's nothing wrong with the EPL being used with the ASL. On Dec 28, 2012, at 5:47 AM, Dennis Lundberg denn...@apache.org wrote: Hi, If SLF4J Simple is now a viable option again, i.e. the problems reported with concurrency and embedding has been sorted out, then that is the obvious choice to me. On 2012-12-24 15:12, Jason van Zyl wrote: I'm going to push this along and I agree with Stephen insofar as if you prefer an implementation then there should be a branch to support that preference. Thus far I have not seen anything aside from Stephen's efforts which are a PoC so the choice is between SLF4J Simple, Logback and Log4J2. If we want to put aside the debate, Ceki has figured out a way for use SLF4J Simple by resetting the streams and logging level. Which I can try if we want to go down that path. I didn't have to do any work in SLF4J myself so I'm fine with this approach. On Dec 17, 2012, at 12:35 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 17 December 2012 17:28, Olivier Lamy ol...@apache.org wrote: 2012/12/17 Stephen Connolly stephen.alan.conno...@gmail.com: Now the above could be fixed... but *somebody* needs to write some code to make them fixed. In the absence of anyone writing such code and committing it, those branches are dead... as are those choices. IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO GET THEM WALKING AGAIN That leaves logback and log4j2 on the table... JvZ has said that logback passes the ITs I have asked quite pointedly that Olivier (or anyone who is advocating for log4j2) would run the ITs and provide confirmation that log4j2 passes the ITs. branch logging/slf4j-log4j2 pass it (at least locally) and with this jenkins job https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/ Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now rush to demonstrate Mr Jenkins passing for his branch so he can move up from PASSES (unconfirmed) ;-) I would expect the other side in either choice, or an independent third party (such as Mr Jenkins if he can be made to get the integration tests to pass
Re: Logging
Cool, do you still need help with the classloader isolation? If not I'll move on to the Aether work. On Jan 6, 2013, at 5:52 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: done in 72bdc8602e5112aa273adc46b06d41c41f0f64a8 resetting slf4j factory wasn't sufficient: needed to so the same for slf4j- simple, with same technique Core ITs now run on my machine: great! Regards, Hervé Le mercredi 2 janvier 2013 08:20:12 Hervé BOUTEMY a écrit : yes, Maven isn't an app server, strict security manager shouldn't be an issue: if someone knows of a situation where it would be, please tell it :) the very good news with this solution is that it is at slf4j-api level, not dependent on logging implementation! I'll look at it in the WE, if nobody beats me at it: the solution is crystal clear, anybody interested in doing some code in core should be able to implement it Regards, Hervé Le mardi 1 janvier 2013 20:58:18 Jason van Zyl a écrit : It is. You create that package structure in your app to access it. jvz On 2013-01-01, at 8:48 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: If I read that right it is accessing a package local method... That won't work with a security manager in play (not that we have one) [unless we repackage the api jar] but just wondering if that may affect embedded use? On Tuesday, 1 January 2013, Jason van Zyl wrote: On Jan 1, 2013, at 6:15 PM, Hervé BOUTEMY herve.bout...@free.frjavascript:; wrote: Le lundi 24 décembre 2012 09:12:07 Jason van Zyl a écrit : If we want to put aside the debate, Ceki has figured out a way for use SLF4J Simple by resetting the streams and logging level. Which I can try if we want to go down that path. I didn't have to do any work in SLF4J myself so I'm fine with this approach. is there something visible somewhere? I didn't find any discussion on slf4j-dev or slf4j-user mailing lists nor any code in slf4j git repo The suggested solution has existed for two years apparently. There is no code that needs to be changed and no features to be added. resetting TARGET_STREAM in SimpleLogger [1] would require a publid method or I imagine we can even tweak private field access and private method invocation through reflection how are we supposed to work on this? Just take a look at: https://github.com/qos-ch/logback/blob/master/logback-classic/src/test/ ja va/org/slf4j/LoggerFactoryFriend.java Pretty straight forward. I don't have time to look at it until Friday but if want to implement the reset go for it. I'll ping you on Friday to see where you are and help out if you need it. Regards, Hervé [1] https://github.com/qos-ch/slf4j/blob/master/slf4j- simple/src/main/java/org/slf4j/impl/SimpleLogger.java - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown - 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 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Three people can keep a secret provided two of them are dead. -- Benjamin Franklin
Re: Logging
I believe this is sufficient provided that we agree when any one attempts to select the logging framework that there is a discussion. As I see it I have been blocked as the person doing the work from selecting the implementation I would like because of a rule against EPL dependencies which was created for something not related to this. That said I understand why it was originally done. What I don't want to see if a month from now try someone trying inject something that isn't Logback without a discussion because I have a lot to say on the matter. So provided there is agreement that if we're choosing SLF4J Simple we just leave it there for at least 6 months because the discussion will be between Logback and Log4J2 and 1) That's at least how long it's going to take for Log4J2 to get to any level of maturity and we can see how it's being adopted and 2) I don't really want to talk about logging for a while. If we pick SLF4J Simple we stick with it for a while. I will express my opinion again that I think Logback is the right choice right now, but I'm fine with the agreed upon selection by the group to use SLF4J Simple provided this isn't going to be contended for the next 6 months. If anyone has any intention of changing the implementation before then we should just stop and have the discussion now. I also think the PMC should remove the requirement to vote in the use of EPL licensed dependencies, there's nothing wrong with the EPL being used with the ASL. On Dec 28, 2012, at 5:47 AM, Dennis Lundberg denn...@apache.org wrote: Hi, If SLF4J Simple is now a viable option again, i.e. the problems reported with concurrency and embedding has been sorted out, then that is the obvious choice to me. On 2012-12-24 15:12, Jason van Zyl wrote: I'm going to push this along and I agree with Stephen insofar as if you prefer an implementation then there should be a branch to support that preference. Thus far I have not seen anything aside from Stephen's efforts which are a PoC so the choice is between SLF4J Simple, Logback and Log4J2. If we want to put aside the debate, Ceki has figured out a way for use SLF4J Simple by resetting the streams and logging level. Which I can try if we want to go down that path. I didn't have to do any work in SLF4J myself so I'm fine with this approach. On Dec 17, 2012, at 12:35 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 17 December 2012 17:28, Olivier Lamy ol...@apache.org wrote: 2012/12/17 Stephen Connolly stephen.alan.conno...@gmail.com: Now the above could be fixed... but *somebody* needs to write some code to make them fixed. In the absence of anyone writing such code and committing it, those branches are dead... as are those choices. IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO GET THEM WALKING AGAIN That leaves logback and log4j2 on the table... JvZ has said that logback passes the ITs I have asked quite pointedly that Olivier (or anyone who is advocating for log4j2) would run the ITs and provide confirmation that log4j2 passes the ITs. branch logging/slf4j-log4j2 pass it (at least locally) and with this jenkins job https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/ Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now rush to demonstrate Mr Jenkins passing for his branch so he can move up from PASSES (unconfirmed) ;-) I would expect the other side in either choice, or an independent third party (such as Mr Jenkins if he can be made to get the integration tests to pass at all) to provide confirmation that their opposition either has a branch that passes the integration tests or a claim that they are needing to give better proof. Now into that maelstrom Benson struck with his $0.02... arguing against log4j2 (for now) which kind of leaves us with logback (unless one of the other branches is brought back from the dead by somebody writing some code...) My 0.02 euros. Perso I use log4j2 for months without any issue. And performance are good. Even here with Maven ! (See various reports from folks on the other thread) I read http://logging.apache.org/log4j/2.x/performance.html (agree benchmarks depends on various factors (and could be maybe different if runed somewhere else) but that's something to take care. Then Log4j2 is a community developpement effort and have a good license for our Maven. These kinds of things are the things we should be debating... so far I have not seen much debate... But I have been waiting to get some options through the technical gates first before trying to stir up any non-technical debates. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl
Re: Logging
On Jan 1, 2013, at 6:15 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le lundi 24 décembre 2012 09:12:07 Jason van Zyl a écrit : If we want to put aside the debate, Ceki has figured out a way for use SLF4J Simple by resetting the streams and logging level. Which I can try if we want to go down that path. I didn't have to do any work in SLF4J myself so I'm fine with this approach. is there something visible somewhere? I didn't find any discussion on slf4j-dev or slf4j-user mailing lists nor any code in slf4j git repo The suggested solution has existed for two years apparently. There is no code that needs to be changed and no features to be added. resetting TARGET_STREAM in SimpleLogger [1] would require a publid method or I imagine we can even tweak private field access and private method invocation through reflection how are we supposed to work on this? Just take a look at: https://github.com/qos-ch/logback/blob/master/logback-classic/src/test/java/org/slf4j/LoggerFactoryFriend.java Pretty straight forward. I don't have time to look at it until Friday but if want to implement the reset go for it. I'll ping you on Friday to see where you are and help out if you need it. Regards, Hervé [1] https://github.com/qos-ch/slf4j/blob/master/slf4j- simple/src/main/java/org/slf4j/impl/SimpleLogger.java - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown
Re: Logging
It is. You create that package structure in your app to access it. jvz On 2013-01-01, at 8:48 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: If I read that right it is accessing a package local method... That won't work with a security manager in play (not that we have one) [unless we repackage the api jar] but just wondering if that may affect embedded use? On Tuesday, 1 January 2013, Jason van Zyl wrote: On Jan 1, 2013, at 6:15 PM, Hervé BOUTEMY herve.bout...@free.frjavascript:; wrote: Le lundi 24 décembre 2012 09:12:07 Jason van Zyl a écrit : If we want to put aside the debate, Ceki has figured out a way for use SLF4J Simple by resetting the streams and logging level. Which I can try if we want to go down that path. I didn't have to do any work in SLF4J myself so I'm fine with this approach. is there something visible somewhere? I didn't find any discussion on slf4j-dev or slf4j-user mailing lists nor any code in slf4j git repo The suggested solution has existed for two years apparently. There is no code that needs to be changed and no features to be added. resetting TARGET_STREAM in SimpleLogger [1] would require a publid method or I imagine we can even tweak private field access and private method invocation through reflection how are we supposed to work on this? Just take a look at: https://github.com/qos-ch/logback/blob/master/logback-classic/src/test/java/org/slf4j/LoggerFactoryFriend.java Pretty straight forward. I don't have time to look at it until Friday but if want to implement the reset go for it. I'll ping you on Friday to see where you are and help out if you need it. Regards, Hervé [1] https://github.com/qos-ch/slf4j/blob/master/slf4j- simple/src/main/java/org/slf4j/impl/SimpleLogger.java - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logging
I'm going to push this along and I agree with Stephen insofar as if you prefer an implementation then there should be a branch to support that preference. Thus far I have not seen anything aside from Stephen's efforts which are a PoC so the choice is between SLF4J Simple, Logback and Log4J2. If we want to put aside the debate, Ceki has figured out a way for use SLF4J Simple by resetting the streams and logging level. Which I can try if we want to go down that path. I didn't have to do any work in SLF4J myself so I'm fine with this approach. On Dec 17, 2012, at 12:35 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 17 December 2012 17:28, Olivier Lamy ol...@apache.org wrote: 2012/12/17 Stephen Connolly stephen.alan.conno...@gmail.com: Now the above could be fixed... but *somebody* needs to write some code to make them fixed. In the absence of anyone writing such code and committing it, those branches are dead... as are those choices. IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO GET THEM WALKING AGAIN That leaves logback and log4j2 on the table... JvZ has said that logback passes the ITs I have asked quite pointedly that Olivier (or anyone who is advocating for log4j2) would run the ITs and provide confirmation that log4j2 passes the ITs. branch logging/slf4j-log4j2 pass it (at least locally) and with this jenkins job https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/ Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now rush to demonstrate Mr Jenkins passing for his branch so he can move up from PASSES (unconfirmed) ;-) I would expect the other side in either choice, or an independent third party (such as Mr Jenkins if he can be made to get the integration tests to pass at all) to provide confirmation that their opposition either has a branch that passes the integration tests or a claim that they are needing to give better proof. Now into that maelstrom Benson struck with his $0.02... arguing against log4j2 (for now) which kind of leaves us with logback (unless one of the other branches is brought back from the dead by somebody writing some code...) My 0.02 euros. Perso I use log4j2 for months without any issue. And performance are good. Even here with Maven ! (See various reports from folks on the other thread) I read http://logging.apache.org/log4j/2.x/performance.html (agree benchmarks depends on various factors (and could be maybe different if runed somewhere else) but that's something to take care. Then Log4j2 is a community developpement effort and have a good license for our Maven. These kinds of things are the things we should be debating... so far I have not seen much debate... But I have been waiting to get some options through the technical gates first before trying to stir up any non-technical debates. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: Logging
I will try out Ceki's suggestion early next week and report back. On Dec 24, 2012, at 11:58 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yep if simple is back on the table commit that and let the fight be resolved later. This logback vs log4j2 debate seems fractious to try and resolve right now so sticking to your original plan of the *non-choice* that is simple will allow moving forward (though with some cribbing and moaning from the we want coloured logging brigade) ;-) On Monday, 24 December 2012, Benson Margulies wrote: On Mon, Dec 24, 2012 at 9:12 AM, Jason van Zyl ja...@tesla.iojavascript:; wrote: I'm going to push this along and I agree with Stephen insofar as if you prefer an implementation then there should be a branch to support that preference. Thus far I have not seen anything aside from Stephen's efforts which are a PoC so the choice is between SLF4J Simple, Logback and Log4J2. You're original plan was to get a release out with Simple and fight later. That would be fine with me. Based on prior discussions and votes, I don't see anyone vetoing that commit or a vote failing to pass. I'm not sure what I think would happen if you just committed logback or log4j at this point; they seem much of a muchness to me. You prefer logback, but log4j floats certain boats. If we want to put aside the debate, Ceki has figured out a way for use SLF4J Simple by resetting the streams and logging level. Which I can try if we want to go down that path. I didn't have to do any work in SLF4J myself so I'm fine with this approach. On Dec 17, 2012, at 12:35 PM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: On 17 December 2012 17:28, Olivier Lamy ol...@apache.orgjavascript:; wrote: 2012/12/17 Stephen Connolly stephen.alan.conno...@gmail.comjavascript:; : Now the above could be fixed... but *somebody* needs to write some code to make them fixed. In the absence of anyone writing such code and committing it, those branches are dead... as are those choices. IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO GET THEM WALKING AGAIN That leaves logback and log4j2 on the table... JvZ has said that logback passes the ITs I have asked quite pointedly that Olivier (or anyone who is advocating for log4j2) would run the ITs and provide confirmation that log4j2 passes the ITs. branch logging/slf4j-log4j2 pass it (at least locally) and with this jenkins job https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/ Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now rush to demonstrate Mr Jenkins passing for his branch so he can move up from PASSES (unconfirmed) ;-) I would expect the other side in either choice, or an independent third party (such as Mr Jenkins if he can be made to get the integration tests to pass at all) to provide confirmation that their opposition either has a branch that passes the integration tests or a claim that they are needing to give better proof. Now into that maelstrom Benson struck with his $0.02... arguing against log4j2 (for now) which kind of leaves us with logback (unless one of the other branches is brought back from the dead by somebody writing some code...) My 0.02 euros. Perso I use log4j2 for months without any issue. And performance are good. Even here with Maven ! (See various reports from folks on the other thread) I read http://logging.apache.org/log4j/2.x/performance.html (agree benchmarks depends on various factors (and could be maybe different if runed somewhere else) but that's something to take care. Then Log4j2 is a community developpement effort and have a good license for our Maven. These kinds of things are the things we should be debating... so far I have not seen much debate... But I have been waiting to get some options through the technical gates first before trying to stir up any non-technical debates. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher
Re: OutputStream that seamlessly switches to disk file?
http://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/io/FileBackedOutputStream.java On Dec 19, 2012, at 12:07 AM, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: Anyone know a buffer (OututStream) that will stay in-memory until it reaches a given size then rolls over to a tempfile? I need one for my tan...? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: Logging
Yup, the logback stuff all passes. The grid has been a bit wonky but I'll put a job up there. On Dec 17, 2012, at 12:35 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 17 December 2012 17:28, Olivier Lamy ol...@apache.org wrote: 2012/12/17 Stephen Connolly stephen.alan.conno...@gmail.com: Now the above could be fixed... but *somebody* needs to write some code to make them fixed. In the absence of anyone writing such code and committing it, those branches are dead... as are those choices. IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO GET THEM WALKING AGAIN That leaves logback and log4j2 on the table... JvZ has said that logback passes the ITs I have asked quite pointedly that Olivier (or anyone who is advocating for log4j2) would run the ITs and provide confirmation that log4j2 passes the ITs. branch logging/slf4j-log4j2 pass it (at least locally) and with this jenkins job https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/ Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now rush to demonstrate Mr Jenkins passing for his branch so he can move up from PASSES (unconfirmed) ;-) I would expect the other side in either choice, or an independent third party (such as Mr Jenkins if he can be made to get the integration tests to pass at all) to provide confirmation that their opposition either has a branch that passes the integration tests or a claim that they are needing to give better proof. Now into that maelstrom Benson struck with his $0.02... arguing against log4j2 (for now) which kind of leaves us with logback (unless one of the other branches is brought back from the dead by somebody writing some code...) My 0.02 euros. Perso I use log4j2 for months without any issue. And performance are good. Even here with Maven ! (See various reports from folks on the other thread) I read http://logging.apache.org/log4j/2.x/performance.html (agree benchmarks depends on various factors (and could be maybe different if runed somewhere else) but that's something to take care. Then Log4j2 is a community developpement effort and have a good license for our Maven. These kinds of things are the things we should be debating... so far I have not seen much debate... But I have been waiting to get some options through the technical gates first before trying to stir up any non-technical debates. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Three people can keep a secret provided two of them are dead. -- Benjamin Franklin
Re: Logging
I'll get it up on our Jenkins but here's a run that shows it passes: http://ci.tesla.io:8080/job/maven-its-logback/jdk=jdk-1.6/20/ On Dec 17, 2012, at 12:35 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 17 December 2012 17:28, Olivier Lamy ol...@apache.org wrote: 2012/12/17 Stephen Connolly stephen.alan.conno...@gmail.com: Now the above could be fixed... but *somebody* needs to write some code to make them fixed. In the absence of anyone writing such code and committing it, those branches are dead... as are those choices. IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO GET THEM WALKING AGAIN That leaves logback and log4j2 on the table... JvZ has said that logback passes the ITs I have asked quite pointedly that Olivier (or anyone who is advocating for log4j2) would run the ITs and provide confirmation that log4j2 passes the ITs. branch logging/slf4j-log4j2 pass it (at least locally) and with this jenkins job https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/ Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now rush to demonstrate Mr Jenkins passing for his branch so he can move up from PASSES (unconfirmed) ;-) I would expect the other side in either choice, or an independent third party (such as Mr Jenkins if he can be made to get the integration tests to pass at all) to provide confirmation that their opposition either has a branch that passes the integration tests or a claim that they are needing to give better proof. Now into that maelstrom Benson struck with his $0.02... arguing against log4j2 (for now) which kind of leaves us with logback (unless one of the other branches is brought back from the dead by somebody writing some code...) My 0.02 euros. Perso I use log4j2 for months without any issue. And performance are good. Even here with Maven ! (See various reports from folks on the other thread) I read http://logging.apache.org/log4j/2.x/performance.html (agree benchmarks depends on various factors (and could be maybe different if runed somewhere else) but that's something to take care. Then Log4j2 is a community developpement effort and have a good license for our Maven. These kinds of things are the things we should be debating... so far I have not seen much debate... But I have been waiting to get some options through the technical gates first before trying to stir up any non-technical debates. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: [1/2] git commit: extracted Slf4jConfiguration interface and corresponding implementation to clearly separate code depending on slf4j binding
Sorry, I looked it up while on my phone. We definitely don't want to use
anything not specific to SLF4J. In that case you might just want to pass in the
LoggerFactory and CliRequest in and let the implementation do whatever it
needs.
On Dec 16, 2012, at 5:16 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
Level class is lg4j specific: I can't use it
I didn't find anything usable more specific than int: ideas welcome.
but what I can do is adding javadoc pointing to plexus Logger constants to
document accepted values
Regards,
Hervé
Le samedi 15 décembre 2012 20:48:15 Jason van Zyl a écrit :
I would suggest you use the Level[1] class instead of a raw int for setting
the level.
[1]: http://www.slf4j.org/apidocs/org/apache/log4j/Level.html
jvz
On 2012-12-15, at 7:57 PM, hbout...@apache.org wrote:
Updated Branches:
refs/heads/master 915b1553f - 39e11cf2e
extracted Slf4jConfiguration interface and corresponding implementation
to clearly separate code depending on slf4j binding
still need to add automatic selection of implementation
Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/39e11cf2
Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/39e11cf2
Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/39e11cf2
Branch: refs/heads/master
Commit: 39e11cf2e51a41fc47001f0fe59da251dab87587
Parents: 73ffdaf
Author: Hervé Boutemy hbout...@apache.org
Authored: Sun Dec 16 01:57:36 2012 +0100
Committer: Hervé Boutemy hbout...@apache.org
Committed: Sun Dec 16 01:57:36 2012 +0100
--
.../main/java/org/apache/maven/cli/MavenCli.java | 12 ++-
.../cli/logging/AbstractSlf4jConfiguration.java| 46 +++
.../maven/cli/logging/Slf4jConfiguration.java | 35
.../cli/logging/impl/Slf4jSimpleConfiguration.java | 62 +++
4 files changed, 151 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/maven/blob/39e11cf2/maven-embedder/
src/main/java/org/apache/maven/cli/MavenCli.java
--
diff --git
a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
b/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java index
e744e65..e3c62f8 100644
--- a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
+++ b/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
@@ -39,8 +39,10 @@ import org.apache.maven.InternalErrorException;
import org.apache.maven.Maven;
import org.apache.maven.cli.event.DefaultEventSpyContext;
import org.apache.maven.cli.event.ExecutionEventLogger;
+import org.apache.maven.cli.logging.Slf4jConfiguration;
import org.apache.maven.cli.logging.Slf4jLoggerManager;
import org.apache.maven.cli.logging.Slf4jStdoutLogger;
+import org.apache.maven.cli.logging.impl.Slf4jSimpleConfiguration;
import org.apache.maven.cli.transfer.ConsoleMavenTransferListener;
import org.apache.maven.cli.transfer.QuietMavenTransferListener;
import org.apache.maven.cli.transfer.Slf4jMavenTransferListener;
@@ -131,6 +133,8 @@ public class MavenCli
private DefaultSecDispatcher dispatcher;
+private Slf4jConfiguration slf4jConfiguration = new
Slf4jSimpleConfiguration(); +
public MavenCli()
{
this( null );
@@ -306,24 +310,24 @@ public class MavenCli
if ( cliRequest.debug )
{
cliRequest.request.setLoggingLevel(
MavenExecutionRequest.LOGGING_LEVEL_DEBUG );
-System.setProperty( org.slf4j.simpleLogger.defaultLogLevel,
debug ); +slf4jConfiguration.setRootLoggerLevel(
MavenExecutionRequest.LOGGING_LEVEL_DEBUG );
}
else if ( cliRequest.quiet )
{
cliRequest.request.setLoggingLevel(
MavenExecutionRequest.LOGGING_LEVEL_ERROR );
-System.setProperty( org.slf4j.simpleLogger.defaultLogLevel,
error ); +slf4jConfiguration.setRootLoggerLevel(
MavenExecutionRequest.LOGGING_LEVEL_ERROR );
}
else
{
cliRequest.request.setLoggingLevel(
MavenExecutionRequest.LOGGING_LEVEL_INFO );
-System.setProperty( org.slf4j.simpleLogger.defaultLogLevel,
info ); +slf4jConfiguration.setRootLoggerLevel(
MavenExecutionRequest.LOGGING_LEVEL_INFO );
}
if ( cliRequest.commandLine.hasOption( CLIManager.LOG_FILE ) )
{
File logFile = new File(
cliRequest.commandLine.getOptionValue( CLIManager.LOG_FILE )
); logFile = resolveFile( logFile,
cliRequest.workingDirectory );
-System.setProperty( org.slf4j.simpleLogger.logFile,
logFile.getAbsolutePath() ); +
slf4jConfiguration.setLoggerFile
Re: Logging
I was just giving folks time to make their branches and evaluate. For people who felt strongly like Olviier and myself I expect them to make branches and implement something for comparison. I didn't want to do anymore work on SLF4J Simple but Ceki is going to implement a reset function in the logger so it may still be viable. I figured this time of year there's no dire rush anymore. On Dec 16, 2012, at 12:16 PM, Benson Margulies bimargul...@gmail.com wrote: Since not much has been heard on the 'pick a logger' question for some time, I'm going to stick my neck out and try to summarize some aspects, in the hopes of discovering how close we are to a consensus. In the following, I use the word 'want' to express *preference*, not non-negotiable demands. We all need: reasonable performance, an acceptable license (i.e. category A or B), a stable, reliable, logger. Various of us want: MDCs, colorization: a package with a community behind it, an avoidance of of EPL, to use our fellow Apache-projects' outputs. We know that: java.util.logging isn't going to give us MDCs or colorization without a great deal of effort. So I'm crossing it off in this email. Now, I'm going to express an opinion based on all the email *I've* seen. I don't claim to be right, but I wonder if people would be willing to follow my logic. Once we eliminate j.u.l from consideration, our choices are logback, log4j 1.x, and log4j 2.x. It seems to me that log4j 2.x is not really ready for us yet, so in this email I'm crossing it off. If we continue to dither for another few months, that might change. If someone disagrees, I'm sure they'll respond. log4j1.x is the tried and true alternative. Colorization, however, would require significant effort. Those of us who don't give a fig about colourization won't be perturbed by this. logback, on the other hand, is very widely adopted, and no one seems to be able to offer any *technical* objection to it. And it gives us colorization out of the box. The objections to logback, then, are cultural, organizational, and/or related to license. In my view, the very broad adoption of logback seems to me to neutralize the concern that it's a one-man-band. While one person projects present certain risks in the abstract, this particular one seems to me not to raise them. In my view, objecting based on EPL is, as I wrote once before, not appropriate. The Maven project erected a barrier to EPL dependencies to respond to cases in which core Maven functionality was forked and EPL-ified, or just proposed to be replaced by EPL code. The situation with logging is simply not analogous. As a project, I don't think we need to anticipate wanting to bring the logging system into our source. Adding a category B logging dependency does not contribute to the 'hollowing out' of Maven. As a Foundation, category B licenses are just as acceptable as category A licenses as dependencies. (I also wonder why this barrier was not specifically set up in terms of 'core code replaced by non-A' instead of 'EPL'). If I add this all up, to me it amounts to a test. If some member(s) of this community really, really, want to take log4j 1.x in order to 'use Apache' or 'have a community', I think that those people should be willing to step up and *write the code* to make log4j 1.x feature-equivalent with logback for our purposes. The same logic would apply to j.u.l, though my impression is that there is no practical coding path that gets to equivalence. I trust that this email will inspire response; perhaps it will inspire a response that allows us to detect some consensus. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - A language that doesn’t affect the way you think about programming is not worth knowing. -- Alan Perlis
Re: core-integration-testing-maven-3 jobs hangs
Igor and I have successfully run the ITs on 1.5. Igor did it on Linux and I did it on OS X. So I think it's some interaction on the CI server. I can't get it to work on Jenkins or Hudson, even with a lot of memory. On Dec 16, 2012, at 2:43 PM, Anders Hammar and...@hammar.net wrote: The pattern I see is that all jobs that build with JDK 1.5 hangs. This includes the windows node. /Anders On Sun, Dec 16, 2012 at 7:10 PM, Dennis Lundberg denn...@apache.org wrote: On 2012-12-14 00:29, Brett Porter wrote: On 13/12/2012, at 9:15 PM, Anders Hammar and...@hammar.net wrote: Also, there's some problems with Jenkins not finding git installation on some nodes. But that's a different topic, but possibly related to the upgrade? If you mean the Windows node, I've already asked about that on builds@a.o but haven't gotten a reply yet. Git is now found on the windows nodes, so I guess your mail triggered some action. But we also have the same problem on the solaris nodes. I'll join the builds list and ask about that. I installed it, but understood that Dennis still need to change something in the build before it would work: http://mail-archives.apache.org/mod_mbox/www-builds/201212.mbox/%3C50BFBBA6.5010809%40apache.org%3E I've tried tweaking the Jenkins job on the Windows slave, but without success. The build fails with this error: --- BUILD FAILED f:\ws\m3-its\maven-3-trunk\build.xml:253: Timeout: killed the sub-process Total time: 10 minutes 58 seconds Build step 'Invoke Ant' marked build as failure --- The thing is that I've disabled all the timeouts I can find... Does anyone have more ideas? Here's a link to the latest build: https://builds.apache.org/job/core-it-maven-3-win/294/console I see the hanging too... haven't looked into where it gets stuck any further though. Perhaps it's using an authenticated URL to checkout additional stuff as part of the bootstrap? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: [1/2] git commit: extracted Slf4jConfiguration interface and corresponding implementation to clearly separate code depending on slf4j binding
I would suggest you use the Level[1] class instead of a raw int for setting the
level.
[1]: http://www.slf4j.org/apidocs/org/apache/log4j/Level.html
jvz
On 2012-12-15, at 7:57 PM, hbout...@apache.org wrote:
Updated Branches:
refs/heads/master 915b1553f - 39e11cf2e
extracted Slf4jConfiguration interface and corresponding implementation
to clearly separate code depending on slf4j binding
still need to add automatic selection of implementation
Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/39e11cf2
Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/39e11cf2
Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/39e11cf2
Branch: refs/heads/master
Commit: 39e11cf2e51a41fc47001f0fe59da251dab87587
Parents: 73ffdaf
Author: Hervé Boutemy hbout...@apache.org
Authored: Sun Dec 16 01:57:36 2012 +0100
Committer: Hervé Boutemy hbout...@apache.org
Committed: Sun Dec 16 01:57:36 2012 +0100
--
.../main/java/org/apache/maven/cli/MavenCli.java | 12 ++-
.../cli/logging/AbstractSlf4jConfiguration.java| 46 +++
.../maven/cli/logging/Slf4jConfiguration.java | 35
.../cli/logging/impl/Slf4jSimpleConfiguration.java | 62 +++
4 files changed, 151 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/maven/blob/39e11cf2/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
--
diff --git a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
b/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
index e744e65..e3c62f8 100644
--- a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
+++ b/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
@@ -39,8 +39,10 @@ import org.apache.maven.InternalErrorException;
import org.apache.maven.Maven;
import org.apache.maven.cli.event.DefaultEventSpyContext;
import org.apache.maven.cli.event.ExecutionEventLogger;
+import org.apache.maven.cli.logging.Slf4jConfiguration;
import org.apache.maven.cli.logging.Slf4jLoggerManager;
import org.apache.maven.cli.logging.Slf4jStdoutLogger;
+import org.apache.maven.cli.logging.impl.Slf4jSimpleConfiguration;
import org.apache.maven.cli.transfer.ConsoleMavenTransferListener;
import org.apache.maven.cli.transfer.QuietMavenTransferListener;
import org.apache.maven.cli.transfer.Slf4jMavenTransferListener;
@@ -131,6 +133,8 @@ public class MavenCli
private DefaultSecDispatcher dispatcher;
+private Slf4jConfiguration slf4jConfiguration = new
Slf4jSimpleConfiguration();
+
public MavenCli()
{
this( null );
@@ -306,24 +310,24 @@ public class MavenCli
if ( cliRequest.debug )
{
cliRequest.request.setLoggingLevel(
MavenExecutionRequest.LOGGING_LEVEL_DEBUG );
-System.setProperty( org.slf4j.simpleLogger.defaultLogLevel,
debug );
+slf4jConfiguration.setRootLoggerLevel(
MavenExecutionRequest.LOGGING_LEVEL_DEBUG );
}
else if ( cliRequest.quiet )
{
cliRequest.request.setLoggingLevel(
MavenExecutionRequest.LOGGING_LEVEL_ERROR );
-System.setProperty( org.slf4j.simpleLogger.defaultLogLevel,
error );
+slf4jConfiguration.setRootLoggerLevel(
MavenExecutionRequest.LOGGING_LEVEL_ERROR );
}
else
{
cliRequest.request.setLoggingLevel(
MavenExecutionRequest.LOGGING_LEVEL_INFO );
-System.setProperty( org.slf4j.simpleLogger.defaultLogLevel,
info );
+slf4jConfiguration.setRootLoggerLevel(
MavenExecutionRequest.LOGGING_LEVEL_INFO );
}
if ( cliRequest.commandLine.hasOption( CLIManager.LOG_FILE ) )
{
File logFile = new File( cliRequest.commandLine.getOptionValue(
CLIManager.LOG_FILE ) );
logFile = resolveFile( logFile, cliRequest.workingDirectory );
-System.setProperty( org.slf4j.simpleLogger.logFile,
logFile.getAbsolutePath() );
+slf4jConfiguration.setLoggerFile( logFile );
try
{
PrintStream ps = new PrintStream( new FileOutputStream(
logFile ) );
http://git-wip-us.apache.org/repos/asf/maven/blob/39e11cf2/maven-embedder/src/main/java/org/apache/maven/cli/logging/AbstractSlf4jConfiguration.java
--
diff --git
a/maven-embedder/src/main/java/org/apache/maven/cli/logging/AbstractSlf4jConfiguration.java
b/maven-embedder/src/main/java/org/apache/maven/cli/logging/AbstractSlf4jConfiguration.java
new file mode 100644
index 000..2b2ef6d
--- /dev/null
+++
Re: Logback in Maven Core
information on the performance -- Daniel Kulp dk...@apache.org javascript:; - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: A very interesting performance regression in 3.1 embedded mode
In embedded mode the ITs were failing without the change. I can't remember what you were looking at but what problem is it causing? jvz On 2012-12-12, at 11:35 AM, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: Does that mean m2e ditches the container every now and then? In that case the whole unloading jason implemented can be reverted...? K Den 12. des. 2012 kl. 16:44 skrev Igor Fedorenko i...@ifedorenko.com: For tests, I think the easiest is to check number of realms at the end of each test and drop plexus container if it grew over certain number of realms. Pick the number large enough to fit in 128M of permgen and I think this will provide good tradeoff between performance and memory usage. This does mean separate container per each test thread, but I think this is required for other reasons. For IDEs, I would not try to guess what they need and let IDE developers come with proposed improvements to caching. I can't speak for other IDEs, but m2e for example, already deals with project realms properly and plugin realms are not usually an issue, so we don't really have any issues we need to fix. -- Regards, Igor On 2012-12-12 3:31 AM, Kristian Rosenvold wrote: 2012/12/12 Milos Kleint mkle...@gmail.com: how much memory will be freed by the soft reference? if it's not a big chunk, most likely not worth it, soft references are released only when your VM is really, really in trouble. by the time it gets released, you've been slowed down by repeatedly hitting the ceiling of your memory and CGed frequently. I think the appropriate question to ask is how much memory would be freed by an eviction strategy? and maybe who needs it?. The answer to how much can precisely be formulated as a truckload. The surefire IT's in embedded mode require 350MB permgen and 500MB memory. When things are evicted those numbers are more or less halved (I seem to believe they ran in 128MB permgen!). I will come up with some hard numbers on that at some point... An embedded core used to hold on to a *lot* of classloaders, both for plugins, extensions and projects. Some of these are never freed and will hence leak for as long as the embedded container is being kept alive. So for someone IDE-like embedding maven it would definitely make sense to release and reallocate the embedded maven instance every time a project is loaded/reloaded. Just recently it was changed to always deallocate the plugins (but still leaking extension/project realms), which is probably too much or too little. From an IDE point of view 0.5 seconds added overhead /may/ be ok (while certainly not world class performance). For something like an embedded test-run it might make sense to just ditch the embedded container every N runs and start with a fresh one. The real problem starts when you decide to hold onto the embedded instance and declare that the instance should release class realms according to some eviction strategy. Like so many times before, neither softreferences nor weakreferences really seem appropriate; one is too liberal in letting go, the other too conservative. Currently core does not track actual usage of each class realm (although it would be fairly simple to implement) ; if it did we could do all sorts of cool stuff. I prefer a /predictable/ eviction strategy. We *could* do something like a round-robin eviction (evict a rotating 25% of all classrealms every time) or a usage based eviction (evict all unused and every N usages of a given class realm). But then again maybe this whole issue is best solved by restoring the old strategy of no eviction and tell the clients to evict us every now and then. That would work very well for embedded test runs, unsure what something like m2e would do about it Kristian just an illustrative story, most likely not related to this usecase but still interesting while embedding maven in netbeans, we've SoftReferenced MavenProject at some point in time. MavenProjects can hold a big object tree, mostly via the cache in ProjectBuildingRequest. So once you run out of memory, the SRs get dropped however sometimes the MP instances are again immediately required, so they are loaded again. And dropped. And loaded and the IDE grinds to a halt. In some cases, one gets OOME fairly fast, but in others it can take fairly long. BTW we don't embed maven builds, just MavenProject loading in netbeans Milos On Sun, Dec 9, 2012 at 11:04 PM, Christian Schulte c...@schulte.it wrote: Am 12/09/12 22:58, schrieb Kristian Rosenvold: Anyone else have any ideas about eviction strategies ? Without having looked at the code. GC driven by using soft references. -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A very interesting performance regression in 3.1 embedded mode
On Dec 12, 2012, at 12:09 PM, Igor Fedorenko i...@ifedorenko.com wrote: On 2012-12-12 11:35 AM, Kristian Rosenvold wrote: Does that mean m2e ditches the container every now and then? No. m2e keeps the same container but injects its own cache implementations that allows purging project-specific cache entries whenever workspace project is re-read or removed from workspace. There is also logic to dispose project realms. m2e never releases plugin realms, but as I mentioned, this does not cause any immediate problems so I have not spent much time on a solution. In that case the whole unloading jason implemented can be reverted...? That was actually my change Jason committed for me. I could not remember my svn password at the time :-) I applied the patch as you gave it to me which had your name in it. If git apply strips it out I didn't know that, I just assumed it would show up as you. -- Regards, Igor K Den 12. des. 2012 kl. 16:44 skrev Igor Fedorenkoi...@ifedorenko.com: For tests, I think the easiest is to check number of realms at the end of each test and drop plexus container if it grew over certain number of realms. Pick the number large enough to fit in 128M of permgen and I think this will provide good tradeoff between performance and memory usage. This does mean separate container per each test thread, but I think this is required for other reasons. For IDEs, I would not try to guess what they need and let IDE developers come with proposed improvements to caching. I can't speak for other IDEs, but m2e for example, already deals with project realms properly and plugin realms are not usually an issue, so we don't really have any issues we need to fix. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language
Re: Logback in Maven Core
at work in production for quite some time now and are very pleased. So yes, using logback in Maven is fine. Regards Ansgar Am 11.12.2012 03:33 schrieb Jason van Zyl ja...@tesla.io: Hi, I looked around a bit more today and I don't think SLF4J Simple is viable long term, I don't want to patch it anymore as I would have to do a day's work to make changes that keep the performance levels up, get it reviewed and released, and I honestly don't think it's worth it anymore. I would rather spend my time building out the plugin test cases and help to finish the classloader blocking of SLF4J. I don't mind spending time getting it all working but I don't want to waste my time on an implementation we're going to toss. After a conversation with the PMC it will require a vote to accept Logback which is EPL but I wanted to ask committers and interested users about using Logback. I believe Logback is the best choice as it's the most mature and battle tested implementation because once it goes in it's likely not ever to come out. Many of us are users and have integration experience with Logback and it's what I use everyday for logging in all my other projects and I've been a happy user for years. I see Logback as best of breed and widely adopted including 8 projects at Apache. There's no point in asking the PMC to vote on the acceptance of Logback if it's not acceptable by the community. If there are interested users I would really like to hear what you think because you're the ones who will have to live with the choice that is made. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: Logback in Maven Core
Would be easy enough to create a template method in MavenCli which in which subclasses can override to do any setup of the underlying logging system. Much like the createModelProcessor() method in the MavenCli currently. On Dec 11, 2012, at 7:39 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: same for me with one precision: IMHO, the few places where we'll have to write implementation-specific code need to be placed in a separate class to ease changing implementation Regards, Hervé Le mardi 11 décembre 2012 16:19:12 Daniel Kulp a écrit : My thoughts: 99.5% (or more) of the maven users will not care one way or another what logging impl we use. They won't configure anything beyond -X. They won't try changing loggers. They won't muck with the configs. Etc.. They just run mvn and expect it to work. For the remaining 0.5%, no matter what we do, we will need to document things clearly about how to configure things. For these folks, they are generally experts and thus a couple extra steps to replace a logging framework, edit configs, etc… is not a big deal at all. (again, DOCUMENT this all clearly or provide a nice maven plugin or something to do it for them) My preference, in order: slf4j-jdk14 slf4j-simple log4j2 slf4j-log4j and then a big gap to logback. The first two are there as they would provide the least amount of extra dependencies, complexity, etc… That said, we know slf4j-simple has issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI case, I don't see any advantage of logback over log4j2 or slf4j-log4j. If the entire argument is around wanting something battle tested, go for slf4j-log4j. It's certainly used by more projects than logback and more people would already know it's configuration options. Personally, I find the number of projects argument annoying and mostly irrelevant. (and at least 2 of the Apache 8 projects that are on the logback homepage don't use logback, they now use slf4j-log4j) Thus, it comes down to two major things for me: 1) License issues - (sorry Stephen, this IS an issue) I fully plan to vote -1 for logback if/when presented to the PMC for approval. There are very good options that would work just as well for our needs that are not EPL. 2) Community - Ceki is great, no doubt about it, but at the end of the day, logback is pretty much a one man show. Apache is more about community and community over code and all that. I strongly prefer something that has a community behind it, or, at the very least, is open to developing a community behind it. Major bonus points if that community already contains Maven PMC members/committers on it.If *we* run into issues, I strongly prefer that *we* can get those issues fixed. If two options are functionally and technically equivalent (within reasonable limits), then I'll take the community driven, permissive licensed version. That's my $0.02 worth. Dan On Dec 10, 2012, at 9:32 PM, Jason van Zyl ja...@tesla.io wrote: Hi, I looked around a bit more today and I don't think SLF4J Simple is viable long term, I don't want to patch it anymore as I would have to do a day's work to make changes that keep the performance levels up, get it reviewed and released, and I honestly don't think it's worth it anymore. I would rather spend my time building out the plugin test cases and help to finish the classloader blocking of SLF4J. I don't mind spending time getting it all working but I don't want to waste my time on an implementation we're going to toss. After a conversation with the PMC it will require a vote to accept Logback which is EPL but I wanted to ask committers and interested users about using Logback. I believe Logback is the best choice as it's the most mature and battle tested implementation because once it goes in it's likely not ever to come out. Many of us are users and have integration experience with Logback and it's what I use everyday for logging in all my other projects and I've been a happy user for years. I see Logback as best of breed and widely adopted including 8 projects at Apache. There's no point in asking the PMC to vote on the acceptance of Logback if it's not acceptable by the community. If there are interested users I would really like to hear what you think because you're the ones who will have to live with the choice that is made. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks
Re: MNG-5406
I'll make the example plugins and then we can try it. Do you have a little snippet as an example? On Dec 10, 2012, at 5:15 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Sunday, 9 December 2012, Hervé BOUTEMY wrote: I just committed a starting point for MNG-5406: don't expose core's slf4j-api by default, add a plugin-descriptor option to expose this is a new field in plugin descriptor. I still don't know how to effectively use it in DefaultClassRealmManager.createPluginRealm() to avoid importing slf4j-api from parent: help appreciated. I still didn't create a Jira issue in plugin-tools to generate the field in plugin descriptor. What I know is that its configuration won't be done as an annotation in a goal/Mojo since it's a plugin-wide configuration, not at goal level. I was thinking a configuration option for m-p-p in the pom for the plugin, since that is where you are adding the dependencies, it makes sense to configure the treatment of those dependencies in the same file Regards, Hervé Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: Logging
Given the time of year, I think everyone's focus will be elsewhere and starting vacations soon so I would rather just wait. I can't even do the minimal to use SLF4J Simple until that patch is reviewed and absorbed if it is accepted at all because. When I say inefficient it's on the order of breaking the performance test harness in SLF4J simple right now, so I'm sure my patch will not go in unchanged. I just wanted to prove it can work. There is also the bit of work Hervé wants to do vis-a-vis isolating the SLF4J implementation and so that's going to take a few days anyway. On Dec 10, 2012, at 3:32 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: As for options; there is also the option of accepting that the technical challenges were slightly larger than anticipated and that getting things right make take some more time. In this context we could push the slf4j introduction to a 3.1 branch and release 3.0.5 now. Or just take the time. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Re: Logging
The changes have only been in the simple logger implementation, not the api itself. On Dec 10, 2012, at 4:06 AM, Mark Struberg strub...@yahoo.de wrote: To be honest. Slf4J is really mature. The fact that we need some 'special treatment' for maven worries me. Are we are trying to do things with slf4j-simple it never was intended for? Again: I think sjf4j is really mature, so I guess the error is on our side. And you also mentioned that Ceki did special changes in slf4j _itself_ and not only the simple logger? That worries me even more, what changes have that been? LieGrue, strub - Original Message - From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org Cc: Sent: Monday, December 10, 2012 8:33 AM Subject: Re: Logging On Dec 10, 2012, at 2:11 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: trying to be concise and neutral 1. because slf4j-api is well known, it has lots of back-ends, that will provide powerfull configuration techniques for filtering, display, recording and so on Maven output: precise use case still need to be described 2. the discussion is not much about the api but about the default back-end that will be shipped with Maven: there is no consensus, then the actual strategy is to start with slf4j-simple in Maven 3.1.0 then have a vote to choose which more complete implementation will go in Maven 3.1.1+ We're blocked on using SLF4J Simple currently. We can wait for my patches to be reviewed, but we should probably start the vote for the implementation if that is what we require because after making several patches already I think it's just time to pick an implementation. As I said in my previous email we're so close to Christmas we might as well decide this and then fire up the release process in the new year after the logging implementation selection is made. It's highly unlikely that in the next few weeks testing a new version of Maven is going to be anyone's priority so we might as well take our time at this point. Regards, Hervé Le dimanche 9 décembre 2012 22:18:51 Chris Graham a écrit : I got lost (in other work) and this thread a long time ago. Can someone please remind me just why we are changing the logging at all? -Chris On Sun, Dec 9, 2012 at 5:52 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: 2012/12/9 Olivier Lamy ol...@apache.org: Perso I'm fine using log4j2. I use the branch I pushed for some weeks now and I'm happy. Log4j2 has quickly added a feature I needed and release it. Furthermore I'm fine working with an Apache community in case of any issue we could have. I'm not entirely sure I follow where this discussion is actually going, but I'm firmly opposed to including a brand new logging framework as default in m3. Kristian - 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 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith
Re: Logging
Not sure what's happening but: http://maven.apache.org/developers/dependency-policies.html is not there. On Dec 10, 2012, at 3:25 AM, Olivier Lamy ol...@apache.org wrote: 2012/12/10 Hervé BOUTEMY herve.bout...@free.fr: Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit : I think it's time to stop patching SLF4J Simple. I have an inefficient fix for the embedding problem, but we're likely to run into issues concurrency with parallel builds and who knows what else. This will patch/change #5 and many hours of trying to get SLF4J Simple to work but I think we're pushing the simple implementation beyond its scope. So I'd just like to put in Logback and be done with it. There are at least three of us opposed to using a new logging framework, logging *implementation*, please, not framework: the framework is slf4j-api, on which our code will have much dependency. The logging implementation is far less invasive choice (even if not completely null). but I don't think there is anyone against using Logback. why this provocation? (should I say lack of respect for others opinion?) I honestly don't think there is any rational argument for not using Logback, so after doing all the SLF4J work and making a best effort to use SLF4J Simple I think it's pointless to pursue that path any longer and put in Logback. we'll need to wait for 3.1.1 and a vote to have a chance to stop tension about this: whatever choice is done, there will be some devs unhappy who will have to live with it notice I won't be able to reply for the next half day, my intent with this reply is just to avoid one more re-spin of a feeling that the vote won't happen and let Olivier once more jump on the case I just hope I won't have to read a lot of replies to this tonight when I'm back from work and loose my time carefully reading if anything new or interesting is written I have already explained my opinion. Folks think log4j2 is immature and/or don't have a community of various people. Furthermore it looks it's not anymore possible to use immature libraries in core (whereas it has been done for more important part: sisu or aether). But now that's not anymore possible... Well things evolve and POV can change that's the life BTW due to our policy [1] and if I correctly read license here [2] a vote is mandatory. (and don't ask me to start this vote :-) ). Cheers -- Olivier [1] http://maven.apache.org/developers/dependency-policies [2] http://logback.qos.ch/license.html Regards, Hervé On Dec 9, 2012, at 5:45 PM, Arnaud Héritier aherit...@gmail.com wrote: I'm a little bit lost too. Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk (for many - good - reasons) but the last bug discovered by Kristian can be solved only * by having a fix from slf4j (but it isn't sure that the patch makes sense - to be validated by Ceki) * or by using a more evolved impl like logback (or log4j ...). I think that everyone's will prefer the first solution if possible but if we cannot we'll have the question to select the impl. Do we need to vote ? Is there really a question logback vs log4j(2) ? Like I said in another thread I'll understand if the project decide to choose log4j2 even if it is young because we want to support another ASF initiative (And I'm sure we won't have to regret it, and we'll have a really good support from its team) but in a general case I would prefer to choose logback which is today the reference logging framework (I that case we need to have a PMC vote to accept an external component under EPL license http://maven.apache.org/developers/dependency-policies ?). What do we need (for 3.1.0) ? What do we do ? Arnaud On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar and...@hammar.net wrote: Not sure where to get into this thread, but I'd just like to add my perspective on this topic. For this first release I would prefer it to not include any of the more advanced slf4j implementations, like a few others have already also stated. Using simple would give us a good start on this new path while we investigate what we and the community want feature wise and then select an implementation based on these requirements. However, if slf4-simple can't do the job of the old behavior when we might not have that option unfortunately. Or, possibly we could live with these deficiencies? I'll leave that to others working with that to decide. But if we have to decide on a more advanced implementation my choice would be logback. My choice is based on two things where one being a past experience where I developed an audit logging solution based on logback, where my research showed that log4j had so many deficiencies when it came to more advanced cases. log4j2 might be a different story with this fixed though, but I don't see any reason trying something else when there is proven option. Secondly, I have good confidence in Ceki
Re: Logging
Maybe you can copy over the index.html we can prevent the directory listing from showing up on our home page. On Dec 10, 2012, at 10:03 AM, Olivier Lamy ol...@apache.org wrote: http://markmail.org/message/mpgn4yshnt2qmdui 2012/12/10 Jason van Zyl ja...@tesla.io: Not sure what's happening but: http://maven.apache.org/developers/dependency-policies.html is not there. On Dec 10, 2012, at 3:25 AM, Olivier Lamy ol...@apache.org wrote: 2012/12/10 Hervé BOUTEMY herve.bout...@free.fr: Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit : I think it's time to stop patching SLF4J Simple. I have an inefficient fix for the embedding problem, but we're likely to run into issues concurrency with parallel builds and who knows what else. This will patch/change #5 and many hours of trying to get SLF4J Simple to work but I think we're pushing the simple implementation beyond its scope. So I'd just like to put in Logback and be done with it. There are at least three of us opposed to using a new logging framework, logging *implementation*, please, not framework: the framework is slf4j-api, on which our code will have much dependency. The logging implementation is far less invasive choice (even if not completely null). but I don't think there is anyone against using Logback. why this provocation? (should I say lack of respect for others opinion?) I honestly don't think there is any rational argument for not using Logback, so after doing all the SLF4J work and making a best effort to use SLF4J Simple I think it's pointless to pursue that path any longer and put in Logback. we'll need to wait for 3.1.1 and a vote to have a chance to stop tension about this: whatever choice is done, there will be some devs unhappy who will have to live with it notice I won't be able to reply for the next half day, my intent with this reply is just to avoid one more re-spin of a feeling that the vote won't happen and let Olivier once more jump on the case I just hope I won't have to read a lot of replies to this tonight when I'm back from work and loose my time carefully reading if anything new or interesting is written I have already explained my opinion. Folks think log4j2 is immature and/or don't have a community of various people. Furthermore it looks it's not anymore possible to use immature libraries in core (whereas it has been done for more important part: sisu or aether). But now that's not anymore possible... Well things evolve and POV can change that's the life BTW due to our policy [1] and if I correctly read license here [2] a vote is mandatory. (and don't ask me to start this vote :-) ). Cheers -- Olivier [1] http://maven.apache.org/developers/dependency-policies [2] http://logback.qos.ch/license.html Regards, Hervé On Dec 9, 2012, at 5:45 PM, Arnaud Héritier aherit...@gmail.com wrote: I'm a little bit lost too. Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk (for many - good - reasons) but the last bug discovered by Kristian can be solved only * by having a fix from slf4j (but it isn't sure that the patch makes sense - to be validated by Ceki) * or by using a more evolved impl like logback (or log4j ...). I think that everyone's will prefer the first solution if possible but if we cannot we'll have the question to select the impl. Do we need to vote ? Is there really a question logback vs log4j(2) ? Like I said in another thread I'll understand if the project decide to choose log4j2 even if it is young because we want to support another ASF initiative (And I'm sure we won't have to regret it, and we'll have a really good support from its team) but in a general case I would prefer to choose logback which is today the reference logging framework (I that case we need to have a PMC vote to accept an external component under EPL license http://maven.apache.org/developers/dependency-policies ?). What do we need (for 3.1.0) ? What do we do ? Arnaud On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar and...@hammar.net wrote: Not sure where to get into this thread, but I'd just like to add my perspective on this topic. For this first release I would prefer it to not include any of the more advanced slf4j implementations, like a few others have already also stated. Using simple would give us a good start on this new path while we investigate what we and the community want feature wise and then select an implementation based on these requirements. However, if slf4-simple can't do the job of the old behavior when we might not have that option unfortunately. Or, possibly we could live with these deficiencies? I'll leave that to others working with that to decide. But if we have to decide on a more advanced implementation my choice would be logback. My choice is based on two things where one being a past experience where I developed an audit logging solution based
Re: MNG-5406
I don't think we're in any dire rush. On Dec 10, 2012, at 11:02 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am on crutches (fractured two bones in my foot while running on wed) and away from my laptop. It will be tomorrow before I can try and dig this stuff out On Monday, 10 December 2012, Jason van Zyl wrote: I'll make the example plugins and then we can try it. Do you have a little snippet as an example? On Dec 10, 2012, at 5:15 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: On Sunday, 9 December 2012, Hervé BOUTEMY wrote: I just committed a starting point for MNG-5406: don't expose core's slf4j-api by default, add a plugin-descriptor option to expose this is a new field in plugin descriptor. I still don't know how to effectively use it in DefaultClassRealmManager.createPluginRealm() to avoid importing slf4j-api from parent: help appreciated. I still didn't create a Jira issue in plugin-tools to generate the field in plugin descriptor. What I know is that its configuration won't be done as an annotation in a goal/Mojo since it's a plugin-wide configuration, not at goal level. I was thinking a configuration option for m-p-p in the pom for the plugin, since that is where you are adding the dependencies, it makes sense to configure the treatment of those dependencies in the same file Regards, Hervé Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks
Re: Logging
John, Eight other projects at Apache use Logback. The whole of JBoss Tooling is EPL so Redhat doesn't appear to have any problems with the EPL. I don't think JBoss would ship a huge product entirely based on EPL if there were a problem. Oracle also now accepts EPL dependencies in their products. So what, exactly, is the potential problem? On Dec 10, 2012, at 3:14 PM, John Casey jdca...@commonjava.org wrote: On 12/9/12 7:50 PM, Jason van Zyl wrote: I think it's time to stop patching SLF4J Simple. I have an inefficient fix for the embedding problem, but we're likely to run into issues concurrency with parallel builds and who knows what else. This will patch/change #5 and many hours of trying to get SLF4J Simple to work but I think we're pushing the simple implementation beyond its scope. So I'd just like to put in Logback and be done with it. There are at least three of us opposed to using a new logging framework, but I don't think there is anyone against using Logback. I honestly don't think there is any rational argument for not using Logback, I guess m2e and related third-party projects are the things requiring these more evolved logging options. One rational argument against including logback is other third-party projects that wish to embed Maven but which have licensing conflicts with EPL. I had a conversation just the other day with the drools folks over this WRT Aether, where its EPL license was a potential problem for them. [1] In considering third-party integration, doesn't it make sense to try to stay clear of introducing licensing problems? Isn't that rational? [1] http://en.wikipedia.org/wiki/Eclipse_Public_License (see the sidebar) so after doing all the SLF4J work and making a best effort to use SLF4J Simple I think it's pointless to pursue that path any longer and put in Logback. On Dec 9, 2012, at 5:45 PM, Arnaud Héritier aherit...@gmail.com wrote: I'm a little bit lost too. Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk (for many - good - reasons) but the last bug discovered by Kristian can be solved only * by having a fix from slf4j (but it isn't sure that the patch makes sense - to be validated by Ceki) * or by using a more evolved impl like logback (or log4j ...). I think that everyone's will prefer the first solution if possible but if we cannot we'll have the question to select the impl. Do we need to vote ? Is there really a question logback vs log4j(2) ? Like I said in another thread I'll understand if the project decide to choose log4j2 even if it is young because we want to support another ASF initiative (And I'm sure we won't have to regret it, and we'll have a really good support from its team) but in a general case I would prefer to choose logback which is today the reference logging framework (I that case we need to have a PMC vote to accept an external component under EPL license http://maven.apache.org/developers/dependency-policies ?). What do we need (for 3.1.0) ? What do we do ? Arnaud On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar and...@hammar.net wrote: Not sure where to get into this thread, but I'd just like to add my perspective on this topic. For this first release I would prefer it to not include any of the more advanced slf4j implementations, like a few others have already also stated. Using simple would give us a good start on this new path while we investigate what we and the community want feature wise and then select an implementation based on these requirements. However, if slf4-simple can't do the job of the old behavior when we might not have that option unfortunately. Or, possibly we could live with these deficiencies? I'll leave that to others working with that to decide. But if we have to decide on a more advanced implementation my choice would be logback. My choice is based on two things where one being a past experience where I developed an audit logging solution based on logback, where my research showed that log4j had so many deficiencies when it came to more advanced cases. log4j2 might be a different story with this fixed though, but I don't see any reason trying something else when there is proven option. Secondly, I have good confidence in Ceki and that he will help us out should we need that. I'm not saying those working with log4j2 will not, it's just that I don't know their track record as I know Ceki's. But to repeat myself, going simple in the first release would be so much better. Then we could get our requirements after this first release and do a selection based on them rather than just a gut feeling. Although using slf4j as the API gives us the technical possibility of switching impl later on, I don't think we want that as we can probably expect some people do solutions expecting a specific impl (as we've seen in the Sonar plugin for example). /Anders On Sun, Dec 9, 2012 at 1:51
Re: Logging
It would be the default backend, people would not be using Logback APIs directly. The one place where it's convenient for use the use the Logback APIs is in the CLI where it's not possible to change the log levels without talking directly to the implementation. On Dec 10, 2012, at 3:40 PM, John Casey jdca...@commonjava.org wrote: Reading through the rest of the thread...is this for the default implementation we'll ship with maven, or are we talking about skipping the slf4j-api abstraction and using logback apis directly? If it's just the default backend, I'm not concerned at all. If we're forcing people to use logback, then to me that's a lot less attractive. On 12/10/12 2:34 PM, John Casey wrote: On 12/10/12 2:25 PM, Jason van Zyl wrote: John, Eight other projects at Apache use Logback. The whole of JBoss Tooling is EPL so Redhat doesn't appear to have any problems with the EPL. I don't think JBoss would ship a huge product entirely based on EPL if there were a problem. Oracle also now accepts EPL dependencies in their products. So what, exactly, is the potential problem? I'm not on the drools team, I was only trying to help them use the Maven / Aether APIs. Conan mentioned the EPL-ness of Aether as a potential problem for them, and was hoping to use Maven to avoid it until I told him that Maven itself is using Aether. His answer was that they would work around it by isolating the functionality into a separate module with different licensing (or something, I didn't get into the details with him). Either he's not clear on the license interactions, or there is an actual problem that will propagate these licensing complexities out to any GPL project embedding Maven. IANAL. I'm only relating a conversation that was specifically dealing with this issue. Increasingly, my work is with integrating Maven into other tools as well. Personally, I'd prefer something that keeps the licensing clean. AFAIK, different Red Hat projects have EPL, ASL, LGPL, and GPL licenses. I'm not sure how we deal with this internally, but it's a conversation that comes up periodically. I don't claim to know all the ins and outs, and I think it's not reasonable for someone outside the projects / products themselves to claim they do. I think it comes down to: Are the licenses compatible? If not, are we forcing people to make a decision about taking on extra licensing complexity in order to embed Maven? On Dec 10, 2012, at 3:14 PM, John Casey jdca...@commonjava.org wrote: On 12/9/12 7:50 PM, Jason van Zyl wrote: I think it's time to stop patching SLF4J Simple. I have an inefficient fix for the embedding problem, but we're likely to run into issues concurrency with parallel builds and who knows what else. This will patch/change #5 and many hours of trying to get SLF4J Simple to work but I think we're pushing the simple implementation beyond its scope. So I'd just like to put in Logback and be done with it. There are at least three of us opposed to using a new logging framework, but I don't think there is anyone against using Logback. I honestly don't think there is any rational argument for not using Logback, I guess m2e and related third-party projects are the things requiring these more evolved logging options. One rational argument against including logback is other third-party projects that wish to embed Maven but which have licensing conflicts with EPL. I had a conversation just the other day with the drools folks over this WRT Aether, where its EPL license was a potential problem for them. [1] In considering third-party integration, doesn't it make sense to try to stay clear of introducing licensing problems? Isn't that rational? [1] http://en.wikipedia.org/wiki/Eclipse_Public_License (see the sidebar) so after doing all the SLF4J work and making a best effort to use SLF4J Simple I think it's pointless to pursue that path any longer and put in Logback. On Dec 9, 2012, at 5:45 PM, Arnaud Héritier aherit...@gmail.com wrote: I'm a little bit lost too. Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk (for many - good - reasons) but the last bug discovered by Kristian can be solved only * by having a fix from slf4j (but it isn't sure that the patch makes sense - to be validated by Ceki) * or by using a more evolved impl like logback (or log4j ...). I think that everyone's will prefer the first solution if possible but if we cannot we'll have the question to select the impl. Do we need to vote ? Is there really a question logback vs log4j(2) ? Like I said in another thread I'll understand if the project decide to choose log4j2 even if it is young because we want to support another ASF initiative (And I'm sure we won't have to regret it, and we'll have a really good support from its team) but in a general case I would prefer to choose logback which is today the reference logging
Re: Logging
On Dec 10, 2012, at 3:46 PM, John Casey jdca...@commonjava.org wrote: On 12/10/12 2:42 PM, Jason van Zyl wrote: It would be the default backend, people would not be using Logback APIs directly. The one place where it's convenient for use the use the Logback APIs is in the CLI where it's not possible to change the log levels without talking directly to the implementation. IMO the CLI isn't usable from an embedding standpoint anyway, so it almost doesn't count (it's almost part of the distribution .zip). Yup, I was just pointing out that we do have to reach into its pocket to do some things. On Dec 10, 2012, at 3:40 PM, John Casey jdca...@commonjava.org wrote: Reading through the rest of the thread...is this for the default implementation we'll ship with maven, or are we talking about skipping the slf4j-api abstraction and using logback apis directly? If it's just the default backend, I'm not concerned at all. If we're forcing people to use logback, then to me that's a lot less attractive. On 12/10/12 2:34 PM, John Casey wrote: On 12/10/12 2:25 PM, Jason van Zyl wrote: John, Eight other projects at Apache use Logback. The whole of JBoss Tooling is EPL so Redhat doesn't appear to have any problems with the EPL. I don't think JBoss would ship a huge product entirely based on EPL if there were a problem. Oracle also now accepts EPL dependencies in their products. So what, exactly, is the potential problem? I'm not on the drools team, I was only trying to help them use the Maven / Aether APIs. Conan mentioned the EPL-ness of Aether as a potential problem for them, and was hoping to use Maven to avoid it until I told him that Maven itself is using Aether. His answer was that they would work around it by isolating the functionality into a separate module with different licensing (or something, I didn't get into the details with him). Either he's not clear on the license interactions, or there is an actual problem that will propagate these licensing complexities out to any GPL project embedding Maven. IANAL. I'm only relating a conversation that was specifically dealing with this issue. Increasingly, my work is with integrating Maven into other tools as well. Personally, I'd prefer something that keeps the licensing clean. AFAIK, different Red Hat projects have EPL, ASL, LGPL, and GPL licenses. I'm not sure how we deal with this internally, but it's a conversation that comes up periodically. I don't claim to know all the ins and outs, and I think it's not reasonable for someone outside the projects / products themselves to claim they do. I think it comes down to: Are the licenses compatible? If not, are we forcing people to make a decision about taking on extra licensing complexity in order to embed Maven? On Dec 10, 2012, at 3:14 PM, John Casey jdca...@commonjava.org wrote: On 12/9/12 7:50 PM, Jason van Zyl wrote: I think it's time to stop patching SLF4J Simple. I have an inefficient fix for the embedding problem, but we're likely to run into issues concurrency with parallel builds and who knows what else. This will patch/change #5 and many hours of trying to get SLF4J Simple to work but I think we're pushing the simple implementation beyond its scope. So I'd just like to put in Logback and be done with it. There are at least three of us opposed to using a new logging framework, but I don't think there is anyone against using Logback. I honestly don't think there is any rational argument for not using Logback, I guess m2e and related third-party projects are the things requiring these more evolved logging options. One rational argument against including logback is other third-party projects that wish to embed Maven but which have licensing conflicts with EPL. I had a conversation just the other day with the drools folks over this WRT Aether, where its EPL license was a potential problem for them. [1] In considering third-party integration, doesn't it make sense to try to stay clear of introducing licensing problems? Isn't that rational? [1] http://en.wikipedia.org/wiki/Eclipse_Public_License (see the sidebar) so after doing all the SLF4J work and making a best effort to use SLF4J Simple I think it's pointless to pursue that path any longer and put in Logback. On Dec 9, 2012, at 5:45 PM, Arnaud Héritier aherit...@gmail.com wrote: I'm a little bit lost too. Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk (for many - good - reasons) but the last bug discovered by Kristian can be solved only * by having a fix from slf4j (but it isn't sure that the patch makes sense - to be validated by Ceki) * or by using a more evolved impl like logback (or log4j ...). I think that everyone's will prefer the first solution if possible but if we cannot we'll have the question to select the impl. Do we need to vote ? Is there really a question logback vs log4j
Re: Process: choosing a logging back end
Then I will just ask the committers to help choose an implementation. I'll send out a separate thread. On Dec 10, 2012, at 2:44 PM, Benson Margulies bimargul...@gmail.com wrote: As an Apache project, we are called upon to make our decisions (*) by an open, public, consensus process. Choosing a logging back end is no different. Ideally, then, the community would reach a consensus. 'The Community' is not defined by any sharp boundary, but it includes at least all the committers. Given that this is a matter of taste, it is possible that everyone might agree that a simple majority vote amongst options would be less stressful than an attempt to send email until we all agree on an option. Of course, all decisions are matters of taste at some level, but this one strikes me as having a particularly strong flavor of 'chacun á son gout.' If the community decides that the right solution is an EPL-licensed component, then there's an additional step. The Maven PMC has adopted a policy that EPL dependencies require a PMC vote. However, if the PMC were presented with an up-or-down vote to add an EPL logging component which was the clear choice of the entire community, I would be stunned if the PMC voted 'no'. So, as I see it, the important decision is the open community decision. (*) except for a very few exceptions involving people. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Logback in Maven Core
Hi, I looked around a bit more today and I don't think SLF4J Simple is viable long term, I don't want to patch it anymore as I would have to do a day's work to make changes that keep the performance levels up, get it reviewed and released, and I honestly don't think it's worth it anymore. I would rather spend my time building out the plugin test cases and help to finish the classloader blocking of SLF4J. I don't mind spending time getting it all working but I don't want to waste my time on an implementation we're going to toss. After a conversation with the PMC it will require a vote to accept Logback which is EPL but I wanted to ask committers and interested users about using Logback. I believe Logback is the best choice as it's the most mature and battle tested implementation because once it goes in it's likely not ever to come out. Many of us are users and have integration experience with Logback and it's what I use everyday for logging in all my other projects and I've been a happy user for years. I see Logback as best of breed and widely adopted including 8 projects at Apache. There's no point in asking the PMC to vote on the acceptance of Logback if it's not acceptable by the community. If there are interested users I would really like to hear what you think because you're the ones who will have to live with the choice that is made. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: regression with finalName?
Can you easily tell in which version of Maven the behaviour changed?
I don't think inheriting this value is a bad per se, and if it's been like this
in all versions of Maven 3.x I think it's probably ok. If the behaviour
changed somewhere along the path of 3.x then that's probably not great.
On Dec 9, 2012, at 7:32 AM, Robert Scholte rfscho...@apache.org wrote:
Hi,
it looks like the behavior of the project.build.finalName has changed in a
multimodule-project.
With Maven-2.2.1 it is always ${project.artifactId}-${project.version} if you
don't specify it.
In Maven-3.0.4 its value is inherited from the parent.
I'd expect that the old behavior is the preferred one.
WDYT?
Robert
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
-
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
Re: Logging
I haven't looked at concurrency per se, but I see the IT for the event spy in parallel mode so if that doesn't account for it then it's not something I specifically checked. This is probably where the simple implementation would likely not be adequate. If you know off hand the ITs that are concurrency specific I'll look at them to make new ones that expand on them. On Dec 9, 2012, at 5:46 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I'm testing the fix now. BY reading code it would seem like this fix does eradicate any options for running parallel invocations with embedded instances ? Kristian 2012/12/9 Jason van Zyl ja...@tesla.io: Hi, I sorted out the ITs running in embedded mode and here's what I came up with. I patched SLF4J Simple to work around some static initialization that locked in the log level and the output stream. So the problem in the ITs is not that the output doesn't arrive in the individual files for each IT, but that all the output is going into the file for the first IT. The same sort of problem arises where an IT expects a particular log level based error. The level is locked in for the suite that's run and can't be changed. The patch I made I have to talk to Ceki about as it's not terribly efficient but it works[1]. I also brought the Logback branch up to date and it passes all the ITs. I think I'm at the point where it might make more sense to use a Logback as we're getting into non-simple use cases. I can get Ceki to look at my changes and cut a release if suitablle, but honestly at this point I propose we integrate Logback. I will put the branch of the grid tomorrow as I'm not sure what's going on with the CI builds for the ITs as they all seem to be misbehaving. [1]: https://github.com/jvanzyl/slf4j/commit/aa4b4545f59f84ae9f3122cc0311745ba6b3008e Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Re: Logging
I agree. I don't believe it's reasonable path to pick an immature library for the core given the existence of Logback. Arnaud, I believe you felt the same way? I honestly gave SLF4J Simple a good run and pushed it with Ceki to make it do more than originally intended but I don't think it makes sense to push anymore. If other committers have an opinion let's please get this sorted out. On Dec 9, 2012, at 5:52 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: 2012/12/9 Olivier Lamy ol...@apache.org: Perso I'm fine using log4j2. I use the branch I pushed for some weeks now and I'm happy. Log4j2 has quickly added a feature I needed and release it. Furthermore I'm fine working with an Apache community in case of any issue we could have. I'm not entirely sure I follow where this discussion is actually going, but I'm firmly opposed to including a brand new logging framework as default in m3. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
