I think any rule needs to be enforced on the server side as much as in
the repository plugin too.
For mine, I think strongly recommending SCM is a good idea, but we do
allow artifacts that are redistributable and not open source and so it
should not be required. If you were to get fancy you could tighten the
requirement for those that specify an open source license.
You might also consider an associated source bundle in the repository
a suitable replacement for the SCM element?
Anyway, strongly recommending/defaulting is one thing, but I wouldn't
get into the practice of rejecting things that don't provide it.
- Brett
On 30/09/2009, at 6:56 AM, 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?
-john
---------------------------------------------------------------------
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]
