If we don't require it then people simply won't populate it even when it could be done.
There will always be a manual way to get artifacts through a process into central if they don't meet the requirements that would have to be judged on a case by case basis. I think that a significant majority of the artifacts in central do in fact come from some place with a valid public scm url. The edge cases will have to follow a slower manual process to get into the repo. We have a whole parallel thread going about the quality of information in central, we won't improve that without raising the bar, which this does. On Tue, Sep 29, 2009 at 3:34 PM, Jason van Zyl <ja...@sonatype.com> wrote: > > On 2009-09-29, at 2:14 PM, Jesse McConnell wrote: > >> there are certainly benefits to having it in place, I wonder about the >> scm metadata suffering from bit rot over time as project juggle around >> stuff in their scm's though.. >> >> kind of throws a monkey wrench into the materialization process for >> projects or dependencies >> > > This is a problem that Maven has tried to solve in one form with > relocations, but any decent project is going to attempt to provide > redirection itself if it actually cares. > > To not put the information is because we think it's going to be hard to > maintain over time is not an argument for not putting it in. > >> jesse >> >> -- >> jesse mcconnell >> jesse.mcconn...@gmail.com >> >> >> >> On Tue, Sep 29, 2009 at 16:06, Jason van Zyl <ja...@sonatype.com> wrote: >>> >>> On 2009-09-29, at 1:56 PM, John Casey wrote: >>> >>>> Hi, >>>> >>>> I've been having a conversation with Jason and some others lately about >>>> the repository plugin, and the fact that it doesn't require the SCM >>>> section >>>> of the POM. POMs with this section missing disable the project >>>> materialization features that some of the more recent Maven tooling >>>> (m2eclipse in my personal experience) takes advantage of. >>>> >>> >>> And just as importantly that the build could actually be replicated from >>> the >>> information in the deployment. Materialization is one great benefit, but >>> knowing where the source of the artifact came from is actually more >>> important. It should be a requirement in my opinion. >>> >>>> Materialization is a HUGE benefit to developers, as I can testify. IMO, >>>> no >>>> OSS project should publish a POM for upload that doesn't specify an SCM >>>> location...it's insane to even pretend you have a project without an >>>> SCM, >>>> and if it's an OSS project, that SCM should probably have a public view. >>>> I'm >>>> not sure of the ins and outs of all OSS licensing, or whether a publicly >>>> available SCM is required for these licenses, but there is a clear >>>> benefit >>>> to having that access. >>>> >>>> I've filed http://jira.codehaus.org/browse/MREPOSITORY-19 to address >>>> what >>>> Jason and I both consider a shortcoming, but I also noticed >>>> http://jira.codehaus.org/browse/MREPOSITORY-2, which originally took >>>> this >>>> requirement out of the plugin. Can we say that the use case driving that >>>> decision is obsolete? >>>> >>>> I'm also working on another approach, a "disableMaterialization" flag >>>> that >>>> would allow the bundling to proceed in spite of missing SCM information. >>>> However, this is probably over-engineering if we can agree that SCM >>>> information should be present for anything hosted in central. >>>> >>>> Thoughts? >>>> >>>> -john >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>> ---------------------------------------------------------- >>> >>> >>> --------------------------------------------------------------------- >>> 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, Apache Maven > http://twitter.com/jvanzyl > ---------------------------------------------------------- > > > --------------------------------------------------------------------- > 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
