Re: Maven Developer Hangout
On 2014-07-07, 1:56, Mark Derricutt wrote: That would in part align things with Aether's somewhat annoying/retarded behaviour of saying oh I see com.acme:special tool:1.0-alpha-1 but it came from repo-1, not repo-2 - so suck it up - I can't resolve this.. I can understand the idea behind this - two artefacts from two different repositories _may_ share the same GAV and yet be totally different, but I find that to be so rare that that I probably never want this to not resolve ( that causes lots of annoying issues with using a mirror, and having to temporarily disable said mirror ). I don't think this has much/anything to do with the same GAV coming from different remote URLs. The project does not have access to repo-1 and Maven does not know if repo-2 has the artifact. Without this check project may get access to artifacts that simply happen to be cached locally during some prior build, which I rather strongly believe is a bad thing. -- Regards, Igor I could see this change also breaking under mirrors, or maybe that's just when using mirror:* On 5 Jul 2014, at 4:56, Robert Scholte wrote: To me it would make sense if you could add a reference to the repository per dependency, like dependency groupIdcom.acme/groupId artifactIdspecialtool/artifactId version1.0-alpha-1/version repositoryIdacme-store/repositoryId !-- only look in this repo, I know it's not in Central -- /dependency - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven Developer Hangout
Here's the link for this week: https://plus.google.com/u/0/b/113247990055413254822/events/c0kc3ecm0sndjj8evs7i1ijnk0g I'll have a follow up on the POM Evolved proposal and I'd like to talk about how to test all our plugins in preparation against the latest version of Maven so we can start seeing all the deprecation in core. As per usual the floor is open to other topics. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
Re: Maven Developer Hangout
Personally, I’ve always wondered if the repository entries should have an includes and excludes tags to say this repository should only be searched for these artifacts (like org.apache.*:*). Should help speed the builds by not looking at every repository for every artifact when we know they are in central. Dan On Jul 4, 2014, at 12:56 PM, Robert Scholte rfscho...@apache.org wrote: In addition to our hangout session: isn't it weird that for a dependency Maven can go over all the repositories, even though when an extra repository is added to the pom.xml, the developer knows exactly which dependencies should make use of that repository. To me it would make sense if you could add a reference to the repository per dependency, like dependency groupIdcom.acme/groupId artifactIdspecialtool/artifactId version1.0-alpha-1/version repositoryIdacme-store/repositoryId !-- only look in this repo, I know it's not in Central -- /dependency Robert Op Thu, 03 Jul 2014 00:37:17 +0200 schreef Mark Derricutt m...@talios.com: On 3 Jul 2014, at 6:25, Robert Scholte wrote: This is probably more than enough for tomorrow. A discussion on a merits and flaws of repositories (when combined with mirrors) is also warranted after some previous discussion on the list. Mark - 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Developer Hangout
Hi, +1 for Daniel Kulp's idea. Furthermore, I have the feeling that adding the option of repository/ per artifact is bound to lead to headaches. On the other hand, if you could specify groupId includes/excludes for repositories, things could be much better in terms of resolution times. I frankly think that this should all be the remote repository's job in the first place (and that people should have one). Otherwise we'll have have to have two different places where this is handled, making things more complicated to track later on. This is why artifact routing rules exist in repository managers. Martin On Mon, Jul 7, 2014 at 2:45 PM, Daniel Kulp dk...@apache.org wrote: Personally, I’ve always wondered if the repository entries should have an includes and excludes tags to say this repository should only be searched for these artifacts (like org.apache.*:*). Should help speed the builds by not looking at every repository for every artifact when we know they are in central. Dan On Jul 4, 2014, at 12:56 PM, Robert Scholte rfscho...@apache.org wrote: In addition to our hangout session: isn't it weird that for a dependency Maven can go over all the repositories, even though when an extra repository is added to the pom.xml, the developer knows exactly which dependencies should make use of that repository. To me it would make sense if you could add a reference to the repository per dependency, like dependency groupIdcom.acme/groupId artifactIdspecialtool/artifactId version1.0-alpha-1/version repositoryIdacme-store/repositoryId !-- only look in this repo, I know it's not in Central -- /dependency Robert Op Thu, 03 Jul 2014 00:37:17 +0200 schreef Mark Derricutt m...@talios.com: On 3 Jul 2014, at 6:25, Robert Scholte wrote: This is probably more than enough for tomorrow. A discussion on a merits and flaws of repositories (when combined with mirrors) is also warranted after some previous discussion on the list. Mark - 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Developer Hangout
Yup, this is essentially what routing rules are in Nexus. Would likely make sense to move this logic into Maven to speed up lookups. I also think trying to have each dependency mark where it comes from as cumbersome. On Jul 7, 2014, at 9:45 AM, Daniel Kulp dk...@apache.org wrote: Personally, I’ve always wondered if the repository entries should have an includes and excludes tags to say this repository should only be searched for these artifacts (like org.apache.*:*). Should help speed the builds by not looking at every repository for every artifact when we know they are in central. Dan On Jul 4, 2014, at 12:56 PM, Robert Scholte rfscho...@apache.org wrote: In addition to our hangout session: isn't it weird that for a dependency Maven can go over all the repositories, even though when an extra repository is added to the pom.xml, the developer knows exactly which dependencies should make use of that repository. To me it would make sense if you could add a reference to the repository per dependency, like dependency groupIdcom.acme/groupId artifactIdspecialtool/artifactId version1.0-alpha-1/version repositoryIdacme-store/repositoryId !-- only look in this repo, I know it's not in Central -- /dependency Robert Op Thu, 03 Jul 2014 00:37:17 +0200 schreef Mark Derricutt m...@talios.com: On 3 Jul 2014, at 6:25, Robert Scholte wrote: This is probably more than enough for tomorrow. A discussion on a merits and flaws of repositories (when combined with mirrors) is also warranted after some previous discussion on the list. Mark - 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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: Maven Developer Hangout
I agree with anyone/everyone who says we should get rid of the idea of a local repository. It should just be looked at as a local remote repo with some default intermediary repository manager built-in to Maven. Jason, is that what you're referring to? Cheers, Paul On Mon, Jul 7, 2014 at 9:31 AM, Jason van Zyl ja...@takari.io wrote: Yup, this is essentially what routing rules are in Nexus. Would likely make sense to move this logic into Maven to speed up lookups. I also think trying to have each dependency mark where it comes from as cumbersome. On Jul 7, 2014, at 9:45 AM, Daniel Kulp dk...@apache.org wrote: Personally, I’ve always wondered if the repository entries should have an includes and excludes tags to say this repository should only be searched for these artifacts (like org.apache.*:*). Should help speed the builds by not looking at every repository for every artifact when we know they are in central. Dan On Jul 4, 2014, at 12:56 PM, Robert Scholte rfscho...@apache.org wrote: In addition to our hangout session: isn't it weird that for a dependency Maven can go over all the repositories, even though when an extra repository is added to the pom.xml, the developer knows exactly which dependencies should make use of that repository. To me it would make sense if you could add a reference to the repository per dependency, like dependency groupIdcom.acme/groupId artifactIdspecialtool/artifactId version1.0-alpha-1/version repositoryIdacme-store/repositoryId !-- only look in this repo, I know it's not in Central -- /dependency Robert Op Thu, 03 Jul 2014 00:37:17 +0200 schreef Mark Derricutt m...@talios.com: On 3 Jul 2014, at 6:25, Robert Scholte wrote: This is probably more than enough for tomorrow. A discussion on a merits and flaws of repositories (when combined with mirrors) is also warranted after some previous discussion on the list. Mark - 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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: Maven Developer Hangout
Hi, @Paul: This would also have downsides like having to bind yourself to a process where you need to download the remote repository's index at least once. These are usually not too small... If I recall correctly, Maven Central's index was something like 100 MB in .gz. (I'm talking off the top of my head, but I did some recent work on the maven-indexer and downloading the index from Central in order to run some tests took *a while* and we wouldn't want people to start saing: Oh, Maven was this slow build tool (had to resolve a million dependencies) and now it's even slower. We should switch to some-next-cool-build-tool-goes-here) (I'm referring to Maven as slow not because it is, but because a lot of people have the feeling it takes ages to build some larger projects due to the resolution of dependencies). You will also need to update this local index on a regular basis... Once a day at the very least. I'm not quite convinced this would be accepted well by everyone. There could also be an option where dependencies could be resolved on a mixed basis -- if you have an index, use/update it, if an option is specified; ignore it, if the option is not specified... I'm not saying the current model is the best, I'm just trying to illustrate the downsides of such a switch. Kind regards, Martin On Mon, Jul 7, 2014 at 3:35 PM, Paul Benedict pbened...@apache.org wrote: I agree with anyone/everyone who says we should get rid of the idea of a local repository. It should just be looked at as a local remote repo with some default intermediary repository manager built-in to Maven. Jason, is that what you're referring to? Cheers, Paul On Mon, Jul 7, 2014 at 9:31 AM, Jason van Zyl ja...@takari.io wrote: Yup, this is essentially what routing rules are in Nexus. Would likely make sense to move this logic into Maven to speed up lookups. I also think trying to have each dependency mark where it comes from as cumbersome. On Jul 7, 2014, at 9:45 AM, Daniel Kulp dk...@apache.org wrote: Personally, I’ve always wondered if the repository entries should have an includes and excludes tags to say this repository should only be searched for these artifacts (like org.apache.*:*). Should help speed the builds by not looking at every repository for every artifact when we know they are in central. Dan On Jul 4, 2014, at 12:56 PM, Robert Scholte rfscho...@apache.org wrote: In addition to our hangout session: isn't it weird that for a dependency Maven can go over all the repositories, even though when an extra repository is added to the pom.xml, the developer knows exactly which dependencies should make use of that repository. To me it would make sense if you could add a reference to the repository per dependency, like dependency groupIdcom.acme/groupId artifactIdspecialtool/artifactId version1.0-alpha-1/version repositoryIdacme-store/repositoryId !-- only look in this repo, I know it's not in Central -- /dependency Robert Op Thu, 03 Jul 2014 00:37:17 +0200 schreef Mark Derricutt m...@talios.com: On 3 Jul 2014, at 6:25, Robert Scholte wrote: This is probably more than enough for tomorrow. A discussion on a merits and flaws of repositories (when combined with mirrors) is also warranted after some previous discussion on the list. Mark - 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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: Maven Developer Hangout
IfIAmNotLocalNexusAdminlocal-repositories are always the first repositories to be searched IfIAmLocalNexusAdminthen promote to local nexus and search local nexus..local nexus repo will be the first searched repo then central then the plethora of maven mirrors I like the idea of package affinity identified in repositories in pom.xml: package org.fubar has affinity to fubar repository (presumably at http://www.fubar.org) package org.apache.struts2 has affinity to main apache repository (presumably at repo http://www.eu.apache.org/dist) package org.apache.maven has affinity to codehaus repository (presumably at repo http://dist.codehaus.org) repositoriesrepository idcodehaus/id nameCodehaus Release Repo/name urlhttp://dist.codehaus.org//url package-affinityorg.apache.maven.*/package-affinity/repository? Martin- Date: Mon, 7 Jul 2014 09:35:31 -0500 Subject: Re: Maven Developer Hangout From: pbened...@apache.org To: dev@maven.apache.org I agree with anyone/everyone who says we should get rid of the idea of a local repository. It should just be looked at as a local remote repo with some default intermediary repository manager built-in to Maven. Jason, is that what you're referring to? Cheers, Paul On Mon, Jul 7, 2014 at 9:31 AM, Jason van Zyl ja...@takari.io wrote: Yup, this is essentially what routing rules are in Nexus. Would likely make sense to move this logic into Maven to speed up lookups. I also think trying to have each dependency mark where it comes from as cumbersome. On Jul 7, 2014, at 9:45 AM, Daniel Kulp dk...@apache.org wrote: Personally, I’ve always wondered if the repository entries should have an includes and excludes tags to say this repository should only be searched for these artifacts (like org.apache.*:*). Should help speed the builds by not looking at every repository for every artifact when we know they are in central. Dan On Jul 4, 2014, at 12:56 PM, Robert Scholte rfscho...@apache.org wrote: In addition to our hangout session: isn't it weird that for a dependency Maven can go over all the repositories, even though when an extra repository is added to the pom.xml, the developer knows exactly which dependencies should make use of that repository. To me it would make sense if you could add a reference to the repository per dependency, like dependency groupIdcom.acme/groupId artifactIdspecialtool/artifactId version1.0-alpha-1/version repositoryIdacme-store/repositoryId !-- only look in this repo, I know it's not in Central -- /dependency Robert Op Thu, 03 Jul 2014 00:37:17 +0200 schreef Mark Derricutt m...@talios.com: On 3 Jul 2014, at 6:25, Robert Scholte wrote: This is probably more than enough for tomorrow. A discussion on a merits and flaws of repositories (when combined with mirrors) is also warranted after some previous discussion on the list. Mark - 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.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, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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: [VOTE] Release Apache Maven Site Plugin version 3.4
-1 ... non-binding; site:run fails with: https://gist.github.com/jieryn/a8dc02b2e6a43d89cd1c On Thu, Jul 3, 2014 at 7:00 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Hi, We solved 13 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=19228 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repo: http://repository.apache.org/content/repositories/maven-1037/ http://repository.apache.org/content/repositories/maven-1037/org/apache/maven/plugins/maven-site-plugin/3.4/maven-site-plugin-3.4-source-release.zip Source release checksum(s): maven-site-plugin-3.4-source-release.zip sha1: 3a8ee1512638bd667ceb9756c564a56730e9391e Staging site: http://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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
[CANCELLED] Re: [VOTE] Release Apache Maven Site Plugin version 3.4
ok, release cancelled the (stupid) problem is fixed, I'll redo the release Regards, Hervé Le lundi 7 juillet 2014 12:26:52 jieryn a écrit : -1 ... non-binding; site:run fails with: https://gist.github.com/jieryn/a8dc02b2e6a43d89cd1c On Thu, Jul 3, 2014 at 7:00 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Hi, We solved 13 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName =Htmlversion=19228 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146s tatus=1 Staging repo: http://repository.apache.org/content/repositories/maven-1037/ http://repository.apache.org/content/repositories/maven-1037/org/apache/ma ven/plugins/maven-site-plugin/3.4/maven-site-plugin-3.4-source-release.zip Source release checksum(s): maven-site-plugin-3.4-source-release.zip sha1: 3a8ee1512638bd667ceb9756c564a56730e9391e Staging site: http://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Apache Maven Site Plugin version 3.4 (take 2)
Hi, We solved 13 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=19228 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repo: http://repository.apache.org/content/repositories/maven-1038/ http://repository.apache.org/content/repositories/maven-1038/org/apache/maven/plugins/maven-site-plugin/3.4/maven-site-plugin-3.4-source-release.zip Source release checksum(s): maven-site-plugin-3.4-source-release.zip sha1: 1829a518c037334b4fd6bde40b33a34344ff1af6 Staging site: http://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Site Plugin version 3.4 (take 2)
+1 2014-07-07 21:24 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr: Hi, We solved 13 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=19228 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repo: http://repository.apache.org/content/repositories/maven-1038/ http://repository.apache.org/content/repositories/maven-1038/org/apache/maven/plugins/maven-site-plugin/3.4/maven-site-plugin-3.4-source-release.zip Source release checksum(s): maven-site-plugin-3.4-source-release.zip sha1: 1829a518c037334b4fd6bde40b33a34344ff1af6 Staging site: http://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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