I will also add that since the primary use case of this plugin is to produce bundles for central, that if this turns out to be a complete mess, we can decide to change or reduce the requirement. I do however think we should try and see how it works out. If the number of exceptions becomes unmanageable, you can bet we'll act to solve it.
On Tue, Sep 29, 2009 at 3:42 PM, Brian Fox <[email protected]> wrote: > 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 <[email protected]> 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 >>> [email protected] >>> >>> >>> >>> On Tue, Sep 29, 2009 at 16:06, Jason van Zyl <[email protected]> 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: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> Thanks, >>>> >>>> Jason >>>> >>>> ---------------------------------------------------------- >>>> Jason van Zyl >>>> Founder, Apache Maven >>>> http://twitter.com/jvanzyl >>>> ---------------------------------------------------------- >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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] >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> ---------------------------------------------------------- >> >> >> --------------------------------------------------------------------- >> 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]
