Re: Central repository in settings.xml
It could be better but far from perfect. Few users are reading this file and are using it to create their own. I think they are often copying it from the page you pointed. There are several annoying things about settings from my point of view but we won't be able to change before a 3.x : - We cannot use properties in mirror url (if we want to switch between several mirrors with different profiles) - We don't have inheritence or mix-in capacity to share some part of them and to split env related settings (repo, mirrors, ..) from personal settings (credentials) Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net On Tue, Apr 27, 2010 at 2:16 AM, Brian Fox bri...@infinity.nu wrote: I assume you want to make it easier for people to get the correct settings? Moving it from the super pom could have unexpected side effects, but what if we put the default boiler plate[1] configuration for that into the default settings.xml commented out? I think this would solve the main visibility problem without affecting runtime. [1] http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html#ex-maven-nexus-simple On Mon, Apr 26, 2010 at 6:41 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Paul Gier wrote: Would there be any problems if the central repo definition was moved out of the Maven internals and into the default settings.xml [1]? I assume you refer to the global settings file shipped inside the Maven installation directory. The one issue I know about is that embedders of Maven like M2E don't have a CLI-style installation directory and hence no global settings file. Not impossible to solve but it needs to be considered. Benjamin - 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
[M3] regression: M3 warns because of parent POM
Hi, M3 complains now if the referenced parent of a POM is not in the parent directory: === % = $ mvn validate [INFO] Scanning for projects... [INFO] snapshot com.scalaris.buildsystem.maven2:master:SNAPSHOT: checking for updates from scalaris-repo-snapshot [WARNING] [WARNING] Some problems were encountered while building the effective model for com.scalaris.commons:scalaris-commons-lang:jar:2.2.11-SNAPSHOT [WARNING] 'parent.relativePath' of POM com.scalaris.commons:scalaris- commons-lang:2.2.11-SNAPSHOT (/home/jos/work/internal/commons/lang/pom.xml) points at com.scalaris.commons:builder instead of com.scalaris.buildsystem.maven2:master, please verify your project structure @ [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING] === % = This is the standard case using a company wide POM that defines e.g. the version of plugins and dependencies. There is simply no relative path to the parent POM in use (and never will be). The POM in the parent directory is only used to build several components at once and has no further relevance. Therefore is this warning absolutely useless. Moreover, Maven itself uses this mechanism e.g. for the common Apache (and Maven) parent(s). Dropping this functionality - as the warning indicates - would require that all Apache projects using Maven (and this parent) have to reside in a physical directory tree - which is obviously nonsense. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven performance
Hi guys, it's not the first time I complain about Maven performance, but it seems M3 is heading the right direction. Yet, still not on the 2.0.x level: % = $ MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=128m mvn-2.0 eclipse:eclipse Apache Maven 2.0.11 Java version: 1.6.0_20 Java home: /opt/sun-jdk-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-gentoo-r7 arch: i386 Family: unix snip [INFO] Total time: 2 minutes 46 seconds [INFO] Finished at: Tue Apr 27 12:06:49 CEST 2010 [INFO] Final Memory: 362M/573M $ MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=128m mvn-2.2 eclipse:eclipse Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /opt/sun-jdk-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-gentoo-r7 arch: i386 Family: unix snip [INFO] Total time: 6 minutes 46 seconds [INFO] Finished at: Tue Apr 27 11:31:13 CEST 2010 [INFO] Final Memory: 434M/682M $ MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=128m mvn-3.0 eclipse:eclipse Apache Maven 3.0-beta-1 (r935667; 2010-04-19 19:00:39+0200) Java version: 1.6.0_20 Java home: /opt/sun-jdk-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-gentoo-r7 arch: i386 Family: unix snip [INFO] Total time: 4:02.127s [INFO] Finished at: Tue Apr 27 12:02:12 CEST 2010 [INFO] Final Memory: 344M/443M % = The build processes ~400 projects. The version output is somewhat faked (esp. for M2.0), it's just to give you the details of the environment. M3 is way better than M2.2, but not (yet ?) at the level of 2.0.11 (and I bet 2.0.9 will be a lot faster again). Also have a look at the memory footprint. Since M2.2 it is quite no longer possible for me to build all the stuff at once. M3 looks very promising here. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [M3] regression: M3 warns because of parent POM
Jörg Schaible wrote: M3 complains now if the referenced parent of a POM is not in the parent directory: [WARNING] 'parent.relativePath' of POM com.scalaris.commons:scalaris- commons-lang:2.2.11-SNAPSHOT (/home/jos/work/internal/commons/lang/pom.xml) points at com.scalaris.commons:builder instead of com.scalaris.buildsystem.maven2:master, please verify your project structure Reading the release notes, you will notice that this is not a regression but an intentional change (MNG-4619). There is simply no relative path to the parent POM in use (and never will be). Then simple set relativePath/ for the parent element and be fine. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Maven performance
Hi Do the same test with mvn org.twdata.maven:maven-cli-plugin:execute-phase - A regular compile with large projects cuts down the time drastically Hermod -Original Message- From: Jörg Schaible [mailto:joerg.schai...@gmx.de] Sent: Tuesday, April 27, 2010 2:11 PM To: dev@maven.apache.org Subject: Maven performance Hi guys, it's not the first time I complain about Maven performance, but it seems M3 is heading the right direction. Yet, still not on the 2.0.x level: % = $ MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=128m mvn-2.0 eclipse:eclipse Apache Maven 2.0.11 Java version: 1.6.0_20 Java home: /opt/sun-jdk-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-gentoo-r7 arch: i386 Family: unix snip [INFO] Total time: 2 minutes 46 seconds [INFO] Finished at: Tue Apr 27 12:06:49 CEST 2010 [INFO] Final Memory: 362M/573M $ MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=128m mvn-2.2 eclipse:eclipse Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /opt/sun-jdk-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-gentoo-r7 arch: i386 Family: unix snip [INFO] Total time: 6 minutes 46 seconds [INFO] Finished at: Tue Apr 27 11:31:13 CEST 2010 [INFO] Final Memory: 434M/682M $ MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=128m mvn-3.0 eclipse:eclipse Apache Maven 3.0-beta-1 (r935667; 2010-04-19 19:00:39+0200) Java version: 1.6.0_20 Java home: /opt/sun-jdk-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-gentoo-r7 arch: i386 Family: unix snip [INFO] Total time: 4:02.127s [INFO] Finished at: Tue Apr 27 12:02:12 CEST 2010 [INFO] Final Memory: 344M/443M % = The build processes ~400 projects. The version output is somewhat faked (esp. for M2.0), it's just to give you the details of the environment. M3 is way better than M2.2, but not (yet ?) at the level of 2.0.11 (and I bet 2.0.9 will be a lot faster again). Also have a look at the memory footprint. Since M2.2 it is quite no longer possible for me to build all the stuff at once. M3 looks very promising here. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [M3] regression: M3 warns because of parent POM
On Tue, Apr 27, 2010 at 2:13 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Jörg Schaible wrote: M3 complains now if the referenced parent of a POM is not in the parent directory: [WARNING] 'parent.relativePath' of POM com.scalaris.commons:scalaris- commons-lang:2.2.11-SNAPSHOT (/home/jos/work/internal/commons/lang/pom.xml) points at com.scalaris.commons:builder instead of com.scalaris.buildsystem.maven2:master, please verify your project structure Reading the release notes, you will notice that this is not a regression but an intentional change (MNG-4619). There is simply no relative path to the parent POM in use (and never will be). Then simple set relativePath/ for the parent element and be fine. that's a rather hidden gem. AFAIK so far empty elements never had a meaning in the pom file. Can we have this documented in the xsd for the relativePath element? Milos Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [M3] regression: M3 warns because of parent POM
Hi Benjamin, Benjamin Bentmann wrote: Jörg Schaible wrote: M3 complains now if the referenced parent of a POM is not in the parent directory: [WARNING] 'parent.relativePath' of POM com.scalaris.commons:scalaris- commons-lang:2.2.11-SNAPSHOT (/home/jos/work/internal/commons/lang/pom.xml) points at com.scalaris.commons:builder instead of com.scalaris.buildsystem.maven2:master, please verify your project structure Reading the release notes, you will notice that this is not a regression but an intentional change (MNG-4619). There is simply no relative path to the parent POM in use (and never will be). Then simple set relativePath/ for the parent element and be fine. Thanks. Sorry for not RTFM first. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [M3] regression: M3 warns because of parent POM
Milos Kleint wrote: Can we have this documented in the xsd for the relativePath element? Done. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven performance
I never had results like you. I always noticed improvements between 2.02.23.0 I'll do some tests. Where I have problems for now, it is on some OS. While with OSes like Suse,OpensSolaris,Windows 7 we have good perfs results for the build, on linux servers like ubuntu, fedora , ... we have results 4x slower. We are studying these problems and if we succeed to explain the issue we'll share it here (I suppose that many of us are using linux for continuous integration servers) Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net On Tue, Apr 27, 2010 at 2:10 PM, Jörg Schaible joerg.schai...@gmx.dewrote: Hi guys, it's not the first time I complain about Maven performance, but it seems M3 is heading the right direction. Yet, still not on the 2.0.x level: % = $ MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=128m mvn-2.0 eclipse:eclipse Apache Maven 2.0.11 Java version: 1.6.0_20 Java home: /opt/sun-jdk-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-gentoo-r7 arch: i386 Family: unix snip [INFO] Total time: 2 minutes 46 seconds [INFO] Finished at: Tue Apr 27 12:06:49 CEST 2010 [INFO] Final Memory: 362M/573M $ MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=128m mvn-2.2 eclipse:eclipse Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /opt/sun-jdk-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-gentoo-r7 arch: i386 Family: unix snip [INFO] Total time: 6 minutes 46 seconds [INFO] Finished at: Tue Apr 27 11:31:13 CEST 2010 [INFO] Final Memory: 434M/682M $ MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=128m mvn-3.0 eclipse:eclipse Apache Maven 3.0-beta-1 (r935667; 2010-04-19 19:00:39+0200) Java version: 1.6.0_20 Java home: /opt/sun-jdk-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-gentoo-r7 arch: i386 Family: unix snip [INFO] Total time: 4:02.127s [INFO] Finished at: Tue Apr 27 12:02:12 CEST 2010 [INFO] Final Memory: 344M/443M % = The build processes ~400 projects. The version output is somewhat faked (esp. for M2.0), it's just to give you the details of the environment. M3 is way better than M2.2, but not (yet ?) at the level of 2.0.11 (and I bet 2.0.9 will be a lot faster again). Also have a look at the memory footprint. Since M2.2 it is quite no longer possible for me to build all the stuff at once. M3 looks very promising here. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven performance
Jörg, If you are going to use the maven-eclipse-plugin as your benchmark I think it's going to be very hard to pin point where the bottleneck is. It's a little universe unto itself. Could be the shared components, resolution code, the plugin itself. I see vast improvements in speed in Maven 3.x. I don't think you can use the maven-eclipse-plugin as the basis for measuring improvement. For example there is behavior in Maven 3.x that is more correct which may contribute to some slow down and that we're just going to have to live with. As one user suggested it may be wise to provide execution timings for the core and individual plugins and phases. For example if you found that Maven's execution time remained constant over all versions of Maven where it was the maven-eclipse-plugin that varied then we know it's an interaction problem with the plugin and you can go from there. Or use a profiler and find out where the actual problem is and tell us. We've done lots of profiling to get Maven 3.x and M2E running faster. But gigantic plugins like m-e-p and the assembler plugin will probably have problems entirely their own. On Apr 27, 2010, at 8:10 AM, Jörg Schaible wrote: Hi guys, it's not the first time I complain about Maven performance, but it seems M3 is heading the right direction. Yet, still not on the 2.0.x level: % = $ MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=128m mvn-2.0 eclipse:eclipse Apache Maven 2.0.11 Java version: 1.6.0_20 Java home: /opt/sun-jdk-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-gentoo-r7 arch: i386 Family: unix snip [INFO] Total time: 2 minutes 46 seconds [INFO] Finished at: Tue Apr 27 12:06:49 CEST 2010 [INFO] Final Memory: 362M/573M $ MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=128m mvn-2.2 eclipse:eclipse Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /opt/sun-jdk-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-gentoo-r7 arch: i386 Family: unix snip [INFO] Total time: 6 minutes 46 seconds [INFO] Finished at: Tue Apr 27 11:31:13 CEST 2010 [INFO] Final Memory: 434M/682M $ MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=128m mvn-3.0 eclipse:eclipse Apache Maven 3.0-beta-1 (r935667; 2010-04-19 19:00:39+0200) Java version: 1.6.0_20 Java home: /opt/sun-jdk-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-gentoo-r7 arch: i386 Family: unix snip [INFO] Total time: 4:02.127s [INFO] Finished at: Tue Apr 27 12:02:12 CEST 2010 [INFO] Final Memory: 344M/443M % = The build processes ~400 projects. The version output is somewhat faked (esp. for M2.0), it's just to give you the details of the environment. M3 is way better than M2.2, but not (yet ?) at the level of 2.0.11 (and I bet 2.0.9 will be a lot faster again). Also have a look at the memory footprint. Since M2.2 it is quite no longer possible for me to build all the stuff at once. M3 looks very promising here. - Jörg - 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 - We know what we are, but know not what we may be. -- Shakespeare
Re: Central repository in settings.xml
2010/4/27 Arnaud Héritier aherit...@gmail.com: It could be better but far from perfect. Few users are reading this file and are using it to create their own. I think they are often copying it from the page you pointed. There are several annoying things about settings from my point of view but we won't be able to change before a 3.x : - We cannot use properties in mirror url (if we want to switch between several mirrors with different profiles) - We don't have inheritence or mix-in capacity to share some part of them and to split env related settings (repo, mirrors, ..) from personal settings (credentials) I think mirrors should be able to be defined inside of (settings) profiles. That would make it easier to deal with moving from location to location. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Central repository in settings.xml
I think mirrors should be able to be defined inside of (settings) profiles. That would make it easier to deal with moving from location to location. +1 If this isn't yet in our backlog for 3.x we can add it.
2.2.1-3.x plugin migration
Hello Maven community, I have written a maven plugin which uses the 2.2.1 api to download artifacts. I see the api's between 2.x and 3.x have changed for plugins like this. Actually, it looks like I use 2 parts of the old api. 1) Downloading artifacts using these deprecated classes. org.apache.maven.artifact.factory.ArtifactFactory; org.apache.maven.artifact.metadata.ArtifactMetadataSource; org.apache.maven.artifact.repository.ArtifactRepositoryFactory; org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout; org.apache.maven.artifact.resolver.ArtifactResolver; 2) Getting the base directory of the project which is executing the plugin. org.apache.maven.project.MavenProject; Question) Can somebody point me towards the classes in 3.x which I should be migrating towards to achieve this functionality? Cheers, Harsha
Re: Central repository in settings.xml
Arnaud, I run into situations where one project demands a complete different settings.xml than another. Assume you have a book project that deals with a separate repo manager and set of credentials vs. a tiny codehaus project with a separate repo man vs. an internal corporate project with different settings. I can't be the only one who is constantly having to either pass in the -s option or just swap out default settings.xml. Has anyone given any thought to the idea of different settings.xml files which would be activated by groupId? Assume I had three files: A. settings.xml B. settings-org-codehaus.xml C. settings-com-example.xml The idea would be that if I were working on a project with a groupId matching org.codehaus.** Maven would interpolate A - B, and if I were working on a project with a groupId matching com.example.** Maven would interpolate A - C. That and I'm sick of having to explain mirror configuration. I wish it were as simple as repomanhttp://localhost:8081/whatever/repoman, but I guess this all has to wait. Ok, I take that back, I really wish it were as simple as Maven sensing the presence of a repository manager via a multicast ping, but I'm fully prepared for someone to tell me that this is the worst idea anyone has ever come up with on this list. 2010/4/27 Arnaud Héritier aherit...@gmail.com: It could be better but far from perfect. Few users are reading this file and are using it to create their own. I think they are often copying it from the page you pointed. There are several annoying things about settings from my point of view but we won't be able to change before a 3.x : - We cannot use properties in mirror url (if we want to switch between several mirrors with different profiles) - We don't have inheritence or mix-in capacity to share some part of them and to split env related settings (repo, mirrors, ..) from personal settings (credentials) Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net On Tue, Apr 27, 2010 at 2:16 AM, Brian Fox bri...@infinity.nu wrote: I assume you want to make it easier for people to get the correct settings? Moving it from the super pom could have unexpected side effects, but what if we put the default boiler plate[1] configuration for that into the default settings.xml commented out? I think this would solve the main visibility problem without affecting runtime. [1] http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html#ex-maven-nexus-simple On Mon, Apr 26, 2010 at 6:41 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Paul Gier wrote: Would there be any problems if the central repo definition was moved out of the Maven internals and into the default settings.xml [1]? I assume you refer to the global settings file shipped inside the Maven installation directory. The one issue I know about is that embedders of Maven like M2E don't have a CLI-style installation directory and hence no global settings file. Not impossible to solve but it needs to be considered. Benjamin - 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
Re: 2.2.1-3.x plugin migration
Harsha Sri-Narayana wrote: org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout; This is an implementation class/component, your plugin should not refer to this directly but rather use something like /** @component roleHint=default */ private ArtifactRepositoryLayout defaultLayout; to get hold of it via the interface. Question) Can somebody point me towards the classes in 3.x which I should be migrating towards to achieve this functionality? The classes you mentioned should still work in Maven 3.x, if not, please give more details about the actual problems. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Central repository in settings.xml
I think you can already do what you are asking with a repo manager. If you need to communicate to 3 different repos, then those repos should all be controlled through the repo manager. One of the repos could be public (ie: like an org) and another could be private (like a com). Your settings.xml file would then just point to the one repo manager which grouped the three repos into a single group. Nexus has a routing feature [1] which I believe (if I understand your needs correctly) will allow you to do what your asking for. [1] http://www.sonatype.com/books/nexus-book/reference/config-sect-managing-routes.html -Original Message- From: Tim O'Brien [mailto:tobr...@discursive.com] Sent: Tuesday, April 27, 2010 10:34 AM To: Maven Developers List Subject: Re: Central repository in settings.xml Arnaud, I run into situations where one project demands a complete different settings.xml than another. Assume you have a book project that deals with a separate repo manager and set of credentials vs. a tiny codehaus project with a separate repo man vs. an internal corporate project with different settings. I can't be the only one who is constantly having to either pass in the -s option or just swap out default settings.xml. Has anyone given any thought to the idea of different settings.xml files which would be activated by groupId? Assume I had three files: A. settings.xml B. settings-org-codehaus.xml C. settings-com-example.xml The idea would be that if I were working on a project with a groupId matching org.codehaus.** Maven would interpolate A - B, and if I were working on a project with a groupId matching com.example.** Maven would interpolate A - C. That and I'm sick of having to explain mirror configuration. I wish it were as simple as repomanhttp://localhost:8081/whatever/repoman, but I guess this all has to wait. Ok, I take that back, I really wish it were as simple as Maven sensing the presence of a repository manager via a multicast ping, but I'm fully prepared for someone to tell me that this is the worst idea anyone has ever come up with on this list. 2010/4/27 Arnaud Héritier aherit...@gmail.com: It could be better but far from perfect. Few users are reading this file and are using it to create their own. I think they are often copying it from the page you pointed. There are several annoying things about settings from my point of view but we won't be able to change before a 3.x : - We cannot use properties in mirror url (if we want to switch between several mirrors with different profiles) - We don't have inheritence or mix-in capacity to share some part of them and to split env related settings (repo, mirrors, ..) from personal settings (credentials) Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net On Tue, Apr 27, 2010 at 2:16 AM, Brian Fox bri...@infinity.nu wrote: I assume you want to make it easier for people to get the correct settings? Moving it from the super pom could have unexpected side effects, but what if we put the default boiler plate[1] configuration for that into the default settings.xml commented out? I think this would solve the main visibility problem without affecting runtime. [1] http://www.sonatype.com/books/nexus-book/reference/maven-sect-single- group.html#ex-maven-nexus-simple On Mon, Apr 26, 2010 at 6:41 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Paul Gier wrote: Would there be any problems if the central repo definition was moved out of the Maven internals and into the default settings.xml [1]? I assume you refer to the global settings file shipped inside the Maven installation directory. The one issue I know about is that embedders of Maven like M2E don't have a CLI-style installation directory and hence no global settings file. Not impossible to solve but it needs to be considered. Benjamin --- -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Central repository in settings.xml
You can't deploy to different repos via the same repo manager though On 27 April 2010 15:43, Thiessen, Todd (Todd) tthies...@avaya.com wrote: I think you can already do what you are asking with a repo manager. If you need to communicate to 3 different repos, then those repos should all be controlled through the repo manager. One of the repos could be public (ie: like an org) and another could be private (like a com). Your settings.xml file would then just point to the one repo manager which grouped the three repos into a single group. Nexus has a routing feature [1] which I believe (if I understand your needs correctly) will allow you to do what your asking for. [1] http://www.sonatype.com/books/nexus-book/reference/config-sect-managing-routes.html -Original Message- From: Tim O'Brien [mailto:tobr...@discursive.com] Sent: Tuesday, April 27, 2010 10:34 AM To: Maven Developers List Subject: Re: Central repository in settings.xml Arnaud, I run into situations where one project demands a complete different settings.xml than another. Assume you have a book project that deals with a separate repo manager and set of credentials vs. a tiny codehaus project with a separate repo man vs. an internal corporate project with different settings. I can't be the only one who is constantly having to either pass in the -s option or just swap out default settings.xml. Has anyone given any thought to the idea of different settings.xml files which would be activated by groupId? Assume I had three files: A. settings.xml B. settings-org-codehaus.xml C. settings-com-example.xml The idea would be that if I were working on a project with a groupId matching org.codehaus.** Maven would interpolate A - B, and if I were working on a project with a groupId matching com.example.** Maven would interpolate A - C. That and I'm sick of having to explain mirror configuration. I wish it were as simple as repomanhttp://localhost:8081/whatever/repoman, but I guess this all has to wait. Ok, I take that back, I really wish it were as simple as Maven sensing the presence of a repository manager via a multicast ping, but I'm fully prepared for someone to tell me that this is the worst idea anyone has ever come up with on this list. 2010/4/27 Arnaud Héritier aherit...@gmail.com: It could be better but far from perfect. Few users are reading this file and are using it to create their own. I think they are often copying it from the page you pointed. There are several annoying things about settings from my point of view but we won't be able to change before a 3.x : - We cannot use properties in mirror url (if we want to switch between several mirrors with different profiles) - We don't have inheritence or mix-in capacity to share some part of them and to split env related settings (repo, mirrors, ..) from personal settings (credentials) Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net On Tue, Apr 27, 2010 at 2:16 AM, Brian Fox bri...@infinity.nu wrote: I assume you want to make it easier for people to get the correct settings? Moving it from the super pom could have unexpected side effects, but what if we put the default boiler plate[1] configuration for that into the default settings.xml commented out? I think this would solve the main visibility problem without affecting runtime. [1] http://www.sonatype.com/books/nexus-book/reference/maven-sect-single- group.html#ex-maven-nexus-simple On Mon, Apr 26, 2010 at 6:41 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Paul Gier wrote: Would there be any problems if the central repo definition was moved out of the Maven internals and into the default settings.xml [1]? I assume you refer to the global settings file shipped inside the Maven installation directory. The one issue I know about is that embedders of Maven like M2E don't have a CLI-style installation directory and hence no global settings file. Not impossible to solve but it needs to be considered. Benjamin --- -- 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 - To unsubscribe,
RE: Central repository in settings.xml
But isn't settings.xml only related to artifacts that are downloaded, not deployed? Deployment of artifacts to a repo I believe goes in the pom. -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Tuesday, April 27, 2010 11:09 AM To: Maven Developers List Subject: Re: Central repository in settings.xml You can't deploy to different repos via the same repo manager though On 27 April 2010 15:43, Thiessen, Todd (Todd) tthies...@avaya.com wrote: I think you can already do what you are asking with a repo manager. If you need to communicate to 3 different repos, then those repos should all be controlled through the repo manager. One of the repos could be public (ie: like an org) and another could be private (like a com). Your settings.xml file would then just point to the one repo manager which grouped the three repos into a single group. Nexus has a routing feature [1] which I believe (if I understand your needs correctly) will allow you to do what your asking for. [1] http://www.sonatype.com/books/nexus-book/reference/config-sect-managin g-routes.html -Original Message- From: Tim O'Brien [mailto:tobr...@discursive.com] Sent: Tuesday, April 27, 2010 10:34 AM To: Maven Developers List Subject: Re: Central repository in settings.xml Arnaud, I run into situations where one project demands a complete different settings.xml than another. Assume you have a book project that deals with a separate repo manager and set of credentials vs. a tiny codehaus project with a separate repo man vs. an internal corporate project with different settings. I can't be the only one who is constantly having to either pass in the -s option or just swap out default settings.xml. Has anyone given any thought to the idea of different settings.xml files which would be activated by groupId? Assume I had three files: A. settings.xml B. settings-org-codehaus.xml C. settings-com-example.xml The idea would be that if I were working on a project with a groupId matching org.codehaus.** Maven would interpolate A - B, and if I were working on a project with a groupId matching com.example.** Maven would interpolate A - C. That and I'm sick of having to explain mirror configuration. I wish it were as simple as repomanhttp://localhost:8081/whatever/repoman, but I guess this all has to wait. Ok, I take that back, I really wish it were as simple as Maven sensing the presence of a repository manager via a multicast ping, but I'm fully prepared for someone to tell me that this is the worst idea anyone has ever come up with on this list. 2010/4/27 Arnaud Héritier aherit...@gmail.com: It could be better but far from perfect. Few users are reading this file and are using it to create their own. I think they are often copying it from the page you pointed. There are several annoying things about settings from my point of view but we won't be able to change before a 3.x : - We cannot use properties in mirror url (if we want to switch between several mirrors with different profiles) - We don't have inheritence or mix-in capacity to share some part of them and to split env related settings (repo, mirrors, ..) from personal settings (credentials) Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net On Tue, Apr 27, 2010 at 2:16 AM, Brian Fox bri...@infinity.nu wrote: I assume you want to make it easier for people to get the correct settings? Moving it from the super pom could have unexpected side effects, but what if we put the default boiler plate[1] configuration for that into the default settings.xml commented out? I think this would solve the main visibility problem without affecting runtime. [1] http://www.sonatype.com/books/nexus-book/reference/maven-sect-single - group.html#ex-maven-nexus-simple On Mon, Apr 26, 2010 at 6:41 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Paul Gier wrote: Would there be any problems if the central repo definition was moved out of the Maven internals and into the default settings.xml [1]? I assume you refer to the global settings file shipped inside the Maven installation directory. The one issue I know about is that embedders of Maven like M2E don't have a CLI-style installation directory and hence no global settings file. Not impossible to solve but it needs to be considered. Benjamin --- -- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional
Re: Central repository in settings.xml
server specific setting and proxy details go into settings.xml you might need to use a different proxy to deploy to a specific repo you might need to use different server credentials esp if you have two different projects which have decided to use the same server-id for different servers On 27 April 2010 16:14, Thiessen, Todd (Todd) tthies...@avaya.com wrote: But isn't settings.xml only related to artifacts that are downloaded, not deployed? Deployment of artifacts to a repo I believe goes in the pom. -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Tuesday, April 27, 2010 11:09 AM To: Maven Developers List Subject: Re: Central repository in settings.xml You can't deploy to different repos via the same repo manager though On 27 April 2010 15:43, Thiessen, Todd (Todd) tthies...@avaya.com wrote: I think you can already do what you are asking with a repo manager. If you need to communicate to 3 different repos, then those repos should all be controlled through the repo manager. One of the repos could be public (ie: like an org) and another could be private (like a com). Your settings.xml file would then just point to the one repo manager which grouped the three repos into a single group. Nexus has a routing feature [1] which I believe (if I understand your needs correctly) will allow you to do what your asking for. [1] http://www.sonatype.com/books/nexus-book/reference/config-sect-managin g-routes.html -Original Message- From: Tim O'Brien [mailto:tobr...@discursive.com] Sent: Tuesday, April 27, 2010 10:34 AM To: Maven Developers List Subject: Re: Central repository in settings.xml Arnaud, I run into situations where one project demands a complete different settings.xml than another. Assume you have a book project that deals with a separate repo manager and set of credentials vs. a tiny codehaus project with a separate repo man vs. an internal corporate project with different settings. I can't be the only one who is constantly having to either pass in the -s option or just swap out default settings.xml. Has anyone given any thought to the idea of different settings.xml files which would be activated by groupId? Assume I had three files: A. settings.xml B. settings-org-codehaus.xml C. settings-com-example.xml The idea would be that if I were working on a project with a groupId matching org.codehaus.** Maven would interpolate A - B, and if I were working on a project with a groupId matching com.example.** Maven would interpolate A - C. That and I'm sick of having to explain mirror configuration. I wish it were as simple as repomanhttp://localhost:8081/whatever/repoman, but I guess this all has to wait. Ok, I take that back, I really wish it were as simple as Maven sensing the presence of a repository manager via a multicast ping, but I'm fully prepared for someone to tell me that this is the worst idea anyone has ever come up with on this list. 2010/4/27 Arnaud Héritier aherit...@gmail.com: It could be better but far from perfect. Few users are reading this file and are using it to create their own. I think they are often copying it from the page you pointed. There are several annoying things about settings from my point of view but we won't be able to change before a 3.x : - We cannot use properties in mirror url (if we want to switch between several mirrors with different profiles) - We don't have inheritence or mix-in capacity to share some part of them and to split env related settings (repo, mirrors, ..) from personal settings (credentials) Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net On Tue, Apr 27, 2010 at 2:16 AM, Brian Fox bri...@infinity.nu wrote: I assume you want to make it easier for people to get the correct settings? Moving it from the super pom could have unexpected side effects, but what if we put the default boiler plate[1] configuration for that into the default settings.xml commented out? I think this would solve the main visibility problem without affecting runtime. [1] http://www.sonatype.com/books/nexus-book/reference/maven-sect-single - group.html#ex-maven-nexus-simple On Mon, Apr 26, 2010 at 6:41 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Paul Gier wrote: Would there be any problems if the central repo definition was moved out of the Maven internals and into the default settings.xml [1]? I assume you refer to the global settings file shipped
Re: maven-archetype-plugin 2.0-beta-5 and Central
I just created a cli tool using code from nexus-archetype-plugin, and updated the central archetype catalog with latest central index The nexus-archetype-plugin is open sourced: http://scm.sonatype.org/repobrowser.svn?path=/trunk/revision=HEADname=Nexus-plugins I will clean up the cli code and publish it. On Mon, Mar 29, 2010 at 12:28 AM, Jason van Zyl ja...@sonatype.com wrote: We already have all the code because this is what we integrated into the Maven Shell. I'll find all the pointers and send them to you. On Mar 28, 2010, at 9:00 AM, Hervé BOUTEMY wrote: Le dimanche 28 mars 2010, Jason van Zyl a écrit : Question: how to update it? Run crawl Mojo against Central once a day, for example? No, there will be no scanning of Maven Central. The best thing is to use the Nexus index like we do in M2Eclipse. Everything required is in the index and you can just make a Nexus index source which is far more efficient. Scanning just kills the performance of the machine and there aren't many windows of time anymore where Central isn't heavily used. Scanning simply isn't required anyway with the index. yes, far better approach for Central. I found Nexus Archetype Plugin code [1], with everything needed, thank you for the tip. Now the question is: where to add code, and how to add catalog generation after central index creation? Is there an extension point in repository-tools? Regards, Hervé [1] http://svn.sonatype.org/nexus-plugins/trunk/nexus-archetype- plugin/src/main/java/org/sonatype/nexus/plugins/mac/DefaultMacPlugin.java [2] http://svn.apache.org/viewvc/maven/repository-tools/trunk/ - 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 -- -- - juven
Re: Central repository in settings.xml
Ah, I forgot that it's defined in the super pom. I was thinking that it was in the code somewhere. I think adding the central repo to the default global settings would be a good start. Would it even need to be commented out? If it is defined in both places, I'm assuming that the one in the settings.xml take priority? Brian Fox wrote: I assume you want to make it easier for people to get the correct settings? Moving it from the super pom could have unexpected side effects, but what if we put the default boiler plate[1] configuration for that into the default settings.xml commented out? I think this would solve the main visibility problem without affecting runtime. [1] http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html#ex-maven-nexus-simple On Mon, Apr 26, 2010 at 6:41 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Paul Gier wrote: Would there be any problems if the central repo definition was moved out of the Maven internals and into the default settings.xml [1]? I assume you refer to the global settings file shipped inside the Maven installation directory. The one issue I know about is that embedders of Maven like M2E don't have a CLI-style installation directory and hence no global settings file. Not impossible to solve but it needs to be considered. Benjamin - 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
Re: Central repository in settings.xml
Benjamin Bentmann wrote: Paul Gier wrote: Would there be any problems if the central repo definition was moved out of the Maven internals and into the default settings.xml [1]? I assume you refer to the global settings file shipped inside the Maven installation directory. The one issue I know about is that embedders of Maven like M2E don't have a CLI-style installation directory and hence no global settings file. Not impossible to solve but it needs to be considered. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Right the global settings in the Maven install directory. I'm not sure what the current M2E behaviour is, but it should probably look for a user ~/.m2/settings.xml and ship with a default one in case it can't find a user settings. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Central repository in settings.xml
You can deploy to different repos via a single repo manager (and a single URL) if those repos are hosted on a single server. We're doing that currently with Nexus where the destination repository is determined by the groupId. Maybe you meant you can't deploy to different servers via the same repo manager? Stephen Connolly wrote: You can't deploy to different repos via the same repo manager though On 27 April 2010 15:43, Thiessen, Todd (Todd) tthies...@avaya.com wrote: I think you can already do what you are asking with a repo manager. If you need to communicate to 3 different repos, then those repos should all be controlled through the repo manager. One of the repos could be public (ie: like an org) and another could be private (like a com). Your settings.xml file would then just point to the one repo manager which grouped the three repos into a single group. Nexus has a routing feature [1] which I believe (if I understand your needs correctly) will allow you to do what your asking for. [1] http://www.sonatype.com/books/nexus-book/reference/config-sect-managing-routes.html -Original Message- From: Tim O'Brien [mailto:tobr...@discursive.com] Sent: Tuesday, April 27, 2010 10:34 AM To: Maven Developers List Subject: Re: Central repository in settings.xml Arnaud, I run into situations where one project demands a complete different settings.xml than another. Assume you have a book project that deals with a separate repo manager and set of credentials vs. a tiny codehaus project with a separate repo man vs. an internal corporate project with different settings. I can't be the only one who is constantly having to either pass in the -s option or just swap out default settings.xml. Has anyone given any thought to the idea of different settings.xml files which would be activated by groupId? Assume I had three files: A. settings.xml B. settings-org-codehaus.xml C. settings-com-example.xml The idea would be that if I were working on a project with a groupId matching org.codehaus.** Maven would interpolate A - B, and if I were working on a project with a groupId matching com.example.** Maven would interpolate A - C. That and I'm sick of having to explain mirror configuration. I wish it were as simple as repomanhttp://localhost:8081/whatever/repoman, but I guess this all has to wait. Ok, I take that back, I really wish it were as simple as Maven sensing the presence of a repository manager via a multicast ping, but I'm fully prepared for someone to tell me that this is the worst idea anyone has ever come up with on this list. 2010/4/27 Arnaud Héritier aherit...@gmail.com: It could be better but far from perfect. Few users are reading this file and are using it to create their own. I think they are often copying it from the page you pointed. There are several annoying things about settings from my point of view but we won't be able to change before a 3.x : - We cannot use properties in mirror url (if we want to switch between several mirrors with different profiles) - We don't have inheritence or mix-in capacity to share some part of them and to split env related settings (repo, mirrors, ..) from personal settings (credentials) Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net On Tue, Apr 27, 2010 at 2:16 AM, Brian Fox bri...@infinity.nu wrote: I assume you want to make it easier for people to get the correct settings? Moving it from the super pom could have unexpected side effects, but what if we put the default boiler plate[1] configuration for that into the default settings.xml commented out? I think this would solve the main visibility problem without affecting runtime. [1] http://www.sonatype.com/books/nexus-book/reference/maven-sect-single- group.html#ex-maven-nexus-simple On Mon, Apr 26, 2010 at 6:41 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Paul Gier wrote: Would there be any problems if the central repo definition was moved out of the Maven internals and into the default settings.xml [1]? I assume you refer to the global settings file shipped inside the Maven installation directory. The one issue I know about is that embedders of Maven like M2E don't have a CLI-style installation directory and hence no global settings file. Not impossible to solve but it needs to be considered. Benjamin --- -- 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
Re: Central repository in settings.xml
Different server credentials is not a problem since you just associate each cred with an ID. Unless for some reason you are defining a single repository ID for multiple deployment URLs. Multiple proxies would require separate settings, but I wouldn't think this is a common use case. If it is common, I guess proxies should be put into profiles. Stephen Connolly wrote: server specific setting and proxy details go into settings.xml you might need to use a different proxy to deploy to a specific repo you might need to use different server credentials esp if you have two different projects which have decided to use the same server-id for different servers On 27 April 2010 16:14, Thiessen, Todd (Todd) tthies...@avaya.com wrote: But isn't settings.xml only related to artifacts that are downloaded, not deployed? Deployment of artifacts to a repo I believe goes in the pom. -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Tuesday, April 27, 2010 11:09 AM To: Maven Developers List Subject: Re: Central repository in settings.xml You can't deploy to different repos via the same repo manager though On 27 April 2010 15:43, Thiessen, Todd (Todd) tthies...@avaya.com wrote: I think you can already do what you are asking with a repo manager. If you need to communicate to 3 different repos, then those repos should all be controlled through the repo manager. One of the repos could be public (ie: like an org) and another could be private (like a com). Your settings.xml file would then just point to the one repo manager which grouped the three repos into a single group. Nexus has a routing feature [1] which I believe (if I understand your needs correctly) will allow you to do what your asking for. [1] http://www.sonatype.com/books/nexus-book/reference/config-sect-managin g-routes.html -Original Message- From: Tim O'Brien [mailto:tobr...@discursive.com] Sent: Tuesday, April 27, 2010 10:34 AM To: Maven Developers List Subject: Re: Central repository in settings.xml Arnaud, I run into situations where one project demands a complete different settings.xml than another. Assume you have a book project that deals with a separate repo manager and set of credentials vs. a tiny codehaus project with a separate repo man vs. an internal corporate project with different settings. I can't be the only one who is constantly having to either pass in the -s option or just swap out default settings.xml. Has anyone given any thought to the idea of different settings.xml files which would be activated by groupId? Assume I had three files: A. settings.xml B. settings-org-codehaus.xml C. settings-com-example.xml The idea would be that if I were working on a project with a groupId matching org.codehaus.** Maven would interpolate A - B, and if I were working on a project with a groupId matching com.example.** Maven would interpolate A - C. That and I'm sick of having to explain mirror configuration. I wish it were as simple as repomanhttp://localhost:8081/whatever/repoman, but I guess this all has to wait. Ok, I take that back, I really wish it were as simple as Maven sensing the presence of a repository manager via a multicast ping, but I'm fully prepared for someone to tell me that this is the worst idea anyone has ever come up with on this list. 2010/4/27 Arnaud Héritier aherit...@gmail.com: It could be better but far from perfect. Few users are reading this file and are using it to create their own. I think they are often copying it from the page you pointed. There are several annoying things about settings from my point of view but we won't be able to change before a 3.x : - We cannot use properties in mirror url (if we want to switch between several mirrors with different profiles) - We don't have inheritence or mix-in capacity to share some part of them and to split env related settings (repo, mirrors, ..) from personal settings (credentials) Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net On Tue, Apr 27, 2010 at 2:16 AM, Brian Fox bri...@infinity.nu wrote: I assume you want to make it easier for people to get the correct settings? Moving it from the super pom could have unexpected side effects, but what if we put the default boiler plate[1] configuration for that into the default settings.xml commented out? I think this would solve the main visibility problem without affecting runtime. [1] http://www.sonatype.com/books/nexus-book/reference/maven-sect-single - group.html#ex-maven-nexus-simple On Mon, Apr 26, 2010 at 6:41 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Paul Gier wrote: Would there be any problems if the central repo definition was moved out of the Maven internals and into the default settings.xml [1]? I assume you refer to the global settings file
Re: Central repository in settings.xml
Brian Fox wrote: 2010/4/27 Arnaud Héritier aherit...@gmail.com: It could be better but far from perfect. Few users are reading this file and are using it to create their own. I think they are often copying it from the page you pointed. There are several annoying things about settings from my point of view but we won't be able to change before a 3.x : - We cannot use properties in mirror url (if we want to switch between several mirrors with different profiles) - We don't have inheritence or mix-in capacity to share some part of them and to split env related settings (repo, mirrors, ..) from personal settings (credentials) I think mirrors should be able to be defined inside of (settings) profiles. That would make it easier to deal with moving from location to location. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org It seems like the complex mirror settings is really just a workaround for the issue of repositories being added to the build by dependencies [1]. If Maven disabled this by default I think most people wouldn't need to define any mirrors. You would just define the repositories that you wanted in the correct order and be done. [1]http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Central repository in settings.xml
On 27 April 2010 19:46, Paul Gier pg...@redhat.com wrote: Different server credentials is not a problem since you just associate each cred with an ID. Unless for some reason you are defining a single repository ID for multiple deployment URLs. or in the case I described where you are working on multiple projects (which you don't control) amd they have decided to use the same server id e.g. server Multiple proxies would require separate settings, but I wouldn't think this is a common use case. If it is common, I guess proxies should be put into profiles. Stephen Connolly wrote: server specific setting and proxy details go into settings.xml you might need to use a different proxy to deploy to a specific repo you might need to use different server credentials esp if you have two different projects which have decided to use the same server-id for different servers On 27 April 2010 16:14, Thiessen, Todd (Todd) tthies...@avaya.com wrote: But isn't settings.xml only related to artifacts that are downloaded, not deployed? Deployment of artifacts to a repo I believe goes in the pom. -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Tuesday, April 27, 2010 11:09 AM To: Maven Developers List Subject: Re: Central repository in settings.xml You can't deploy to different repos via the same repo manager though On 27 April 2010 15:43, Thiessen, Todd (Todd) tthies...@avaya.com wrote: I think you can already do what you are asking with a repo manager. If you need to communicate to 3 different repos, then those repos should all be controlled through the repo manager. One of the repos could be public (ie: like an org) and another could be private (like a com). Your settings.xml file would then just point to the one repo manager which grouped the three repos into a single group. Nexus has a routing feature [1] which I believe (if I understand your needs correctly) will allow you to do what your asking for. [1] http://www.sonatype.com/books/nexus-book/reference/config-sect-managin g-routes.html -Original Message- From: Tim O'Brien [mailto:tobr...@discursive.com] Sent: Tuesday, April 27, 2010 10:34 AM To: Maven Developers List Subject: Re: Central repository in settings.xml Arnaud, I run into situations where one project demands a complete different settings.xml than another. Assume you have a book project that deals with a separate repo manager and set of credentials vs. a tiny codehaus project with a separate repo man vs. an internal corporate project with different settings. I can't be the only one who is constantly having to either pass in the -s option or just swap out default settings.xml. Has anyone given any thought to the idea of different settings.xml files which would be activated by groupId? Assume I had three files: A. settings.xml B. settings-org-codehaus.xml C. settings-com-example.xml The idea would be that if I were working on a project with a groupId matching org.codehaus.** Maven would interpolate A - B, and if I were working on a project with a groupId matching com.example.** Maven would interpolate A - C. That and I'm sick of having to explain mirror configuration. I wish it were as simple as repomanhttp://localhost:8081/whatever/repoman, but I guess this all has to wait. Ok, I take that back, I really wish it were as simple as Maven sensing the presence of a repository manager via a multicast ping, but I'm fully prepared for someone to tell me that this is the worst idea anyone has ever come up with on this list. 2010/4/27 Arnaud Héritier aherit...@gmail.com: It could be better but far from perfect. Few users are reading this file and are using it to create their own. I think they are often copying it from the page you pointed. There are several annoying things about settings from my point of view but we won't be able to change before a 3.x : - We cannot use properties in mirror url (if we want to switch between several mirrors with different profiles) - We don't have inheritence or mix-in capacity to share some part of them and to split env related settings (repo, mirrors, ..) from personal settings (credentials) Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net On Tue, Apr 27, 2010 at 2:16 AM, Brian Fox bri...@infinity.nu wrote: I assume you want to make it easier for people to get the correct settings? Moving it from the super pom could have unexpected side effects, but what if we put the default boiler plate[1] configuration for that into the default settings.xml commented out? I think this would solve the main visibility problem without affecting runtime. [1]
Re: Maven performance
Hi Jason, Jason van Zyl wrote: Jörg, If you are going to use the maven-eclipse-plugin as your benchmark I think it's going to be very hard to pin point where the bottleneck is. It's a little universe unto itself. Could be the shared components, resolution code, the plugin itself. I see vast improvements in speed in Maven 3.x. I don't think you can use the maven-eclipse-plugin as the basis for measuring improvement. For example there is behavior in Maven 3.x that is more correct which may contribute to some slow down and that we're just going to have to live with. Well, it is an indication. Running a plugin that makes a lot usage of the Maven infrastructure does tell more than a build including compilation task and packaging time. From 2.0.8 to 2.2.1 there have been also changes to ensure more correct behaviour, but performance got worse. To be honest, I was positively surprised by M3 ;-) However, Arnaud's remark for Linux is also interesting. As one user suggested it may be wise to provide execution timings for the core and individual plugins and phases. For example if you found that Maven's execution time remained constant over all versions of Maven where it was the maven-eclipse-plugin that varied then we know it's an interaction problem with the plugin and you can go from there. Yes, that would be the best approach for a first examination in more detail. I'm not close enough to the Maven core, but isn't it possible to exchange the Plexus component that executes the mojos with a delegate that measures the time for each execution? Is there some kind of Plexus configuration that can be used to injected such a component from the outside e.g. with the m2.conf or with system properties? Or use a profiler and find out where the actual problem is and tell us. A profiler gets interesting if you already can put a finger onto some part with such a complex application. We've done lots of profiling to get Maven 3.x and M2E running faster. But gigantic plugins like m-e-p and the assembler plugin will probably have problems entirely their own. Actually I was really impressed by the memory footprint. Especially since it is a necessity e.g. with the Eclipse plugin to generate all Eclipse projects at once to get these projects linked. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release some Maven Archetypes
Hi, I want to release Maven Archetypes parent pom - maven-archetype-bundles version 4- and some Maven Archetypes: - maven-archetype-plugin version 1.1 - maven-archetype-plugin-site version 1.1 - maven-archetype-quickstart version 1.1 - maven-archetype-site version 1.1 - maven-archetype-site-simple version 1.1 Staging repo: https://repository.apache.org/content/repositories/maven-028/ Site: http://maven.apache.org/archetype/maven-archetype-bundles/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here is my +1 Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-archetype-plugin 2.0-beta-5 and Central
Just a question: will use central catalog, or the catalog got from the _roor_ of defined reposes? In other word: will mirrorOf affect from where is catalog pulled? Asking, since initially when I talked to Raphael wrt nexus-archetype-plugin, the main reason why this plugin put the catalog in the root of reposes was exactly this: transparently publish archetypes to users Juven: good work! We have now all archetypes present in central enlisted! Thanks, ~t~ On Sun, Mar 28, 2010 at 12:18 AM, Hervé BOUTEMY herve.bout...@free.frwrote: Hi, I'm working on Maven Archetype Plugin, helped by Raphael who explained me lots of things (thank you Raphael). maven-archetype-plugin 2.0-beta-5 will use Central catalog as default instead of internal. But this catalog is actually empty [1]. Question: how to update it? Run crawl Mojo against Central once a day, for example? Regards, Hervé [1] http://repo1.maven.org/maven2/archetype-catalog.xml - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
