You can turn a quality of something to be a requirement only if that something can be verified at any given time. How about <scm></scm>? Would you accept this? Not bbecause you want to verify that you can connect to the server? What if the server is down because of maintenance? Or it is behind a firewall? Acceptance verification should be automated as much as possible to avoid the human error.
On Tue, Sep 29, 2009 at 5:53 PM, Brian Fox <[email protected]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
