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
