I agree with Jörg. <scm> is just another "required" information, which helps nothing but it may lead to corruption. OSS projects should be allowed to protect their version control server with a firewall. Many <scm>-s of different artifacts, with the same ip address of 192.168... would be ugly and confusing. If the source bundle is there, (bonus if that is "buildable"), then it is still a 100% correct OSS release.
On Tue, Sep 29, 2009 at 4:33 PM, Jörg Schaible <[email protected]> wrote: > 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. >> >> 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? > > IMHO this requirement is a bad idea. There are quite some artifacts that can > be used and distributed, but that do not provide source code or provide the > source as tarball only (no public SCM available). Central is not only for > downloading artifacts, it has also a normative role regarding groupdId and > artifactId. As prominent example, a lot of javax.XXX artifacts would not > have been added with such a policy (even the POMs). As result you will get > even more artifacts that differ in their groupId/artifactId although the > artifact itself is the same. > > - Jörg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
