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]
