You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benjamin Bentmann <be...@udo.edu> on 2010/05/03 12:10:44 UTC
Metadata Integrity on Central
Hi,
somehow related to my previous question about the checksums, what are
our chances to automatically detect and fix bad maven-metadata.xml's
deployed to Central like seen in [0]?
Benjamin
[0] http://jira.codehaus.org/browse/MEV-658
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Metadata Integrity on Central
Posted by Paul Gier <pg...@redhat.com>.
Good point, it's probably a bad idea to add a pom that contains any dependencies
or other information that would affect the build of a project using the
dependency. Although I think it would be safe to add information like project
url, description, and license if those are available since those would not
affect builds.
Brian Fox wrote:
> Possibly if we introduce a pom that has the exact internal model maven
> generates when it can't find one. This could cause some issues for
> people who have their own versions of those poms.
>
> On Mon, May 3, 2010 at 2:05 PM, Paul Gier <pg...@redhat.com> wrote:
>> Jason van Zyl wrote:
>>> On May 3, 2010, at 12:10 PM, Benjamin Bentmann wrote:
>>>
>>>> Hi,
>>>>
>>>> somehow related to my previous question about the checksums, what are our chances to automatically detect and fix bad maven-metadata.xml's deployed to Central like seen in [0]?
>>>>
>>> While the content of the POMs is not something we can't really change, the information about what artifacts exist I believe is something we can fix.
>>>
>> I agree that we can't change content of any existing poms. But can we add a
>> basic pom where there is none? For example, I noticed that this artifact does
>> not have any pom.
>>
>> http://repo2.maven.org/maven2/ws-commons/policy/1.0/
>>
>>> I suppose the only downside is we might potentially change the results someone is getting if they are using ranges. But ranges are used so infrequently, and it really is undefined right now whether you would deploy something with this range resolved or resolve against a repository with fixed versions (more like OSGi). I think we could probably correct the metadata with very little, if any, harmful impact.
>>>
>>> This is one area where I would likely side on changing the contents in Maven Central. But how it's changed is another question.
>>>
>>> We could simply run over it with Nexus and fix it all. But if it's not fixed at the source the cat will just come back. I think a real solution involves something Brian and I have been talking about for a while where project registers for ownership of a groupId. We could suggest fixes which can be accepted and then tracking to any changes to this metadata would also need to be recorded.
>>>
>>>> Benjamin
>>>>
>>>>
>>>> [0] http://jira.codehaus.org/browse/MEV-658
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>> ---------------------------------------------------------
>>>
>>> Selfish deeds are the shortest path to self destruction.
>>>
>>> -- The Seven Samuari, Akira Kurosawa
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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: Metadata Integrity on Central
Posted by Brian Fox <br...@infinity.nu>.
Possibly if we introduce a pom that has the exact internal model maven
generates when it can't find one. This could cause some issues for
people who have their own versions of those poms.
On Mon, May 3, 2010 at 2:05 PM, Paul Gier <pg...@redhat.com> wrote:
> Jason van Zyl wrote:
>> On May 3, 2010, at 12:10 PM, Benjamin Bentmann wrote:
>>
>>> Hi,
>>>
>>> somehow related to my previous question about the checksums, what are our chances to automatically detect and fix bad maven-metadata.xml's deployed to Central like seen in [0]?
>>>
>>
>> While the content of the POMs is not something we can't really change, the information about what artifacts exist I believe is something we can fix.
>>
>
> I agree that we can't change content of any existing poms. But can we add a
> basic pom where there is none? For example, I noticed that this artifact does
> not have any pom.
>
> http://repo2.maven.org/maven2/ws-commons/policy/1.0/
>
>> I suppose the only downside is we might potentially change the results someone is getting if they are using ranges. But ranges are used so infrequently, and it really is undefined right now whether you would deploy something with this range resolved or resolve against a repository with fixed versions (more like OSGi). I think we could probably correct the metadata with very little, if any, harmful impact.
>>
>> This is one area where I would likely side on changing the contents in Maven Central. But how it's changed is another question.
>>
>> We could simply run over it with Nexus and fix it all. But if it's not fixed at the source the cat will just come back. I think a real solution involves something Brian and I have been talking about for a while where project registers for ownership of a groupId. We could suggest fixes which can be accepted and then tracking to any changes to this metadata would also need to be recorded.
>>
>>> Benjamin
>>>
>>>
>>> [0] http://jira.codehaus.org/browse/MEV-658
>>>
>>> ---------------------------------------------------------------------
>>> 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
>> ---------------------------------------------------------
>>
>> Selfish deeds are the shortest path to self destruction.
>>
>> -- The Seven Samuari, Akira Kurosawa
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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: Metadata Integrity on Central
Posted by Paul Gier <pg...@redhat.com>.
Jason van Zyl wrote:
> On May 3, 2010, at 12:10 PM, Benjamin Bentmann wrote:
>
>> Hi,
>>
>> somehow related to my previous question about the checksums, what are our chances to automatically detect and fix bad maven-metadata.xml's deployed to Central like seen in [0]?
>>
>
> While the content of the POMs is not something we can't really change, the information about what artifacts exist I believe is something we can fix.
>
I agree that we can't change content of any existing poms. But can we add a
basic pom where there is none? For example, I noticed that this artifact does
not have any pom.
http://repo2.maven.org/maven2/ws-commons/policy/1.0/
> I suppose the only downside is we might potentially change the results someone is getting if they are using ranges. But ranges are used so infrequently, and it really is undefined right now whether you would deploy something with this range resolved or resolve against a repository with fixed versions (more like OSGi). I think we could probably correct the metadata with very little, if any, harmful impact.
>
> This is one area where I would likely side on changing the contents in Maven Central. But how it's changed is another question.
>
> We could simply run over it with Nexus and fix it all. But if it's not fixed at the source the cat will just come back. I think a real solution involves something Brian and I have been talking about for a while where project registers for ownership of a groupId. We could suggest fixes which can be accepted and then tracking to any changes to this metadata would also need to be recorded.
>
>> Benjamin
>>
>>
>> [0] http://jira.codehaus.org/browse/MEV-658
>>
>> ---------------------------------------------------------------------
>> 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
> ---------------------------------------------------------
>
> Selfish deeds are the shortest path to self destruction.
>
> -- The Seven Samuari, Akira Kurosawa
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Metadata Integrity on Central
Posted by Jason van Zyl <ja...@sonatype.com>.
On May 3, 2010, at 12:10 PM, Benjamin Bentmann wrote:
> Hi,
>
> somehow related to my previous question about the checksums, what are our chances to automatically detect and fix bad maven-metadata.xml's deployed to Central like seen in [0]?
>
While the content of the POMs is not something we can't really change, the information about what artifacts exist I believe is something we can fix.
I suppose the only downside is we might potentially change the results someone is getting if they are using ranges. But ranges are used so infrequently, and it really is undefined right now whether you would deploy something with this range resolved or resolve against a repository with fixed versions (more like OSGi). I think we could probably correct the metadata with very little, if any, harmful impact.
This is one area where I would likely side on changing the contents in Maven Central. But how it's changed is another question.
We could simply run over it with Nexus and fix it all. But if it's not fixed at the source the cat will just come back. I think a real solution involves something Brian and I have been talking about for a while where project registers for ownership of a groupId. We could suggest fixes which can be accepted and then tracking to any changes to this metadata would also need to be recorded.
>
> Benjamin
>
>
> [0] http://jira.codehaus.org/browse/MEV-658
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------
Selfish deeds are the shortest path to self destruction.
-- The Seven Samuari, Akira Kurosawa