Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] "artifact.reference" in metadata as a result of mirror call

interesting! Thanks Ian,

so it turns out that http://download.eclipse.org/technology/subversive/0.7/update-site/ has both the repo metadata and site.xml! I copied that dir to local http server, but mirroring from here mirror works fine - creates no "artifact.reference" properties.



On Tue, Dec 21, 2010 at 6:05 PM, Ian Bull <irbull@xxxxxxxxxxxxxxxxx> wrote:
IIRC, artifact.references (along with something called partial IUs) happen when you reference an update site. In these case, the site.xml doesn't have enough information to give us the full IUs, so we create partial ones instead (and when the full one is needed, we do a full download of the artifact and parse the feature.xml).

When you mirror, these references (which look like update sites), are likely being mirrored too.

cheers,
ian


2010/12/21 Jacek Pospychała <jacek.pospychala@xxxxxxxxx>

thanks Ian,
I looked into metadata again and now I think I see the reason. Earlier I was looking into artifacts.xml only, assuming that mirroring is as simple as artifacts.xml->artifacts.xml and content.xml->content.xml. But it turns out that there's something unusual in content.xml affects that affects my artifacts.xml. SVN's repo content.xml contains this:

  <references size='4'>
    <repository uri='http://download.eclipse.org/technology/subversive/0.7/update-site/' url="" href="http://download.eclipse.org/technology/subversive/0.7/update-site/" target="_blank">http://download.eclipse.org/technology/subversive/0.7/update-site/' type='0' options='0'/>
    <repository uri='http://download.eclipse.org/tools/gef/updates/releases' url="" href="http://download.eclipse.org/tools/gef/updates/releases" target="_blank">http://download.eclipse.org/tools/gef/updates/releases' type='1' options='1'/>
    <repository uri='http://download.eclipse.org/tools/gef/updates/releases' url="" href="http://download.eclipse.org/tools/gef/updates/releases" target="_blank">http://download.eclipse.org/tools/gef/updates/releases' type='0' options='1'/>
    <repository uri='http://download.eclipse.org/technology/subversive/0.7/update-site/' url="" href="http://download.eclipse.org/technology/subversive/0.7/update-site/" target="_blank">http://download.eclipse.org/technology/subversive/0.7/update-site/' type='1' options='0'/>
  </references>

I don't see this in another repositories, so I guess this forces creation of absolute references, yes?


What's the use case for having this references entry in repository's content.xml?
I'm going to ask SVN team to remove it so I'd like to know what exactly they'll loose :-)


 

On Tue, Dec 21, 2010 at 7:22 AM, Ian Bull <irbull@xxxxxxxxxxxxxxxxx> wrote:

This come from using 'raw' artifact descriptors.  Essentially you are using the exact same artifact descriptor as the one in the source repo, and those happened to specify artifact.references.

HTH
Ian

On 2010-12-06 1:09 AM, "Jacek Pospychała" <jacek.pospychala@xxxxxxxxx> wrote:
> Anyone know where 'artifact.reference' property usually comes from in
> metadata?
> And is it really possible that it caused p2.director to download using that
> link?
>
>
> I looked at svn repository artifacts.jar, but it looks very usual. I also
> looked into one of plugin jars, hoping that there's some p2.inf file, but
> didn't found anything like this. I believe that my environment wasn't
> changing recently, and only part that has changed was their repo...
>
>
> 2010/12/3 Jacek Pospychała <jacek.pospychala@xxxxxxxxx>
>
>> hi,
>> I'm mirroring some repository using ant mirror task. But recently, instead
>> of a local copy, I started getting "artifact.reference" entries in my mirror
>> metadata. Like this:
>>
>> <artifact classifier='osgi.bundle' id='org.eclipse.team.svn.help'
>> version='0.7.9.I20101203-1700'>
>> <properties size='1'>
>> <property name='download.size' value='2974696'/>
>> </properties>
>> <repositoryProperties size='1'>
>> <property name='artifact.reference' value='
>> http://download.eclipse.org/technology/subversive/0.7/update-site/plugins/org.eclipse.team.svn.help_0.7.9.I20101203-1700.jar'/
>> >
>> </repositoryProperties>
>> </artifact>
>>
>> My local mirror is required to speedup the builds, but due to the
>> references in metadata, artifacts are downloaded from orig. repository.
>>
>> My ant task call looks like this:
>>
>> <p2.mirror>
>>
>> <repository location="${localRepo}" append="true" />
>>
>> <source>
>>
>> <repository location="
>> http://download.eclipse.org/technology/subversive/0.7/update-site/" />
>>
>> <repository location="
>> http://community.polarion.com/projects/subversive/download/eclipse/2.0/update-site/
>> " />
>>
>> </source>
>>
>> <iu id="org.eclipse.team.svn.feature.group" version=""/>
>>
>> <iu id="org.eclipse.team.svn.mylyn.feature.group" version=""/>
>>
>> <iu id="org.polarion.eclipse.team.svn.connector.feature.group" version=""
>> />
>>
>> <iu id="org.polarion.eclipse.team.svn.connector.svnkit15.feature.group"
>> version=""/>
>>
>> <iu id="org.polarion.eclipse.team.svn.connector.svnkit16.feature.group"
>> version=""/>
>>
>> </p2.mirror>
>>
>>
>> This happens only for the SVN repo (
>> http://download.eclipse.org/technology/subversive/0.7/update-site). Using
>> the same process several other repos are being mirrored, but with no such
>> "artifact.reference" things.
>>
>>
>> Could someone explain where does this "artifact.reference" come from and
>> how to get rid of it?
>>
>>
>>
>> Jacek
>>
>>

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev



_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev




--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev



Back to the top