You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Casey <jd...@commonjava.org> on 2009/09/29 22:56:38 UTC
Repository Plugin: Should SCM be Required??
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Repository Plugin: Should SCM be Required??
Posted by Gilles Scokart <gs...@gmail.com>.
There is no requirements for open sources project to offer access to a
repository : http://www.opensource.org/docs/osd
So recommending it is good, but make it mandatory would be excessive.
Gilles Scokart
Re: Repository Plugin: Should SCM be Required??
Posted by Albert Kurucz <al...@gmail.com>.
I agree with Brett, Gilles, Daniel.
Gilles, thanks for that reference, I think we should all learn from that!
On Wed, Sep 30, 2009 at 7:49 AM, Daniel Kulp <dk...@apache.org> wrote:
>
> I agree with Brett. Strongly recommend, but not require.
>
> Dan
>
>
> On Wed September 30 2009 12:57:34 am Brett Porter wrote:
>> 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: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Repository Plugin: Should SCM be Required??
Posted by Daniel Kulp <dk...@apache.org>.
I agree with Brett. Strongly recommend, but not require.
Dan
On Wed September 30 2009 12:57:34 am Brett Porter wrote:
> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Repository Plugin: Should SCM be Required??
Posted by Brett Porter <br...@apache.org>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Repository Plugin: Should SCM be Required??
Posted by Albert Kurucz <al...@gmail.com>.
I agree with Jörg.
<scm> is just another "required" information, which helps nothing but
it may lead to corruption.
OSS projects should be allowed to protect their version control server
with a firewall.
Many <scm>-s of different artifacts, with the same ip address of
192.168... would be ugly and confusing.
If the source bundle is there, (bonus if that is "buildable"), then it
is still a 100% correct OSS release.
On Tue, Sep 29, 2009 at 4:33 PM, Jörg Schaible <jo...@gmx.de> wrote:
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Repository Plugin: Should SCM be Required??
Posted by Jörg Schaible <jo...@gmx.de>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Repository Plugin: Should SCM be Required??
Posted by Albert Kurucz <al...@gmail.com>.
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 <br...@infinity.nu> 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 <br...@infinity.nu> 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 <ja...@sonatype.com> 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
>>>> jesse.mcconnell@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>>
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder, Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> ----------------------------------------------------------
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ----------------------------------------------------------
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Repository Plugin: Should SCM be Required??
Posted by Brian Fox <br...@infinity.nu>.
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 <br...@infinity.nu> 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 <ja...@sonatype.com> 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
>>> jesse.mcconnell@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ----------------------------------------------------------
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Repository Plugin: Should SCM be Required??
Posted by Brian Fox <br...@infinity.nu>.
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 <ja...@sonatype.com> 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
>> jesse.mcconnell@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ----------------------------------------------------------
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Repository Plugin: Should SCM be Required??
Posted by Jason van Zyl <ja...@sonatype.com>.
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.mcconnell@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Repository Plugin: Should SCM be Required??
Posted by Brian Fox <br...@infinity.nu>.
I think having it even if over time it rots, is better than having
nothing to start with. Bottom line is that we will want this in
central and will look to automate enforcement, so the bundle plugin
should line up with that process to simplify life for everyone.
On Tue, Sep 29, 2009 at 2:14 PM, Jesse McConnell
<je...@gmail.com> 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
>
> jesse
>
> --
> jesse mcconnell
> jesse.mcconnell@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Repository Plugin: Should SCM be Required??
Posted by Jesse McConnell <je...@gmail.com>.
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
jesse
--
jesse mcconnell
jesse.mcconnell@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Repository Plugin: Should SCM be Required??
Posted by Jason van Zyl <ja...@sonatype.com>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org