> This seems like a very specific use case. I think it's more > to the point to say that many people (including, I suspect, > 100% of Maven developers) use the same workstation to work on > projects which are deployed to different repositories, e.g. > apache, codehaus, <shudder> java.net, a corporate repository, > etc. It doesn't make sense to deploy an apache.org project to > the codehaus repository or vice versa. Nor do you want to > deploy corporate artifacts to the java.net repository. Thus, > artifact deployment/distribution is project-specific.
Sort of. What seems to happen is that artifacts will go through an incubation period on a particular repo before it gets migrated to a more central accessible repository. The feature content that the artifact offers remains largely the same. All that changes is the GAV and the repo it gets deployed to. So corporate artifacts can very much start on a corporate repo and then migrate to a more public one like java.net or central. That seems to be a fairly common scenario in fact. Thus I definately could see an argument for putting distribution management in the settings.xml file. Particularly in a corporate environment where you are deploying to a local repository and the location of that repo may change. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
